Re: Exit point like functionality for spool files.

[Paul Roy <paul.roy@xxxxxxx>]

Hi Kevin, 

you could possibly modify the behavior of the OVRPRTF command using the 
Change Command exit point...  registering OVRPRTF 

a possible scenario could be 
        - assuming you have a way to retrieve client code from a temporary 
data area or a data base
        - in the exit point program you retrieve the client code and 
modify the command string  forcing for example TOSTMF(/&client/... ) 
WSCST(*PDF) 

I did not test it but  just an idea... 

kind regards
Paul 









From:   Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
To:     midrange-l@xxxxxxxxxxxx
Date:   07/07/2017 19:31
Subject:        Re: Exit point like functionality for spool files.
Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Kevin

IIRC there are a couple printing exit points - one where I think you 
list OUTQs, then an entry goes on a DTAQ when some status changes for 
spooled files.

I did see another one in a Google, something about network printing.

I just looked in Knowledge Center - in there go to Programming, then 
Apis, then API Finder and go to the bottom of that page, where you can 
search by groups - one of those is "all exit programs" or something - in 
THAT list there are a couple items on DTAQ support for spooled files. 
Things like SPLF creation and SPLF ready stuff.

Might give you something to use, eh?

HTH
Vern

On 7/7/2017 8:41 AM, 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 thinks 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.