Caveats? COBOL SORT - USING and GIVING are same file

Dennis1SOIL · Posted: Fri Feb 05, 2010 11:11 pm

I inherited some COBOL code with this type of Statement:

SORT sorted-file ASCENDING KEY
field-1
field-2
WITH DUPLICATES IN ORDER
USING prebuilt-file <------I
GIVING prebuilt-file <----- I
. I<---- SAME prebuilt-file on both lines

Haven't found anything after initial searching in COBOL area/manuals ... can anyone comment about specifically why this type of coding might not be "the best idea"? -- I suspect there are likely several limitations associated with the convenience of this capability.

For instance:

-- I noticed the FASTSRT ability is not available when the USING file is the same as GIVING file.

...Other things to be aware of?

Thanks in advance,

-Dennis

CICS Guy · Posted: Fri Feb 05, 2010 11:32 pm

dick scherrer · Posted: Sat Feb 06, 2010 12:12 am

Hello and welcome to the forum,

IMHO, a cobol program should not use both USING and GIVING in the same SORT. . . As with everything, there is probably some exception. . . Most often this was coded using/giving because the coder was either lazy or because they were unable to use the better alternative.

Having an INPUT PROCEDURE and/or and OUTPUT PROCEDURE is more efficient with system resources.

If the only thing the program does is a using/giving sort, it should most likely an external sort.

Other than performance, a big drawback is that if there are problems, the input will have to be recreated as it will likely have been distroyed during the problem run (as CG mentioned before).

Dennis1SOIL · Posted: Sat Feb 06, 2010 1:36 am

Thanks Dick and CG !

In looking closely at this program I see the overall systems resources could certainly be improved by using INPUT and OUTPUT PROCEDUREs.

Things might get a bit complicated though ... as the program currently does two internal SORT operations.

Here is my next Question:
If I leave the SORTs being invoked by COBOL code - (and I think I should) - I want to know if I can specify an INPUT PROCEDURE for a second SORT within the OUTPUT PROCEDURE for a differnt SORT ?
(I searched some IBM COBOL manuals but have'nt found anything specifically addressing this -- maybe I'm missing some obvious thing which render my question silly).

Here is a very high-level description of what the program does:

-- While reading a really big file - it selects certain records and builds another (still large) file containing what I'll call "Detail Lines",
then ...

-- it Sorts the "Detail file"

then...
-- it reads the sorted Detail file while counting the number of record occurrences until any of the sort field values change - at that point it writes appropriate sub-total lines to a "Summary lines" output dataset.

then...
-- it sorts the "Summary lines" dataset by the counts in the sub-total fields so summary lines can be reported in descending "Ranking" order (e.g. showing which values in the original sort fields occur most often --- presented in descending order based on the number of detail records containing that value.)

-- So as I alluded to above - I'm mainly wanting to know if it's possible to be feeding records into a second SORT operation while the COBOL program is still in the process of RETURNing records from a first SORT operation.

? Second INPUT PROCEDURE in OUTPUT PROCEDURE of earlier SORT ?

-Dennis

dick scherrer · Posted: Sat Feb 06, 2010 1:50 am

Hello,

Only one SORT can be executing at a time.

You might get this done by GIVING the output of the first sort. . .

How much is a "really big file"?

Dennis1SOIL · Posted: Sat Feb 06, 2010 2:05 am

Thanks again Dick,

Could be several million record occurrences in the "Detail Lines" - each 133 bytes (sort of coincidence with length of print line). (This program can conceivably read archive tapes stretching back many months or even years).

I'm wondering if I were to write assembler sort exit(s) --- could that possibly open up a get around for the "only one SORT executing at a time" - in a given address space? ... or invoked from a given COBOL program?

(Not certain at this point if it would be worth the effort to get really fancy with writing SORT exits though).

.....

I think this question is probably mute now - but just because my inquiring mind still wants to know ....

My understanding is that the use of FASTSRT takes away the option of specifying //SORTWRK?? datasets as being on TAPE. (i.e I think DASD is required when FASTSRT is used).

Since the first SORT (in the program I mentioned earlier) would always be of a file containing many more record occurrences (the "Detail Lines" file) -- If GIVING and USING options where still used -- there could possibly be a need for SORT Work files to be on TAPE. However, most likely DASD would be fine for the sort of the reduced number of record occurrences in the "Summary Lines" file.

Here's my question (If I were not to go to using INPUT PROCEDURE):

If both SORTs can qualify for using FASTSRT, is there a way to direct the system such that only one SORT should use FASTSRT?

I notice FASTSRT is a Compiler option and I haven't seen any parameter to specify in the code itself.

(Sorry if I'm asking too many questions)

-Dennis

Frank Yaeger · Posted: Sat Feb 06, 2010 4:10 am

I'm not an expert on COBOL, so I'll just throw out a few random thoughts/responses:

We recommend that you NEVER use tape work data sets with DFSORT since they prevent DFSORT from using its most efficient techniques and from using many of its features.

The FASTSRT compiler option allows COBOL to use FASTSRT - it does NOT force it. COBOL decides whether or not FASTSRT can be used depending on the type of sort, parameters, etc being used. FASTSRT is just a way for COBOL to allow DFSORT to access the input and/or output files directly which can be beneficial since DFSORT's I/O is more efficient than COBOL I/O.

You might be able to call DFSORT from within an Assembler Ex5 exit.

You can certainly attach parallel DFSORT tasks from an Assembler program.

Dennis1SOIL · Posted: Sat Feb 06, 2010 4:57 am

Thanks Frank,

As I see things now (given the great answers from you guys), I'm thinking the least resource intensive way (during the execution of the job) for me to accomplish the objective would most likely involve some Assembler exit code to facilitate having the two SORTs executing at the same time.

--> Do you know whether there might be some place where I might look in hopes of finding sample code which attaches a parallel DFSORT process?

For the short term, I may not be up to the task of getting things working the ABSOLUTE BEST way - but I may at least change the USING and GIVING files to be different - as I am assuming even that may help some.

I wish I could use the INPUT PROCEDURE technique, however since the program invoking SORT is being called repeated by a Driver (earlier I simplified what actually happens - but I posted more detail in the COBOL forum) - and since it would need to RELEASE records during successive invocations, it appears the "INPUT PROCEDURE" phase is not going to be available (this time).

I think the general idea of what's going on might be somewhat common - especially for a common summarization type of thing. For instance I would think products like SAS, and/or Easytrieve, etc .. might be doing something similar --- i.e Ranking reports showing counts of record occurences containing the same values in given variable names.

I looked at the reporting capability in ICETOOL and I really like much of what is available there !- however I think I'm only allowed to specify one break field when using the DISPLAY and ON stuff.

Sorry if this is too cryptic ... let me know if I'm not making sense...

-Dennis

Frank Yaeger · Posted: Sat Feb 06, 2010 5:26 am

Yes, you can only use one break field with DISPLAY. Of course, you could reformat your records so one break field encompasses several contiguous fields.

You can use multiple break fields with the OUTFIL SECTIONS parameters.

Dennis1SOIL · Posted: Sat Feb 06, 2010 5:46 am

Sorry if I should be asking this elsewhere ... but I would like to put some actual parameters I used with ICETOOL into a post, along with a bit of the resulting report. However, I need to use a non-proportional font in order for the report data to retain the columnar allignment (as it appears on the mainframe).

Is there a way to tell this internet software to use such a specific font for the text in my post (e.g. maybe Courier New) ???

(Even though my profile says I can use HTML - under OPTIONS on this page it indicates HTML is OFF - and I don't see any way change it.)

-Dennis

Frank Yaeger · Posted: Sat Feb 06, 2010 5:51 am

You can use the ubb code tags.

<code>
this is my code.
</code>

but use [] instead of <>. It will look like this:

William Thompson · Posted: Sat Feb 06, 2010 5:55 am

Dennis1SOIL · Posted: Sat Feb 06, 2010 6:31 am

Thanks - yeah that "CODE" / ubb does what I was looking for!

When I mentioned the BREAK field I was talking about something like the following:

Frank Yaeger · Posted: Sat Feb 06, 2010 6:38 am

Dennis1SOIL · Posted: Sat Feb 06, 2010 7:03 am

Thanks Frank,

I need to spend a little time learning more about what OUTFIL offers!

-Dennis