Re: Checking if a program is active

Checking only the invocation stack of all jobs is inadequate, because
in OS/400, programs such as RPG can "exit" with LR=OFF, thus'
staying "active", or in MI assembler terms, they can return or exit
without issuing DEACTPG.  In that case, these programs are still
"activated" (as in, activation groups, whether we are talking about
the "default activation group" for OPM *PGMs, or some "named"
activation group for ILE *PGMs and *SRVPGMs.

Unfortunately, IBM does not yet provide any APIs or any other
documented way to find these "activated" *PGMs, that I am aware
of, without going "below the MI".

This is a potentially major flaw in OS/400, because, for example, if
you issue a RSTOBJ for a *PGM in a "production" library, and
that *PGM happens to be "in use" ("activated"), RSTOBJ will
destroy the existing *PGM object (issues an MI DESPG instruction)
before restoring the new version.  Then, eventually, one or more
other jobs will "fail" with various MCHxxxx errors, such as my
personal favorite, "MCH3402 Tried to refer to all or part of an object
that no longer exists."

----- Original Message -----
From: "Bernard Burchell" <bburch@connexus.net.au>
To: <mi400@midrange.com>
Sent: Monday, November 11, 2002 3:48 PM
Subject: Re: [MI400] Checking if a program is active


> Harry,
>
> I have a shareware tool called 'Programs in Use' that can do this.  One of
> its features is the ability to search all jobs to see if a program is in a
> call stack (invocation stack).  It runs either as a display program or can
> be called in API mode.
>
> Normally you would not get an error from renaming an active program
because
> their are no locks against it, and because its address in memory does not
> change when it is renamed.  So the job running it is not aware of it being
> renamed, until it tries to call it a second time, then it will not find
it.
> But if it is a system program being referenced from the SEPT, the system
> does not care about the object name, only its address.  Although I would
> avoid renaming system programs.
>
> Bernard Burchell
> Precosis Pty Ltd
> http://www.precosis.com
>