Re: Outline view falsely reports zoned I-spec fields as packed

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

As 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.

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.