Re: backups on AS/400; part2 -- MIDRANGE-L

The only problem with this is the SAVSYS command must be run from an
interactive job.

Eric Graeb
System Operations

----- Original Message -----
From: "Jim Damato" <jdamato@dollargeneral.com>
To: <MIDRANGE-L@midrange.com>
Sent: Monday, May 28, 2001 1:19 PM
Subject: RE: backups on AS/400; part2


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

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