|
OK - sorry I missed the 5 digit - 3 digit bit. I just assumed your example was using a different size. That does appear to be an error if it shows a 3 digit field as 5 long. My guess is that RDi is incorrectly using the 3 byte length as representing as 5 packed as it would be if you used from/to notation in a D-spec.
I see your point but it really depends on what one means by “defined” - when outline shows it as packed that is accurate in that if you were passing the field as a parm to another program (for example) you would be passing a packed field - not a zoned. Since you can never actually “see” the zoned version would it really make any sense for RDi to show the field as zoned? The conversion takes place on the READ itself.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Oct 24, 2014, at 5:04 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:
Yeah, and I've not used secondary files since maybe school 25 years ago. I regularly have a RElearning experience here!
My concern is that the outline view does not present the same information as the compile listing - it clearly says FLD1 is a 5-digit packed - that's not the case in any case.
This isn't a program I need to or can change in the I-specs - I was just noticing a discrepancy in reporting - and this IS different from, say RDp 7.6, which also has an issue - FLD1 is shown as 2-digit packed, FLD2 as 3-digit - non-issue, since that's long ago.
I'd like the outline to display the data type as defined, not as internally processed - that's more useful when editing, seems to me. I know it's not "the truth" - but I don't know if I can handle the truth!
Sorry - kind of!
Vern
On 10/24/2014 3:49 PM, Jon Paris wrote:
I can’t recall the last time I used I-specs - I guess the last time I used RPG II - never used them in RPG III or IV. As a result I had never thought about the situation for zoned fields in program described files. However they do appear to follow the same pattern that I outlined for externally described files - and that makes sense.
Modify the code like this and you’ll see that fld1 remains as zoned but fld2 is still packed as it should be.
fflatfile ip f 100 disk
d ds <—— Added
d fld1 <—— Added
iflatfile AA 01
i 1 3 0fld1
i s 4 6 0fld2
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Oct 24, 2014, at 4:31 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:
This is defined in I-specs that define fields for an internally-described file.
Here is a bit of code -
fflatfile ip f 100 disk
iflatfile AA 01
i 1 3 0fld1
i s 4 6 0fld2
In the outline view that I'm looking at now, under Fields, I see this -
fld1 : Packed Decimal (5,0)
fld2 : Zoned Decimal (3,0)
From what you said, both of these are incorrect - they should both say Packed Decimal (3,0). And the compile listing showed them both as packed (3,0).
It IS Friday - what am I missing?
Vern
On 10/24/2014 2:49 PM, Jon Paris wrote:
Defined where Vern?
If it is on a D-spec then yes this is an error. If it is 4 0 in the DDS then see my earlier reply.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Oct 24, 2014, at 2:46 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:
That's all well and good - but this is defined as 4 bytes, say, and has 0 decimals and nothing in the data type column - that is a 4-digit zoned field, right? The outline in 9.1 reports it to be a 7,0 packed - that can't be right.
On 10/24/2014 1:30 PM, Jon Paris wrote:
RPG will always convert zoned fields to packed for internal use - unless - the field in question is defined in a DS. Thus has ever been - at least on the S/38 side of the family.
So what Vern saw in RDi was accurate.
To see the difference just define a zoned file field in a DS (just bu specifying the filed name in the DS) and then hover over the variable and it will be shown as zoned.
A similar thing happens with date/time fields. No matter what format they have on the DB they will be converted by RPG to the default format for the program (normally *ISO) for internal usage. Same rule re placing the field in a DS applies here. The DS will preserve the original format. This is often a cause of performance issues with date heavy files where in DB2 they are in *USA but there was no *USA datefmt specified to the RPG program.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Oct 24, 2014, at 1:23 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:
On 24-Oct-2014 11:29 -0500, Vernon Hamberg wrote:
I just noticed, working in some old code, that when there is anAs I recall, that is the expected effect; an /implicit/ conversion to packed that consistently confounded me every time I looked at a listing and saw the Packed designation.
I-spec that defines a zoned field (blank in the data type and a
number in decimal places) that the field list displays it as packed.
<<SNIP>>
In my experience, as I recall, although the /field/ is being properly represented as zoned data for the actual file I\O, the /variable/ that gets declared to store that data is generated as Packed; i.e. in the expansion of the program listing where the data types\attributes are presented for the variables of the RPG program, a /variable name/ that happens to have been declared with the same name as the /field name/ appears as a Packed Decimal, but the I/O performs as expected because the /field/ within the database buffer is properly represented as Zoned Decimal.?
--
Regards, Chuck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
