Re: OVRPRTF OVRSCOPE(*JOB)

Yes, that is what I meant; i.e. a CL wrapper is the /user/ in that case.

I suppose within that statement I should have also clarified directly, rather than expecting the reader to infer from the other information provided, even at the cost of being repetitive. So...

FWiW there really should be no overrides issued by an application where the intent is that the overridden parameters will actually effect the final setting for the open *unless* the parameters overridden by the application are _secured_ by the override. That is because the non-secured overridden parameters established *prior* to the override issued by\within the application will take precedence.

The application is *not* its wrapper program. In that case, the application is what would be invoked by the wrapper program. The wrapper program is something that is acting for, _in place of_, the user. If however the wrapper were to eventually become [be consumed as] part of the application, such that the /user/ as invoker both is able to and may want to perform their own overrides to parameters that the wrapper had chosen to override to specific values, the wrapper no longer gets the opportunity to effect all of what it had intended. The properly scoped override to parameters as requested by the /user/ will take effect, thus defeating the probable intent of the wrapper, as originally coded.

Similarly if the override had been coded directly in the application with the expectation of establishing non-secured parameter overrides, the effects will reflect what the /user/ requested prior to invoking the application, not what the application had coded. If the application secures its parameter overrides then the /user/ loses the control instead. That is why there "really should be no overrides issued by an application".

Regards, Chuck

Jeff Crosby wrote:

I think both of you are saying the same thing.

Example: The same RPG program prints either a weekly summary or monthly summary. Same report, the timeframe included is different
and the number of copies needed is different.

The CL wrapper looks at which is requested and sets the number of
copies via OVRPRTF. Since the user specified either *WEEKLY or *MONTHLY, the user, in effect, determined the number of copies.


On Wed, Apr 7, 2010 at 8:14 AM, Charles Wilt wrote:

On Wed, Apr 7, 2010 at 12:51 AM, CRPence wrote:

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].

Come down from the ivory tower Chuck! :)

I've never had (non-IT) users issuing OVRPRTF...

But I've put them in lots of programs. Examples, changing the
user data that's set on the spool, or even setting the COPIES
parameter based on a prompt screen.