|
midrange.com
Yes.
And to verify, change the initial program to one that only does a DLYJOB
and try to hack out of that.
Rob Berendt
==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.
D.BALE@handleman.co
m To: MIDRANGE-L@midrange.com
Sent by: cc:
owner-midrange-l@mi Subject: RE: backups on
AS/400; part2
drange.com
05/29/01 10:47 AM
Please respond to
MIDRANGE-L
As you may have already surmised, I *have* written the CL (but only for a
secured system console), but I expect to have to answer to management as to
why the system console has to be signed on and left unattended for several
hours in an unsecured location while it waits for the second shift to call
it
quits around 1a.m.
So, let's suppose I create a special SAVEUSER user profile. It has an
initial
program that prompts the user for the parameters by which the backup should
be
run, including a DLYJOB RSMTIME(x) before the system is ended to a
restricted
state. The program ends with a SIGNOFF. The user profile's initial menu
is
*SIGNOFF. Does that cover all the bases for restricting anyone from being
able to issue a system request #2 "End previous request"?
Dan Bale
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 --------------------------
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
+---
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.
