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

James H. H. Lampert wrote:

rob@xxxxxxxxx wrote:

I don't suppose a File Information Data Structure is a possibility to get the library name versus PRTTXT, is it?

No, because this particular program doesn't open any other files. But retrieving an object description on something known to be in the environment library is (and that's exactly what happens in another program in the same application).

I think, since I'm already getting a JOBI0100 for another purpose, I may as well bump it up to a JOBI0400, since both have the fields I'm already getting. I was merely hoping that there was someplace I was overlooking, where I already had that information.

And Chuck, if somebody is really enough of a doofus to go into a server job and change the PRTTXT, then they deserve whatever malfunction they might cause. After all, nothing is ever completely foolproof, because complete fools are so ingenious.

True. There is no cure for stupid. :-)

However what I alluded to was the calling of any program which might have the undesirable effect of changing the print text value [i.e. with CHGJOB JOB(*)], not for some user invoking the CHGJOB JOB(named). For instance, a "CALL CJD" coded in the application might not currently issue a CHGJOB JOB(*) PRTTXT('CJD REPORT'), but what controls are in place within the application development environment to ensure that is not done in a future revision? Is program CJD even part of the source controlled code, or could it be vendor code changing the PRTTXT for their own purpose; whammy bug, then beg them to fix it, or remove their /enhancement/ which impacts the internal app. Even within source control, one can not easily intuit a need to avoid using CHGJOB to modify various job attributes appropriate for declaring some assumptions, but the same programmer is unlikely to overwrite data in variables which are declared and documented only to the application as the "application name" & "port" or whatever. FWiW I really dislike such dual-use in programming if\when that is easily avoidable; i.e. is "print text" value the printer text, or does the "print text" define the application name & port?

If the information from JOBI0100 is limited to a few specific attributes, one of the "key APIs" that I noted [for their ability to retrieve just the attributes of interest and thus limited return data size] may be preferable to the QUSRJOBI [with its "formats" of pre-defined control blocks of sizable returned information].

Regards, Chuck