|
Multi-library saves work as follows: 1). Library 1 locks (No tape movement) 2). Library 2 locks Library 1 saves to tape 3). Library 3 locks Library 2 saves to tape Library 1 unlocks 4). Library 4 locks Library 3 saves to tape Library 2 unlocks ... Each line must totally complete before going to the next line. Locking time is proportional to the number of internal objects in the library, and has nothing to do with size. Save time is almost totally based on size, and has relatively little to with the number of internal objects, This locking technique is used regardless of save device or save command. You can only save one library at a time to a save file. Al Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com |---------+-----------------------------> | | Dennis Munro | | | <DMunro@badgermini| | | ngcorp.com> | | | Sent by: | | | midrange-l-admin@m| | | idrange.com | | | | | | | | | 09/14/2002 10:35 | | | AM | | | Please respond to | | | midrange-l | | | | |---------+-----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: "'midrange-l@midrange.com'" <midrange-l@midrange.com> | | cc: | | 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. Dennis Munro "I love deadlines. I especially like the whooshing sound they make as they go flying by." Dilbert's Words Of Wisdom: Badger Mining Corporation www.badgerminingcorp.com dmunro@badgerminingcorp.com (920) 361-2388 -----Original Message----- From: Al Barsa [mailto:barsa@barsaconsulting.com] Sent: Friday, September 13, 2002 4:01 PM To: midrange-l@midrange.com Subject: Re: SAVCHGOBJ question My suggestion is not to mess with SWA unless you *REALLY know what you're doing. If anyone wants a copy of my COMMON session on SWA, or my article that I wrote for the experts journal, send me a *PRIVATE note. Al Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com Dennis Munro <DMunro@badgermini To: "Midrange List (E-mail)" <MIDRANGE-L@midrange.com> ngcorp.com> cc: Sent by: Subject: SAVCHGOBJ question midrange-l-admin@m idrange.com 09/13/2002 08:13 AM Please respond to midrange-l 820 running V5R1M0 installed two weeks ago with all the latest group ptf's. I have been having a problem with my day end processing since then & I am not sure why. The following is a time line of what runs at what time. I do a SAVCHGOBJ OBJ(*ALL) LIB(*ALLUSR) DEV(TAP02) ENDOPT(*LEAVE) ACCPTH(*YES) which starts about 23:30 & takes about 45 minutes to run At 23:50 I have another job scheduled to run & the first thing it does is a CHKOBJ to verify the existence of a data area in QGPL. It is timing out (120 seconds) with an MCH5802 - Lock operation for object DEPPARM not satisfied. 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". Is this saying that "ALL" the changed objects & the libraries they are in are locked for the total duration of the SAVCHGOBJ? At least that is what I am reading it to say. And has it always been that way? Yes, I did change one thing that makes the SAVCHGOBJ run longer. But today I removed/omitted two data libraries (BPCSF & BPCSUSRF) from this command because I save them in total daily as a save file which then gets saved to an 8mm tape. And these libraries are almost the largest objects on the system. Just curious if the SAVACT(*SYNCLIB) would be a better way to go because right now it is at *NO. Then I read the note for *SYNCLIB & wonder how much time that will add to the save operation?? Or will just not processing the two largest libraries get it done in time before the CHKOBJ runs? I really would have trouble getting more time from the users (23:15 through 00:05) daily to run day end/backups/etc. where it used (pre v5r1m0) to work just fine. Hopefully omitting the two libraries from the SAVCHGOBJ will get my time line back in order. If not, back to the drawing board this weekend. Thanks - Dennis. Dennis Munro "I love deadlines. I especially like the whooshing sound they make as they go flying by." Dilbert's Words Of Wisdom: Badger Mining Corporation www.badgerminingcorp.com dmunro@badgerminingcorp.com (920) 361-2388 _______________________________________________ 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 Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ 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 Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ 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 Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
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.
midrange.com
