Re: When is a DS not equal to another DS?

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hi Bruce,

> The only thing we can see is that when the based-on DS has an embedded DS in
> it, the result is false, otherwise it is true.  Here is a sample of the
> offending code.  If anyone sees what we are doing wrong or has a link to a
> manual with a reference to this condition, I'd sure appreciate it.
One thing that struck me about your message is that you say something 
about comparing the subfields to make sure they have the same values -- 
subfields?  RPG isn't comparing subfields, it's comparing two character 
strings, one named "curdta" and one named "orgdta"!  Basically, all of the 
subfields you defined in the DS overlay those character strings -- but 
there's still a chance that there's something else in the string aside 
from the subfields (RPG sometimes has unused positions in the DS to align 
the subfields -- and those extra positions would still be part of the "big 
string" even though there's not subfields in those positions.)
Having said that, however, I haven't been able to reproduce the problem 
you describe.  What sort of data are you putting the in DS?  How is it 
getting there?
Here's the code I used to try to reproduce your situation:

     h dftactgrp(*no)
      *===============================================================
     d rpname          ds                  based(@)
     d                                     qualified
     d  rjkey                              likeds(rpnamekey)
     d  rjprim                        1a
     d  rjsnam                       15a
     d  rjfnam                       30a
      *===============================================================
     d rpnamekey       ds                  based(@)
     d                                     qualified
     d  rjcomp                        3a
     d  rjresp                        7s 0
     d  rjprof                        2s 0

     d UpdRPName...
     d                 PR             3i 0
     d  curdta                             likeds(rpname)
     d  orgdta                             likeds(rpname) const
     d  newdta                             likeds(rpname) const

     D ds1             ds                  likeds(rpname)
     D ds2             ds                  likeds(rpname)
     D ds3             ds                  likeds(rpname)
      /free

           ds1.rjkey.rjcomp = '123';
           ds1.rjkey.rjresp = 7654321;
           ds1.rjkey.rjprof = 12;
           ds1.rjprim = 'A';
           ds1.rjsnam = *ALL'B';
           ds1.rjfnam = *ALL'C';

           ds2 = ds1;
           ds3 = ds1;

           UpdRPName( ds1: ds2: ds3 );

           *inlr = *on;

      /end-free

      *===============================================================
     p UpdRPName...
     p                 b                   export
      *===============================================================
     d UpdRPName...
     d                 pi             3i 0
     d  curdta                             likeds(rpname)
     d  orgdta                             likeds(rpname) const
     d  newdta                             likeds(rpname) const
      *===============================================================
      /free
           select;
           when curdta = orgdta;
              dsply 'curdta = orgdta';
           other;
              dsply 'curdta <> orgdta';
           endsl;
           return 0;
      /end-free
     P                 E


When I run this, I get 'curdta = orgdta' displayed in my job log.  So -- 
for me, it works the way you'd expect, but that doesn't match your 
findings.
Have you tried displaying the DS names in hex with the debugger?  In the 
green screen debugger you can type "eval curdta:x" and it'll show a hex 
dump. You could do that for both DS names and compare the contents... if 
you don't have the same data in the same positions, then you need to 
investigate why.  If you do get the same data in the same positions, it's 
obviously a bug in RPG.
But, in my tests, it was no problem, they looked identical, and the 
program reported them as equal.  So if you can tell me how to reproduce 
the problem, I may have more to say...