99% sure the answer is yes. I know it is possible to open a new dataset and ATTEMPT to read the data already on the tracks. My tests have tended to "fail" (so to speak) for the reason that I am not "trying" to read someone else's data, and the tests tend to fail on bad block size (if reading FB) or invalid RCW format (if reading VB). I suspect an attempt reading RECFM=U would succeed.
I think IBM's answer to the security issue is an erase feature. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of glen herrmannsfeldt Sent: Monday, January 22, 2007 12:13 AM To: [email protected] Subject: BLKSIZE=0 Charles Mills wrote: > 1. It IS on SMS DASD. This is not a theoretical problem -- it happens in > real life. The problem is ***not*** with DS1LSTAR or EOF markers. The > problem is that the BLKSIZE in the DSCB is zero, QSAM picks that up, puts it > in a CCW, falls on its face, and diagnoses the situation with a message that > it takes a CCW expert to decode -- rather than diagnosing an easily > diagnosable situation with a simple explanation. Is this a (relatively) new problem? As far as I know, OS/360 didn't allow BLKSIZE=0 so this should not happen. At some time later, the ability to specify BLKSIZE=0 was added, along with this problem. Also, is it still possible to open a new data set and read the existing data on the tracks? I know OS/360 would do it, but security requirements have changed since then. (I do remember once having the link editor read some data into SYSLIN that my program never wrote, and then processing it as control cards.) ---------------------------------------------------------------------- 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
