× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: RPG - conversion vs re-write
  • From: Bob Cozzi <BobCozzi@xxxxxxx>
  • Date: Thu, 11 Sep 1997 17:55:11 -0500

Hans,

First, I would NEVER put a pointer in a database file, hence I'd never have 
the problem you mentioned. If I did, I'd set the pointer to X'00' and use 
that as my convention.

Second, the thorn in the RPG programmer's side I was referring to, has 
NEVER been an IBM employee. I know who you think I meant, but it was in no 
way your namesake. I have no problems with him.

Finally, I suppose it would help if you'd at least come up with a plan to 
back-peddle some of this new feature so that everyone can take advantage of 
it. For example, compiler directives and longer names. This stuff is not 
going to be widely useful for at least 3 more years because of the release 
compatibility issues. I mean, gosh, why can't I use compiler directives on 
my V3R7 machine?  If I want the object code to run pre-V3R7 systems, I 
cannot use compiler directives. So what good are they?  They're no good. 
And in fact, they are contra productive. They've taking resource from you 
guys--kept you from doing that one or two other functions now. And they 
give me an ulcer because I really want to use it, but I can't. So close and 
yet so far.....................


Bob Cozzi
Bob@RPGIV.COM
www.rpgiv.com
AS/400 Books:  http://www.rpgiv.com/as400Books.html


On Thursday, September 11, 1997 8:17 AM, Hans Boldt 
[SMTP:hboldt@vnet.IBM.COM] wrote:
> 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
> +---
> 
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.