× 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: "Michael Oakes" <michael_oakes@xxxxxxxxxxx>
  • Date: Mon, 17 Apr 2000 13:43:41 GMT

I experienced a 150% increase in the time to do an option 21 from GO SAVE 
after having upgraded to 4.4 from 4.2.

I found that by deleting the 3590 device description and letting the system 
autoconfigure another device that the option 21 from GO SAVE returned to the 
previous backup time.

Hope it helps in your situation

Regards Michael Oakes

>From: MacWheel99@aol.com
>Reply-To: MIDRANGE-L@midrange.com
>To: MIDRANGE-L@midrange.com
>Subject: Re: Long running backups to a 3590-B11
>Date: Fri, 7 Apr 2000 03:20:33 EDT
>
>We only have 12 GB, running at about 75% used - it has been in excess of
>100%, but normally fluctuates between 69% & 78% - we recently had a 
>scenario
>which we labeled lemon/400 - our hardware reps told us we were getting an
>upgrade, but in reality they installed a downgrade.  Speed of processor &
>amount of memory can have astronomical impact.
>
>News/400 has a book on Mastering/400 Performance
>
>How often do you re-IPL to reclaim disk space associated with humongous 
>print
>jobs?  We get about 5% disk space back when we do a re-IPL.
>
>Review GO CLEANUP settings.
>
>We have had several upgrades in which some types of backups went faster &
>some went slower ... we used to do GO BACKUP daily on just our most active
>libraries & GO SAVE biweekly for a SAVE 21 because GO BACKUP took 90 
>minutes
>while SAVE 21 took 6 hours, but now we do SAVE 21 every nite because it 
>takes
>90 minues while the GO BACKUP takes 3 hours.
>
>My theory is that GO BACKUP is now doing some kind of start stop tape
>movement on each library, where previously it was a smoother copy process,
>and that this is related to AS/400 model, processor, and OS/4 version.
>
>Since we converted from MAPICS to BPCS, and installed UPS for key
>communications hardware, we have had to do one restore from backups about
>once every 3-5 months, while in the olden MAPICS days without UPS, we had 
>to
>restore from backups several times a week.
>
>If your need to restore is comparable then not saving access paths makes
>sense.
>
>WRKF look for QHST* in QSYS ... you may only need a day or two activity -
>adjust System Value QHSTJOBLOG
>
>WRKPRB work with problems & see if there are unneccessary problem logs ...
>System Value QPRBHLDITV governs how long they are kept ... last time I 
>tried
>to muck with this it would not let me lower it below 30 days
>
>I got some code off one of the trade zine forums to DSPFD all files all
>libraries to a temporary area, that should be in QTEMP, then Query off it 
>to
>show how much disk space is wasted by which files that contain records 
>coded
>for deletion in need of reorg ... when we started this, some files had
>millions of such records, but now the report runs off the job scheduler
>regularly, and I do a reorg when the wasted space exceeds 10 meg.
>
> >  From:    BullJ1@Midas-Kapiti.com (Bull, Jeff)
>
> >  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 ?
> >
> >  Kind regards,
> >  Jeff Bull.
> >  Senior AS/400 Support Consultant (AS/400)
> >  Midas Kapiti International Ltd
> >
>
>
>Al Macintyre  ©¿©
>http://www.cen-elec.com MIS Manager Programmer & Computer Janitor
>http://www.whma.org = our nitch industry has a large committee searching 
>for
>ErPdMes products right for WHM without work-arounds, which for many members
>resemble a snipe hunt - if you are in this software business & want to fix
>your product so it will not be mistaken for what your competition has been
>doing, then you might want to join our great game.
>
>Y2K is not the end of my universe, but a re-boot of that old Chinese curse.
>The road to success is always under construction.
>Stiff in opinions, always in the wrong.
>When you want it cheap - you get what you paid for.
>When in doubt, read the manual, assuming you can find the right one.
>+---
>| 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
>+---

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.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.