<snip> I've also seen it done by accident. Part of the production run deletes and redefines a dataset (IEFBR14). Next, program 1 updates it, then program 2 reads it. One day, program 2 got the previous day's data. User tried again with same result. As it turned out, there was only the one area available to reallocate the dataset - right where it was, before. Program 1 had no data for that dataset, so it never opened and closed it, so there was no EOF written. Program 2 read the old data. <snip>
We had this exact problem with a payroll application from an outside vendor. Data from one user would be picked up by another user ... The problem was, as indicated, if the outputting program did not have any data then the temp dataset would be allocated but not opened or closed. Whatever was at that place on disk would be passed to the next step ... We had to set up a special IEBGENER job to do the allocation and force an EOF (SYSUT1 DD DUMMY) at the beginning of the data set. This pre-allocated data set would then be passed to the problem program. This assured that the data in the data set was either ligitimate or had a clear 'no data' indication. At the time I was curious about this whole thing and set up an assembler program to try try to 'harvest' data (in good hacker fashion) from the disk, just to see how possible it was. A: It was very possible. The program allocates a temp data set and then does a GL 'read' (recfm=U) and checks the residual count and outputs a 121 byte record: //INPUT DD DSN=&&TMP,DISP=(NEW,PASS),SPACE=(CYL,(10,1)), // UNIT=SYSDA,DCB=(RECFM=FB,LRECL=133,BLKSIZE=23408) The program is very crude (I will deny that I wrote it), but if anyone wants to test their own disk, sent me an email offline. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
