RE: What a fun week

["Bale, Dan" <Dan.Bale@xxxxxxxxxxxxx>]

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