× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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
--
This is the RPG programming on the IBM i / System i (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 / System i (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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.