On 11 May 2013 11:05, Kirk Goins wrote:
Me thinks everyone is over thinking this... Take a look at the
printer file parameters EXPDATE and DAYS . The default is *NONE
(next to last page of the parms). Change the printfile to 60 and
*DAYS. Now you can use the DLTEXPSPLF cmd
Perhaps. But the Expiration feature for spooled files is not helpful
directly, to resolve the issue for any existing spool file either which
does not already have an expiration attribute or which was [or will be]
created in a manner that would not have the spool expiring [within the
stated 30 days]; e.g. per OVRPRTF EXPDATE(*NONE), even if CHGPRTF had
already set every Printer File to effect an expiration other than *NONE.
Thus using the Delete Expired Spooled files (DLTEXPSPLF) likely would
give no joy for the originally stated goal, of deleting those existing
spools currently over thirty days old :-(
A separate reply to the Opening Post that I had composed with mention
of the DLTEXPSPLF was not yet sent, pending determination of when the
EXPDATE feature came into the OS. Seems that the EXPDATE() and DAYS()
are not documented at v5r3 for CHGSPLFA and CHGPRTF, yet these appear in
the v5r4 docs for both, *without* any change flags <ugh>; I am fairly
confident that the /convention/ was that changes to commands would
appear bracketed with <start of change> <end of change> markers, but
seems that did not occur. Anyhow, it seems the capability came in v5r4;
I will send my reply with the links to the current docs.
Nonetheless my comment was specifically to suggest that *if* someone
were to choose to avoid the APIs against which to code a solution for
existing spool files, and to use WRKSPLF spooled output, then they could
do better to avoid the three separate spool-related actions of Spool,
CPYSPLF, and DLTSPLF by just pushing the output data from the WRKSPLF
request directly to a database file member over which a query using a
function call to the command interpreter can issue ad hoc spool file
command invocations.
Perhaps worth noting that a variation on the SQL I presented, can be
used to issue a CHGSPLFA request to assign an EXPDATE() [via DAYS()] to
specify the [date or] number of days for any existing spool files. That
is, instead of using the DLTSPLF, as was noted could be any ad-hoc
command request string built from the data, a CHGSPLFA command string
could be built to change the expiration attribute on any spool files
selected according to similar WHERE-clause criteria. FWiW: Whatever
particular release of the OS being used, may or may not have added the
expiration information to WRKSPLF output, whereby that information might
be worthwhile to include in a predicate on the WHERE clause.
After the query to effect DLTSPLF for those spool files over thirty
days old [in my earlier quoted reply found below], the following request
could set expiration dates for those remaining spool files less than or
equal to thirty days old [those which were not previously deleted] to
have an expiration in ~30 days since their creation date:
select cmdExec( 'chgsplfa ' concat file concat ' job('
concat jobnbr concat '/' concat rtrim(jobuser)
concat '/' concat jobname concat ')'
concat ' splnbr(' concat filenbr concat ')'
concat ' expdate(*days) days(' concat char( dec( min(
days(current date) - days( nullif(crtdate, '') +1 ), 366
)/*end-min*/ , 5 )/*end-dec*/ )/*end-char*/
concat ')' )
from qtemp/qprtspldta /* pf under LF qprtsplf */
where days(current date) - days( nullif(crtdate, '') ) <= 30
Note: the MIN function and the "+1" work together to satisfy the
limits requirement of the DAYS() parameter irrespective of the above
selection which nullifies the effect of the MIN. However if the
selection were to change to include spool data already older than 366
days, then the query would still generate a valid command string.
The command string to be performed by the cmdExec function, as
generated from such a query, could be for example [noting: some extra
but insignificant spaces\white-space are not trimmed in the above string
expression]:
'chgsplfa QPDSPLIB job(177811/THEUSER/QPADEV0013) splnbr( 3)
expdate(*days) days(18 )'
Note: More parameters than shown in the examples here might be
required on either of the DLTSPLF or CHGSPLFA, if spool files were
/restored/ to the system. The other parameters may be required to
ensure a distinct spool file can be located with the criteria specified
as parameters on the command string.
Regards, Chuck
On Fri, May 10, 2013 at 4:27 PM, CRPence wrote:
If one were really so averse to using the APIs that are provided,
and also were content with such /tricks/ both being easily impacted
by OS reporting [printer file] changes and possibly functional only
on the installed language and release on which the code was first
written, then why not just write the output of the WRKSPLF directly
into a database file over which a SQL query is run to effect the
command invocation? e.g. the following work gets the data into a
database file and the SQL can be used to issue any ad-hoc requests
beyond just the DLTSPLF, by dynamically building the command
request from the column data:
clrpfm qtemp/qprtspld
; -- presumes prior effective CRTPF QTEMP/QPRTSPLD
ovrdbf qprtsplf qtemp/qprtsplf lvlchk(*no)
; -- presumes prior CRTLF QTEMP/QPRTSPLF over QPRTSPLD
wrksplf *all output(*print)
;
/* run in same SQL OPTION DATFMT as job DATFMT() */
select cmdExec( 'dltsplf ' concat file concat ' job('
concat jobnbr concat '/' concat rtrim(jobuser)
concat '/' concat jobname concat ')'
concat ' splnbr(' concat filenbr concat ')' )
from qtemp/qprtspldta /* pf under LF qprtsplf */
where days(current date) - days( nullif(crtdate, '') ) > 30
; -- presumes UDF cmdExec exists for the purpose of QCMDEXC
dltovr qprtsplf
;
midrange.com
