RE: What a fun week

[rob@xxxxxxxxx]

I didn't declare it that size, I did use *NOMAX.  Actually, for these kind
of files I do the command, selecting only one object.  Then I do a CHGPF to
*NOMAX.  Maybe we just got a xxxxload of files.

Rob Berendt

==================
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    "Bale, Dan"
                    <Dan.Bale@handleman       To:     <midrange-l@midrange.com>
                    .com>                     cc:
                    Sent by:                  Fax to:
                    midrange-l-admin@mi       Subject:     RE: What a fun week
                    drange.com


                    10/29/2001 12:47 PM
                    Please respond to
                    midrange-l






This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I have to ask out of curiosity.  Not excusing IBM for such a dumb error
but, why would anyone define a PF's size as (2147483646 32767 32767)?
Why not just use *NOMAX?

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com

> -----Original Message-----
> From:         rob@dekko.com [SMTP:rob@dekko.com]
> Sent:         Monday, October 29, 2001 12:23 PM
> To:           midrange-l@midrange.com
> Subject:           RE: What a fun week
>
>
> <snip>
> >pmr 42957,500 - "DSPFD results in MCH1210" - The problem you reported
> >is a known problem that development has decided to fix in a future
> release.
> Wow.  DSPFD dumps and IBM says to wait til the next release?  Is this
> caused by a damaged file?
> Dan Bale
> <endsnip>
>
> The problem you reported is a known problem that development has
> decided
> to fix in a future release.  The APAR is SA92492.  The Problem Summary
> which is relevant to you is:
> .
> CRTPF FILE(lib/file) RCDLEN(100) SIZE(2147483646 32767 32767)
> then a dspfd of the file results in a msgmch1210.
> .
> I know you are doing FILE(*ALL/*ALL), so you may not know which file
> is
> giving the error.  Furthermore, you may not have the exact size as
> listed in the problem summary above, but the bottom line is that the
> problem exist when someone places a size that is close to or the
> equivalent of *NOMAX.
> .
> The specifics of this problem are as follows:
> .
> A mathematical calculation was causing an over-flow condition
> while attempting to determine the maximum record capacity of a
> file.  This can occur for any file created using the
> CRTPF command SIZE(2,147,483,647 32767 32767) parameter when an
> extract of the result file is performed. File extracts are
> performed for such functions as DSPFD and RTVMBRD, among others.
> The problem may also occur for files whose SIZE parameter
> values total a maximum record capacity greater than
> 2,147,483,647.
> .
> Therefore, the circumvention until it is fixed is:
> .
> The problem may be circumvented by specifying SIZE(*NOMAX) on
> the CRTPF command. The DSPFD and RTVMBRD will then be
> successful and the MCH1210 should not occur.
> .
> If you are trying to see the last change date for files on your
> system,
> try using DSPOBJD instead of DSPFD.  Although this will give different
> results (DSPOBJD gives both member last change date <ODLDAT> and
> member
> last used date <ODUDAT>) you should be able to achieve what
> information
> you are looking for.  Once you know what you are looking for, query
> that
> outfile created by DSPOBJD on the field you need information from.  I
> don't believe DSPOBJD has the same problems with file sizes that mimic
> SIZE(*NOMAX) (i.e. 2,147,483,647).  Otherwise, you will have to locate
> the files with this problem and change the file size to *NOMAX.
>
> Rob Berendt
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.