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].
The following CHGCMDDFT CMD(CRTPRTF) NEWDFT('EXPDATE(*DAYS)
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.
midrange.com
