On 13 Feb 2007 19:28:48 -0800, in bit.listserv.ibm-main
(Message-ID:<[EMAIL PROTECTED]>)
[EMAIL PROTECTED] (Paul Jodlowski) wrote:
I have a wierd problem, a programmer runs a job that
creates a dsn (tst.report) then he ftp's it down to a
server and then uncat/deletes it.
Later on he runs the job again expecting the dsn
(tst.report) to be empty.
AND IT SHOULD BE. Well it's not in fact it has the same
data as the first run. I go to 3.4 screen an try to
browse the dataset but it says it is empty. I even ran a
IEBGENER and i showed the data???? (of cource we DID NOT
run the uncat/delete step) This is all done on the same
volume (userb4) and it is NOT sms-managed. In fact We
don't HAVE any SMS-managed data sets. We are running of
z/os v1r7.
I've hit this, before. This "feature" goes 'way
back. I first hit some variation of it more than 25 years
back.
It's caused when the new allocation is in the same
exact spot as the old (deleted) allocation was. This is
not rare enough.
Some programs (such as ISPF's 3.4) notice that the
VTOC's pointer to the last record (I forget its name, but
it ends with STAR) is zero. No records means an empty
dataset, therefore it won't show any data.
Most other programs (such as IEBGENER) will read
until it hits an EOF.
If you did have this under SMS management, you
wouldn't have the problem. When the system allocates a PS
dataset on SMS dasd, it immediately writes an EOF. You can
see recent threads for details on exactly when this does
and doesn't happen.
--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" com
----------------------------------------------------------------------
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
