RE: System IPL -- MIDRANGE-L

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 below.

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   *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
> * * * * *
> umidr
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
uucp

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