Mainframe, MVS and zOS Discussion

Posted: **Fri Jul 01, 2022 10:48 am**

Hi,

We had been using CA products but they have decommissioned. Though there was an email from System Teams but for some reason the Team responsible has forgot to remove two of the data sets from a list of JCLs.

Pattern 1:

Code: Select all

//JOBLIB   DD  DSN=PROD.USDTE.LOADLIB,DISP=SHR 
//         DD  DSN=PROD.STAGE.LOADLIB,DISP=SHR 
//         DD  DSN=PROD.FINAL.LOADLIB,DISP=SHR 
//         DD  DSN=IPO2.CAOPT.CAILPA,DISP=SHR  
//         DD  DSN=IPO2.CAOPT.CAILIB,DISP=SHR  
//         DD  DSN=SYS1.VSCLLIB,DISP=SHR       
//         DD  DSN=SYS1.VSCOLIB,DISP=SHR

Pattern 2:

Code: Select all

//JOBLIB   DD  DSN=PROD.STAGE.LOADLIB,   
//             DISP=SHR                  
//         DD  DSN=PROD.FINAL.LOADLIB,   
//             DISP=SHR                  
//         DD  DSN=IPO2.CAOPT.CAILPA,    
//             DISP=SHR                  
//         DD  DSN=IPO2.CAOPT.CAILIB,    
//             DISP=SHR                  
//         DD  DSN=SYS1.VSCLLIB,         
//             DISP=SHR                  
//         DD  DSN=SYS1.VSCOLIB,         
//             DISP=SHR

Dataset at 4th and 5th position needs to be removed. There are 2000+ JCLs. They have similar pattern like above, not same though.

Is there a way to do it in single go than doing it manually?

Also, we sue ISPW, which allows maximum of 300 components only to be 'checked-out' once. I might need to ask it with our ISPW Team, but if anybody has faced this constraint please guide on this to go beyond the limit.

Posted: **Fri Jul 01, 2022 10:03 pm**

Rather than spend the time to remove two libraries from 2000+ sets of JCL, why not create replacement load libraries for the two data sets and just put something innocuous in them (like IEFBR14)? Then your group can clean up the JCL as you make other JCL modifications over time.

Questions like yours are probably the main reason that INCLUDE libraries were defined and allowed by JES -- if the 2000+ sets of JCL used INCLUDE statements for the JOBLIB, then you'd have to change one member of the INCLUDE library and you'd be done with it.

But in general, someone has to touch every one of the 2000+ sets of JCL to remove the libraries if your group decides that the data sets have to be removed. There's not a good shortcut for what you want to do.

Posted: **Mon Jul 04, 2022 8:37 pm**

Thanks Robert for your reply.

Rather than spend the time to remove two libraries from 2000+ sets of JCL, why not create replacement load libraries for the two data sets and just put something innocuous in them (like IEFBR14)? Then your group can clean up the JCL as you make other JCL modifications over time.

We did this now though can they not keep it like this for long time? Or forever?

Posted: **Mon Jul 04, 2022 8:38 pm**

Robert Sample wrote: Fri Jul 01, 2022 10:03 pmQuestions like yours are probably the main reason that INCLUDE libraries were defined and allowed by JES -- if the 2000+ sets of JCL used INCLUDE statements for the JOBLIB, then you'd have to change one member of the INCLUDE library and you'd be done with it.

In some of the JCLs we have INCLUDE not in all.

Posted: **Thu Dec 01, 2022 8:22 pm**

What about using REXX to remove the cards? There are REXX functions to read/write the members using EXECIO and you can get the member list by using LISTDS with the MEMBERS option and capture the output.

There also was/is and IBM utility that was used during the installation process of z/OS call IPOUPDTE/CPPUPDTE that performed PDS edits ( not sure if it is still available or if it works with PDSEs ).

However, for what you are doing, I think if you use REXX and LISTDS you can get the job done.

Mainframe, MVS and zOS Discussion

Mass update the JCLs in a PDS.

Mass update the JCLs in a PDS.

Re: Mass update the JCLs in a PDS.

Re: Mass update the JCLs in a PDS.

Re: Mass update the JCLs in a PDS.

Re: Mass update the JCLs in a PDS.