× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Long running backups to a 3590-B11
  • From: Rob Berendt <rob@xxxxxxxxx>
  • Date: Thu, 6 Apr 2000 11:06:51 -0500

And lest you think that Y2K is already past, the last update on 
the group PTF for Y2K was 3/21/00.

For a list of group PTF's:
http://as400service.rochester.ibm.com/supporthome.nsf/Document/10000031

I concur with Al on the restore of access paths.  After having done 
it and waiting about a week for the access paths to rebuild.  Always 
save them.  If you can't afford the down time during the save, you
sure as heck can't afford the week of downtime waiting for the access
paths to rebuild during the restore.

Perhaps you are doing too many complete saves.  We only do it once
every 8 weeks.

Al,
I don't see the group PTF for save/restore at the 
above web site.  Oops I found it,
SF99076 - V4R4 BACKUP RECOVERY SOLUTIONS                                        
Description: BRMS, TA, LD, SR Group PTF                                         
Product:  5769BR1 5769SS1                                                       
Previously I assumed this was strictly for BRMS.  Damn, 
and downtime is this weekend.  I hope I can get it for 
the rest of our 400's in time.
Oh well, obviously this hasn't affected our 3590.  The machine 
running BRMS is on a 3570.





barsa2@ibm.net on 04/06/2000 10:41:08 AM
Please respond to MIDRANGE-L@midrange.com@Internet
To:     MIDRANGE-L@midrange.com@Internet
cc:      
Fax to: 
Subject:        Re: Long running backups to a 3590-B11

At 10:58 AM 04/06/2000 +0100, you wrote:
>Has anyone else had a similar problem -
>
>I have a system with 102GB of DASD, running at about 80% used.  It has
>regularly taken between 11 to 13 hours to do a full system backup each
>weekend (SAVSYS + NONSYS + SAVDLO + SAV (ifs)).  All of a sudden, the
>backups started taking 15/16 hours.  I have recently upgraded to v4r3 (from
>v4r1), initiallly the backups jumped to 28 hours!!  IBM recommended we apply
>additional PTFs, a series of group-ptf packages, this cut the 28 to 18 but
>this is still very painful to system availablility, as you can imagine.
>
>I am liaising with IBM and with the CE; I've stopped saving access paths,
>I'm getting staff to delete old/redundant data, what more can I do?  Has
>anyone had similar experiences or have some advice ?

First of all, go back to saving access paths.  On a system with 102 GB of 
DASD, if you had to rebuild them you would a very unhappy puppy.

Secondly, you need to understand that IBM did a very stupid thing in the 
middle of V4R4, which was to upgrade the database via PTF (i.e.: without a 
version/release/modification change).  I told them not to do this, but they 
didn't listen.

Because this upgrade failed to go through the normal release testing 
process, and because IBM is attempting to act in a mode that is *CHEAP, 
this caused lots of bugs to fall through the cracks.  Every legitimate bug 
leads to a PTF (*VERYEXPENSIVE [You wouldn't think so, but nevertheless 
this is what IBM claims.]).

Ultimately PTF's get into a "Cumulative PTF Package", which gets a good 
amount of testing.

However because of database changes, tape changes and Y2K changes, IBM has 
instituted a new set of PTF's called "group PTF's".  "Group PTF's" are not 
as extensively tested, to say the least.  (They resemble doing business 
like Micro$oft, but nevertheless this is what IBM is providing.)  I would 
recommend that all customers at V4R4 have the "group PTF's" for both 
database and Y2K.  In addition if you are running a 3570 or 3590, you need 
the "group PTF's" for save/restore.  There are other sets of "group PTF's" 
for the net, and things like that.

Al





+--------------------------------------------------+
| Please do not send private mail to this address. |
| Private mail should go to barsa@ibm.net.         |
+--------------------------------------------------+

Al Barsa, Jr. - Account for Midrange-L
Barsa Consulting, LLC.  
400 > 390

Phone:          914-251-1234
Fax:            914-251-9406
http://www.barsaconsulting.com
http://www.taatool.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
+---


+---
| 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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.