Re: Easiest way for a program to find out the PRTTXT ("print text") of the job it's running in?

[CRPence <CRPbottle@xxxxxxxxx>]

  IMO the PRTTXT seems inappropriate to use in that manner.  The 
print text setting would seem more appropriately classified as an 
effect, not as an indication, of the application environment that 
was established.  Its use requires that there is prevention of any 
CHGJOB JOB(*) PRTTXT(another_value) activity within any existing or 
new [future additions to] invocations made by the application, when 
not used explicitly for changing the environment.  Preventing the 
use of that command to change the print text is more difficult to 
ensure, or to predict its [mis]use, as compared to just changing 
some storage owned only by the application.  IMO the application 
environment should be stored elsewhere, precluding any need to have 
the print text value retrieved.

  Regardless, if the QUSRJOBI API [or the equivalent in keyed API, 
either Retrieve Current Attributes (QWCRTVCA) or Retrieve Thread 
Attribute (QWTRTVTA) API retrieves), or RTVJOBA] is not desirable 
for retrieval of the app environment then, again, why not just store 
the environment detail in another place?  In so doing, the value 
would still be stored only once IMO, considering the PRTTXT as an 
effect.  Choose the alternate [or /additional/] location that would 
enable a\the most preferable method of retrieval of the active 
application environment details.  My preference is an input 
parameter when possible [tell the application what to do rather than 
the application inferring\divining what to do], but there are others 
such as an environment variable, a data area, a row of a database 
file, a held lock, etc..

Regards, Chuck

James H. H. Lampert wrote:
> Last month, I had a question about a keyed union of enrollment files for 
> multiple separate environment libraries of an application.
>
> It turned out to be much easier to accomplish the goal by switching to a 
> single enrollment file in the application library, with the environment 
> added as a leading key to it and all its logicals.
>
> But that opens another can of worms: now I have programs that need to 
> know which environment they're running in. Easy enough if the program 
> opens a file in the environment library, but not so easy if it doesn't.
>
> But for a variety of other reasons, the application already sets the 
> Print Text of every one of its jobs to the environment library and TCP 
> port it's using. (Among other things, it makes it easy to find the 
> server jobs using a particular environment, so they can be held, 
> serviced, or terminated.)
>
> Obviously, I can get the print text from a call to QUSRJOBI, format 
> JOBI0400, but is there another way to get it?