Because Wikipedia would not consider that a reliable source. What I need is a
published document that I can cite to justify the challenged footnote
" 1 Not true for CMS file system[2] on a CMS minidisk, TSS VAM-formatted
volume,[3]
z/OS Unix file systems[citation needed] or VSAM in IBM mainframes "
to
"As a general rule,[nb 1] formatting a disk by default leaves most if not
all existing data
on the disk medium; some or most of which might be recoverable with
privileged[nb 2]
or special tools.[4]"
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Mark Jacobs [00000224d287a4b1-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, May 19, 2020 10:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Does allocating an HFS or zFS erase all existing data?intervals
formatted?
Unless I'm totally off the mark here, why not go through this process (or
something like it) and see for yourself.
1) Use an empty 3390 volume.
2) Allocate a single PS dataset that takes up the entire volume.
3) Use IEBDG to write a known value to each block in the dataset.
4) Delete the dataset.
5) Allocate HSF and zFS datasets on the volume.
6) DFDSS (or other tool) to print the track contents in the allocated space.
7) Review output.
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
https://secure-web.cisco.com/1gFYwIxkr1KZghOPP0bmd9UCZ3A32F6aKyRlie071QEp6B8F4K5623W_ZThHbxX_9XjtAI51EmQ9VqQf6ftGgqa8RHkNUgQkupA2dcNYGPCDt6hjTWtXQmUgUhtrSHHZlbJlpusSRr-cqz27SDoB0auiltqFr6X0jamxG0gDa9X4vnUbwfQRrN6ZBsFsclp6TI8zlzKOCxB4jcXLIHe8sPvcS0QuUExDXarvaWIMKe46mi7YeFieyHxf_FaQL2FUshplNXeIwn-QQ6Tgt40GL3JTb9DGoVje-22LgV5w783cp7btfgseip0nl64JQdpJpKzZFs2RHMTAXLxouRfAahorTrMcGBxcZOG0gMEgbSf_8xgeOzCYJrDzc3VUIz3WRguaRh0vgG5kO5f2EK9iU-ZqFeQEK8_K8tIBrKpf0SBlIGosd0whdiKKOoUETBlSB/https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, May 19, 2020 9:30 AM, Seymour J Metz <sme...@gmu.edu> wrote:
> There is, or used to be, a common service used by VSAM and other components
> for data with CI-like formatting, including PDSE. If it still exists then I
> assume that it is also used for HFS. My prime concern was HFS and zFS, and I
> don't know whether SPEED/RECOVERY applies to linear, which zFS is based on.
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
> Mike Kerford-Byrnes [m...@hill-leys.com]
> Sent: Tuesday, May 19, 2020 8:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Does allocating an HFS or zFS erase all existing data?intervals
> formatted?
>
> From various manuals - and a lot of time spent with VSAM...
>
> A VSAM file is DEFINEd with an amount of space. This space is managed by
> VSAM as a set of Control Areas (CAs). The maximum size of a CA is 1
> Cylinder, and the minimum is one track.
>
> Each CA contains a number of Control Intervals (CIs), of fixed length,
> determined at DEFINE time. The last 4 bytes of a CI (the CIDF) contain
> information as to the occupancy of the CI (amount of unused space and its
> offset). A CIDF containing all zeros is known as a Software End Of File or
> SEOF. The CIDF of an EMPTY CI shows (CISIZ - 4) bytes available at offset
> 0.
>
> Records are stored in the CI (left to right) along with control information
> (3-byte 'RDF' stored right to left).
>
> Linear Datasets are different. They do not have any control information in
> the (mandatory) 4K CIs which are employed to store the data. As far as I
> can deduce, the only connection to VSAM is that it provides the vehicle to
> read and write 4K blocks of data to and from a disk and a catalog structure
> in which to hold relevant data about the file - name, size, volser etc.
> Although I have used a linear Dataset in the past (1994!) I have not
> researched it in any detail.
>
> When a file is DEFINEd, nothing happens to the tracks. Only when the file
> is loaded does anything happen.
>
> What happens depends on the choice of SPEED/RECOVERY at DEFINE time and the
> type of VSAM file.
>
> SPEED
>
> When SPEED is specified, records are loaded into each control interval,
> along with the RDF, and the CIDF is updated as each record is loaded. This
> continues across all relevant CIs until the load is complete. At CLOSE (and
> only then), the SEOF is written and the Catalog will show a value in the
> High Used RBA field.
>
> For ESDS and RRDS, the SEOF is written in the CI FOLLOWING the last occupied
> CI. All remaining CIs in the current CA are also formatted as EMPTY.
>
> For a KSDS, all remaining CIs in the CA are formatted as EMPTY, and the
> first CI in the NEXT CA is also formatted as SEOF (assuming space is
> available). The HURBA reflects the last byte in the CA that contains loaded
> data.
>
> RECOVERY
>
> When RECOVERY is specified (or defaulted), each CA is preformatted
> immediately prior to its load.
>
> For both ESDS and RRDS, each CI in the CA is formatted with SEOF.
>
> For a KSDS, All CIs in the CA are formatted as EMPTY and the first CI of the
> NEXT CA is also formatted as a SEOF (again assuming space is available).
>
> In all cases, the load of that CA proceeds updating each CI in turn.
>
> CLOSE will update the HURBA as per SPEED.
>
> The net of this is that, in the case of RECOVERY, if the load fails part-way
> through, there is a predictable format in the file structure such that a
> 'resume load' can be executed (that is if you have programmed one to start
> with!). There will always be a SEOF which identifies the last point at
> which data was loaded. This is identified when a subsequent OPEN, having
> detected a 'failed CLOSE', invokes the VERIFY function, which locates the
> SEOF, updates the catalog and then resumes the OPEN process with a 'clean'
> catalog. In the case of SPEED, there is no such support and you have to go
> back to the beginning and rerun. Although RECOVERY is the default, IBM
> recommend SPEED, since it is obviously a faster option.
>
> There is one 'gotcha' in this story. Once a file has been loaded (I.e. at
> least one record written, followed by a successful CLOSE), RECOVERY is
> operative, irrespective of the SPEED/RECOVERY option chosen at DEFINE time.
> So don't do what I have seen a couple of times - Open, load 1 control
> record, Close, followed by Open, load thousands of records, Close - under
> the misconception that SPEED is in effect throughout.
>
> Mike Kerford-Byrnes
>
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
