:>: -----Original Message----- :>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>: Behalf Of Storr, Lon A CTR USARMY HRC (US) :>: Sent: Wednesday, April 09, 2014 7:27 AM :>: To: IBM-MAIN@LISTSERV.UA.EDU :>: Subject: Accessing DASD areas that have no DSCB (UNCLASSIFIED) :>: :>: Classification: UNCLASSIFIED :>: Caveats: NONE :>: :>: Hello List, :>: :>: Due to an audit requirement, we shall be enabling the "ERASE" function :>: provided by RACF. We know better than to resist this mandate but it did :>: make me wonder about the purpose of this feature. :>: :>: When a dataset is deleted, it is scratched and its DSCB in the VTOC is :>: freed. Hence, as far as I know, the dataset's data can only be accessed :>: in one of two ways: :>: :>: 1) Via a utility like AMASPZAP that accepts CCHHR addresses :>: 2) Via a program that uses EXCPVR (or SSCH) :>: :>: In case #2, the program must be authorized in some way (i.e. key 0-7, :>: supervisor state or APF-authorized). :>: :>: In case #1, most installations (including us) use program protection to :>: restrict users of these utilities. A user would have to be authorized in :>: some way (i.e. key 0-7, supervisor state or APF-authorized) to bypass :>: that protection. :>: :>: It therefore seems to me that a user must have the ability to become :>: authorized in some way to access areas of DASD (in which a deleted :>: dataset resided) by CCHHR. A user who has become authorized in some way :>: can also access any live (undeleted) dataset. Why then are we worried :>: that a user who can access any live dataset in the system may attempt to :>: access a deleted dataset? :>: :>: If the aforementioned is true and complete, the "ERASE" functionality :>: doesn't appear to have any practical purpose other than to slow down the :>: scratch process. So, I assume that I'm missing something. :>: :>: Can someone please identify the flaw in my logic? Can a non-authorized :>: user gain access to these "scratched" areas of DASD?
As others have noted, there are multiple ways to gain access to previously occupied tracks. But there still can be a practical result from using ERASE. When you initialize a volume, do so without the SMS parameter. Then allocate one or more datasets to completely fill the volume. Delete the dataset(s) and let ERASE zero all the tracks. If necessary, CONVERT the volume to SMS. Make the volume available to users. From that point on, all unused space on the volume should always be zeroed. Note that this is not foolproof. On at least one old STK DASD system, when data is written to a "CKD track", the hardware automatically "remapped" that track to a different "FBA address". While a read always returned the current data, the old data was still physically present if anyone could figure out how to get to it. I don't know if any modern DASD systems do something similar. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
