Re: Comparing data in data structures -- RPG400-L

I've just had a "DOH" moment. SO mad that I didn't spot this before.

The cause of the problem has to be that one of the varchar fields contains trsiling blanks.

When RPG compares character fields it blank pads the shorter field with blanks before comparing the two. So a varchar loaded with 'ABC' and another loaded with 'ABC ' will test equal.

BUT when thoise fields are in a DS the whole DS is treated as a huge char lump and the binary length of the two fields alone (X'03' and X'05' in my example) make the two DS different - regardless of whether the back end of the arch contains spaces (as would normal in RPG) or garbage left lying around.

Hope this helps you to find the root cause - which is not your current code. Direct DS comparison is by far the best way to compare - as long as the data is good!

Jon P.

On Apr 16, 2024, at 11:27 AM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

Yes INZ will initialize the DS, once..after the memory is allocated.

If the DS is global, that occurs once. If you are reusing the structure,
then you could end up the difference between the end of the VARCHAR data
and the end of storage.

Charles

On Tue, Apr 16, 2024 at 9:12 AM Greg Wilburn <
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

I like to use VARCHAR when loading data into data structures that are
transformed to JSON for APIs.
Both structures are defined with INZ. Does that not really initialize all
the subfields?

For now I've just moved on. I don't have the time to diagnose what's
going on.

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Charles
Wilt
Sent: Tuesday, April 16, 2024 9:48 AM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Comparing data in data structures

I could see how some VARCHAR fields could end up with a difference in the
"junk" after the end of that value and the end of storage...

While one doesn't normally need to initialize or reset VARCHAR fields, in
this case given that you want to compare at the DS level, you should ensure
that the varchar fields are all reset to all *BLANKS or x'00' before
loading.

I think INZ(*BLANKS) and RESET would do the trick...

I'm normally a big fan of VARCHAR...

But it might be worthwhile to use fixed length fields in the DS,
especially if they end up as fixed length in the DB.

Charles

On Tue, Apr 16, 2024 at 7:02 AM Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:

I don't see how that can be the problem because if the varchar fields
had extra space padding they would be unequal in the individual test

cases too.

Admittedly I loaded no data in the fields, but my test with Greg's
exact code showed the correct results.

Jon P.

On Apr 16, 2024, at 8:52 AM, Vern Hamberg via RPG400-L <

rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:

Greg

Apologies, somehow I hadn't noticed your code - of course, you would

compare to a single subfield DS!

I think you might have hit it with the varchar fields. You might
look in

debug and view the structure in hex. I wonder if somewhere a varchar
subfield is being populated with a fixed value.

Also, DS' are seen as an amalgamation - I believe the individual

subfields are not compared one at a time by RPG - that's an
interesting idea, perhaps, to submit! But varchar's include the length
in 2 bytes, and those might differ, hence, would the entire DS be called

unequal?

Cheers
Vern

On 4/16/2024 7:39 AM, Greg Wilburn wrote:

Vern,

If you look at my code... I'm comparing the UPS data structure with
a

single element (x) of UPSSUGG.

In this case x=1.

I had this in RDI debug, monitoring both values - UPS and
UPSSUGG(1) I

copied them from RDI to Notepad++ to do a compare and it found no
differences. Yet I hit the line of code that sets DIFF=*ON when
comparing the structures.

Both structures are passed to a service program procedure that hits
UPS

Street Level Address Validation API.

UPS represents the original street address.
UPSSUGG represents the (up to 3) suggested addresses returned.

Could this have something to do with extra spaces in varchar

subfields?

I'm at a complete loss here. I hate to give up and look at each

subfield separately, but I have no idea why this is happening.

Thanks,
Greg

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of

VERNON HAMBERG Owner via RPG400-L

Sent: Monday, April 15, 2024 5:34 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Cc: VERNON HAMBERG Owner <vhamberg@xxxxxxxxxxxxxxx>;

rpg400-l@xxxxxxxxxxxxxxxxxx

Subject: Re: Comparing data in data structures

At first guess, Greg, I don't think you can compare them just by
name,

if that is what you are doing. There are X number of subfields in onw,
3*X in the other. Do you get a message that some things are being
dropped from the array? LIke this?

RNF5343

Array has too many omitted indexes; specification is ignored.

I think you can compare the single DS to each array element in turn.

Cheers
Vern

On Mon, 15 Apr, 2024 at 3:53 PM, Greg Wilburn <

gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

To: rpg400-l@xxxxxxxxxxxxxxxxxx

I'm at my wits end...

I am trying to compare two address data structures to see if they
are

different. BOTH are defined "like" a template ds, however one is
dimensional (3).

Can anyone point out what I may be missing??

TIA
Greg

Code:

dcl-ds upsAddr_t qualified template;
name varchar(40);
street varchar(50);
street2 varchar(50);
street3 varchar(50);
city varchar(30);
state varchar(30);
zipcode varchar(10);
cntry varchar(2);
end-ds;

dcl-ds ups likeds(upsAddr_t) inz;
dcl-ds upsSugg likeds(upsAddr_t) dim(3) inz;

if ups.name <> upsSugg(x).name;
diff = *on;
endif;
if ups.street <> upsSugg(x).street;
diff = *on;
endif;
if ups.street2 <> upsSugg(x).street2;
diff = *on;
endif;
if ups.street3 <> upsSugg(x).street3;
diff = *on;
endif;
if ups.city <> upsSugg(x).city;
diff = *on;
endif;
if ups.state <> upsSugg(x).state;
diff = *on;
endif;
if ups.zipcode <> upsSugg(x).zipcode;
diff = *on;
endif;
if ups.cntry <> upsSugg(x).cntry;
diff = *on;
endif;

// In Debug... diff is still *OFF at this point

// In this expression.. DIFF turns ON
if ups <> upsSugg(x);
diff = *on;
endif;

[Logo]<https://www.totalbizfulfillment.com/><

https://www.totalbizfulfillment.com/>> Greg Wilburn

Director of IT
301.895.3792 ext. 1231
301.895.3895 direct
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx<mailto:gwilburn@totalbizfulfillmen
tcom

<mailto:gwilburn@xxxxxxxxxxxxxxxxxxxxxxx<mailto:

gwilburn@xxxxxxxxxxxxxxxxxxxxxxx>>

1 Corporate Dr
Grantsville, MD 21536
www.totalbizfulfillment.com<http://www.totalbizfulfillment.com><

http://www.totalbizfulfillment.com<http://www.totalbizfulfillment.com>

--
This is the RPG programming on IBM i (RPG400-L) mailing list To
post a

message email: RPG400-L@xxxxxxxxxxxxxxxxxx<mailto:
RPG400-L@xxxxxxxxxxxxxxxxxx>

To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx<mailto:

RPG400-L-request@xxxxxxxxxxxxxxxxxx>

Before posting, please take a moment to review the archives at

https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx<mailto:

support@xxxxxxxxxxxxxxxxxxxx> for any subscription related questions.

.
--
This is the RPG programming on IBM i (RPG400-L) mailing list To
post a

message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,

visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at

https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post
a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.