RE: RPG - conversion vs re-write -- MIDRANGE-L

Bob Cozzi <BobCozzi@ibm.net> wrote:
>Hans,
>> Bob:  There's nothing wrong with the implementation of null-capable
>> fields in RPG.  I have my concerns about the design, but the
>> implementation is just fine!
>
>Well, yes, the design, but don't you guy usually design it and write it?
>Then if it's accepted that's the way it is?

Touche!

>
>Anyway, I agree, I'm talking about the design.
>
>But it seems like the whole idea of NULL is difference from things like C.
>For example, if a pointer is NULL, it is set to X'00' isn't it? I thought
>that was how C did it. This happens to be the value of the pointer
>variable, is it also the attribute?

That's exactly my point!  The null value is not the same as the null
attribute.  Imagine, for a moment, having pointers in database files.
You then need to distinguish between the null value and the null
attribute.  A pointer with a null value is not the same as a pointer
with the null attribute.

>
>Sometime this dictionary definition of a word and the practical use of the
>word are often two different things. Take the *OMIT and *NULL use on
>parameters.  Why do we have to pass *OMIT, and then actually do an
>
>IF myParm = *NULL
>
>This is very confusing to me. I'm sure there's a reason, but wouldn't it
>have made it more clear to the end-programmer to have been written as
>
>  CALLP   MyProc(value1, value2,  3 + 4,  *NULL, value5)
>
>Then do the IF myParm = *NULL?  I would have liked that 1 million time
>more.  I avoid things like this because it's so unclear that maintenance
>programmers may not easily identify with it. (and that includes me.)

Forgive me for quibbling, but the test is "IF %ADDR(MyParm) = *NULL".
If a parameter is omitted, it's value is not null, but rather, it's
address is null.

Why did we choose *OMIT instead of *NULL on the call?  Think about
passing a pointer as a parameter.  Does *NULL as a parameter mean the
null value?  or an omitted parameter?  (OK, *NULL can't be passed as a
reference parameter, but it is allowed as a value parameter.  Wouldn't
this be more confusing when casually reading your code?)

>
>I guess you really said what is bothering me more than each of these little>
>subtle issues in RPG IV.  It the point that stuff isn't ever finished. It's>
>always "almost the way we wanted it" or "we're looking at doing that in a>
>future release."

I'm sure you are familiar with the reason for this:  Too few resources
to implement too many things.  Planning a new release is always an exercise
in compromise.  Most times we look at what must be done, and we try to
come up with some package that meets the requirements while providing
useful function to those who don't care about those requirements.  (The
same thing is going on with our current planning efforts for our next
release after V4R2.)

I do agree with you on this point.  It's never as good as we'd like.

>Since the biggest thorn in RPG's side seems to have moved
>on with his life, there really isn't any distractions or subversive
>actions. Maybe we can start fresh with V4R2?

Well, he may have been a big "thorn" to some people, but to us developers,
he was one of the most highly respected members of the RPG team.  Not
just for his experience, but also for the no-nonsense approach he used
when dealing with management.  He was one of the few senior developers in
the lab who could tell upper level management what they needed to hear,
not what they wanted to hear, regardless of the consequences.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, hboldt@vnet.ibm.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---