IEFBR14 does not allocate anything. The Initiator physically allocates a new DASD dataset before invoking the jobstep program, so it is already there when IEFBR14 gets control. For non-SMS, the VTOC will have been updated but not the catalog; for SMS datasets, the catalog is updated at the same time as the VTOC..
OPEN output for a new non-SMS dataset will allocate an extent for the EOF if the primary extent is zero (cylinders|tracks). -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of CM Poncelet [[email protected]] Sent: Thursday, May 12, 2022 11:51 PM To: [email protected] Subject: Re: [EXTERNAL] Re: Potential Resource Savings Techniques I could be wrong, but I had the vague impression that allocating datasets via IEFBR14 did not *physically* allocate them on DASD - but that they were physically allocated only when an 'OPEN for WRITE' was issued against them. BTW I cannot check this, as I have no access to a mainframe (8+ years.) On 12/05/2022 15:06, Pommier, Rex wrote: > David, > > My point was that if you allocate the dataset with a very small primary and > large secondary, if the dataset is never opened, you've only wasted a > cylinder of space instead of 500. I just played with Richard's suggestion of > using SPACE(CYL(0,500),RLSE) and it works just fine, allocating no space > unless the dataset actually gets opened and data written to it. For some > reason I had it stuck in my head that strange things happened if you set a > primary space of 0 but that doesn't appear to be the case. So even in my old > age I learned something. :-) > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > <David> <Mingee> > Sent: Wednesday, May 11, 2022 4:30 PM > To: [email protected] > Subject: Re: [EXTERNAL] Re: Potential Resource Savings Techniques > > Great technique. What utility or JCL is being used, if the dataset is not > opened then RLSE does not happen. > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > Pommier, Rex > Sent: Wednesday, May 11, 2022 5:20 PM > To: [email protected] > Subject: Re: [EXTERNAL] Re: Potential Resource Savings Techniques > > David, > > Here's another solution to that scenario. We have several datasets that > historically got allocated like you show here on a nightly basis. The jobs > would either populate the datasets or not even open them. I had the > developer change the JCL to allocate them with SPACE(CYL(1,500),RLSE). > Dataset doesn't get populated? No problem, 1 cylinder used. If it gets > populated, it typically fills up 1 or 2 extents. No more huge amounts of > wasted space. > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > <David> <Mingee> > Sent: Wednesday, May 11, 2022 4:13 PM > To: [email protected] > Subject: [EXTERNAL] Re: Potential Resource Savings Techniques > > My 2nd apology. The main reason for using this IDCAMS method is to reduce > wasted disk space for empty files. Sometimes empty files are Updated with > data after they are created and sometimes they just remain empty. One user > created a few hundred of these each month with > SPACE=(CYL,(500,200),RLSE) . So IDCAMS creating them saved 1000's of CYLs of > DISK. > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > Paul Gilmartin > Sent: Wednesday, May 11, 2022 4:21 PM > To: [email protected] > Subject: Re: Potential Resource Savings Techniques > > On Wed, 11 May 2022 15:36:01 -0400, wrote: > >> I apologize to all. The Correct JCL is below. It must use INFILE of DD >> DUMMY. >> > How do IEFBR14, IEBGENER, and IDCAMS compare in behavior and performance? > I'd expect: > IEFBR14 fails to RLSE. > IEBGENER is simplest to code for a single data set. > IDCAMS has best performance for multiple data sets because it minimizes job > step overhead. > > Is there any purpose in allocating a primary with multiple storage units > then immediately RLSE, other than demonstration? > > I recall I was told that the EOF is written automatically if the SMS address > space is active, regardless whether the data set is SMS managed. > > How does this play with data recovery by allocating with ABSTRK? > > I prefer BLKSIZE=0. SDB knows best. > >> IDCAMS TO ALLOCATE EMPTY FILE VS USING IEFBR14 AS BR14 DOES NOT USE SDB >> or RLSE SPACE >> //STEP010 EXEC PGM=IDCAMS >> //DD1 DD DUMMY CAN USE DD DUMMY OR DD * WITH NO DATA >> //DD2 DD DSN=GRT.GIOIDXM.TEST.BLK1(+1), >> // DISP=(NEW,CATLG,DELETE), >> // DCB=(BLKSIZE=0,DSORG=PS,LRECL=80,RECFM=FB), >> // SPACE=(CYL,(100,200),RLSE),UNIT=DISK >> //DD3 DD DSN=GRT.GIOIDXM.TEST.BLK2, >> // DISP=(NEW,CATLG,DELETE), >> // DCB=(BLKSIZE=0,DSORG=PS,LRECL=80,RECFM=FB), >> // SPACE=(TRK,(180,180),RLSE),UNIT=DISK >> //SYSPRINT DD SYSOUT=* >> //SYSIN DD * >> REPRO INFILE(DD1) OUTFILE(DD2) >> REPRO INFILE(DD1) OUTFILE(DD3) >> /* > -- > 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 > > ---------------------------------------------------------------------- > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to this message and destroy the material in its entirety, whether in > electronic or hard copy format. 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 > > ---------------------------------------------------------------------- > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to this message and destroy the material in its entirety, whether in > electronic or hard copy format. 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
