For a variety of reasons, notably for helping the system and the
customers maintain better system\data integrity, the ability to change
the Library List of another job, the effective "path" for resolving both
data and executable objects, there is no direct capability provided to
modify that attribute of another job; only actions within the job, such
as those commands noted. One can imagine the possible negative effects
of an effective /randomly placed/ request to change a path; e.g. a
RMVLIBLE between a CHGPF FILE(*LIBL/X) SIZE(*NOMAX) and a CHGOBJD
OBJ(*LIBL/X) OBJTYPE(*FILE) TEXT('Since updated to NoMax Size')
I had always desired that capability [to change the library list] to
be integrated into "service" [STRSRVJOB] features, though probably more
generally the ability to directly perform a CL request in the serviced
job. There was at one time some capability, via the TRCJOB EXITPGM()
parameter, but that capability was disabled and replaced by an API.
However instead of using that, I just adopted the concept of using the
message event, a /Break Program/ for any application\job for which I
wanted to enable the capability. For a general capability I would just
integrate the CHGMSGQ PGM() in the routing program for a subsystem.
So anyhow, while there exist such possibilities for one job to
perform work in another job, the general implementation [the API] has
been defined such that system and the job must allow\enable that
capability... via Registration Information (WRKREGINF):
_i Call Job Interrupt Program Exit Program i_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/xwcjbitp.htm
"...
Exit Point Name: QIBM_QWC_JOBITPPGM
Exit Point Format Name: JITP0100
The Call Job Interrupt Program exit program is indirectly called by the
Call Job Interrupt Program (QWCJBITP) API. The QWCJBITP API is used to
interrupt a specified target job to run a user-written program. ..."
There is an API with constraints defined as limitations\restrictions
for the capability on the system [and job] as noted just above; i.e.
"job interrupt". Here are some related links:
_i Call Job Interrupt Program (QWCJBITP) API i_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qwcjbitp.htm
"...
The Call Job Interrupt Program (QWCJBITP) API will execute an exit
program in the initial thread of a specified job. For additional
information on API and exit program restrictions, see Usage Notes.
..."
_i Change Job Interrupt Status (QWCCJITP) API i_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qwccjitp.htm
"...
The Change Job Interrupt Status (QWCCJITP) API will retrieve and
optionally modify the job interrupt status of the current job. For
additional information, see Usage Notes. ..."
_i Jobs system values: i_
_i Allow jobs to be interrupted to run user-defined exit programs i_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzakz/rzakzqalwjobitp.htm
"The Allow jobs to be interrupted to run user-defined exit programs
system value is also known as QALWJOBITP. You can use this system value
to specify how the system responds to user-initiated requests to
interrupt a job to run a user-defined exit program in that job.
..."
I only have a modicum of familiarity with the above. However here is
an article describing a feature coded [Run Job Command (RUNJOBCMD)] to
implement the capability more generally to run a command in another job
[describing an enhancement to remove its dependence on the since-removed
TRCJOB Exit Program capability... as I inferred from a very cursory review]:
_i Sending Commands to Another Job - Revisited for i5/OS V5R4 i_
Date Posted: March 05, 2008 12:00 AM
Author: Carsten Flensburg
http://www.iprodeveloper.com/article/security/sending-commands-to-another-job---revisited-for-i5os-v5r4-60148
--
Regards, Chuck