Re: %LEN and *ZERO

Hello Barbara,

You wrote:
>Simon, to follow up on Hans telling you that it's already fixed
>in the next release ...

Yeah, but ..... we poor developers can't use the new you-beaut features if we 
need to provide code for lagardly customers ...

>The obvious circumvention is to use 0, but a better one is to assign
>the null literal '' to cmdString.

Assigning a null literal hadn't occured to me because I'm actually using the 
variable length field as the return value for a prompt override program (POP).  
The mechanism for informing the command analyzer that there was an error in 
the POP is to set the first two bytes to zero hence me thinking in bytes.

(Having read Hans' later note regarding the performance I think I'll stick 
with the %LEN() function which also seems a little more obvious to me -- even 
though the performance would not matter in this case).

>You said you thought *LOVAL and *HIVAL should be supported to.
>Hans didn't mention that the compiler now only allows *ZERO, not
>*LOVAL or *HIVAL.  But *LOVAL means the same as *ZERO.  *HIVAL
>isn't really defined - is it the maximum for the 5u 0 (not 4b 0 or
>5b 0) length part or is it the maximum for the length of the variable?

I was only thinking aloud (what is it called when thought's are written rather 
than spoken ??) about the *LOVAL and *HIVAL figurative constants.  Personally, 
I'd rather spend development dollars on new function rather than supporting 
*HIVAL and *LOVAL.  My favourite enhancement is user-defined types -- I'd 
spend $40 dollars on that single feature alone.  If you did choose to support 
*HIVAL and *LOVAL then I'd expect them to work as follows:

        %LEN(cmdString) = *HIVAL should set the length to the maximum declared 
length of the variable.

        %LEN(cmdString) = *LOVAL should set the length to zero

>Anyway, you can get the exact equivalent of meaningfully setting
>the length to *HIVAL by assigning *BLANKS.

That's true and therefore another argument for not adding support for *HIVAL.  
Which is more obvious?
        C               EVAL    varChar = *BLANKS
or
        C               EVAL    %LEN(varChar) = *HIVAL
I'd argue the former is the more obvious code and therefore preferable.

>> I can feel a PMR coming on ....

>(Ewww.)

>I don't know if you'd get a PTF for this, but I guess you could try.
>But you'd probably be given the circumventions I just gave you.

I don't intend to open a PMR for this, it is too trivial, although I would if 
I didn't know it is fixed in a later release.  Wearing my customer hat I'd 
like it PTFed because I don't like using:
        C               EVAL    %LEN(varChar) = 0
and it is obviously broken, but wearing my ex-IBMer hat I'm thinking:
"What is with this customer?  We're not going to fix this because it is 
already fixed in a later release and there is an acceptable work-around.  Tell 
him to get real!" Of course, that sentiment would be expressed so much more 
politely by IBM support :)

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---