|
midrange.com
Alister,
Two items.
One. I agree with your management that the machines will be completely
cycled out every few years. IBM changes the box because of economical
reasons which then get passed on to the customer. This then obsoletes many
of the cards and other hardware. Having been through many upgrades and
currently supporting 7 AS/400 of which none are the same height and width
yet all run V4R5. Machines that weren't being cycled out have had their
division consolidated onto our 730. (And even some that were recently
upgraded! Like the 170 below.)
Two. A 170 we used to have was phenomenally fast in it's backup. Alas we
no longer have it, or DASD history so I can't give that apples-to-apples
comparison but I can give you the following news. We had the 25GB 1/4"
tape drive on it. Several hours were shaved off of the nightly backup and
the periodic complete save. So much we could not believe that the save was
good and did testing on it. We have a couple of 720's which also use the
25GB 1/4" tape drive and give thanks to God for it. Here are the history
on these machines:
Here is the before and after on one 720 after upgrade to 25GB (no processor
upgrade involved):
Date of Length of Length of Length of Length of Length of Length
of Length of Total
Downtime RCLDLO RGZDLO RCLSTG SAVSYS NONSYS SAVDLO
SAV of IFS Length
2000-11-17 45 13 40 1
4 1:45
2000-09-22 1 42 1:35 7:15 4
26 10:05
Here is the before and after on the other 720 after upgrade to 25GB (a
processor upgrade was involved):
Date of Length of Length of Length of Length of Length of Length
of Length of Total
Downtime RCLDLO RGZDLO RCLSTG SAVSYS NONSYS SAVDLO
SAV of IFS Length
1999-12-17 3 48 11 34 1
4 1:43
1999-10-22 4 56 1:17 5:50 12
28 8:49
Our operator went home early and I forget what tape drive they used to
have.
Rob Berendt
==================
Remember the Cole!
MacWheel99@aol.com
Sent by: To: MIDRANGE-L@midrange.com
owner-midrange-l@mi cc:
drange.com Subject: Re: IBM Save 21 &
GO BACKUP
12/26/00 12:48 PM
Please respond to
MIDRANGE-L
From MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
Al Barsa will probably say there is a bug to be reported here.
I expect a backup that runs smoothly with no hassles so that when I am not
there taking care of it personally, there are zero problems.
Once I have something, in which the crew that does my job when I am not
there, manages to do it Ok without mishap, I do not want to rock that boat.
I also want a backup that runs in a reasonable amount of time.
When we were on AS/436 until December 1999, we ran SAVE 21 approx twice a
month, to get everything & it took almost 4 hours, and we ran GO BACKUP of
all our application stuff that changed daily & our modifications & so forth
&
it took about 1/2 hour to run. In both cases there's some other stuff we
do
first, like ending M36 but that takes no time at all.
When we switched to AS/400 model 170, some stuff ran faster, some ran
slower.
GO BACKUP of the same stuff went from 1/2 hour to 5 hours.
GO SAVE 21 of everything went from 3 hours to 1 1/2 hours
So we switched to SAVE 21 every nite.
I speculated that GO BACKUP on the new box was saving individual libraries
by
some start stop process rather than smoothly get everything that is
relevant
to be saved & copy continuously like GO SAVE.
I asked our Hardware Support how come the same Application Software that
they
were finger pointing at being why running less efficiently, ran faster on
the
AS/436 than this "faster box", when we had not changed the software ... I
was
only looking at it now to see if I could help it with new logical paths
etc.
because performance was in the toilet & the answer had to do with the
OS/400
upgrade made at the same time in which we needed to add the data base
performance PTFs. I was grateful for having my attention called to some
performance tuning issues that I had been neglecting too long, but was
still
miffed that application software would run more slowly on a hardware
upgrade,
a reality that I had thought was history for MIS to have to be concerned
with.
Now there were a bunch of other things going on, so after the other stuff
was
fixed, we never did go back to benchmark the GO BACKUP story
Our Hardware Partners messed up by their new sales rep not having access to
the history of upgrades to our box, that were made as a result of the
sizing
questionairre that the new sales rep did not have access to either, so
various promises were made about the 170 based on comparing it to the base
436 before a bunch of memory & faster processor added to it. We were
complaining bitterly about various things marketing promised to run 1300
times faster that were actually running significantly slower, but it wasn't
until I was at a 400 user meeting saying something very negatively publicly
about our new LEMON 400 that IBM lit a fire under our Hardware Partners &
got
the problem fixed.
In my judgement the final fixed model 170 box runs perhaps 1.3 times faster
overall than the old AS436. This 1300 percent increase in speed business
is
a marketing game to confuse the numbers.
I have told my management repeatedly that replacing the AS/400 box every 3
years or so is using PC mentality on AS/400 investment. The AS/400 is
designed so that hardware improvements can be plugged in & immediately
applies to the whole box, not like replacing a PC motherboard which limits
what gets the benefits. It does make sense to me to totally replace PC
hardware every 2 years or so. It does not make sense to me to do this with
the 400. I believe that just as we might upgrade OS/400 every 3rd release,
we should upgrade the box every other year, and replace the box every 8-10
years. We should replace the box when there is some new IBM technology
that
we just have to have, not because we replacing all our PCs every few years
or
we hear some sales promises with nothing substantial to back them up. I
sometimes say that we are not a company that can afford to have bonfires
with
our money. Management does not agree with me on my analysis of our
choices.
We had spent a pretty penny in a variety of tapes for the 436 & now we went
from two tape drives (QIC due to M36 & 8 mm which had been sold to us on
the
notion that it was high speed high productivity) to a new kind of QIC using
MLRI tapes (which was sold to us on the notion that it was superior to
either
of the prior tape drives & also everything on our DASD would fit on one
backup tape) but now if we needed to copy back on-line stuff that had been
stored off-line on the 8 mm tapes, there would be a hassle & even fee to
get
that copied to compatible tape, and I was getting erroneous tape error
messages approx 1/3 of the time on the old QIC tapes for 436 ... I had just
added to our collection while management was negotiating this surprise &
had
I known a couple months earlier that this was coming down, I might have
saved
the company a chunk of bucks on buying tapes that the 170 cannot process.
Bottom Line, I think GO BACKUP is really cool,
but SAVE 21 works better for us right now
This reality might switch again on the next 400 box we get. We will see.
I am still doing my MIS job from twinax reality, although now more than 1/2
our users are on PCs. This means some tools not readily accessible to me.
I
imagine GO ASSIST is probably similar to Operational Assistant.
> From: JOLLIGES@SMURFIT.COM (Olliges, James)
>
> Al,
>
> Why not use the OA (Operational Assistant) GO BACKUP menu instead? It
> does the ENDSBS processing, Change QSYSOPR message queue notification,
etc. under the covers from one menu.
>
> James A. Olliges
> Smurfit-Stone ITD Chicago
> jolliges@smurfit.com
MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax
interactive & batch) @ http://www.cen-elec.com Central Industries of
Indiana--->Quality manufacturer of wire harnesses and electrical
sub-assemblies - fax # 812-424-6838
+---
| 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.
