Train/Rexx


REXXcedrin headache #2245

There are several places in my code where I use stem variables indexed by something other than numbers and I have discovered an instance where seemingly proper code can be just imprecise enough.  The particular example I ran afoul of used an ISPF table, but this could happen almost anywhere:


    ct.  = 0
    valuelist = ""
    do forever
        TBSKIP table         /* get tablevalue */
        if rc > 0 then leave
        ct.tablevalue  = ct.tablevalue + 1
        if wordpos(tablevalue,valuelist) = 0 then,
            valuelist = valuelist tablevalue
        ...etcetera,
    end /* forever */

then later....

    do ii  = 1 to words(valuelist)
        thisvalue = word(valuelist,ii)
        say ct.thisvalue
    end

Some of the 'say's deliver 0, but there can't be any of those, right?    We're interrogating only those stems for which we have stored values and (therefore) done some counting.  How can the count be zero ?

---------------------------------

Answer: the TBSKIP delivered tablevalue, alright.   Unfortunately, tablevalue was "ABCDE       ".  We stored this into valuelist as "AB1111         ABCDE       PDQ46          MXDREG3 .......", then, when we got around to asking for Word(valuelist,2), we wound up with "ABCDE", neatly packaged and trimmed.

Surprise !   ct.'ABCDE      '  does NOT equal ct.'ABCDE'   :-( The first one has a value > 0, but it's lost forever, because we no longer know how many blanks to add to produce the right result; the second version has the default value of zero unless we're REALLY unlucky, in which case it will have a value that looks like it might be right but is actually dead wrong.

The worst calamity that can befall a programmer is that a program appears to work correctly.

Frank Clarke, <Nisus@Mindspring.com>