Giving empty files

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

I've been running a test job over and over again (that deletes the file, cre
ates
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 f
ound
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', a
nd
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

Howard,
Have you tried running with NOFASTSRT?

At:
[url]http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg20/1.12.13.2[/url
]

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 the
re
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, t
hen
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 goin
g
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 compil
er
> apparently opened the file but didn't close it.    I can code around it, b
ut
> 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.