Re: Reading RPG style record in Java

On 01-Dec-2015 03:55 -0600, Marco Facchinetti wrote:

as implied by the title I have to read (and use) this file (and
cannot modify it) in a Java program:

A R AF2WK TEXT('Afpds: workfile')
A*
A AWIDDOC 5 0 TEXT('Id doc')
A AWIDPAG 10 0 TEXT('Id page')
A AWIDOPE 14 0 TEXT('Id')
A AWNMOPE 20 TEXT('Operation')
A AWDSOPE 40 TEXT('Ds name')

A AWFLD 256 VARLEN(30) CCSID(1144)
A AWFLDEX 32000 VARLEN(1) ALWNULL DFT('')
A CCSID(1144)
A*
A K AWIDDOC
A K AWIDPAG
A K AWIDOPE

I use in RPG programs AWFLD and AWFLDEX as DS:

dDs_w_StampaTesto...
d ds qualified
d h like(Ubase)
d v like(Ubase)
d punti 4s01
d font 8
d codepage 8
d Orientamento 3s00
d Lunghezza 3s00
d Colore 3s00

so the code is very easy:

<ed: text from a followup reply expands code snippet:>

dow not %eof();
read af2wk;
if %eof();
leave;
endif;

Select;
When AWDSOPE = 'Ds_w_StampaTesto';
Ds_w_StampaTesto = AWFLD;

When AWDSOPE = 'Ds_w_StampaBox';
Ds_w_StampaBox = AWFLD;
Ds_w_StampaBoxExtended = AWFLDEX;

...
Endsl;

enddo;

So my question is: how to do the same in Java with hardcoding
positions, names and types?

Perhaps easy, but also seemingly flawed, at least according to the DDS. The CCSID-tagged character data from the file is being utilized in the program as though the data had been read from the file as binary\CCSID(*HEX); suggesting that the effects are potentially undesirable, if ever the job runs with anything other than the CCSID(*HEX) or CCSID(1144). The ill effects could be quite covert and if\when noticed, the origin [being a user with a different CCSID] probably not easily inferred. Binary data is data that must not be translated\converted according to a character encoding, but when the data from AWFLD and AWFLDEX is being read from the file, character conversion can occur; those fields should be identified as FOR BIT DATA, as Hex, BINARY, or a similar specification to avoid an issue.

FWiW: Each mapping of the data from AWFLD, into individual fields, could be defined in a VIEW; scalar User Defined Function(s) (UDF) can be created to define the effective _direct map_ of the un-typed data [i.e. bytes of data] into typed-scalar values. The SQL can not easily effect that directly [without UDF(s)], because the SQL only supports a well-defined set of scalar-to-scalar mappings; a substring of bytes is effectively either typed as BINARY or as CHAR, for which the ability to cast into another data type is not simple, because the data is the internal-format vs the character-format the SQL perceives the scalar value to be. Similarly, the DDS LF also does not have any support for untyped\direct-map capabilities, but also provides no alternative like the SQL does with expressions [that optionally are UDF invocations]. Note: a creative use of a FIELDPROC could also implement the mapping of the data, to character, but not if the AWFLDEX could ever approach the 32K, because the expansions of the data for examples like the internal value of x'F3F2F1F5' as type 4S01 into the string '321.5' might not fit.

For example, the following [untested] is an expression that can effect the conversion of the character data for variable punti into the expected 4S01 [aka NUMERIC(4, 1)] value:
zone(concat(substr(AWFLD, 5, 3),'.',substr(AWFLD, 8, 1)), 4, 1)

For example, the following [untested] is an expression that can effect the conversion of the character data for variable Orientamento into the expected 3S00 [aka NUMERIC(3, 0)] value:
zone( substr(AWFLD, 25, 3 ), 3, 0 )

Note: in the prior two examples, those can be functional only for the file-data that was positive zoned Binary Coded Decimal (BCD) numeric data, and only when the preferred-positive sign 0xF; i.e. any negative values and even any zone portions of the BCD that are not 0xF, would give errors, despite those values being valid while stored in the database file.

For example, the following is not available with the SQL, until after someone has created a UBIN2_SMALL function to effect the conversion of the ushort value of the character data for variable v into a SMALLINT; noting also that the SQL has no unsigned integer type, so if the positive data is too large, the effect would be a negative value when effecting a direct-map from the ushort into short\smallint:
UBIN2_SMALL(substr(AWFLD, 3, 2) )