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



So to review you have a very large number of objects in the IFS.
You have a small CPU and memory allocation.
Not sure if you mentioned disk arms, arm speed, RAID card etc or configuration but this matters a LOT with such a backup.
You are still on tape one but with LTO4 that could still be over 1.5TB!

Pete asked about a failed RAID cache battery. This would absolutely slow down a backup with this many objects a lot and will of course slow any backup.
Check your SAV command defaults for the value of the UPDHIST parm. If that is set to *YES when saving this many IFS objects you'll pay a massive penalty in backup performance. The IBM Default is *NO but it could have been changed.
Are you journaling IFS objects? I believe again with this number of objects that would hurt performance.

RTVDKSINF will populate the QUSRSYS/QAEZDnnnnD and nnnnO files with what's in the IFS. Join these with SQL to find what directories contain the large number of objects or large number of bytes. My guess is you have some 'hyperactive' program creating log files or similair and many of these files will be in one directory. The IFS allows for a fantastically large number of objects in one directory!

- Larry

On 3/28/2010 8:20 PM, PaultinNZ wrote:
First off, thanks Vern and Pete.

I have all the manuals and redbooks and am following these.

The system that I am doing this work on is a test partition which is only
allocated 0.25 Proc Units and minimal RAM as well.

So I don't expect great performance.

The 'GO SAVE - 21' which is what I was doing (and not a SAVSYS - sorry Pete)
eventually ended at +/- 22:30. This was my first bash at doing this and I
was just worried that the save hadn't somehow got itself in a pickle and was
looping or something along those lines.

I had decided to do the SAVE prior to permanently applying all V5R4 PTF's so
I could restore to a 'known' stable state in need.

Okay about to apply the 'not permanently applied' fixes, load the images
etc.

Will be back.


On 29 March 2010 01:52, Vern Hamberg<vhamberg@xxxxxxxxxxx> wrote:

DSPOBJD shows you only objects in libraries. There is all the rest of
the IFS to consider.

Be very careful about cleaning the IFS up.

You might want to run RTVDSKINF and PRTDSKINF before doing anything
more, to see where the most disk space is being used.

Do you have a business partner to help you? If not, have you looked at
the manuals from IBM that describe upgrading to 6.1?

Another thing you should probably do is permanently apply all PTFs. This
will reduce the size of your save, etc.

There is much more in the manuals - I don't remember which ones to look
in - someone else here can jump in.

HTH
Vern

PaultinNZ wrote:
I think using DSPOBJD could do the display of what is loaded to the
system.
I need to think about what we need to exclude from the actual savsys.

Agree?

On 28 March 2010 21:28, PaultinNZ<paultormey@xxxxxxxxx> wrote:


Yes Stefan,

SAVE 21 is the actual command.

Well, I'm no where near the site right now. But this is configured as a
3580-004 and capabilities on TAPE properties hows this as being ULTRIUM
2/3/4 capable.

Is there anyway of seeing how many objects we 'need' to save prior to
doing
the actual save 21?

Paul


On 28 March 2010 21:15, Stefan Tageson<stefan.tageson@xxxxxxxxxxx>
wrote:

I'm doing a Savsys (ALL) on a test V5R4M0 system prior to upgrading to
V6R1.
I currently have the savsys saying it's processed 3150764 objects.

You are actually running a SAVSYS or ( as I guess ) a Save 21?

If it is a save 21 then we are probably talking about IFS objects,
folders, streamfiles.
You should probably check what's in the IFS before upgrading to 6.1.
What kind of tape device are you using? "Older" Ultrium devices is
extremely slow on small ifs objects.

Regards



Stefan Tageson

AddconIT AB

Cell : +46 (0) 732 36 99 34

stefan.tageson@xxxxxxxxxxx

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



--
Paul Tormey
2/12 Ayrshire Place
Somerville
Manukau
2014
New Zealand
Home: 09 534 3469 or 0064 9 534 3469
Mobile: 021 0654157 or 0064 210654157





--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.