On Mon, 13 Jul 2009 09:30:48 +0200, Vernooij, CP - SPLXM wrote:
>> >
>> > From the z/OS V1.11 Preview,
>> >
>> >"In z/OS V1.11, DFSMSdfp processing is planned to be changed to indicate
>> >end-of-file (EOF) during the allocation of data sets on DASD that are not
>> >SMS-managed and have either sequential or an undefined data set
>organization."
>> >
>> "Indicate" is an interesting word.  It doesn't say it physically
>> writes an end-of-file.  Is this a logical rather than  physical
>> end-of-file.
>>
>> Is this for data security or convenience?  Can the residual
>> data still be read with EXCP?
>
>I think 'indicate' is the same method as for SMS datasets. AFAIK
>DS1LSTAR is set to zeros and the Acces Methods 'know' then that this is
>an empty dataset. These datasets can occupy 0 tracks, which is pysically
>impossible if a EOF was written in the dataset.
>
(From ancient experience and fading memory):

Even before SMS existed, DS1LSTAR was set to beginning-of-file
(Allocation wouldn't just leave the field uninitialized, would it?)
QSAM correctly reported EOF on the first read.  BPAM did not and
programs that didn't electively check DS1LSTAR read residual
data.  For a while, my circumvention was to allocate temporary
data sets with a primary extent of 0.  (This had undesirable
consequences with VIO.)

>Secondly, the EXCP question is similar to the 7 sysprogs and the
>ligthbulb (and please don't reply if there were 5 or 8): if you need to
>securely delete your data, delete it with the EREASE feature. Any other
>'delete' will leave the data on the track and is therefor unsecure. I
>can think of a dozen ways to read it.
>
Even ERASE might be ineffective with virtual disks; the overwriting
pattern might be written to different tracks.  Even the CMS MDFS
works that way.

-- gil

----------------------------------------------------------------------
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

Reply via email to