Hi Rex,
A good while ago, on 3390 SLEDs, non-SMS, z/OS 1.4, I used this 'feature' fairly often . We had a big batch process that, on the monthly run would delete a large PS work dataset at eoj. For the quarterly, that same dataset needed to be used in a successor job. The monthly job ran about 12-14 hours. The 'responsible' (or not!) programmer was supposed to take care of the disposition of that big dataset for the quarterly process. A bunch of times (until that programmer left), I'd get in to work to find the monthly still running and a bunch of panicked messages. Sure enough, the disp on the dataset was delete. So, I would mount the vol private and map it. Watch the job and map it again each time it took an extent. No space release coded, so that helped. When the monthly ended, IEFBR14 absolute track allocate the pieces of the dataset, concatenating it all together back into 1 whole with IEBGENER. It was a nice tool to have at the time. :-) Saved a huge rerun to recreate the data set and a day of application outage for the customer. I have also seen the situation you wrote about. One fairly ugly one where bad data was picked up and feed into a database. Linda ----- Original Message ----- From: "Rex R. Pommier" <[email protected]> To: [email protected] Sent: Monday, March 12, 2012 11:53:37 AM Subject: Re: IEFBR14 Bill, You are absolutely correct in that this change doesn't really provide much security. I'm looking at it from a different aspect, that of removing one additional way of shooting oneself in the foot. If not you (you being collective, not just Bill), how many of your colleagues (either in the systems programming area or application developers/operations) have had a dataset deleted, only to have a new one allocated directly on top of the old one with a compatible set of DCB information, and have somebody inadvertently run a program that read the old data. I know it has happened more than once where I've worked over the years. I'm sure this change will result (and has resulted) in fewer holes in feet. :-) Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Fairchild Sent: Monday, March 12, 2012 11:09 AM To: [email protected] Subject: Re: IEFBR14 Writing an EOF record at the beginning of the data set does indeed "help prevent programs from reading old data when a data set is read immediately after being allocated", but the way it does this results in preventing the reading of old data only from the first track. If a program can read beyond this first track (which is not difficult to do even in an unauthorized program), then the program can still read all the rest of the old data in the allocated tracks. The only way truly to prevent a program from reading any of the old data is to erase each allocated track, either when the old data set is deleted or when the new data set is allocated. Erasing is a very expensive process in terms of DASD utilization and elapsed time, which is why it is almost never done. This is perhaps another example of "security through obscurity", which has been discussed lately under thread subjects starting with " Program FLIH backdoor ". I call it obscurity since getting beyond the first ! track deters most programs, but is not difficult if you know the "obscure" fact that it is quite easy to do if you want to. Bill Fairchild The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
