How to find which program/who called CL/RPG program???

[Gary Segal]

Good Afternoon.

I inherited iSeries system(V6R1) - no documentations.

There is no Pathfinder or any similar tools. Only standard IBM OS programming tools.

I need to find out which program calls one of the CLs that is somehow randomly called either by system or by one of the users.
I searched the whole system, but I could not find where it is called from.

There is M3 ERP system installed and I have no control of program sources, etc.

Is there a way find out who called the program or what screen(PGM) called it?

I was thinking to add few lines into CL to retrieve Job attributes and store it into DataArea, but there is no attribute like PRIORPGM.

Any suggestions?

Thank you in advance
Gary

[CRPence]

On 18-Jul-2014 11:34 -0500, Gary Segal wrote:
> <<SNIP>>

>
> I need to find out which program calls one of the CLs that is
> somehow randomly called either by system or by one of the users.
> I searched the whole system, but I could not find where it is called
> from.
>

> <<SNIP>> Is there a way find out who called the program or what
> screen(PGM) called it?

Auditing is probably the easiest. The Change Object Audit
(CHGOBJAUD) command against the program is minimally required; obviously
minimally beyond that, is establishing the QAUDJRN journal and the
auditing system values. I do not recall the User auditing [setup]
requirements, in conjunction; been too long.

> I was thinking to add few lines into CL to retrieve Job attributes
> and store it into DataArea, but there is no attribute like PRIORPGM.

That seems to imply the program source is available and the program
can be recompiled to replace the current version [with the proper\same
attributes and authorization].?

The _prior program_ is easily enough retrieved at run-time, in a
variety of ways. Messaging, API, MI instruction, Dump, Trace, Inquiry,
PgmStk, WRKJOB, etc. What method(s) are available depends on whether
the effects can be disruptive, can be presumed to be /untouched/ by the
producer, need to be /invisible/ to the user, require access to the CL
source, require knowing only the parameter(s) of the CLP, and ?other?

Probably better however, to /log/ the caller versus merely /storing/
the invoker information. As contrasted with /logging/, /storing/ [and
esp. in a Data Area (*DTAARA) seemingly] implies the possibility that
the information could be overwritten; only the most recent stored info
would be available for review, rather than every incident. The audit
log [or any other journal, using Send Journal Entry (SNDJRNE)] would be
a good place for logging, and auditing [using the QAUDJRN journal] is
probably already a direct and probably better means, and auditing is
something every system should have in effect anyhow; noting however, use
of a data area, even with stored data vs /logged/ entries, events could
be logged as separately visible values by having journaled [Start
Journal Object (STRJRN)] the data area.

> Any suggestions?

If the means is allowed to be disruptive, then likely just rename
(RNMOBJ) and\or move (MOVOBJ) the CLP; unless the *PGM is invoked by
address, which is unlikely except invoked via some registered
exit-point, such that the program is a user-exit; the source of the
program would be telling, if that were the purpose of the program. The
failure [of the user] to invoke\call should result in an error that
manifests as a help-desk inquiry to resolve; the "not found" error will
identify the program\screen that failed to locate that program by name.

Similarly, the existing program can be replaced [an effective Trojan
Horse]; depending on the availability of source, the replacement program
could log and then optionally Transfer Control (TFRCTL) to the
renamed\moved program. The design could be either disruptive, or not.

--
Regards, Chuck

[Gary Segal]

Thank you, so there is no easy way out.
Thanks
Have a good weekend

[CRPence]

On 18-Jul-2014 16:15 -0500, Gary Segal wrote:
> On Friday, July 18, 2014 12:34:09 PM UTC-4, Gary Segal wrote:

>> <<SNIP>>
>> Any suggestions?

>
> Thank you, so there is no easy way out.

Was that response intended as a reply to my comments; the threading
and quoting both suggest a reply made to the OP\self, not a reply to any
commentary about there being no simple solution.? I hardly meant to
imply that there is no easy means to determine what program was
responsible for calling another; quite the opposite really. What
options are the easiest or even capable of being implemented, are wholly
dependent upon the requirements and capabilities specific to the
scenario. Without knowing the specifics, I offered generically what
might be done given some varied requirements [e.g. intrusive vs
non-intrusive] and available capabilities [e.g. access to the source];
the easiest IMO, in either case of those two "e.g.", would be to
implement auditing because auditing is non-intrusive and does not
require any access to the program source.

--
Regards, Chuck

[jse...@yahoo.co.nz]

On Saturday, 19 July 2014 09:15:57 UTC+12, Gary Segal wrote:
>
> Thank you, so there is no easy way out.
>
> Thanks
>
> Have a good weekend

Depends on what you call easy.
As Chuck mentioned, auditing is probably the easiest way to do this.
Change the auditing attributes of the program to *ALL so the system captures read access to the program. You can then extract the ZR entries from the auditing journal and see what is accessing the object.

[njalfi...@gmail.com]

> I need to find out which program calls one of the CLs that is somehow randomly called either by system or by one of the users.
>

My DSPOBJREF tool can find out which programs CAN call the CL program by looking at the program reference information in each library on the system.
You could also use DSPPGMREF for all libraries to an outfile and query the output file.
If you need to find which program called the CL one specific time you could call an API to retrieve the job invocation stack.

Regards
Njål Fisketjøn