System IPL -- DON'T IPL

Rob,

You also bring up some good points and some key questions.

We use BRMS to do our daily and weekly saves via many 3590 tape 
drives.  Our interfaces into BRMS allow us to bring down certain 
subsystems at a time--QINTERXX and QBATCHXX--that effectively 
lock our users at that location or application program for a 
short time then we push it off to tape. Once the libraries for 
that group are completed, we bring the users back on-line.  Most 
of these outages are very short--under 20 minutes. Our backups 
run all night but only a finite number of users are affected at 
one time.  Our weekly backups are much the same.

We backup security data and configurations weekly but we don't 
do a SAVSYS since this requires restricted state.  We pushed IBM 
hard to modify the SAVSYS command and they did via data areas in 
V3R7 that allow only the "boot" part of SAVSYS to be saved. 
 Since security data and configuration information can be saved 
independently, the SAVSYS runs much quicker.  In V4R1 these are 
command parameters.  As far as the SAVSYS portion of our backup 
plan is concerned, we  run the SAVSYS on only the development 
system. This always has the latest PTF index available.  If we 
need to recover our production systems we can use the 
development SAVSYS portion to "boot" from the use the security 
and configuration data from the actual system backups.  This 
plan future eliminates user downtime since we never reach 
restricted state on our production systems.  In reality, the 
SAVSYS eliminates the need to recover the PTF index and put the 
latest cum package on while recovering.  By the way, a model 500 
or model 510 SAVSYS will recover a model 530 from a "boot" 
standpoint.  And vice versa.

Without going into specifics about V4R1, I can tell you the IPL 
is much faster and cum packages are much easier and faster to 
install--there is only one IPL.  We don't plan to change our IPL 
strategy--we  won't IPL unless we have to--but we may change our 
philosophy on when we IPL.  Currently we use a rolling year 
schedule where we publish a yearly IPL schedule for each system. 
 This is updated quarterly to take into account changes in 
business requirements.  We take one 12 hour outage per year per 
system for release upgrades.  A twelve minute IPL in V4R1 will 
allow us to do some finer adjustments within our schedule.

The goal is to have the AS/400 available as much as possible to 
our  user community. We lean on IBM very hard to help us attain 
this goal.  So far, they are listening.

Gary




On Wednesday, July 30, 1997 10:28 AM, Rob Berendt 
[SMTP:ROB@dekko.com] wrote:
> Gary,
> You bring up some good points on the basic system maintenance.
>
> We had a system, back when it was CISC, gobbled up temporary
> space and
> HAD to be IPL'd every 4 weeks.  Now, that it is RISC, it is no
> longer a
> concern.  People, keep that in mind when it comes time to
> justify moving
> from a CISC to a RISC box, reduced down time.
>
> We bring our systems down every 8 weeks.  (This has to do with
> our 13,
> four week periods per year; and which weekend is best for
> users).  We do
> an IPL during this time, along with RCLSPLSTG, etc.  At this
> time we also
> bring the systems into dedicated mode and do a complete save.
>  And on all
> systems, except one, we do a RGZDLO, RCLDLO, RCLSTG 
immediately
> prior to
> the save.  Why?  Because we have had the backup blow up 
because
> there
> were damaged objects on the system.  We do have one system 
that
> we skip
> the RCLSTG on because it used to take 10-13 hours.  We run
> several
> versions of BPCS, from 2.1 on up.  We also have Software Plus,
> etc.  All
> versions are on our development machine, which has more DASD
> than many of
> our other systems combined.
>
> I hear that with V4R1 that an IPL now takes less time than it
> took for me
> to type up this response.  So this being the case, why not IPL
> after the
> save?  It takes less time to do the IPL than to argue against
> it.
>
> You do bring up an interesting point about the PTF's.  I'll
> have to think
> about that.  Especially since they keep increasing in the
> length of time
> to install.  Time estimates of 3-8 hours to install, and the
> potential
> for new problems.  That is a good point.  However at any given
> point I
> usually have 15 open problems with IBM and I don't like to 
hear
> 'What
> level of cum are you at?'.  We have more systems than systems
> personnel
> and lining up help to work downtime weekends is a bear.  It is
> strictly
> voluntary, and we almost always get enough volunteers, (comp
> time helps).
>  We did have to go to doing half the systems every 4 weeks.  I
>  try to
> help them out as much as possible.  I've written programs that
> will
> automatically run the following in sequence:  RGZDLO, RCLDLO,
> RCLSTG,
> SAVSYS, SAVLIB *NONSYS, SAVDLO, SAV of the IFS; and log how
> long each
> step takes.  It prompts at the beginning for which tape drive
> to use for
> each save operation.  We normally SAVSYS to 1/4" cartridge and
> the rest
> to the main tape unit.
>
> Gary,
> How often do you do a complete save?
>  ----------
> From:  Gary S. Lagarde[SMTP:MIDRANGE-L@midrange.com]
> Sent:  Tuesday, July 29, 1997 3:30 PM
> To:  ROB; 'MIDRANGE-L@midrange.com'
> Subject:  RE: System IPL
>
>
> I usually enjoy scanning the mail from the AS/400 list server
> and rarely comment but this thread touched on of my hot
> buttons.
>
> There are only five reasons to IPL a system.  Three of these
> reasons have become extinct on V3R7 RISC systems. The five
> reasons to IPL for CISC systems are listed below.
>
> One -- Hardware additions.
> Two -- PTFs that require IPL to become active.
> Three -- Jobs that become hung in the system or hang the
> system
> and require IPL to recover.
> Four -- Running out of temporary or permanent addresses.
> Five -- System automatically does main store dump (MSD).
>
> For companies still on CISC, you have very few options--you
> need
> to IPL when one of the above events occur.
>
> We have been running V3R7 since early GA on our 530 4 ways.
>  One
> of these systems has 4500 users, 500 GB mirrored, 2GB memory
> and
> very heavy communication requirements (TCP/IP and SNA).  There
> are no locally attached users.  The system runs about 15
> million
> transactions monthly.   This particular system ran for five
> straight months without an IPL.  We finally IPLed last weekend
> to put on a PTF cum package and enabled support for network
> computers, etc... I had IBM analyze our address usage before
> the
> IPL and the prediction is that we will last for 25 YEARS
> without
> running out of address space.  We have scheduled our next IPL
> for October.   We have other systems similar to this system
> with
> the same results.
>
> Our new paradigm is to not IPL unless absolutely necessary.
>  We
> do not accept IBM PTFs that require IPL unless there is
> positively no other way to get the code on the box and
> activated.  In fact, when plotting our problem history, we can
> look to IPLs and PTF cum packages as the main cause.  Yes, our
> feeling is that IPLs have the potential to introduce more
> problems than they correct. Of course, we do believe in PTFs
> and
> we do expect some additional IPLs early in a release cycle to
> put cum packages on.  But as a release matures, we feel the
> need
> for cum packages decreases and the problems affecting the
> systems also decrease.  Then the cycle starts again at GA for
> the next release.
>
> By the way, clean up at IPL is minimal.  You can do most of it
> through the use of APIs and commands.  WE DO NOT DO RECLAIM
> STORAGE .  WE WILL NEVER RUN RECLAIM STORAGE.
>
> I ask you to consider the next time you feel the need to IPL
> on
> a V3R7 RISC box, ask yourself "Why am I doing this?"  IPLing
> for
> IPL sake is not necessary.  Think about it.
>
> The only reasons to IPL on a V3R7 RISC system are listed be  
low.
>
>
> One -- Hardware additions other than DASD.  DASD can be added
> dynamically.
> Two -- PTFs that require IPL to become active.  Still a
> problem
> but very few require this on V3R7.
> Three -- Jobs that become hung in the system and require IPL
> to
> recover.  Almost every job can be cancelled or eliminated from
> the system with KILL Job PTFs.
> Four -- Running out of temporary or permanent addresses.  You
> will never run out of addresses again.  Don't even bother
> looking at the statistics anymore.  You will be on another
> Rochester architecture long before you ever hit a quarter of
> total addresses.
> Five -- System automatically does main store dump (MSD).  This
> can still occur but the system will IPL to MSD screen on V3R7
> and in a soon to be announced (V4R1) release the system will
> IPL
> through MSD, dump, and bring the system back up.
>
> Of course, there is always the Oops IPL--usually this is a
> problem between keyboard and chair.  This will only happen
> once
> in my company and there is an employment PTF for that.
>
> If you like to get more info on our IPL strategy, please drop
> me
> a note.
>
> *****************************************************
> Gary S. Lagarde
> Senior Technical Specialist
> Reynolds Metals Company
> 6605 West Broad Street
> Richmond, VA  23230
> Phone:  804-281-4419   Fax:  804-281-4149
> E-mail: gslagard@rmc.com
> *****************************************************
>
> On Friday, July 25, 1997 7:03 AM, Tim Shepherd [SMTP:tshepher
> d@lia.co.za] wrote:
> > >Currently my company (bank) is having AS/400 model 530
> running
> > >v3r6.
> > >Every week my system guy will perform system IPL on Sunday
> and
> > >which
> > >will require to stop  running the machine for about 1- 1.5
> > >hours. My
> > >question is "is it necessary to perform IPL every week ?"
> > > My
> > >DASD
> > >utilization is about 60% of 60GB storage and temp. address
> > >is
> > >about
> > >0.126 and 2Gb of memory.
> >
> > I ipl our machine every Monday at 04:30. I don't really need
> > to, but it
> > keeps the system tidy.
> > I would suggest that you ipl at least once a month though,
> > or
> > if the temp
> > addresses start to rise too high.
> >
> > Tim Shepherd
> >
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *