On 24-Aug-2014 04:51 -0500, Gad Miron wrote:

In (hopeless?) effort to control the proliferation of old spool files
I'm creating/changing PRTFs with parameters EXPDATE(*DAYS) DAYS(60).
(with a scheduled DLTEXPSPLF CMD to execute once a week).

Unless those objects are being defined and created in a controlled environment [e.g. source control and object development\production control] such that the creator was prevented from simply changing the value on the parameter(s) or changing the Printer File (PRTF) to have values other than a preferred default, then the ability to ensure those settings [not to mention getting applied to each SPLF] would remain a potential issue.

As an alternative, the PRTFs could be changed periodically. I used to, on my test systems for example, issue a Change Printer File (CHGPRTF) request to modify every file to have MAXRCDS(*NOMAX). In any case that effect would have been an issue for someone, we could have had an exception process to avoid changing some specific printer files to have that preferred\changed default, or anyone could have reverted the change to any of their own printer files; though in my case, the changes were not scheduled in advance, so anyone's testing requiring otherwise, needed to always include reverting\establishing their printer files to their preferred value in anticipation that they may have been changed.

In applications at run-time, or generally within a job, the Override With Printer File (OVRPRTF) command could be used to cause the desired attributes to be in effect, either against all printer files (*PRTF) or against just specifically named printer file(s). A Routing Program [or for interactive jobs, perhaps an Initial Program] could effect the desired override request scoped to the level of *JOB. The desired effect is obtained without any need to change any printer files, as well if any printer files are changed.

However, I'm unable to change the DFTs of the CRTPRTF CMD so that
whenever someone re-create(compiles) a PRTF (using PDM option 14)
these parameters are lost.

If the 14=Compile option does not effect what is desired, most typically an alternate User-Defined Option would be created and used in place of a System-Defined numeric Option. But then, everyone must use that user-option in place of option-14 for their Create request.

As for recompiles adopting the old attributes, that generally requires that the objects are being created or /promoted/ within a controlled environment. The effect of PDM's built-in compile feature via option-14 is not such a beast. If the development\system environment were already so well controlled, there would be no need to consider trying to modify the defaults of the create; the /correction/ could be made once, and the effect would persist.

FWiW: A design capability [I recall discussing ages ago] is that the PDM could, like with user-defined-options, open some capability to specify the parameters for the default command-string used to perform the option-14; i.e. provide some customization for the command associations to the object type\attribute, the ability to add parameter specifications not already included by the PDM system-defined option. If there is some perceived value in such a capability, submitting a Design Change Request (DCR) might be something to consider [others have noted some links to do so].

DAYS(60)') results in error <<SNIP>> CPD6260 "No default value exists
for keyword DAYS" error MSG.

Anyone familiar with it?

That which does not exist, can not be changed. The Days Until File Expires (DAYS) parameter has no default value. A possibly reasoned argument could be made that changing from having no default to having a default should qualify as a _change_ [and that a non-existent Add Command Default (ADDCMDDFT), an effective Alter Command, should not be an implied requirement as an alternative]; however given the conceptual contradiction [from nothing to something via such _change something_ activity] and more importantly the implementation of how default are stored with [and modified within] command objects, such an argument is unlikely to gain any traction, nor would any possible future change be of any assistance for the present.

Any number of the available as possible alternative approaches, is probably more appropriate than trying to mess with the Create Printer File (CRTPRTF) command object. For one, the dependence on just the capability of Delete Expired Spooled files (DLTEXPSPLF) could be relaxed; a separate process could search and destroy older spool files irrespective of the /expiration/ settings. If a process to ensure not every spool file will be created with those desired expiration settings and something done to prevent anyone from changing printer files and\or spool files to avoid those expiration settings, such processing may be desirable or necessary anyhow.?

If the perspective of overriding the effects of CRTPRTF remains the focus\perspective despite the potential for finding alternate approaches... The command exits being what was provided by the OS to enable people to customize commands without them /mucking with/ the system command objects, is probably best approach. Note: some changes to system commands may result in MCH6801 errors, requiring a restore of the command object from a backup to recover; a re-install being one means to effect that restore. For testing, always modify only an actual _duplicate_ of the *CMD object [avoid changing a proxy command], never modify the original command object; the original could have been moved and\or renamed to maintain an effective backup copy, and also be saved to a save file and\or tape separately, thus allowing for an easy restore for recovery, as contrasted with being left with only the ability to effect a restore from SAVSYS media.

Return to Archive home page | Return to MIDRANGE.COM home page