Timothy Adair wrote:
I need to do an OVRPRTF OVRSCOPE(*JOB), and then later do an
OVRPRTF to the same printer file, but only affect the parms I
specify.
Example:
OVRPRTF FILE(PRT1) DEV(D1) OUTQ(OUTPUTQUE1) COPIES(5)
OVRSCOPE(*JOB)
then do
OVRPRTF FILE(PRT1) COPIES(99)
I need the second override to only change the COPIES, and leave
everything else from the first override intact.
I've searched the archives and IBM's site and can't find an
answer.
Any thoughts?
The OVRSCOPE() of the second invocation was not noted, though
possibly of no consequence to the outcome, with both the same FILE()
& OVRSCOPE() the entry is simply replaced at the same LVL(); i.e.
there is only one [DMCQ] entry stored for the named FILE(), for any
combination of activation\call level and scope.
The concept of overriding the file for certain parameters is to
allow the first requester\earliest call level, generally the end
user, to get what they want; i.e. overriding what the application
would normally effect for the user. Thus any overrides to the same
parameter(s) issued at a new level in between the first request[er]
and the open are ignored; i.e. nobody can override my request to
override to request the five copies if I was the first requester of
an override to that file. FWiW, there really should be no overrides
issued by an application, only overrides issued by a user, prior to
invoking the application [that in the given scenario will produce
the spool file].
The exception to that would be in /securing/ parameters of the
open. As I recall, a SECURE(*YES) override via the CL OVRxxxF
commands will unfortunately secure the entire request, not just the
specified parameter(s). However IIRC an application program can
[potentially, if supported by the language,] open with a parameter
secured using a UFCB [User File Control Block], to ignore\override
the desires of the first requester. Instead of a second override,
the application would want to open the printer file with the
COPIES(99) secured, where the SECURE option is effected as part of
the /open/ feature, not effected via the CL request to OVRPRTF.
I thought there was an API to retrieve the override parameters
merged, just as they appear on the DSPOVR, such that a new command
string could be generated. However all I noticed in a quick search
was the QDMRTVFO Retrieve File Override Informatioh API which is
rather limited; i.e. no parameter details. The merged override with
SECURE(*YES) plus the change to COPIES(99) to replace the COPIES(5)
could be issued to get the override to apply; i.e. defeating the
capability of the original override as the design intends for normal
operation.
Regards, Chuck
midrange.com
