Re: Savsys taking an awful long time to complete

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.