Re: KLIST question

On Mon, Dec 5, 2011 at 12:39 PM, Gary Thompson <gthompson@xxxxxxxxxxx> wrote:

John wrote:
       I am confused as to why this would have ever seemed to work.
       From what I am encountering, it doesn't, at least not consistently.

First, I think Barbara's response should provide some assurance
       that the key lookup will work >consistently>.  As she explains,
       RPG is designed to handle slight differences in numeric
       key data types.

       If you want to confirm this for yourself, you could change
       (maybe a copy of) your program to:

       1) Define keys based on local work fields defined to
        match data types of the file.

       2) Load local work fields just prior to setll and reade
        operations.

       3) Confirm key values have been correctly set (debug perhaps)

       4) Observe the result of setll and reade

By following steps something like those just described, I expect
       you will see results consistent with the original program.

Without more detail, I guess you see the original program as failing
       to successfully read a record(s) that you know to exist.

My guess is there is something other than the difference between
packed and zoned numeric types (number of decimals???) that is
causing your issue.




-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of jmmckee flinthills.com
Sent: Monday, December 05, 2011 9:17 AM
To: RPG programming on the IBM i / System i
Subject: Re: KLIST question

 I am not getting any message from the compiler.  The reason I am asking is I am having issues with records not existing.

There is, of course, an error in the following.  Which I have addressed.  I rarely use the delete operation.

But, I am seeing odd missing records.

xxpaky  klist
           kfld          aphsp#
           kfld          apacct


  xxpaky    setll  pfhcm
  xxpaky    reade pfhcm
               if       not %eof(SPBHCMP)
  xxpaky    delete  pfhcm
               endif


Obvious mistake I found was including factor 1 on the delete.

APHSP# P 1   2 0
APACCT P 3   6 0

The above came from the first file.

Those are used to chain to the second file, where the fields are:
HMHSP#  P   3 0
HMACCT  Z   7 0

I got both definitions from the compiler list.  I am confused as to why this would have ever seemed to work.  From what I am encountering, it doesn't, at least not consistently.

John McKee
On Mon, Dec 5, 2011 at 8:08 AM, Gary Thompson <gthompson@xxxxxxxxxxx> wrote:

Sure, the compiler "diagnoses" the mismatch, it then goes further,
doing you a "favor".

The compiler is not complaining because it will be able to "convert"
the key value, provided the number of decimal digits (scale) in the
key defined in the program matches the key of the file.  Also, I
think, the key defined in the program must supply at least as many
digits left of the dp to "cover" the key of the file.

So, think of this as similar to what the compiler does when adding
numeric fields of mixed numeric type, but with the additional
restriction that key "conversion, does not permit rounding...

If you are comparing flavors of RPG to other, much more strongly typed
languages, this is pretty confusing.  For fun, experiment with moving
(MOVE instruction) a character field to a packed decimal....


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of jmmckee flinthills.com
Sent: Saturday, December 03, 2011 10:43 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: KLIST question

Two externally described files.  Both are keyed with two fields.  One file has both fields as packed numeric.  The other has signed numeric and packed numeric.

I thought the compiler would complain about the mismatch.  I know it does if alphanumeric is used for numeric.  But, the compiler did not complain.  This applied to RPG III and RPG IV.  At least not on the system I use.

First file is read and the two data fields are in the klist to read the second file.

My questions:

1) What happens when a setll/reade is performed with this mismatched field issue?  No error is generated.  I am wondering if some other record is returned, or if the mismatched fields are corrected internally, somehow.

2) Since the files are externally defined, shouldn't the compiler be able to diagnose the mismatch?


Thanks

John McKee

One program writes/updates or deletes records. I know a record was
supposed to be added. And, as far as I can tell, the add/update logic
is working. But, a specific record was not to be deleted, and yet it
is not there. I jumped on the KLIST and field differences as a
possible issue. The first file is a daily file. I can backtrack
through a log file and see the history for a given account. No record
should have been deleted from the second file.

Anyway, thanks for reassurance. I will have to dig deeper.

John McKee