Joined: 03 Feb 2007 Posts: 175 Location: PUNE(INDIA)
Thanks for your reply.
and about your doubt, the file MY-OUTPUT-FILE will not be empty. It would contain the records given by earlier part of program. So now I want it to be sorted within itself. So I guess, I can do it , the way I mentioned. right ?
Joined: 07 Nov 2005 Posts: 1105 Location: The Netherlands at Hole 19
Yep........the inputfile for a sort can be the outputfile too (both disp=shr). We often do this. The intermediate results are stored in the SORTWK's. Be aware though; if the sort failes your inputfile might get lost --> be empty So carefull with this logic and always take care of enough space for the SORTWK's.
Joined: 13 Dec 2005 Posts: 154 Location: The Netherlands
the file MY-OUTPUT-FILE will not be empty. It would contain the records given by earlier part of program
As mentioned above the input files is created in the earlier part of the pgm, so when the control comes to the sorting part of the Cobol pgm, the file is available as a shared one for the Sort process to happen, so Technically what u say is rite from the JCL prespective specifying disp as (,CATLG,DELETE) for the ds, but logically when it comes to the sort step (In cobol pgm), the data set is created by the previous part of the program and is available for sorting .
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix
While the earlier part of the program is creating the data to be sorted it does NOT need to write to MY-FILE. A better alternative for the program as described is to do the processing to create a data record, then RELEASE each record to the SORT. This is done in the INPUT PROCEDURE section of the COBOL program.
Please look in the COBOL manual if you are not familiar with sort optons other than using/giving. Here is a bit from the COBOL manual from this site:
The RELEASE statement transfers records from an input/output area to the
initial phase of a sorting operation.
The RELEASE statement can only be used within the range of an INPUT
PROCEDURE associated with a SORT statement.
It may take a short time to convert your code to use INPUT PROCEDURE but the things you would need to do are minor. Here is a little sample that i wrote earlier this week for a quick-n-dirty requirement. Because this was a one-time shot i did not check for successful sort completion and issue an error message if the sort failed (i was running this manually and would see if any problem occurred). For production jobs, i'd recommend checking SORT-RETURN for zero and issuing an appropriate message/condition code if the sort ever fails (this should be done for ANY internal sort that is in production code). My preference is to make the INPUT PROCEDURE a section (when there is processing on both sides of the sort, i also make my OUTPUT PROCEDURE a section.
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix
As the "using" file is created in this same program, recovering it shouldn't be an issue.
To re-iterate - with using/giving the data in that particular file will be written as the "real" input is processed, read back in by the sort, and written again coming out of the sort.
Even though we CAN do some things, it does NOT mean we should do them. As we're in a COBOL program there will code to be run before and/or after the data is sorted. For code that runs before the data is sorted, INPUT PROCEDURE should be used - for code that requires the data in sequence OUTPUT PROCEDURE should be used. If there is no processing on either side, the sort shouldn't be inside a COBOL program (i.e. using/giving has no need to be "inside" a program) . This, of course, assumes that we're interested in saving MANY, MANY machine resources versus a few minutes of programmer time. The code will be written once - the system resources will be used EVERY time the program is executed . . . Once someone gets into the bad habit of "using/giving" it is hard to break - once someone is confortable with input/output procedures, coding is as easy as using/giving. On the good news side, there are installations that are determined to conserve system resources and will not permit a program with using/giving in the code to be promoted to UAT or Production
Here is a bit from the Fine COBOL Manual available via this forum:
Use SORT . . . USING if you don't need to process the records in an input
file (or files) before they are released to the sort program. With SORT .
. . USING file-name, the compiler generates an input procedure to open the
file, read the records, release the records to the sort program, and close
The input file must not be open when the SORT statement begins execution.
If you want to process the records in the input file before they are
released to the sort program, use the INPUT PROCEDURE option of the SORT
Each input procedure must be contained in either paragraphs or sections.
For example, to release records from Working-Storage (a table) to the new
PERFORM WITH TEST AFTER
VARYING X1 FROM 1 BY 1 UNTIL X1 = 100
RELEASE SORT-WORK-2-AREA FROM TABLE-ENTRY (X1)
An input procedure contains code for processing records and releasing them
to the sort operation. You might want to use an input procedure to:
? Release data items to the new file from Working-Storage
? Release records that have already been read in elsewhere in the
? Read records from an input file, select or process them, and release
them to the new file.
Use SORT . . . GIVING if you want DFSORT to transfer the sorted records
directly from the sort work file into another file without any further
processing. With SORT . . . GIVING file-name, the compiler generates an
output procedure to open the file, return the records, write the records,
and close the file. At the time the SORT statement is executed, the file
named with the GIVING option must not be open.
If, however, you want to select, edit, or otherwise modify the sorted
records before writing them from the sort work file into another file, use
the OUTPUT PROCEDURE option of the SORT statement.
In the output procedure, you must use the RETURN statement to make each
sorted record available to your program (the RETURN statement for a sort
file is similar to a READ statement for an input file). Your output
procedure can then contain any statements necessary to process the records
that are made available, one at a time, by the RETURN statement.
You can use RETURN INTO, instead of RETURN, to return and process the
records into Working-Storage or to an output area. You can also use the
AT END and END-RETURN phrases with the RETURN statement. The imperative
statements on the AT END phrase will execute after all the records have
been returned from the sort file. The END-RETURN explicit scope
terminator serves to delimit the scope of the RETURN statement.
When you code output procedures, remember that each output procedure must
include at least one RETURN or RETURN INTO statement. Also, each output
procedure must be contained in either a section or a paragraph.
If you have any questions on this, please let me know.