|
I'm treading on thin ice here since I've always worked in shops with 24x7 operations... The last time I retrieved the source for the GO SAVE option 21 it consisted of: SAVSYS SAVLIB *NONSYS SAVDLO SAV Couldn't you create a batch subsystem "SPARKy" with it's own jobd, jobq, etc. and create a backup script to be run from the console? You'd bring the system to it's restricted state then bring up only subsystem SPARKY and submit a CL to SPARKY's queue that would run the equivalent of the save option 21. The last steps in the CL would be to bring bring down SPARKY and bring up the whole system. Once submitted you could sign off and go home. I'm sure I'm oversimplifying. The one weak link has got to be "bring the system to it's restricted state then bring up only subsystem SPARKY", since I'm unsure if you could start that subsystem from the restricted state. If I still had a spare AS/400 to play with I'd try to work out how to bring the system from a restricted state to a "minimally unrestricted state" with no TCP/IP, network services, interactive subsystem, QSPL, etc -- just SPARKY. Perhaps you could code your system startup script to conditionally bypass bringing up most of the good stuff based on a mode bit or flag in a data area. Then you would either start QCTL in backup mode or normal mode. We're at the point where we need to gut the Save option 21 anyway. It takes too long with all our data. I'm gonna have to figure out if I really know what I'm talking about so that I can split the SAVLIB *NONSYS into two batch streams to two 3590 tape drives. I'll let you know if it's easy, or if it's Advanced AS/400 System Administration. -Jim Manager - Technical Administration Dollar General Corporation <mailto:jdamato@dollargeneral.com> -----Original Message----- From: D.BALE@handleman.com To: MIDRANGE-L@midrange.com Sent: 5/25/01 5:06 PM Subject: RE: backups on AS/400; part2 Well, H*LL YES, Jim, we AS/400 bigots *ARE* spoiled, I freely admit. Unlike yourself, some of us have no idea of the headaches involved in managing other platforms, although managing my own Windows desktop makes me very thankful for the reliability and relative ease-of-use of the AS/400. Although I have a clue based on the system problems that are broadcast throughout the company email - "Database AB-123 has to be reloaded." or "The Oracle Financial system has crashed and will be unavailable until further notice." These type of messages come at us several times weekly. I've never seen one for our AS/400 systems in the 9 months I've been here. But I digress. "Do we expect too much?" you ask. Yes, you see a lot of griping about IBM on this list sometimes, some of it valid, and others, well, everybody has a soap box, right? Better to have high expectations than to live with the expectations we all put up with something like Windows. "Hey, no Windows BSOD today? Today was a good day, indeed! Wait til I tell my friends!" Sorry, got on the reliability track again. In regards to the idea of being able to perform a reliable, "guaranteed", CYA backup and being constrained to having to do it interactively at the system console, well there's just no way around that, according to IBM. (Al Barsa has informed me that TAA tools does, in fact, have a save function that would help out here.) I've already mentioned the plight of being a small shop without a night operator. IBM has to know that there are a lot of these type of sites out there. Maybe they're just too small for IBM to lose any sleep over the possibility of losing them as a customer? Why is it so difficult to do this properly? IBM recommends SAVE 21 as the "complete" backup. You must do it in a dedicated state and do it interactively. Knowing that, does IBM expect everyone to follow this critical recommendation on a regular basis? - Dan Dan Bale says "BAN DALE!" IT - AS/400 Handleman Company 248-362-4400 Ext. 4952 D.Bale@Handleman.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.) -------------------------- Original Message -------------------------- As a seasoned AS/400 bigot who has recently been asked to manage Unix systems I find myself on the fence on these issues. It drives me crazy that every time we change a drive in our HP tape library my Unix Administrator has to drop everything and reconfigure the backups. The layered software for configuring backups requires that we do it at the correct moment in time -- it's not even possible to rewrite the backup in anticipation of changes. And don't even talk to me about degree of training necessary to set up a good Oracle backup. On the other hand it's starting to surprise me how much we expect OS/400 to do for us. GO SAVE option 21 is just a CL program. AS/400 documentation provides a nice poster explaining the different levels of backups, and the SAV* commands allow you to design backups from a conceptual (or object based) point of view rather than chasing down disks, volumes, and directories. I don't think you have to be a certified AS/400 Sys Admin to design an effective backup. My relatively untrained AS/400-VMS Admin came up with a good CL to save data libraries, including SAVACT in pretty short order. Maybe I'm biased because I've always worked in very large shops. I don't think it's unreasonable to expect customers to live within the constraints of the canned options or write their own customizations. The menu options on the AS/400 evolved from next to nothing over the past decade or so. I always looked at them as "serving suggestions". Or maybe I'm just cranky because it's been a long week. James Damato Manager - Technical Administration Dollar General Corporation <mailto:jdamato@dollargeneral.com> -----Original Message----- From: D.BALE@handleman.com [mailto:D.BALE@handleman.com] Sent: Friday, May 25, 2001 12:13 PM To: MIDRANGE-L@midrange.com Subject: Re: backups on AS/400; part2 Al, maybe you've been around the block way too many times to count on this issue, but what's your take on the fact that a SAVE 21 type of save, one requiring a dedicated system with all subsystems ended, must be run interactively from the system console? I find it ridiculous that, after all these years, IBM still has not given us a solution to this gaping hole. Do others feel that way? Most shops I know of can only do a dedicated system backup (which, IMHO, is the only sane way to do a backup; your comments on SWA considered) off hours in the middle of the night, and the only way I've been able to figure out how to accomplish this is to sign on to the console prior to leaving for the day and start the backup application that waits until late at night to start the ENDSBS *ALL and run the backup. Most AS/400 shops aren't big enough to be able to justify the expense of a night operator. The so-called way to secure this is to lock the console using the key on the display. It would seem to be a no-brainer (well, consider who's talking here, o.k.?) to allow a batch job to run from the controlling subsystem in a restricted state. But what do I know? I have taken a renewed interest in this pet peeve of mine, considering my new responsibilities. - Dan Dan Bale says "BAN DALE!" IT - AS/400 Handleman Company 248-362-4400 Ext. 4952 D.Bale@Handleman.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.) +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@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.