Scott,
Thanks for the very helpful info.
I have been using the ability to have constants and expressions in my key fields for some time now, but have just recently noticed that the compiler was not giving me errors when the length of my key fields did not match.
Mainly, this was a problem for me only in that I had reversed two of the key fields in the list, and since they were both character, the compiler did not give me any indication that I had a problem. Took me a while to figure out that. lol
As always, you have provided a clear and easy to understand of not only what, but why things work the way they do.
Thanks,
Jeff Young
Sr. Programmer Analyst
IBM -e(logo) server Certified Systems Exper - iSeries Technical Solutions V5R2
IBM Certified Specialist- e(logo) server i5Series Technical Solutions Designer V5R3
IBM Certified Specialist- e(logo)server i5Series Technical Solutions Implementer V5R3
________________________________
From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Sent: Tuesday, September 8, 2009 1:39:57 PM
Subject: Re: Free Form I/O with list of fields does not checkl the length of the field vs key of file
Hello,
... the free format op codes for file i/o, that the compiler does not
seem to be testing the length of the fields ...
Yes, that is expected/documented behavior. Here's a link to the ILE RPG
Reference manual:
http://tinyurl.com/lpcxxd
here's what the documentation says (this is copy/paste from the link
cited above):
For free-form calculations, a search argument may be:
1. A single field name
2. A klist name
3. A list of values, such as "(a:b:c+2)". Each part of the
composite key may be any expression. Data types must match the
corresponding key field, but lengths and data format do not
have to match.
4. %KDS(ds{:num})
Note that option #3 (which is the one you're referring to) states that
data types must match, but lengths and format do not have to match. I
find that behavior to be very helpful.
We have files where the lengths aren't consistent (GL number is 5,0 in
one file, 6,0 in another file. I don't have to move the number to a
temp field, I can just chain with it!)
chain (inputGL) GLMAST;
In this example, inputGL is 5,0, but the key to GLMAST is 6,0. No need
to copy to a temp variable.
You can use any expression for these key fields -- so it works just like
EVAL works, which I find to be very intuitive. When you assign one
variable to another with EVAL, the data types of the variables don't
have to match. (You can assign a 6,0 field to a 5,0 field, as long as
the number would fit in a 5,0 field...)
Expressions also mean you can do some manipulation. For example, I can
convert a date field from one format to another right on the keylist.
setll (%dec(%date(inputField:*USA):*ISO)) Calendar;
The above code converts a field from MMDDYYYY format to YYYYMMDD right
on the keylist. Saves me having to code a temporary field.
Furthermore, we have some inventory files where a "location" is
represented by a warehouse number (1A) and a location (7A). And we have
some where it's one 8A field. No problem! I can do this:
chain (WHSE + LOCATION) MyFile;
In this case, the two fields (WHSE and LOCATION) get concatenated, and
then the output is used as the first key to MyFile. Again, saves me
effort of coding a temp field.
If you want to guarantee that your field sizes match, you can use %KDS
or KLIST to get that behavior. So you can do it either way, best of
both worlds. But personally I like having the flexibility of expressions.
midrange.com
