Re: Reading RPG style record in Java

Hi Chuck, my comments in-line.

2015-12-02 20:24 GMT+01:00 CRPence <crpbottle@xxxxxxxxx>:

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.

If I understand correctly your warning it's about Binary data (i.e. INT or
similar). Strings with normal text should not be effected. I'll convert any
INT or packed to Signed.

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

The problem with a VIEW is the number, there are approx. 60 DS's with
diffrent layout and fields. Moreover the overall scope of the file
structure is a sequential (by key) reading to preserve the rigth sequence
of operations.

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.

I'll store all the numbers splitting the sign, using %ABSOLUTE and moving
the sign in a separate field supposed to be safe. Using them in Java means
converting the BINary fields (AWFLD and AWFLDEX) in ascii.

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) )

Thanks very much.

--
Regards, Chuck


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