MVSFORUMS.com

[tempuser]

Hi,
There is a job which is having 5 stpes.The first step with a program(say x) creates 2 files and then the next 2 stpes are SORT steps.the 4th and 5 th steps again creates 2 diffrent reports with 2 diffrent programs by using the SORT'ed (2 nd and 3 rd sort steps) o/p files.

Now our requireent is to combine all these steps into a sinlge stp thru a COBOL program.The basic idea here is to remove the SORT conditions.

Here are the sample details.

The input file is a VSAM file and based on few conditions we create 2 flat files.
Let's say the 2 flat files are of FB with the below.
File -1

AAA 123 X
BBB 234 Y
CCC 123 X
DDD 135 Y

file-2
CCC 123456 xyz
DDD 234567 klm
EEE 123456 xyz

Now in the second step we are SORTing the file-1 on second column and in 3 rd SORT step we are sorting on third column.The 4 step uses the 2 nd sort out file and creates a report.The same way the 5 th step create a report using 3 rd sorted o/p file form step 3.

The final o/p files from the step 4 and step 5 will come like below.

4 th :

AAA 123 X
CCC 123 X
DDD 135 Y
BBB 234 Y

5 th:
CCC 123456 xyz
EEE 123456 xyz
DDD 234567 klm

Can anybody give some idea how to achive this one in a single step.
I am having an option to use multiple programs with internal calling.
Like I can use the CALL <program> in the X program.

Thanks
Tempuser

[CICS Guy]

One input, two intermediate and two reports?

COBOL internal SORT:
Read input...
Add an extra identifier for the two outputs, selecting for one or the other or both...
If needed, add additional keys for the sort...
Upon the extra identifier, use fro one report or the other....
Do-able....

Need more info?

[dbzTHEdinosauer]

Though the number of Steps in the job will be reduced, is this such long running job (5 steps) that it is worth exchanging the 5 obvious (and probably simple) steps to the complexity of one monster program which will be harder to maintain than the 5 simple steps?

is the extract criteria so complex that the 1st program could not be replaced with enhanced sort 2 and 3? sort can read vsam. code the INCLUDE parms and you have your sorted output without the need of pgm 1.

is the report format so complex that you can't use sorts report building capabilities? If you did that you would only need two steps and nothing else.

If you just gotta write a monster program, have it read the two sort outputs and CALL modified versions of pgm's 4 and 5. Pgms 4 and 5 would be gutted. I/O removed to new control pgm. Pgm 4 and 5 would be passed the record image.

So instead of having one new monster program scenario to replace 5 steps, that by the way work, think about using the extract and report building capabilites of sort. If the extract criteria or the reporting criteria is really, really complex then you can use the user exits capabiliites of either DFSORT or SYNCSORT.

• If DFSORT, then you have Frank, Kolusu and many others on this board to help.
• If SYNCSORT, then you have Alissa, Kolusu and many others on this board to help.

Thus you would reduce the Job from 5 to 2 steps - without increasing the sort volume.

If some yoyohead hands you garbage about the possibility of changing sort products, this can't be the only job in your system that uses sort.

you are looking at the possibility of generating control cards for a pair of sort steps in a few days, as apposed to the development time of a new monster module - which based on your original question will take you definitely more than a few days to develop. (and that is after you figure out what to do).

In addition, there is a higher cost to debugging a COBOL internal sort than debugging a complex sort. The Frank's and Alissa's will always be around (they support the SORT product), but the original developer of the Monster Double Internal COBOL Sort and Report program (MDICSRAP) may not always be available to your shop. That is a pro-argument for management. The trade of complexity of a one program solution to the simple-to-analyze-and-change-control-cards solution is BEST PRACTICE. If these are large volume sorts, combining them will make it a single double-large volume sort.

Agreed, an experienced sr. programmer/analyst (if he choose to accept this assignment) could write/debug/install/DOCUMENT this monster program within a couple of weeks. Actually, the job is easy - if you are experienced and understand what is involved. But if you don't, you are talking about a real-pain-in-the-butt debugging project, as well as the fact that this is not a Best Practice to reduce steps in a job with a higher volume sort and complex program.

sorry about the preaching, it's Sunday!
_________________
Dick Brenholtz
American living in Varel, Germany

[dbzTHEdinosauer]

[edkir98]

Given the current situation the best option would be
1) Execute the first X program
2) Use COBOL sort for the 1st file
3) Use COBOL sort for the 2nd file
4) Open the output of the 1st sort file and do the report process
5) Open the output of the 2nd sort file and do the report process
Although this process is bound to be less effective than using the JCL sort, given this situation only this could be effective.
_________________
Thanks

[kolusu]