Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Beginner DSPFD question

502 views
Skip to first unread message

angus

unread,
Apr 29, 2008, 10:50:08 PM4/29/08
to

Recently had to take over an AS400 and learning the hard way. Had a
file fill up during update and was presented with the option to
increase it's size, which seems to have solved the problem for now. My
question is looking at the file with DSPFD, I see two different max
records sizes, and I don't understand the relationship. The first is
under the section:

Data Base File Attributes
...
Member size SIZE
Initial number of records . . . . . . . . : 1000000
Increment number of records . . . . . . . : 30000
Maximum number of increments . . . . . . : 600
Record capacity . . . . . . . . . . . . . . : 19000000

And then father down there is a second one under header:

Member Description
Initial number of records . . . . . . . : 1000000
Increment number of records . . . . . . : 30000
Maximum number of increments . . . . . : 600
Current number of increments . . . . . . : 857
Record capacity . . . . . . . . . . . . . : 26710000
Current number of records . . . . . . . . : 19001778


So a few questions come to mind looking at this:

1. What's the relation between a DB file and a Member and their
respective max sizes?

2. If the max number of increments is 600, how did we get to 857?

Thanks

Jonathan Ball

unread,
Apr 29, 2008, 11:29:33 PM4/29/08
to

Every member in the file (if it is a multi-member file) starts with the
same size characteristics as those defined for the overall file.


>
> 2. If the max number of increments is 600, how did we get to 857?

When the file gets full - that is, it uses up its initial number of
records (1,000,000 here) and all of its initial number of increments
(600 increments of 30,000 records each, or an additional 18,000,000
records; total of 19,000,000) - then subsequent attempts to write
records will cause the job to issue a CPA5305 message: "Record not
added. Member xxx is full. (C I 9999)" If the operator replies "I"
(ignore) to the message, one additional increment (30,000) of records is
added; if the operator replies with a number between 1 and 9999, then
that number of increments is added. One way or another, an additional
257 increments of 30,000 records have been added to your file in
response to "member full" messages, for a total capacity of 26,710,000.
Note that there are only 19,001,778 records in the file, meaning
records have been deleted. Most likely the file specifies
REUSEDLT(*NO), meaning delete record space cannot be reused

Chris Pando

unread,
Apr 30, 2008, 10:15:38 AM4/30/08
to
On Apr 29, 9:50 pm, angus <stephen.a.cochran.li...@cahir.net> wrote:

[CPA5305]

The question you didn't ask is "how do I make this go away"?

CHGPF FILE(LIBNAME/FILENAME) SIZE(*NOMAX)

I usually use CHGCMDDFT to alter CRTPF so that all files are
created SIZE(*NOMAX).

Chris
--
"The primary purpose of the DATA statement is to give
names to constants; instead of referring to pi as
3.141592653589793 at every appearance, the variable PI
can be given that value with a DATA statement and used
instead of the longer form of the constant. This also
simplifies modifying the program, should the value of
pi change." - Early FORTRAN manual for Xerox Computers

Jonathan Ball

unread,
Apr 30, 2008, 10:27:11 AM4/30/08
to
Chris Pando wrote:
> On Apr 29, 9:50 pm, angus <stephen.a.cochran.li...@cahir.net> wrote:
>
> [CPA5305]
>
> The question you didn't ask is "how do I make this go away"?
>
> CHGPF FILE(LIBNAME/FILENAME) SIZE(*NOMAX)
>
> I usually use CHGCMDDFT to alter CRTPF so that all files are
> created SIZE(*NOMAX).

The conventional wisdom used to be that that's not a good solution
across the board, because of the risk of a runaway looping job filling
up your disk. However, as SQL tables are all created with SIZE(*NOMAX)
and SQL DDL defined objects are the preferred direction (replacing DDS
defined objects), one has to believe the conventional wisdom has changed.

angus

unread,
May 4, 2008, 4:01:02 PM5/4/08
to
On Apr 30, 10:15 am, Chris Pando <chris.pa...@gmail.com> wrote:

> On Apr 29, 9:50 pm,angus<stephen.a.cochran.li...@cahir.net> wrote:
>
> [CPA5305]
>
> The question you didn't ask is "how do I make this go away"?
>
> CHGPF FILE(LIBNAME/FILENAME) SIZE(*NOMAX)
>
> I usually use CHGCMDDFT to alter CRTPF so that all files are
> created SIZE(*NOMAX).
>

I didn't ask that question because the CPA5305 message allowed me to
increase the size. What I dind't realize was that it was going to
increase in increments of 30,000. It hit the limit in 8 different
processes (order entry), On one I entered 250, the rest I chose "i" to
add that individual record for a total of 257 increments. Figured 250
would get me through the day until I figured out how to purge. Instead
I increased it enough to last another few years.

Still working on the purge though, basically inherited a system that
didnt' have an admin/operator and I'm a unix guy. Thanks for the
responses, sure I'll be asking more as I learn.

0 new messages