Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

*PGM object locks

242 views
Skip to first unread message

Larry Paque

unread,
Jan 4, 2000, 3:00:00 AM1/4/00
to
We'd like to periodically delete programs from QRPLOBJ. We have not been
able to find a way to determine if a program is in use, though, since the
object doesn't get locked. Is there a way to determine "in-use" status for
a program object that we don't know about?

Thanks,
Larry

john smith

unread,
Jan 5, 2000, 3:00:00 AM1/5/00
to
The easiest way is to use the WRKOBJLCK command,alternatively you can look
at the last used date by using the command DSPOBJD

C
Larry Paque wrote in message ...

Bernard Burchell

unread,
Jan 5, 2000, 3:00:00 AM1/5/00
to
Larry,

Have a look at 'Programs in Use' which can be downloaded from
http://www.precosis.com.au .

This does what you are after.
In this case you would put: WRKPGMINU QRPLOBJ/*ALL and that will list any
programs running in QRPLOBJ.

By the way, WRKOBJLCK won't work on programs.

Tim

unread,
Jan 5, 2000, 3:00:00 AM1/5/00
to
Why? An IPL will clear this library

"Larry Paque" <la...@paque.net> wrote in message
news:uwyc4.837$F74....@nntp1-sf.pbi.net...

Larry Paque

unread,
Jan 5, 2000, 3:00:00 AM1/5/00
to
Thanks, but from what I can see, though, this does not completely solve the
problem. It looks for the program in the call stack. From my
understanding, this is not enough because the program might still be in
memory because it might have returned with *INLR = *off.


"Bernard Burchell" <burc...@REMOVETHISconnexus.net.au> wrote in message
news:3872...@news.internex.net.au...


> Larry,
>
> Have a look at 'Programs in Use' which can be downloaded from
> http://www.precosis.com.au .
>
> This does what you are after.
> In this case you would put: WRKPGMINU QRPLOBJ/*ALL and that will list
any
> programs running in QRPLOBJ.
>
> By the way, WRKOBJLCK won't work on programs.
>
> Larry Paque wrote in message ...

Larry Paque

unread,
Jan 5, 2000, 3:00:00 AM1/5/00
to
We run a 24-7 shop and are not able to IPL very often.

"Tim" <scot...@home.com.xyz> wrote in message
news:VtHc4.2$9m1...@news1.rdc1.ne.home.com...


> Why? An IPL will clear this library
>
> "Larry Paque" <la...@paque.net> wrote in message
> news:uwyc4.837$F74....@nntp1-sf.pbi.net...

Larry Paque

unread,
Jan 5, 2000, 3:00:00 AM1/5/00
to
Thanks for the link. I don't think knowing that the program is not
currently in a program stack is enough, tho. The program might still be in
some job's memory because it might have returned with *INLR = *off.

"Njål Fisketjøn" <n...@figu.no> wrote in message
news:edn77sk9s3mktif8g...@4ax.com...


> On Tue, 4 Jan 2000 19:03:41 -0800, "Larry Paque" <la...@paque.net>
> wrote:
>
> >We'd like to periodically delete programs from QRPLOBJ. We have not been
> >able to find a way to determine if a program is in use, though, since the
> >object doesn't get locked. Is there a way to determine "in-use" status
for
> >a program object that we don't know about?
> >
>

> I have put some source code on my web pages at
>
> http://www.robin.no/~nfisketj
>
> for a command called DSPACTPGM that does this. Hope that it's useful.
>
>
> Njål Fisketjøn, FIGU DATA AS
> n...@figu.no
> http://www.robin.no/~nfisketj

Larry Paque

unread,
Jan 5, 2000, 3:00:00 AM1/5/00
to
Yes, QRPLOBJ can be used for recovery and I have done so. However, since we
have a source control system in place, previous versions of the program can
virtually always be created if necessary.

We are a 24x7 shop so we don't get the opportunity to IPL as often as we
would like. We also have 4 programmers recreating programs every day.
That adds up over several weeks. While it may be "minimal at best" in your
shop, the space recovered will be of significant value to us.

Larry

"Thomas" <tho...@inorbit.com> wrote in message
news:850udc$u6g$1...@nnrp1.deja.com...
> Further, this library provides a very nice recovery for programs
> recompiled with bugs; the previous version is more or less immediately
> available. I agree -- why clear *PGM objects from here at all (other
> than by using the system standard means)? Space recovered would be
> minimal at best.
>
> I seem to recall some IBM recommendations against deleting objects from
> QRPLOBJ, but I can't recall any specifics. Could easily be a warped
> memory.
>
> Tom Liotta
>
> In article <VtHc4.2$9m1...@news1.rdc1.ne.home.com>,


> "Tim" <scot...@home.com.xyz> wrote:
> > Why? An IPL will clear this library
> >
> > "Larry Paque" <la...@paque.net> wrote in message
> > news:uwyc4.837$F74....@nntp1-sf.pbi.net...

> > > We'd like to periodically delete programs from QRPLOBJ. We have not
> been
> > > able to find a way to determine if a program is in use, though,
> since the
> > > object doesn't get locked. Is there a way to determine "in-use"
> status
> > for
> > > a program object that we don't know about?
> > >

> > > Thanks,
> > > Larry
> > >
> > >
> >
> >
>
> --
> Tom Liotta
> AS/400 systems programmer
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Thomas

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to

Njål Fisketjøn

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
On Tue, 4 Jan 2000 19:03:41 -0800, "Larry Paque" <la...@paque.net>
wrote:

>We'd like to periodically delete programs from QRPLOBJ. We have not been


>able to find a way to determine if a program is in use, though, since the
>object doesn't get locked. Is there a way to determine "in-use" status for
>a program object that we don't know about?
>

I have put some source code on my web pages at

Tim

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
The problem isn't necessarily that the programs end with LR off it is the
fact that AS/400 HLLs resolve to called programs at program initialization
time unless the program is called with a dynamic call (ie. the program name
is in a variable and not a literal).

So examining the call stack of your active jobs is doomed to failure whether
or not LR is set on. But even if you used dynamic calls everywhere and
always returned with LR off, even so there would be no way to reliably
determine if a program in a library were in use because calling a program
does not place a lock on the program object.

I work for a 24x7 shop (Inbound call center) and only have the oppurtunity
to IPL once a month. We also face the problem of how to roll out new
versions of software and ensuring that everyone gets the most recent
release. The solution we found was to build into the users application a
method such that the operator can initiate a restart of each active users
job.

This is accomplished by setting a flag in a database that has a record for
each active user. The program checks this flag at set points in the program
and if it indicates a restart, the program ends itself in a controlled
manner and its caller (a cl program can issue a RRTJOB command that
effectively ends the routing step and releases all resources in the job.
(this does leave QTEMP alone) and the users application then restarts


"Njål Fisketjøn" <n...@figu.no> wrote in message
news:edn77sk9s3mktif8g...@4ax.com...

Thomas

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
Larry:

Believe me, I understand 24x7. We manage approx 1TB of data at this
data center alone on our AS/400s and downtime for IPLs is at a definite
premium. I couldn't even get approval for downtime for the latest Y2K
group PTFs after mid-December. We're slimmed down right now, but a year
ago we had some 60 developers at this site and the volume in QRPLOBJ
approached the total DASD on the AS/400s at two previous sites I worked.

One previous site was at the data center for a mid-sized city that
handled all city business including all Public Safety. 24x7 was a
necessity. Only 10GB DASD but 6 application programmers plus myself as
systems programmer.

But at no time has QRPLOBJ reached a size that was so significant that
clearing objects from it was any kind of priority. There've always been
numerous alternatives that recovered much more.

An example of one that has become more important in recent releases of
OS/400 is RCLSTG SELECT(*DBXREF). If your developers are making
numerous database changes, the system xref can grow quickly unless you
keep it re-org'd with this. (But note that the SELECT() parm should be
specified unless you really want a full RCLSTG.)

Lots of other choices. But no matter; the system is yours, not mine...
maybe you can settle on a date scheme -- program objects more than say,
5 days old (10? 15?) are deemed expendable. Or maybe you can just
delete a file object or two from QRPLOBJ.

Tom Liotta

In article <ykUc4.1153$lf.7...@nntp1-sf.pbi.net>, "Larry Paque"


<la...@paque.net> wrote:
> Yes, QRPLOBJ can be used for recovery and I have done so. However,
> since we
> have a source control system in place, previous versions of the
> program can
> virtually always be created if necessary.
> We are a 24x7 shop so we don't get the opportunity to IPL as often
> as we
> would like. We also have 4 programmers recreating programs every
> day.
> That adds up over several weeks. While it may be "minimal at
> best" in your
> shop, the space recovered will be of significant value to us.
> Larry
> "Thomas" <tho...@inorbit.com> wrote in message
> news:850udc$u6g$1...@nnrp1.deja.com...

> > Further, this library provides a very nice recovery for programs
> > recompiled with bugs; the previous version is more or less
> immediately
> > available. I agree -- why clear *PGM objects from here at all
> (other
> > than by using the system standard means)? Space recovered would
> be
> > minimal at best.
> >
> > I seem to recall some IBM recommendations against deleting
> objects from
> > QRPLOBJ, but I can't recall any specifics. Could easily be a
> warped
> > memory.
> >
> > Tom Liotta
> >
> > In article <VtHc4.2$9m1...@news1.rdc1.ne.home.com>,
> > "Tim" <scot...@home.com.xyz> wrote:
> > > Why? An IPL will clear this library
> > >
> > > "Larry Paque" <la...@paque.net> wrote in message
> > > news:uwyc4.837$F74....@nntp1-sf.pbi.net...

> > > > We'd like to periodically delete programs from QRPLOBJ. We
> have not
> > been
> > > > able to find a way to determine if a program is in use,
> though,
> > since the
> > > > object doesn't get locked. Is there a way to determine
> "in-use"
> > status
> > > for
> > > > a program object that we don't know about?
> > > >

> > > > Thanks,
> > > > Larry
> > > >
> > > >
> > >
> > >
> >
> > --
> > Tom Liotta
> > AS/400 systems programmer
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


Roland

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
I believe that you can delete a program even if it is in
use without causing any problems to the user - they can
continue to use the program until they sign off.

If you are worried about deleting a program that is being
used regularly then DSPOBJD and check the last used date.

Also programs in QRPLOBJ are only copies of programs and
shouldn't be used from QRPLOBJ in the first place, if you
need to put the program back DUPOBJ it.

I hope this is of some help,
Roland Goldsack.

* Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful

Njål Fisketjøn

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
On Thu, 06 Jan 2000 01:13:06 +0100, Njål Fisketjøn <n...@figu.no>
wrote:

>I have put some source code on my web pages at
>
>http://www.robin.no/~nfisketj
>
>for a command called DSPACTPGM that does this. Hope that it's useful.

Oops, I promise to never put out any source without testing it first.

The program worked once, but OS/400 internals obviously still changes.
:)

Njål Fisketjøn

unread,
Jan 6, 2000, 3:00:00 AM1/6/00
to
On Wed, 5 Jan 2000 18:34:45 -0800, "Larry Paque" <la...@paque.net>
wrote:

>Thanks, but from what I can see, though, this does not completely solve the


>problem. It looks for the program in the call stack. From my

>understanding, this is not enough because the program might still be in


>memory because it might have returned with *INLR = *off.

Create a small program that runs every night (or every week perhaps).
Use DSPOBJD to list all objects to a database file (in QTEMP) and
select objects to be deleted from QRPLOBJ based on the last used date.

Although you run 24 hours 7 days a week, I guess you terminate your
interactive subsystems from time to time to make sure that you don't
have any "unnecessary" jobs "floating around".

Thomas

unread,
Jan 7, 2000, 3:00:00 AM1/7/00
to
Roland:

Before you go about deleting programs that are in use, I suggest you
should try it with a test *pgm object a couple times. I think you might
be confusing the deletion of a *pgm object with the process that takes
place when you recompile a program with the REPLACE(*YES) option. The
two are most definitely *NOT* the same animal. You can test it with a
very simple CL program.

And although I've never actually examined the code that implements
REPLACE(*YES), I can't see any reasonable way that the object that ends
up in QRPLOBJ is a "copy". AFAIK, it is the actual original program
object, but simply renamed and placed in a different library. The simple
fact that it is still accessed by active jobs through the original
pointer pretty much guarantees that.

Finally, running the program out of QRPLOBJ usually isn't a conscious
choice. It's usually a result of a program being placed there through
the REPLACE(*YES) process while it's actively already in use. This
"feature" of OS/400 and its compilers is both a blessing and a curse.
When needed, it's hard to imagine a better tool. But when it comes up
unexpectedly, it can cause some very puzzling debug sessions.

Tom Liotta

In article <02af5b34...@usw-ex0103-019.remarq.com>,

--

Daniel Hicks

unread,
Jan 7, 2000, 3:00:00 AM1/7/00
to
Thomas wrote:
>
> Roland:
>
> Before you go about deleting programs that are in use, I suggest you
> should try it with a test *pgm object a couple times. I think you might
> be confusing the deletion of a *pgm object with the process that takes
> place when you recompile a program with the REPLACE(*YES) option. The
> two are most definitely *NOT* the same animal. You can test it with a
> very simple CL program.

You can "delete" a running RPG program without having it actually go
away. So long as the program is activated it will only be "logically
deleted". It will actually go away when deactivated.

Deleting a running CL program, however, is not advised, as CL is
"reentrant" and the program won't be activated. (NB: "Not advised"
here means the whole system might crash.)

The big danger with RPG is if the program has been resolved to but is
not currently activated. Then the user will get an "object destroyed"
when attempting to call it.

Tim

unread,
Jan 7, 2000, 3:00:00 AM1/7/00
to
I think you have your facts wrong on both counts.

Deleting a program that is currently in use will cause the job to end
whether it is CL or RPG. It won't cause the whole system to crash. This is
OS/400 we're talking about, not Windows

"Daniel Hicks" <danh...@ieee.org> wrote in message
news:38754BE3...@ieee.org...

Daniel Hicks

unread,
Jan 7, 2000, 3:00:00 AM1/7/00
to
Tim wrote:
>
> I think you have your facts wrong on both counts.
>
> Deleting a program that is currently in use will cause the job to end
> whether it is CL or RPG. It won't cause the whole system to crash. This is
> OS/400 we're talking about, not Windows

Why do you think the whole QRPLOBJ thing was invented? I know whereof I
speak.

Tim

unread,
Jan 7, 2000, 3:00:00 AM1/7/00
to
And you are confusing the Replace parameter of the compilers with the DLTPGM
command. I *KNOW* whereof I speak.

"Daniel Hicks" <danh...@ieee.org> wrote in message

news:387565B4...@ieee.org...

Blair Wyman

unread,
Jan 7, 2000, 3:00:00 AM1/7/00
to
Tim wrote:
>
> And you are confusing the Replace parameter of the compilers with the DLTPGM
> command. I *KNOW* whereof I speak.

The issue at hand is running DLTPGM against programs that have been
put into the QRPLOBJ library by virtue of a replace parameter, eh?

And just so you know, Dan designed most of this stuff. ;-)

--
___ _ Blair Wyman (bla...@us.ibm.com) / Ph: 507.253.2891
( /_) / _ ' _ Advisory Programmer, Dept GZAA / TieLine: 553.2891
_/__)_/_<_/_/_/_' SLIC Program Model, IBM Rochester/ VM: RCHLAND(BLAIR)
Opinions expressed are not IBM's

Thomas

unread,
Jan 8, 2000, 3:00:00 AM1/8/00
to
Tim:

Looks like you read what I wrote. I suspect Dan just got a bit ahead of
himself on this one, eh? BTW, your writing style might be a bit strong
for some, but I personally pay attention to your posts. You're an asset
to the NG. (You, too, Dan. But you might need to rethink this one.)

Tom Liotta

In article <Tnld4.742$9m1....@news1.rdc1.ne.home.com>,


"Tim" <scot...@home.com.xyz> wrote:
> And you are confusing the Replace parameter of the compilers with the
DLTPGM
> command. I *KNOW* whereof I speak.
>

> "Daniel Hicks" <danh...@ieee.org> wrote in message
> news:387565B4...@ieee.org...
> > Tim wrote:
> > >
> > > I think you have your facts wrong on both counts.
> > >
> > > Deleting a program that is currently in use will cause the job to
end
> > > whether it is CL or RPG. It won't cause the whole system to crash.
This
> is
> > > OS/400 we're talking about, not Windows
> >
> > Why do you think the whole QRPLOBJ thing was invented? I know
whereof I
> > speak.
>
>

--

Joep Beckeringh

unread,
Jan 8, 2000, 3:00:00 AM1/8/00
to

"Thomas" <tho...@inorbit.com> wrote in message
news:850udc$u6g$1...@nnrp1.deja.com...
> Further, this library provides a very nice recovery for programs
> recompiled with bugs; the previous version is more or less immediately
> available. I agree -- why clear *PGM objects from here at all (other
> than by using the system standard means)? Space recovered would be
> minimal at best.

Tom,

In our company (a software house) the AS/400's are mainly used for
development. Every compile adds to QRPLOBJ. Recently we changed from IPL
every night to once a week, because of an increasing number of night jobs
analyzing software. Believe me, in our case a nightly clearing of QRPLOBJ
(through the scheduler) is essential.

Joep Beckeringh


Joep Beckeringh

unread,
Jan 8, 2000, 3:00:00 AM1/8/00
to
Daniel,

On a few occasions I have deleted CL-programs that were still in use
(mostly, but not always, in other sessions on my own work station). My
experience so far is that these jobs run fine, until they return (or try to)
to the deleted program. Then they crash, of course. I shall try to
remember not to do that again (honest!), but out of curiosity, how big a
risk was I taking?

Joep Beckeringh


"Daniel Hicks" <danh...@ieee.org> wrote in message

news:38754BE3...@ieee.org...

Daniel Hicks

unread,
Jan 9, 2000, 3:00:00 AM1/9/00
to
Can't say for sure. I do know that having an ILE program deleted "out
from under" a job can bring down the system. (It's not supposed to
happen, but things go wrong during development.) Most often, though,
it's caused in the lab by deleting an XPF or LIC program out from under
the job. Whether the system will go down depends on a number of
factors, such as what exception handlers are up, whether there are files
open, etc, and I'm not real familiar with the details.

Technically what happens is that the missing program creates an
exception, and the system exception handler, in handling the exception,
tries to find the "traceback table" of the missing program to know what
was going on at the time of the exception. Of course, the traceback
table comes up missing as well. It can tolerate this, but there are
cases where the missing information is required to put the job back in a
consistent state. If the missing information is critical enough then
the whole system comes down.

Charles R. Pence

unread,
Jan 10, 2000, 3:00:00 AM1/10/00
to
Thomas wrote:
> <<SNIP>>

> I seem to recall some IBM recommendations against deleting objects from
> QRPLOBJ, but I can't recall any specifics. Could easily be a warped
> memory.

Because OS/400 may use QRPLOBJ to replace its own programs, the primary
consideration is to avoid deleting programs which the system may be
using. Most typically this would be a concern for *IMMED PTF applies.

Regards, Chuck
All comments provided "as is" with no warranties of any kind whatsoever.

0 new messages