Re: IBM Save 21 & GO BACKUP -- 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
+---