Customers who are moving from the mainframe to another processing platform want to be able to IPL their system and not start some products. This article discusses one approach to preventing Datacom from starting when it is being turned off.
There are two parts to this answer:
The first thing I would do is run this job today on every LPAR. You will need to have a loadlib ending with CABDLOAD or CAAXLOAD
//*
//DBUTLTY EXEC PGM=DBUTLTY,REGION=6M
//STEPLIB DD DISP=SHR,DSN=CAI.CHLQ.CUSLIB <<<-- Change this
// DD DISP=SHR,DSN=CAI.THLQ.CABDLOAD <<<-- Change this
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SNAPER DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD *
REPORT MEMORY=MVS
/*
This report will show you which Datacom MUFs have run on this LPAR since the last IPL of the system. From here, you should be able to track down the JCL for that MUF, and in there, you can identify the STEPLIB files. These files should be removed.
If you are unable to run the above job on every LPAR, you will need to manually identify the Datacom loadlibs and remove them. If you have continued with our SMP/E configuration, you should search for any loadlib that ends in CABDLOAD or CAAXLOAD, along with any related CUSLIB (note that other products may use a CUSLIB, too, so you will have to watch this).
You should also have an entry in your CAS9 Proc/CARIMPRM member that references the CABDLOAD/CAAXLOAD. Remove this entry. The next time the system has an IPL, this will prevent you from executing and loading a Datacom module into the system's memory.
For the long term, you will need to review your APF list (and possibly your LinkList), and remove these CABDLOAD/CAAXLOAD entries from there.
Once the loadlibs have been removed, you will not be able to run any Datacom processing.
This could be a bit harder and more involved. If your installation followed our recommended configuration, you should have a collection of files that end with CABD* or CAAX*. In addition, the SMP/E components would end with AABD* or AAAX*. These need to be removed.
As noted earlier, you may have seen a CUSLIB along with the other Datacom loadlibs. With the CUSLIB, there would likely be also a file ending CUSPROC and with CUSMAC.
For each MUF, you will also have a number of database files--some are internal and others are for your application. These are harder to identify, and cannot be used without the Datacom environment, so there is not much exposure there. You might see files ending with XX, like CXX, LXX, FXX, PXX, or RXX. These should be deleted as they contain proprietary information.
Beyond these, there could be other files, but if the above are done, this will prevent the product from being used, and should keep Datacom off the usage reports until the shutdown.
As always, please contact Broadcom support for Datacom if you have further questions.