× 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 17:07:41 -0500

I hear that part of the testing to put something on a cume 
is how many people order it.  If X number of people order it, 
and they don't get a whole lot of complaints, then IBM will 
put it on a cume.





barsa2@ibm.net on 04/06/2000 03:59:13 PM
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 11:12 AM 04/06/2000 -0400, you wrote:
>Al, can I assume that Group PTFs are included in cumes ?


No.  IBM ships any pertinent PTF in the group, to avoid waiting for the 
cume cycle.  Also, not every PTF makes it to a cume.

Al



>Ron
>
>----- Original Message -----
>From: "Al Barsa, Jr." <barsa2@ibm.net>
>To: <MIDRANGE-L@midrange.com>
>Sent: Thursday, April 06, 2000 9:12 AM
>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
>+---



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