I should have added that we have a IGGPRE00 exit that I am trying to retire that was written many years ago in such a way that when allocating a VB format dataset, it not necessary to provide LRECL or BLKSIZE. The exit assumes 1/2 track blocking, and LRECL = BLKSIZE-4. So now we have a LOT of JCL that does not code either of those parameters in production jobs. All that is needed is a valid LRECL, and let SDB take over.
What in the name of everything good would such exit functionality be introduced into a system? I am guessing, but probably was written before the days of SDB, but now is monumental to retire. _________________________________________________________________ Dave Jousma Assistant Vice President, Mainframe Services [email protected] 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jousma, David Sent: Wednesday, February 22, 2012 3:36 PM To: [email protected] Subject: Re: Request for comments on the GDG IEFAB461 exit By slippery, I mean some of these things to think about: Given the following over simplistic JCL example: //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=MY.GDG.DATASET(+1),DISP=(NEW,CATLG,DELETE) . . . //STEP2 EXEC PGM=IEBGENER //SYSUT1 DD DSN=MY.GDG.DATASET(+1),DISP=OLD //SYSUT2 DD DSN=MY.NEW.GDG.DATASET(+1),DISP=(NEW,CATLG,DELETE) . . . //STEP3 ...... - how does one implement such a EXIT or PARMLIB change? To Change the behavior, requires mass change of JCL in the shop coordinated at the same time as the change, because now STEP2 SYSUT1 has to be referenced as (0), instead of (+1). Or visa versa if going back to standard IBM behavior. - what if somehow the EXIT or PARMLIB change was not consistently set in all members of a sysplex? Wow, would that create a storm. - what does the behavior do to auto restart cleanup that TWS or the other schedulers do? - What about JCL provided by outside sources(i.e. vendor software)? What I think is that there is a "shop" out there that has been living in this alternate universe (anyone watch Fringe?), and has been zapping IBM code for years, and are now stuck because IBM has made changes. Again, I see no possible benefit from this behavior. Let's go ahead and write a front-end to IDCAMS that automatically does dynamic allocations with DISP=SHR so that we can delete files that are allocated elsewhere? Or zap IEBCOPY to do additional GRS ENQ's? Or write a RACF front-end that does additional console command checking? Fact is we have to realize that if we modify our systems to do something other than the vendor sees fit, we have to live with the consequences. I will get off the soapbox now. _________________________________________________________________ Dave Jousma Assistant Vice President, Mainframe Services [email protected] 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Pinnacle Sent: Wednesday, February 22, 2012 1:57 PM To: [email protected] Subject: Re: Request for comments on the GDG IEFAB461 exit On 2/22/2012 1:43 PM, Jousma, David wrote: > Sounds like a slippery slope to me. Almost like allowing System symbol > resolution on batch jobs. What possible benefit can there be to this? > > Dave, If you need to create and reference more than 2 different generations of a GDG in a job, you can't do it without this usermod. Regards, Tom Conley ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
