AFAIK the writing of an EOF in allocation is still a parmlib option and only occurs for SMS managed data sets.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Jesse 1 Robinson <[email protected]> Sent: Friday, August 9, 2019 12:08 AM To: [email protected] Subject: Re: CPU time cost of dynamic allocation Once upon a memorable time, a data set allocated in (say) an IEFRB14 step got a DSCB created complete with whatever DCB attributes were specified in JCL. However, the 'data' on disk had no actual format, so opening the data set would get some kind of I/O error. Unless, perhaps, the data on the track had previously been written by a real program, in which case the data would be 'readable' even though it was leftover garbage. So it was customary for an application to create a new empty data set with something like IEBGENER using dummy input just so that a later read operation on the empty file would get immediate EOF without error. Then MVS was changed to simulate an OPEN/CLOSE on a new allocation so that a later read would get immediate EOF. We don't even think about it today, but applications are simpler and less error prone without having to worry about the format of a newly allocated data set. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of CM Poncelet Sent: Thursday, August 8, 2019 6:46 PM To: [email protected] Subject: (External):Re: CPU time cost of dynamic allocation I mentioned "temp datasets" because Charles' post referred to them as such: On 08/08/2019 20:17, Charles Mills wrote: > I see > > IEF285I SYS19218.T143507.RA000.xxx00114.R0105346 PASSED > IEF285I SYS19218.T143507.RA000.xxx00114.R0105347 PASSED > IEF285I SYS19218.T143507.RA000.xxx00114.R0105348 PASSED > ... > > And > > IEF285I SYS19218.T143507.RA000.xxx00114.R0105346 DELETED > IEF285I SYS19218.T143507.RA000.xxx00114.R0105347 DELETED > IEF285I SYS19218.T143507.RA000.xxx00114.R0105348 DELETED > ... > > So it looks to me like DSCBs were actually created. > > Charles Meanwhile, yes, they (as temp datasets) are not actually catalogued - but are "PASSED" via the JFCB or JFCBX, or whatever similar else, to subsequent JCL steps. My argument was that datasets allocated via IEFBR14 are not *physically* allocated on DASD - and that this could be checked as per the example JCL and then cross-checked (after the IEFBR14) via ISPF "3.2" and "3.4". Yes, I did suggestDSORG=PS in my example JCL "// DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS)" OPENing such a dataset for READ (rather than WRITE) would probably hit an abend as well as, if not before, hitting the EODAD. HTH Cheers, Chris Poncelet (retired sysprog) On 09/08/2019 00:30, Paul Gilmartin wrote: > On Thu, 8 Aug 2019 23:52:25 +0100, CM Poncelet wrote: > >> FWIW I hesitate to believe that PASSED/DELETED implies that the temp >> datasets were ever physically created on DASD - unless they were >> OPENed for OUTPUT in-between. I think the *physical* alloc happens >> only on an OPEN DCB with MACRF=(PM/L). >> >> Have you tried something like the following with IEFBR14? >> >> '//WHATEVER DD DISP=(,CATLG), >> '// ... > I don't believe temp data sets can be catalogued. > > I'd consider the proof to be whether the data set can be OPENed in a > later step. I'd expect a READ to enter EODAD instantly. > > Specifying DSORG=PS might make a difference. > > -- gil ---------------------------------------------------------------------- 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
