3) allocate a new data set and be sure that the DSORG is _not_ specified either in the JCL or via the DATACLAS, or that it is DA. This tells DADSM to _not_ write an EOF or anything else in the newly allocate disk space. If you need to "inspect" some specific tracks, _and the disk is not SMS managed_, then use ABSTR allocation. Once allocated, you can use BSAM or BDAM to read the data as RECFM=U to simply read the "uninterpreted" blocks of data (physical blocks).
Or, once allocated, you can use ADRDSSU to DUMP the tracks in HEX format. Again, you are simply "fishing" and hoping to see something "interesting". Back, long ago, I have a manager who did this for _every_ disk volume we ever installed just because he was curious. This was in the 3350 days. In today's environment where the back end is usually RAID 5, I would say the likelihood of someone getting one of the array drives, inspecting it, and finding proprietary information of any use is very unlikely. But if you have credit card data, or HIPAA data then it _might_ be a good idea for CYA. On Wed, Apr 9, 2014 at 9:27 AM, Storr, Lon A CTR USARMY HRC (US) < lon.a.storr....@mail.mil> wrote: > 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? > > Thanks, > Alan > > > > > Classification: UNCLASSIFIED > Caveats: NONE > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
