|
midrange.com
Oh, well...
I think a disclaimer is in order - whatever I say in this list is just my
personal opinion and can't be perceived as an official IBM statement.
It was my impression that this forum is for informal exchange of thoughts
and experiences.
Otherwise I would be almost impossible for IBMers to be participants in
this list.
There are other channels for formal IBM-endorsed statements - Information
Center, Support Line etc.
And what I say here is mostly just my personal experience - and I can be in
error.
Having said that and now returning to a subject...
I think you are right, that when you see an object in QRPLOBJ and do not
know exactly how it is used and why it is there, it would be potentially
dangerous to delete it - this is probably true of any other object on
system.
I am not an authority on PTF application and I am not aware of any
guideline regarding QRPLOBJ use.
What I have done - I ran PTF application process through various stages and
looked what happened.
PTF application itself does not use QRPLOBJ.
Objects are moved to QRPLOBJ only when you permanently apply or permanently
remove PTFs.
You are in danger clearing QRPLOBJ, if some job still uses one of these
objects.
Now from practical point of view - PTFs are very rarely removed (especially
permanently removed). As for permanent PTF application - normal practice
(CUM application or applying some individual PTF) is to apply PTFs
temporarily and leave them in this state for a long time until next CUM -
most probably several IPL cycles.
This is why I said that for all practical purposes it is safe to clear
QRPLOBJ.
Best regards
Alexei Pytel
thomas@inorbit.com
Sent by: To: midrange-l@midrange.com
midrange-l-admin@mi cc:
drange.com Subject: RE: CLRLIB QRPLOBJ??
(was Re: IPL
regains storage.......but)
08/27/2001 09:06 PM
Please respond to
midrange-l
Alexi:
The following is a quote from a normally totally reliable IBMer on
technical issues from just over a year and a half ago:
"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."
The statement was made outside of any support channel because the subject
was raised informally; therefore, there's no reason to mention who said
it.I raised the issue then because I recalled warnings from IBM in earlier
releases and couldn't recall any specifics. It is perfectly possible that
the statement is obsolete for any release of OS/400 commonly in use today.
However, I have a couple specific concerns.
First, there is no doubt that system objects do get placed in QRPLOBJ under
some circumstances. Second, a primary use of QRPLOBJ is to hold objects
that may be in use and therefore cannot be directly deleted without
'unpredictable results'; by moving the objects to QRPLOBJ (even including
renaming the objects), resolved pointers can continue to be used by active
processes. This use can be seen by examining call stacks of jobs that are
using such objects. An additional, secondary use is to hold objects that
might need to be recovered quickly.
As long as system objects may end up in QRPLOBJ, I will always be wary of a
CLRLIB. This is simply because they show up in there and I can't know why
they weren't directly deleted.
Beyond that, even if there is no specific instance of potential trouble in
current implementations of OS/400, I'm aware of no guarantee that a brand
new PTF or OS/400 release that I apply tomorrow won't be a problem. If
QRPLOBJ is used by Rochester developers, I'm going to respect standard
usage. I have to assume that the object should not be deleted outside of
the basic use of QRPLOBJ which allows for objects to be recovered up to the
next IPL.
I easily agree that objects I can identify from my own development work are
candidates for deletion whenever I choose because I chose to put them
there. But I sure ain't going to advise anyone to do a CLRLIB without
investigation. I have to recommend that the only objects to delete are ones
you can identify.
If you want to make a flat recommendation to clear it at any time, be my
guest. You probably have better sources than I have. But I hope you'll also
supply a published reference in official documentation. I'll gladly take up
the practice if IBM officially condones it. Given contradicting indications
from IBMers I respect, I think it's worth resolving.
Tom Liotta
On Mon, 27 August 2001, "Alexei Pytel" wrote:
>
> I've had to do some investigation.
> I was wrong in my previous post.
> The bottom line is PTF process moves data to QRPLOBJ only if it is not
> supposed to be used anywhere on system.
> So as far as system itself is concerned it is safe to clear QRPLOBJ
> anytime.
>
> Alexei Pytel
>
> "The better is the worst enemy of the good"
>
>
> ----- Forwarded by Alexei Pytel/Rochester/IBM on 08/27/2001 11:53 AM
-----
>
> Alexei Pytel
> To: midrange-l@midrange.com
> 08/25/2001 cc:
> 06:26 PM From: Alexei
Pytel/Rochester/IBM@IBMUS
> Subject: RE: CLRLIB
QRPLOBJ?? (was Re: IPL
> regains
storage.......but)(Document link: Alexei
> Pytel)
>
>
>
>
>
>
>
>
>
> When PTF is applied - say a program object is replaced - the old object
is
> moved to QRPLOBJ.
> In this way jobs which were using old program will continue to use it.
> Deleting a program when some job is executing instructions from this
> program, will cause the job to fail.
> This is why PTF process uses QRPLOBJ.
> It is safe to clear QRPLOBJ at IPL time, because there are no jobs using
> any object from QRPLOBJ.
>
> Earlier in this thread Tom Liotta said that you should be careful what
you
> remove from QRPLOBJ - very true.
>
> Best regards
> Alexei Pytel
>
> "The better is the worst enemy of the good"
>
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone 253-872-7788
Fax 253-872-7904
http://www.400Security.com
___________________________________________________
The ALL NEW CS2000 from CompuServe
Better! Faster! More Powerful!
250 FREE hours! Sign-on Now!
http://www.compuserve.com/trycsrv/cs2000/webmail/
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
