In the beginning, IEBGENER did not itself change. IBM recommended replacing it with a copy of ICEGENER aliased to IEBGENER so that SDB would be in effect without anyone having to change JCL. That's what we did but accidentally messed up the wacko application that was depending totally on the default behavior of IEBGENER.
I'm not aware that IEBGENER itself ever changed. You either kept the classic version or played the alias game. The app we shot in the foot counted on IEBGENER default behavior by hardcoding I/P block size later on for the same file. I personally think it's inexcusable to make that kind of choice. If you're going to hardcode on input, you should also be hardcoding at creation. IIRC the I/P block size was some kind of complicated logic that calculated a specific number of records per block on tape. . . 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 robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, December 04, 2018 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Examples of roll your own "LIKE()" for data sets? On Tue, 4 Dec 2018 21:09:37 +0000, Jesse 1 Robinson wrote: >When my home shop of that long ago the day 'converted' to SDB, we stumbled on >a (screwball) app that routinely created a file using--depending >on!--IEBGENER's practice of duplicating input DCB attributes to output, >complete with the boiler plate warning to that effect. The real mischief was >that a later program in the app read that file with hard-coded input DCB to >match the original file. > Used to be the custom. > ... All had gone well for years until we replaced IEBGENER with ICEGENER. > Boom. SDB was not a heavenly gift to that application. > IEBGENER switched to SDB for a while, then enough users had your experience that they made the old behavior the default and provided PARM=SDB. Did ICEGENER never imitate? Don't they claim compatibility. I can't understand the Ref. for PARM=SDB. It seems to tell what it doesn't do, not what it does. The best I find is a sentence in a table, "All are used". -- gil >. >. >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 >robin...@sce.com > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >On Behalf Of Paul Gilmartin >Sent: Tuesday, December 04, 2018 10:45 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: Examples of roll your own "LIKE()" for data sets? > >On Tue, 4 Dec 2018 11:41:43 -0600, Kirk Wolf wrote: >> >>Are there examples in CBT of code that do similar analysis of DASD >>datasets? Even something that does a good job at deducing >>SPACE=(unit,(pri,sec)) is not as simple as one might think. >> >AVGREC adds to the chaos. > >If the initial allocation was performed in multiple extents, is there any way >to retrieve the initial request? > >HSM MIGRATE/RECALL can coalesce extents, further obscuring the initial request. > >I have used ISPF to capture the attributes of a data set; changed only the >DSN, then allocated. The new data set was smaller because ISPF? Allocation? >applied a correction for 3380/5590 capacity ratio. >(I understand this is optional, but our site had it turned on.) > >I'd like to be able to code "BLKSIZE=0,SPACE=(1,10000000000),..." >and let allocation and SDB figure it out. > >They're only trying to help me. > >-- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
