Re: OVRPRTF OVRSCOPE(*JOB)

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