That's what I thought (VTOC and catalog updated) roughly. Thanks. On 13/05/2022 05:33, Mike Schwab wrote: > The VTOC and catalog is updated. SMS writes an EOF record on the > first track, non-SMS gets the last contents. > > On Fri, May 13, 2022 at 3:52 AM CM Poncelet > <000003e99a92061c-dmarc-requ...@listserv.ua.edu> wrote: >> 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of >>> <David> <Mingee> >>> Sent: Wednesday, May 11, 2022 4:30 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of >>> Pommier, Rex >>> Sent: Wednesday, May 11, 2022 5:20 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of >>> <David> <Mingee> >>> Sent: Wednesday, May 11, 2022 4:13 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of >>> Paul Gilmartin >>> Sent: Wednesday, May 11, 2022 4:21 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, send email >>> to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, send email >>> to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
