RE: What a fun week -- MIDRANGE-L

Given the size of this file, I think that waiting for the next release is
acceptable.

Al

Al Barsa, Jr.
Barsa Consulting Group, LLC

400>390

914-251-1234
914-251-9406 fax

http://www.barsaconsulting.com
http://www.taatool.com






                    rob@dekko.com
                    Sent by:                  To:     midrange-l@midrange.com
                    midrange-l-admin@mi       cc:
                    drange.com                Subject:     RE: What a fun week


                    10/29/01 12:23 PM
                    Please respond to
                    midrange-l







<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

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

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