Re: RGZPFM -- MIDRANGE-L

Luis - no worries.  I appreciate your responses.  Regarding the
controllers...we were having IO problems with our 270 when we first put it
in place.  It was absolutely horrible.  We ended up filling up the cage with
the addition of 8 more drives (we started with 10 - the 270 can hold 18
internal) and replaced the SCSI card with the 2757 with 757MB write cache.

Our througput went through the roof.  In fact, the controller had about
twice as much inpact as the 8 additional drives.  I am a believer...

RH


"Luis Rodriguez" <luisrodriguez@xxxxxxxxxxx>
wrote in message news:002901c65585$fda35930$920aa60a@xxxxxxxxx
Ryan,

First, let me apologize as I believe that maybe my answer wasn't as clear o
relevant as you needed. My native language is not English and sometimes I
have some problem getting my ideas across.

When you create a file (CRTPF), OS/400 allows the data to be stored across
several disks and, as better guys than me have explained in this forum, this
allows faster and better access to your info. That's the reason why,
depending on your hardware and workload type, sometimes having few disk arms
can represent a performance problem. Nowadays this can often be resolved, in
part, thru the use of IO adapters with a very big disk cache memory. Let me
recommend the following document:

www.ibm.com/servers/eserver/iseries/perfmgmt/pdf/V5R2FiSArmct.pdf

That said, if you really want to have a file created with contiguous
sectors, the CRTPF command has a parameter that allows you to do this:
CONTIG (*NO/YES). As per the manual:

CONTIG
Specifies whether records in the initial allocation in each physical file
member are stored contiguously (next to each other) on auxiliary storage. If
so, and the necessary contiguous space is unavailable, the system sends a
message to the job log and allocates the storage space noncontiguously. The
file is still entirely usable. This parameter does not affect additional
allocations that might be needed later, which would probably be
noncontiguous.
*NO: The storage space for each member does not have to be contiguous.
*YES: The system allocates contiguous space for each member of the physical
file being added. If it cannot, the user is notified and a message is put in
the job log. The affected member is still added, even if the storage space
is allocated noncontiguously. The member is just as usable in noncontiguous
form. If *YES is specified for CONTIG, then ALLOCATE(*YES) must also be
specified.


Hope this helps.

Best Regards,

Luis Rodríguez

IBM Certified Systems Expert
eServer i5 iSeries Technical Solutions

Caracas, Venezuela
> ------------------------------
>
> message: 3
> date: Fri, 31 Mar 2006 14:13:43 -0500
> from: "Ryan Hunt" <ryan.hunt@xxxxxxxxxxxxx>
> subject: Re: RGZPFM
>
> A couple people have refered to proper data balance across striped volumes
> as synomous with contigous clusters/sectors on an individual disk (or at
> least that's how I read it).
>
> My disks are perfectly balanced (or at least I desire no better
> balancing)...that's not what I was going for.  Someone also stated that HD
> heads will be all over the place so there would be no advantage to
> contiguous disk usage.  I disagree with this.
>
> Having data spread contiguously on disk will promote sequential file reads
> instead of many non-sequential reads with latency lags for the same
> non-contiguous file.  Sure, there will be interrupts to service many user
> requests, but wouldn't interrupts + non sequential file reads exacerbate
> the
> issue?
>
> I once had an IBM tech suggest using the CPYLIB / RSTLIB to re-spread
> large
> libraries across disks because RSTLIB will rebuild each file one at a time
> and keep data contiguous at the disk level.  In fact, if you really wanted
> to put the time in, you could copy files/tables one-by-one with your
> largest
> (or most likely to be scanned) tables first so the are both contiguous and
> as close to the outer edges of the disks as possible.
>
> Anyway, obviously RGZPFM is not going to do want I needed.  Thanks for all
> the responses.
>
> Ryan
>
> "Luis Rodriguez" <luisrodriguez@xxxxxxxxxxx>
> wrote in message
>
news:1143752622.10391.257948192@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Ryan,
>>
>> 1) RGZPFM reorganizes only 1 member at a time. The default is *FIRST.
>>
>> 2) Usually, in the AS/400, you don't define a file as having contiguous
>> sectors on your disk. In fact, as your system has several disks, it
>> balances them automatically so you get better performance that way.
>>
>> Regards,
>>
>> Luis Rodriguez
>>
>> >
>> > ------------------------------
>> >
>> > message: 8
>> > date: Thu, 30 Mar 2006 15:21:01 -0500
>> > from: "Ryan Hunt" <ryan.hunt@xxxxxxxxxxxxx>
>> > subject: RGZPFM
>> >
>> > We've had our AS400 for 6 years now and we've never performed an RGZPFM
>> > on
>> > our production database. Our AS400 serves as our Enterprise Server for
>> > a
>> > JDE
>> > OneWorld ERP so there is LOTS of activity on this thing.
>> >
>> > I'm under the impression that the running RGZPFM again my production DB
>> > library with no other parameters will remove deleted records from all
>> > members and place the members/files into contiguous sectors of my disks
>> > (thus making sequential I/O more likely).  Is this correct?
>> >
>> > Thanks in advance.
>> >
>> > Ryan Hunt