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



Sounds exactly like what we did on one library.  We had a library used by 
Tivoli storage manager.  This size of this library trounced all the rest 
of our libraries together, by far!
....+....1....+....2....+....3.
Object                     SIZE
PCBACKUP00      262,209,286,144
PCBACKUP01      262,209,286,144
PCBACKUP06      104,884,985,856
PCBACKUP07       52,447,748,096
PCBACKUP11       52,447,748,096
PCBACKUP12       52,447,748,096
PCBACKUP13       52,447,748,096
PCBACKUP14       52,447,748,096
PCBACKUP02       52,443,553,792
PCBACKUP03       52,443,553,792
PCBACKUP05       26,224,934,912
PCBACKUP10       26,224,934,912
PCBACKUP04       26,222,837,760
PCBACKUP09       20,990,439,424
PCBACKUP08       10,504,667,136
DB00              7,866,449,920
LOG02             1,050,697,728
DB02                790,650,880
LOG03               538,992,640
LOG01               421,552,128
DB01                270,557,184
LOG00               148,922,368
DUM                  27,287,552
QANRDTAQ                 73,728

We ran two 3581's in parallel to save the objects by size, descending 
(using a data queue loaded with the objects by size descending).

Old system:
840
Twin 3581's
attached via 2749's
Time:  22:00-08:14
Tapes:  10-12

New system:
840
One 3582
attached via fiber via 5704
Time:  22:00-06:58
Tapes:  5

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Larry Bolhuis <lbolhuis@xxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/07/2004 02:37 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
Re: *SAVFs -vs- Direct to Tape performance.






Rob,

  Most recently I did this on an 825 with 4 Processors, 6G (I think) 
memory and 50 15K rpm drives. Tape drives on the box are 3581s. Even 
paralleling the 3581's used about 10% of the CPUs. With four parallel 
*SAVFs we push the CPUS to 60+% and that's good for now.  My CL is set 
to support up to 16 parallel saves.

   In one case we even break the largest library into four parallel save 
pieces.  The program that copies the *SAVFs to disk also authors a CLP 
that will restore everything and saves it at the beginning of the tape.

  - Larry

rob@xxxxxxxxx wrote:

>Larry,
>
>There was quite a discussion on whether or not save files were any 
faster. 
> And lots of people reported the opposite.  The only new argument you 
>bring the table is the parallel concept.  That might be significant.
>
>I'd like to know the system specs:  Model and tape drive, that you 
>enhanced.  Too often I hear stuff that someone discovered in V1R2 on a 
B10 
>and take as gospel today.
>
>Rob Berendt
> 
>

-- 
Larry Bolhuis                   IBM eServer Certified Systems Expert:
Vice President                    iSeries Technical Solutions V5R2
Arbor Solutions, Inc.             iSeries LPAR Technical Solutions V5R2
1345 Monroe NW Suite 259          iSeries Linux Technical Solutions V5R2
Grand Rapids, MI 49505            iSeries Windows Integration Technical 
Solutions V5R2
                                IBM eServer Certified Systems Specialist
(616) 451-2500                    iSeries System Administrator for 
OS/400 V5R2
(616) 451-2571 - Fax              AS/400 RPG IV Developer
(616) 260-4746 - Cell             iSeries System Command Operations V5R2



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

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.