Re: Retrieving ODBC information

The login should match the current user for the job. As noted in the KB Document Number: 8021834 "If the program that needs to retrieve the current user profile is called directly from the target prestart job, then the CL command RTVJOBA can also be used. For example, a user exit program or stored procedure could simply call the CL command RTVJOBA CURUSER(&CURUSR)." So if the printer can be established solely on the user name, that might be an option. Additionally the SQL supports the USER, SESSION USER, and SYSTEM USER special registers.

The response beyond this paragraph refers to printer name. It could just as well refer to output queue name or printer IP. If the concern includes how to establish spooling on the server to direct to the network printers, that is deserving of its own topic, separate from the subject concern. Most notably, those who might best respond to printing related questions, might just ignore a topic with ODBC subject.

IMO if the application has to know /who/ [regardless if 'who' is a user, program, or client PC] invoked the application, in order to decide what to do, then the application has a bug; i.e. the application should be told what to do. For example, what if the user starts making requests from a different client or the client address or name changes? So...
Depending on the client interface, there should be the option to have the client send the desired printer name to be used for the packslip print requests. That is, rather than the code trying to infer where to print based on the caller, have the caller tell the code what it should do. If the existing server application can not be changed to accept as a parameter the requested printer, then perhaps the client can effect, before starting the existing application, issue a request to either override the printer file for the packslip or store the printer name [e.g. in a data area in qtemp] for later reference by the CLP which will eventually do the printing. The request to start the application would have to share the connection started by the procedure inserted prior.

Regards, Chuck