Cobol - Giving empty files

Author

Giving empty files

Howard Brazee

2004-04-27, 12:30 pm

Has anybody ever had occasional problems in an IBM mainframe environment reading
empty files created by a COBOL GIVING statement?

I've been running a test job over and over again (that deletes the file, creates
it with a CoBOL sort program, and then reads it with another CoBOL program).
Sometimes the return status is '10' when I read the file. Sometimes it is a
'00' with garbage read (I could gener this empty file to a new file and it found
data that I couldn't see by browsing it), and sometimes it aborts with a '30'
error status when reading.

No consistency.

One time I edited this empty file copied in data. The abend was because it
read this old record despite the file being deleted with the IEFBR14 below.:

Step #01 deletes this file.
Step #02 is a CoBOL sort that is creating an empty file using a GIVING file but
no data found. It does check for sort status.
Step #04 is a CoBOL program that opens and reads this empty file, sometimes
giving '00' return code (and data that should be deleted), sometimes '10', and
sometimes aborting with '30'.

//MPCM$#01 EXEC PGM=IEFBR14 ************ CLEAN-UP FILES
//FINDFILE DD DSN=&SYSTEM..MPCMTMP1.&APP.&CAMPUS..FINDER,
// DISP=(MOD,DELETE),SPACE=(TRK,0)
//MPCM$#02 EXEC PGM=SIPR856
// ****************************************
*******
//* EXTRACT STUDENTS WITH DEBIT BALANCE *
// ****************************************
*******
//STEPLIB DD DSN=UMS.PROD.LOAD,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
// DD DSN=IDMS.SYSTEM&SYSNUM..LOADLIB,DISP=SHR
// DD DSN=IDMS.&VER..LOADLIB,DISP=SHR
//SYSIDMS DD DSN=UMS.PROD.DATA(SI&SYSNUM.&MODE),DISP=SHR
//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,15,,CONTIG)
//SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,15,,CONTIG)
//SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,15,,CONTIG)
//SYSOUX DD SYSOUT=&PRTB2
//PARMFL DD DSN=&USER1,
// DISP=SHR
//FINDOUT DD DSN=&SYSTEM..MPCMTMP1.&APP.&CAMPUS..FINDER,
// DISP=(NEW,CATLG,CATLG),
// UNIT=&UNIT,
// SPACE=(CYL,(24,12),RLSE),
// DCB=(RECFM=FB,LRECL=80,DSORG=PS)
//SYSDBOUT DD SYSOUT=&PRTB1
//SYSOUT DD SYSOUT=&PRTB2
//MPCM$#03 EXEC PGM=IEFBR14 ************ CLEAN-UP FILES
//FINDFILE DD DSN=&SYSTEM..MPCMTMP2.&APP.&CAMPUS..FINDER,
// DISP=(MOD,DELETE),SPACE=(TRK,0)
//MPCM$#04 EXEC PGM=SIPR857
// ****************************************
*******
//* EXTRACT STUDENTS WITH DEBIT BALANCE *
// ****************************************
*******
//STEPLIB DD DSN=UMS.PROD.LOAD,DISP=SHR
// DD DSN=CEE.SCEERUN,DISP=SHR
// DD DSN=IDMS.SYSTEM&SYSNUM..LOADLIB,DISP=SHR
// DD DSN=IDMS.&VER..LOADLIB,DISP=SHR
//SYSIDMS DD DSN=UMS.PROD.DATA(SI&SYSNUM.&MODE),DISP=SHR
//SYSOUX DD SYSOUT=&PRTB2
//PARMFL DD DSN=&USER1,
// DISP=SHR
//FINDIN DD DSN=&SYSTEM..MPCMTMP1.&APP.&CAMPUS..FINDER,
// DCB=(RECFM=FB,LRECL=80,DSORG=PS),
// DISP=(OLD,KEEP,DELETE)
//FINDOUT DD DSN=&SYSTEM..MPCMTMP2.&APP.&CAMPUS..FINDER,
// DISP=(NEW,CATLG,CATLG),
// UNIT=&UNIT,
// SPACE=(CYL,(24,12),RLSE),
// DCB=(RECFM=FB,LRECL=80,DSORG=PS)
//SYSDBOUT DD SYSOUT=&PRTB2
//SYSOUT DD SYSOUT=&PRTB2
//EXCEPT DD SYSOUT=&PRTE1

William M. Klein

2004-04-27, 2:30 pm

Howard,
Have you tried running with NOFASTSRT?

At:
http://publibz.boulder.ibm.com/cgi-...3pg20/1.12.13.2

it explicitly talks about FASTSRT and COBOL Declaratives. I couldn't find
anything indicating that having a SORT statement where an "empty" file is
created (GIVING) is a problem with FASTSRT, but it might be.

Finally, can you "clarify" what you mean about

"SORT GIVING that wasn't run"

Do you mean that the COBOL SORT statement was never executed? (and that there
was no explicit OPEN of it in the program?) If so, what happens if you run just
the 1st and 3rd steps of your job? Certainly if the compiler is doing
"something" to the file when you never OPEN it and you never run the SORT, then
you are right that you have found a "bug" in the compiler. If, however, you get
the same results when you skip that middle step, then something else is going
on.

--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:c6m31t$op9$1@peabody.colorado.edu...
>
> On 27-Apr-2004, bsthomp@ibm-main.lst (CICS Guy) wrote:
>
>
> Yep. The file was created by a SORT GIVING that wasn't run. The compiler
> apparently opened the file but didn't close it. I can code around it, but
> this appears to me to be a compiler bug.
>
> I can't display the close, as there is no explicit close in a SORT GIVING.

Sponsored Links