|
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 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.