Re: DCB NECESSSARY?
Elardus, I found this jcl which is currently being run to reorg. the MCDS in an LPAR. It has the DCB specified: /* //STEPA EXEC PGM=IEFBR14,COND=(0,NE) //MCDS DD DSNAME=SYS2.MBMCDS.T,DISP=(,CATLG), // DCB=(RECFM=VBS,LRECL=2044,BLKSIZE=0), // SPACE=(CYL,(550,550)) /* The file is reorged using EXPORT/IMPORT. It is not recreated. This is what the DEFINE CLUSTER looks like/* //DEFINE EXEC PGM=IDCAMS,TIME=1439 //SYSPRINT DD SYSOUT=* //HSMMCDS DD UNIT=3390,VOL=SER=PROD03,DISP=SHR //SYSIN DD * DEFINE CLUSTER - (NAME(SYSP.MCDS.PROD) VOLUME(PROD03) - CYLINDER(2500 0) FILE(HSMMCDS) - RECORDSIZE(435 2040) FREESPACE(0 0) - SPEED BUFFERSPACE(530432) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - UNIQUE NOWRITECHECK) - DATA (NAME(SYSP.MCDS.NEW.DATA) CISZ(12288) ) - INDEX (NAME(SYSP.MCDS.NEW.INDEX) CISZ(2048) ) /* // From: Elardus Engelbrecht <elardus.engelbre...@sita.co.za> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, February 9, 2017 11:32 AM Subject: Re: DCB NECESSSARY? Paul Gilmartin wrote: >>To Esmie, I see there are NO LRECL and BLKSIZE in this snippet. Seemed you >>can just let IDCAMS figure it out for you. >Oooh! This is tricky. Some utilities "figure it out for you", others don't, >yet others will override whatever you code, sometimes corrupting an existing >non-empty PDS. Indeed. This is tricky just as you said. The Big Blue a$$umed you are using SMS with the correct SMS constructs. In that snippet, if the IMPORT does not work after the EXPORT, then whoever is using it, is really SOL. I initially recommended using IDCAMS to define the backups, then shut every HSM down, REPRO, ALTER both sets and start all again. I safely used that method without problems at all (and without being called before management!!! ;-D ) Perhaps someone could tell what is the correct LRECL and BLKSIZE after all the EXPORT/IMPORT work is completed successfully. >And the prevailing recommendation is omit BLKSIZE; let SDB operate. Yup. Let SDB decides depending on whatever device you have. Unless you're sitting with IBM's default compiling procs like IGYWCLG (Compile, Link, Go), then you had to insert these DCB=(RECFM=U,LRECL=0,BLKSIZE=6144) or BLKSIZE= in //SYSLMOD DD DSNAME=&GOSET(), etc ... ... to avoid LKED with RC=12 because SMS has the last say. This is WAD and I'm not complaining about this. >But are there still facilities that require an absurd BLKSIZE, such as <=3120? I think I have seen some of them in the ancient past. With the small disks then, it was a cruel wastage of space. >... If DCB=(...) is optional for tape, DASD, (terminal, punch, reader, >printer, spool, ...), why not likewise for PATH? Good question. PMR time for the device definition tables [which fill in the rest if not coded in JCL or overridden by SMS]? Groete / Greetings Elardus Engelbrecht -- 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
Re: DCB NECESSSARY?
Paul Gilmartin wrote: >>To Esmie, I see there are NO LRECL and BLKSIZE in this snippet. Seemed you >>can just let IDCAMS figure it out for you. >Oooh! This is tricky. Some utilities "figure it out for you", others don't, >yet others will override whatever you code, sometimes corrupting an existing >non-empty PDS. Indeed. This is tricky just as you said. The Big Blue a$$umed you are using SMS with the correct SMS constructs. In that snippet, if the IMPORT does not work after the EXPORT, then whoever is using it, is really SOL. I initially recommended using IDCAMS to define the backups, then shut every HSM down, REPRO, ALTER both sets and start all again. I safely used that method without problems at all (and without being called before management!!! ;-D ) Perhaps someone could tell what is the correct LRECL and BLKSIZE after all the EXPORT/IMPORT work is completed successfully. >And the prevailing recommendation is omit BLKSIZE; let SDB operate. Yup. Let SDB decides depending on whatever device you have. Unless you're sitting with IBM's default compiling procs like IGYWCLG (Compile, Link, Go), then you had to insert these DCB=(RECFM=U,LRECL=0,BLKSIZE=6144) or BLKSIZE= in //SYSLMOD DD DSNAME=&GOSET(), etc ... ... to avoid LKED with RC=12 because SMS has the last say. This is WAD and I'm not complaining about this. >But are there still facilities that require an absurd BLKSIZE, such as <=3120? I think I have seen some of them in the ancient past. With the small disks then, it was a cruel wastage of space. >... If DCB=(...) is optional for tape, DASD, (terminal, punch, reader, >printer, spool, ...), why not likewise for PATH? Good question. PMR time for the device definition tables [which fill in the rest if not coded in JCL or overridden by SMS]? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DCB NECESSSARY?
On Thu, 9 Feb 2017 08:00:26 -0600, Elardus Engelbrecht wrote: > >To Esmie, I see there are NO LRECL and BLKSIZE in this snippet. Seemed you can >just let IDCAMS figure it out for you. > Oooh! This is tricky. Some utilities "figure it out for you", others don't, yet others will override whatever you code, sometimes corrupting an existing non-empty PDS. And the prevailing recommendation is omit BLKSIZE; let SDB operate. But are there still facilities that require an absurd BLKSIZE, auch as <=3120? And a few selected attributes are not replicated by LIKE. And is DD PATH=...,LIKE=CATALOGUED.DATA.SET.NAME allowed? Why not? And allocation will not write an EOF with DISP=NEW unless you code DSORG. Why not? Syntax. Years ago, I instructed a colleague on the form for allocating a UNIX file: //SYSPRINT DD FILEDATA=TEXT,PATH=...,LRECL=125,BLKSIZE=12500 "But don't I need": //SYSPRINT DD FILEDATA=TEXT,PATH=...,DCB=(LRECL=125,BLKSIZE=12500) "No. Don't do that." He tried it his way; got JCL error. (Why!?) "I told you so." I hate JCL! If DCB=(...) is optional for tape, DASD, (terminal, punch, reader, printer, spool, ...), why not likewise for PATH? And some facilities would work better if one were allowed to code DSORG with PATH. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN