RE: QUSRMBRD at 7.1

It appears that the format containing this field was introduced at v5r3 based on the change marks around the entire format definition. The problems started there, and were just maintained. Here are the rest of the links I know about in case anyone is interested:

v7.1: http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp
v6.1: http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp
v5r4: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp
v5r3: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp
v5r2: http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm
v5r1: http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm
v4r5: http://publib.boulder.ibm.com/pubs/html/as400/v4r5/ic2924/index.htm
v4r4: http://publib.boulder.ibm.com/pubs/html/as400/v4r4/ic2924/info/index.htm

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx

-----rpg400-l-bounces@xxxxxxxxxxxx wrote: -----
To: "'RPG programming on the IBM i / System i'" <rpg400-l@xxxxxxxxxxxx>
From: "Robert Houts"
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
Date: 08/17/2011 08:06PM
Subject: RE: QUSRMBRD at 7.1

It also doesn't appear in 6.1.  The following is from the Data Space List
Entry section data structure:

D QUSDSIKL             1061   1064B 0 DS Index Key Len
D QUSDSIKF             1065   1068B 0 DS Index Key Flds
D QUSLOATR             1069   1069    DS Index DECFLOAT Rounding @ABA
D QUSLOATW             1070   1070    DS Index DECFLOAT Warning @ABA
D QUSIHUDF             1071   1071    DS Index Has UDF @ABA
D QUSRSV406            1072   1150    Reserved4 @ABC
D  QUSSIKFL            1151   1152B 0 DS Index Key Fld Len
D  QUSSIKFN            1153   2176    DS Index Key Fld Names

Looking at the 6.1 documentation, it appears to have problems in this
section:

Dec    Hex Type       Field
1060   424 BINARY(4)  Data space index key length
1062   428 BINARY(4)  Number of data space index key fields

1066 42C CHAR(1)    Data space index DECFLOAT rounding mode

1067   42D CHAR(1)    Data space index DECFLOAT warning
1068   42E CHAR(1)    Data space index WHERE clause has UDF
1069   42F CHAR(79)   Reserved <<
1150   47E BIN(2)     Data space index key field names length
1152   480 CHAR(1024) Data space index key field names

Several of the offsets in the documentation don't match the data structure,
and those offsets should be corrected as follows:

Incorrect  Correct
1062       1064
1066       1068
1067       1069
1068       1070
1069       1071

Looking at the 7.1 documentation, it also appears to have a problem for this
section:

Dec    Hex Type       Field
1060   424 BINARY(4)  Data space index key length >> for this format <<
1062   428 BINARY(4)  Number of data space index key fields >> for this
format <<
1066   42C CHAR(1)    Data space index DECFLOAT rounding mode
1067   42D CHAR(1)    Data space index DECFLOAT warning
1068   42E CHAR(1)    Data space index WHERE clause has UDF

1069 42F CHAR(1)    Data space index keep in memory

1070   430 BINARY(2)  Data space index media preference
1069   42F CHAR(76)   Reserved <<
1150   47E BINARY(2)  Data space index key field names length
1152   480 CHAR(1024) Data space index key field names >> for this format <<

Again, offsets 1062 through 1069 are off by 2 places.  Offsets 1069 and 1070
are new fields on 7.1, but the offsets should be 1071 and 1072,
respectively.  Notice that offset 1069 appears twice.  The second occurrence
seems that it should be 1074.  Here's another correction table:

Incorrect  Correct
1062       1064
1066       1068
1067       1069
1068       1070
1069       1071
1070       1072
1069       1074

This means that the field in question at position 1073 (corrected offset
1072) should be a length of 2, not 1, and it is in the correct position in
the include.

This is why I personally never use IBM's supplied includes.  I take the time
to make my own includes to ensure they are accurate.  It may be time
consuming, but it saves a lot of headaches and allows me to choose the
naming convention.

Looking at the V5R4 documentation, it looks like it this has been incorrect
for a while:

Dec    Hex Type       Field
1060   424 BINARY(4)  Data space index key length
1062   426 BINARY(4)  Number of data space index key fields
1064   428 CHAR(82)   Reserved
1150   47E BIN(2)     Data space index key field names length

As you can see, offsets 1062 and 1064 are incorrect; they should be 1064 and
1068, respectively.  There are no change marks, so this was screwed up on a
prior release.  I looked at the V5R3 documentation and it was also incorrect
there, with no change marks.  I don't have links to any prior release
documentation, so that's as far as I can trace it.



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Kurt Anderson
Sent: Wednesday, August 17, 2011 15:04
To: RPG programming on the IBM i / System i (rpg400-l@xxxxxxxxxxxx)
Subject: QUSRMBRD at 7.1

I was wondering if anyone NOT at 7.1 could look inside their
QSYSINC/QRPGLESRC for member QUSRMBRD and tell me the positions of
QUSDSIMPR.

At 7.1, it is:
D QUSDSIMPR            1073   1073B 0

And I'm getting an error saying it's an invalid binary length.
*RNF3730 20   1672 000732  Binary numeric subfield QUSDSIMPR has a length
that is not valid; defaults to 2.

I'm trying to compile our System-Related Procedures Service Program and of
course after dealing with the most annoying "invalid host data structure"
error with SQL, I am now having an issue with code I haven't even touched.

Thanks,
Kurt Anderson
Sr. Programmer/Analyst
CustomCall Data Systems
--

This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.


---wlteihnssf---