James H. H. Lampert 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].