On 17-Mar-2014 10:39 -0700, Cyndi Bradberry wrote:
<<SNIP>>
IFILE01 NS 99 25 Z2 25 D0
Here is a DSPPFM of a portion of the file <<SNIP>> in Hex Over/Under
with the portion being used for Record Id highlighted
<<SNIP>>
*...+....1....+....2....+....3
256305000000000404475 Rec Id 99
FFFFFFFFFFFFFFFFFFFFF444244
256305000000000404475000000
I keep getting a unidentified record type, always on the record I
want called Rec Id 99. What am I not doing correctly? RTM is
acceptable if you point to the page in the book. I am V7R1.
While I am aware that the issue for an "unidentified record type" was
already resolved with the feedback received in other replies [i.e. omit
all tests from the Input specifications for the record identification
entry for the Record ID using the general indicator 99], there may be
value in knowing that the ability to define the selection of a Record
Identifier Code with the character value of x'20' is problematic; or
perhaps more accurately, not even possible. So I post this /reply/,
merely as FWiW and for the archives, with the modified subject line in
the off chance there are any followup replies.
FWiW: The EBCDIC /character/ nature of the feature prevents a
reasonable means to effect a test for any specific hex code point below
x'40', due to those code points being control characters; i.e. an
implicit limitation per the specification of a literal /character/ being
required, without the ability to specify instead, for example, either a
hex value or a named variable or constant. That restriction would be
consistent with the equivalent support that is provided by the
Interactive Data Definition Utility for its "Define Record ID Codes";
i.e. which also offers only a single character input field.
FWiW: The quoted I-Spec for the "Rcd Id 99" includes two comparisons
of the byte at Position-25 of the record for the file FILE01; a
comparison against each nibble of the byte. These predicates could be
rewritten in pseudo-code, and\or as RPG with actual %BIF notation.
Setup: A reference to the byte from the file record data could be
referred to by a variable\field named RcdID. In pseudo-code, the Z-Zone
test could be represented as a HON() [High-Order Nibble] function, and
the D-Digit test could be represented as a LON() [Low-Order Nibble]
function; with each function result being a nibble, or one hex digit.
The logic in pseudo-code is effectively the following:
If ( HON(RcdID)=HON(0xF2) // '2'=x'F2'=0xF2
and LON(RcdID)=LON(0xF0) // '0'=x'F0'=0xF0
) ;
*in99 = *on ; // RcdID, byte-position 25, is x'F0'
Endif ;
Or in RPG, the above could be rewritten as:
If ( %bitand(RcdID:x'F0')=%bitand('2':x'F0')
// '2'=x'F2'; mask LON of row data and literal, test IFEQ
and %bitand(RcdID:x'0F')=%bitand('0':x'0F')
// '0'=x'F0'; mask HON of row data and literal, test IFEQ
) ;
*in99 = *on ; // RcdID, byte-position 25, is x'F0'
Endif ;
Hopefully the above rewrite(s) helps to clarify why the "Rcd ID 99"
selection was incapable of selecting any row with x'20' in position-25,
and thus why that row effected the "unidentified record type" condition;
i.e. because the logic instead, had effected selecting any row with
x'F0' in position-25.
FWiW: The Z-Zone test does not compare the Digits portion of the
specified (Character) value against the Zoned portion of the
byte\character "in the position specified in the input record." That
however seems conspicuously to have been the intended effect of the "Rec
Id 99" tests; i.e. the tests seemed to want to identify the rows having
the value x'20' in position-25 of the record, such that the zoned
portion is tested for b'0010' and the digit portion is tested for
b'0000'. Instead, the Z-Zone test compares the Zone portion of the
specified [literal] character value against the Zoned portion of the
byte "in the position specified in the input record." Note: that quoted
text comes from the SEU prompted RPG help for the Record ID Codes,
requested for the Record Identification Codes (Character) input field.
A link to the InfoCenter docs defining the effect of the effect of the
Z-Zone RcdID test:
<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzasd/sc092508608.htm#iriz>
_i Zone (Z) i_
"The Z entry indicates that the zone portion of the character is to be
tested. The zone entry causes the four high-order bits of the character
entry to be compared with the zone portion of the character in the
record position specified in the position entry. The following three
special cases are exceptions:
...
<ed: "&" (ampersand) x'50' tests both: zone(byte) in (0x5, 0xC)>
...
<ed: "-" (minus sign) x'60' tests both: zone(byte) in (0x6, 0xD)>
...
<ed: " " (space ␠\blank ␢) x'40' tests: zone(byte) in (0x4, 0xF)>
...
"
FWiW: The IDDU (WRKDTADFN) along with Query/400 (WRKQRY) can be used
to help define and test Record ID Codes. The former to establish the
definitions of the Record ID Codes selection logic [albeit the above
noted "exceptions" are apparently not consistently supported, which is
probably a defect, something I was never aware of and thus something I
never tested in migration of IDDU dictionaries and query definitions
from the S/36], and then the latter to test the effects with a Query
Definition (*QRYDFN) using Run Query (RUNQRY). A separate query could
be defined, one against each Record Format, to verify the selection
using that specified RcdFmt when the query is run; i.e. after having
populated the file with some good test data. There probably exists some
tooling to convert the IDDU RcdIdCode selection from the Record Format
definitions into I-Specs.
midrange.com
