Need to move SORT statements from main procedure to subroutine(s)

[jgcarter56]

I need to move SORT statements from the main procedure of my code into one or more separate subroutines. I also need to remove the use of RETURN and RELEASE statements from the main procedure as well. How do I go about doing this? Should I create temporary files that contain the data that would have been RELEASED to the sort work file? Can I pass an SD in the linkage section? Can I write to an SD just as I would to an FD? If so, I wouldn't need a USING clause, would I? Even better, would it be possible to create a generic SORT subroutine that I could use to replace all of my specific SORT statements?

The SORT statements I'm currently working with are of the variety of SORT ... INPUT / OUTPUT PROCEDURE ...

Thanx for any help that anyone can provide.

 

[fredericofonseca]

operating system and cobol vendor and version please.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[jgcarter56]

IBM z/OS COBOL 3.2

 

[fredericofonseca]

as far as I know, but may be incorrect, you can not call a sub program to pass records to be released. That would mean you would need to write to a temp file, and then on the sort program do the SORT USING FILE-name instead of input-procedure.

the giving can be either a file or a output-procedure.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[jgcarter56]

Thanx, Frederico, for the info. I was kind of afraid of that but perhaps someone else can provide some more info.

 

[webrabbit]

You have to understand that the SORT verb is quit different from other COBOL functions. In every COBOL impementation that I have worked with (including IBM mainframe), SORT calls the sort utility, which then repeatedly calls rhe INPUT PROCEDURE. When the INPUT PROCEDURE issues the RELEASE statment, it exits to the sort utility. When the INPUT PROCEDURE exits (normal COBOL exit), the sort utility does the sort, then begins calling the OUTPUT PROCEDURE, with works the same way as the INPUT PROCEDURE except with the RETURN statement. When the INPUT PROCEDURE exits, the sort utility exits back to the COBOL program following the SORT statement.

When IBM mainframe assembler programs use SORT, the INPUT and OUTPUT PROCEDURES (if they exist) have to be separate callable programs. The sofware engineers who wrote the COBOL compiler and libraries had a lot of effort to make sort work with COBOL as it is actually a recursive call, which COBOL did not initially support.

 

[jgcarter56]

Webrabbit, that is correct; the RELEASE returns control back to the sort so that it can place the data into the sort work area and the RETURN returns control back to the sort so that the sort work area data can be retrieved. Does that sound correct?

So what it comes down to is that I will need to create a separate file that I write to instead of doing a RELEASE and use the SORT ... USING syntax instead of the SORT ... INPUT PROCEDURE syntax. Either that, or put all of the code that the SORT uses in the subprogram (i.e. the INPUT / OUTPUT procedures). I really want to have as little code as possible in the subprogram but, for performance reasons, I may need to do this.

 

[razalas]

Why do you want to move the sort into subroutines?

Are you trying to use the same sort input/output procedures for the same data just sorted in different ways? Since you are running in z/OS environment, can you just make your sort an indepedent step with different sort parms for each unique combination you are trying to achieve?

What are you really trying to accomplish?

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[jgcarter56]

What I'm really trying to accomplish is to move off of hand-coded COBOL to a model driven development system which generates COBOL but does not support the SORT statement. I know that I will still have to maintain hand-written COBOL but I want the amount of that COBOL to be as small as possible. So I have moved most of my COBOL code into the model already and I want to just call hand-coded subroutines to do the SORTs.

 

[papadba]

As you have been told elsewhere, it is not going to happen. . .

'Cause we're stuck with having to use the tools as delivered and not necessarily as we'd like

 

[webrabbit]

Is there a reason you can't use razals' suggestion? I have worked in shops that prohibit the use of COBOL sort, and other shops that prohibit the use of stand-alone sort. There is no logic to either rule, but it's not usuallly under our control.

 

[Crox]

a called module can open it's own files and perform it's own sort. The interface to the called module should contain instructions what to do (do-return, do-release) and on the first return, the called module can execute once the SORT statement before the first return.

So you simply replace the earlier sort related statements by a call to your called module that is going to do all sort-related actions.

about sharing a file between calling and called module, you can look up the possibility's for the EXTERNAL definition. EXTERNAL can not be used with a SD definition.

Perhaps also the use of a dynamic vsam file can help you to do the things you want.

 

[papadba]

Please re-read the entire topic.

So you simply replace the earlier sort related statements by a call to your called module that is going to do all sort-related actions.

Does not fit with the current design of the process.

 

[jgcarter56]

Crox,

Sounds like you are saying that you could code a subprogram that takes a parameter which tells it to RELEASE, SORT and/or RETURN. And then the calling program could do all of the other assorted logic that gets you to the point of doing a RELEASE, RETURN or SORT. Is that correct? But don't the RELEASE and RETURN only work when the input and output procedures are specified on the SORT statement? If that is the case, then you can only do a SORT in a subroutine if you include the input and output procedures in the subroutine as well.

 

[Crox]

Yes, it is possible.

Look at the syntax of the sort statment. You can write a sort statement on its own.

But without input or output procedures, you can not use release and return statemens, but you can use write and read statements instead and use a sort-statement without the procedures.

 

[papadba]

To specify USING and GIVING in the same SORT statement is a complete waste of resources. . .

If there is a need to have a "stand alone" sort, fine - but it sould not be done within the cobol code.

 

[Crox]

I need to move SORT statements from the main procedure..." that is not about optimized programs, that is about if something is possible....

If you want to use release and return in a called module on separate calls, then first you have to find out if the runtime environment closes the sort after a goback or exit program, yes or no. If the sort is not closed, it is possible by using not so common coding techniques to get it done by creating drop throughs (jump out of sections before the end of it, things like that) and that only works if the compiler generates no stacked code when performs are compiled.

Most of the company's have only one goal: creating software that is very easy to maintain. Many times the performance is not so important until it becomes very important, because the job takes longer than the available batch window at night or the response of an online transaction takes too long...

 

[papadba]

Crox,

What you propose (if i understand what you proposed) cannot be done. . .

The "pure COBOL" way to get even close is to call a module that specifies using/giving - which is a resource waste.

Many times the performance is not so important until it becomes very important

Unfortunately, this has become much more common in the last several years - kinda like working in Win-stuff (if it works at all go with it - we can always re-write it later).

However, this is no reason to implement proven poor design in the name of maintainability - good implementations are just as easy to maintain as "lazy" implementations that were chosen because the coder did not know/understand there was a better way or because the coder wanted to write the fewest lines of code.

Back to the performance quote - many everyday processes on large systems work in the hundreds of millions of records. Also unfortunately, these processes are often tested with only hundreds or thousands of input records and there is an ugly surprise when a full-volume run is made (as a test or the first "real" productoin run. Then it does get intense. . .