|
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
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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
