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

Dan

Writing your won CL's to do this is not as hard as it sounds. Making it 
work with the applications you run is the challenging  bit. Integrating it 
with management policy is the complicating factor.

Once you know what applications are running, what data has to be saved and 
what the timetables are, you can write a program that will accommodate all 
this.

IBM has written a program that will save everything - fair enough they have 
to. Can you imagine the complications and complexity it would have had to 
have to take account of every possible permutation of operational practise 
? Essentially they provided the lowest common denominator (at least they 
provided that) and did not attempt to solve the other problem. Nor should 
they in my opinion, at least as part of the OS. Don;t forget that this 
backup running correctly also has to cover IBM's ass and work as predicted 
every time.

As to some practical things you can do to improve this stuff - so you 
aren't working late doubling as the night operator (is this what happens 
<g>) -

Build a CL that will do the saves you want. Make sure by verifying from the 
manual it has what you want. The poster Al referred to (Are you saving the 
rights stuff ?) is really handy.

If you want the job to delay, build in a parameter to pass as the delay.

If you must have it kicked off from the scheduler, well, one way to do that 
is to start a job and make it wait on a data queue before proceeding. Have 
something in the scheduler that sends the appropriate data queue response, 
indicator, command, whatever. I think you will see where I am going with that.

As for problems with it, well I attended my first few till I was confident 
my software worked, then after that I trusted it with the following caveat:

Always check the logs. Always get the printouts. Always check the last line 
of the printouts. Always.

I built in additional logging to my procedures so that there were 
additional places that get checked. I also made sure that the other people 
that deal however indirectly with the AS/400 backups know what our 
expectation is and that and deviation must be bought to my attention. Even 
if they are not sure if it different, just something they don't understand 
or seems wrong. The backup is sacrosanct and we treat it that way.

You can also check whether the system is in a restricted state with an API, 
which will help with the ENDSBS *ALL problem. I like to retrieve a value, 
not muck around with message queues as its much cleaner.

There is also no reason you can't return things to an operational state 
after the restricted portion of the save is completed. If you write the CL 
you have control over this

Hope this provides some food for thoughts

regards
Evan Harris


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