× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dennis,

A few thoughts:

- If you want to save changed objects, then the system will need to
examine each object and determine whether it meets the save criteria.
The number of objects becomes more important than the size of those
objects.  A few thousands of objects in your data file libraries really
won't matter much compared to some of your program libraries.  It makes
sense to me that these don't have much of a time impact on the overall
save, regardless of the size of the objects.  You might have more
success if you could find some stable libraries with more objects which
you could omit.

- The difference between pre- and post- upgrade may well be related to
the number of objects in some IBM-Supplied libraries.  Despite the
*ALLUSR designation, the libraries listed below are included in such a
save and may well have increased in object count:
QDSNX      QRCL      QUSRIJS    QUSRRDARS
QGPL     QS36F     QUSRINFSKR QUSRSYS
QGPL38   QUSER38   QUSRNOTES  QUSRVI
QMPGDATA QUSRADSM  QUSROND    QUSRVxRxMx
QMQMDATA QUSRBRM   QUSRPOSGS
QMQMPROC QUSRDIRCL QUSRPOSSA
QPFRDATA QUSRDIRDB QUSRPYMSVR

- I would expect a system to be fairly useless for many purposes when
locks are placed on QGPL and QUSRSYS.

There's obviously no answer to your 'fitting the save into it's previous
time window' problem here, but I think that it is understandable.

Regards,
Andy Nolen-Parkhouse

> On Behalf Of Dennis Munro
> Subject: RE: SAVCHGOBJ question - rephrased
>
> Let me rephrase my question.  SWA was just a question & not something
I
> want
> to get involved in because it doesn't make sense in out organization.
I'm
> just trying to get my problem solved!
>
> What I am trying to determine is the length of time the "lock" is
placed
> on
> the system in reference to the statement below.
>
> <snip>
> As I read through the help for the SAVCHGOBJ command, it says
"Specified
> objects that were changed and the libraries where they reside remain
> locked
> during the save operation".
> <snip>
>
> Obviously it didn't work last night either otherwise I wouldn't be
here at
> work trying to get this fixed & truly understand my problem.
>
> The only thing I can "assume"  (don't you love that word because that
is
> how
> I feel) is that when the SAVCHGOBJ command starts, the "whole" system
is
> locked???????????  And I just don't want to believe IBM would do that
-
> but......  All I can see from my job logs is that I have a timing
issue.
> I
> will redo my CL program by putting in a "delay" of a couple of minutes
&
> the
> two other jobs that run via the job scheduler will execute at an
earlier
> time than the SAVCHGOBJ - during the delay I just created.
>
> Another thing I found was that the SAVCHGOBJ OBJ(*ALL) LIB(*ALLUSR)
> command
> takes the SAME AMOUNT OF TIME as the same command  with the parm
> OMITLIB(BPCSF BPCSUSRF) included.  The library BPCSF is almost the
largest
> object on my system & I'm thinking the SAVCHGOBJ should get done
sooner
> omitting those two libraries.  Both commands process through my user
> libraries in 31+ minutes.  Why is that?
>
> Thanks - Dennis.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.