Add DTACPR(*MEDIUM) in all the SAV Commands used

[james_alive]

Hi,

I have to add DTACPR(*MEDIUM) to all the save commands used in the CLPs of project environment. So that every savefile created is of small size. Please suggest an easy, possible way to do this.

PS: I cannot manually edit every CLP for this. Need some real ideas please,

[tomliotta]

Re: Add DTACPR(*MEDIUM) in all the SAV Commands used

It's hard to see many (any?) good reasons for perhaps even as many as half a dozen CLPs to include SAVxxx commands in a given project environment. (Possibly even in a lot of full systems, if we discount SAVSYS, SAVCFG, SAVSECDTA and a couple other special purpose commands, and excepting the IBM-provided save programs.) But that's a different issue from what you're asking.

To cover the subject reasonably well, the first thing that should be addressed is the intended 'target' of the SAV* commands in the CLPs. If any tape devices are used for this system, DTACPR(*MEDIUM) is invalid, according to the help for the commands. So, actually changing the commands would cause any program with SAV* commands to blow off with a CPF37A8 *ESCAPE message if any tape device is ever used. That could conceivably cause a lot of trouble at very inconvenient times, e.g., when doing a full-system save to tape with SAVE menu option 21.

Fortunately, the system has a protection or two against that. You can help by not trying to change the system's command. Instead, you might follow the advice in the documentation for the Change Command Defaults (CHGCMDDFT) command:

To change an IBM-supplied command, the user should create a copy of the command in a user library and change the defaults of the copied command, instead of the IBM-supplied command itself. The user library should be listed before the library QSYS on the library list. Save the source of the CHGCMDDFT command so that the changes can be identified later. This procedure allows the user to use the original IBM-supplied command defaults when necessary and ensures that changes made to the copied commands are not overlaid when a new release on the system is installed.

The CHGCMDDFT command can allow you to change the existing default for a command parameter. For example, the SAVOBJ command defaults to DTACPR(*DEV). CHGCMDDFT lets you change it to DTACPR(*MEDIUM).

The IBM-supplied SAVE programs should be protected due to their special way of invoking commands. Those programs will execute unchanged commands because the programs qualify their references with "*SYSTEM" to represent the 'library' to pull the commands from. There are some additional details, but you don't really need to think much beyond the documentation for the CHGCMDDFT command. Make duplicates and change the duplicates. Manipulate the library list so that the duplicates get called by your CLPs.

Well, that's the basics of one alternative. Maybe it's not the best alternative for you.

A second alternative could be the QIBM_QCA_CHG_COMMAND exit point and a Command Analyzer Change Exit Program. The exit point can have programs that you write registered against it. Each registered exit program is associated with a command that you choose. The link describes mostly how it all works, but essentially your program gets called whenever the associated command is run. Your program has the opportunity to change the given command string so that different parameters can be supplied. You could potentially replace any use of DTACPR() so that DTACPR(*MEDIUM) is used instead, or you might simply add DTACPR(*MEDIUM) to the string if the parameter wasn't specified.

Your program logic would run whatever tests it needs to determine what, if any, change is to be made. It's a possible way to get your problem handled without changing any command objects, without changing existing CLPs and without changing system library lists. It could potentially all be done with a single generic program that handles all of the different SAV* commands.

It's not a trivial topic to change how system commands work while maintaining system integrity, keeping existing programs from failing, avoiding problems for possible 3rd-party products, etc. This has been an attempt just to introduce a couple concepts.

There's no way for us to know what might be best for you. "Best" might actually be to look into why there are too many existing CLPs to modify. Creating a very few generic 'save' procedures might be worthwhile.