Re: Exit point like functionality for spool files.

On 07-Jul-2017 14:45 -0600, Kevin Bucknum wrote:

On Friday, July 7, 2017 1:55 PM Roger Harman wrote:

On 07-Jul-2017 07:41 -0600, Kevin Bucknum wrote:

Our setup has a common program library, a common data library,
and a client specific library. As we switch from client to
client, our menu programs set the current library to the client
specific library. The powers that be are rolling out a new
document management system that they want to bolt on to an
existing workflow that uses a home grown spool file routing
system that converts files to PDF's and can then route them
various ways.

The problem I need to solve is that in order to automate the
workflow in the document management system, I need the client
code in the PDF file name. The options I have considered are:
• Go into each program and update the OVRPRTF that is already in
the 99% of the programs to stuff the client code in the SPLFA's.
• Create separate outq's in the routing system and have those
adjust the naming based on the outq used.
One is more work than I would like to do, and doesn't address
things like ad hoc queries, and the other relies on the users
knowing which outq to use, and then actually sending the spool
file there. The 99% of programs that have OVRPRTF's already use
QPRINT and QSYSPRT as the base PRTF. Unless I can come up with a
better way, right now my plan is to put a modified copy of
QPRINT, QSYSPRT, QPQUPRFIL and possibly a few other print files
into each client library with modified USRDFNDTA to indicate the
client, and then have the master routing program look at that to
create the file name.

Is there some sort of exit point that I'm not seeing that would
allow me to modify the SPFLA at creation time? I see some
security exit points, and some for network print server, but too
many of our users bypass the security requirements of the exit
point, and my understanding is that the network print server
isn't involved in regular 5250 spool file creation and printing.

Well, I'm not totally clear on the workflow but couldn't you derive
what you want based on the user profile or some other attribute?
Then, change the USRDTA, FORMTYPE, or USRDFNDTA attributes to drive
the downstream process?

The problem is that one user could switch back and forth between
clients all day. I really needed to grab the information right at the
time the spool file is being generated. Paul Roy ended up pointing me
to a solution that works.

An Override With Printer File (OVRPRTF) with the special value of *PRTF for the File Being Overridden (FILE) parameter could probably suffice; call-level scoped, or scoped to the activation group if applicable. That would be implemented in the same place that effects the "switch from client to client, [wherein] our menu programs set the current library to the client-specific library." The overridden attribute will be, barring any preventive measures such as /secured/ overrides or prior specific overrides, "merged" into the other/later overrides, such that the client-specific attribute will be applied when the Printer File (PRTF) is opened, thus established in/when "the spool file is being generated." The same could be done, instead, to just [the three] specific printer file names, instead of generally across "all printer files being opened except …" [see help text for *PRTF], but a potentially positive side effect for the use of the special-value of *PRTF, is that essentially, all Spooled Files (SPLF) since having changed clients, will be generated specific to that client.

While the command change exit processing could effect similar, the least resources and least programming, if functionally possible for the given environment, should be use of a preceding OVRPRTF FILE(*PRTF) OVRSCOPE(*CALLLVL)