× 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: CF-Spec - another call for opinions
  • From: "Stone, Brad V (TC OASIS)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Wed, 11 Aug 1999 15:39:36 -0500

I also vote for getting ride of CALL, eval, etc. with the free format
statements.  Boolean data types would be neat too.  (more "boolean" than
indicators, values of TRUE of FALSE)

ie...

CF  x=x+1
CF  dow (x < 10)
CF     if (IsPalidrome(string(x)))
CF        text = "It's a palindrome!"
CF     endif
CF  enddo  

Bradley V. Stone
BVS/Tools
http://www.bvstools.com




> -----Original Message-----
> From: James Greene [mailto:triplej@ibm.net]
> Sent: Wednesday, August 11, 1999 2:25 PM
> To: RPG400-L@midrange.com
> Subject: Re: CF-Spec - another call for opinions
> 
> 
> I vote for option 2.  With one thought.  In addition to the 
> CALLP is the
> likelyhood of a CALLx insignificant?
> 
> boldt@ca.ibm.com wrote:
> 
> > Greetings!  Asking the readers of this mailing list seems to work
> > well for us in deciding questions.  And again, we have an issue
> > which your opinions will help us decide on.  In examples that I've
> > posted already, you've seen statements like "CF var = value", where
> > the opcode EVAL is omitted.  Based on someones suggestion earlier
> > today, I investigated allowing "CF UpdateMasterFile()" instead of
> > "CF callp UpdateMasterFile()", and I found it remarkably easy for
> > us to implement.
> >
> > However, allowing the opcode names EVAL and CALLP to be optional
> > raises the issue of future compatibility.  Say someone codes
> > "CF fred = flintstone" and in a later release we add new opcode
> > FRED.  This would result in a compile error!  Note that we're not
> > really making the opcode names reserved since we'd still allow
> > "CF eval read = x", and in fact, coding EVAL would be required if
> > the target variable name is the same as an opcode name.  As a
> > result, the problem is not as bad as the appearance of new
> > statements in other languages, especially COBOL.  But it would be
> > something new for RPG programmers.
> >
> > So, please consider and choose one of the following options:
> >
> > 1) Make EVAL and CALLP always required:
> >
> >       CF eval KeepLooping = *ON
> >       CF dow KeepLooping
> >       CF    read MasterFile
> >       CF    if %eof
> >       CF       callp HandleEndOfFile()
> >       CF    endif
> >       CF enddo
> >
> > 2) Allow EVAL and CALLP to be omitted:
> >
> >       CF KeepLooping = *ON
> >       CF dow KeepLooping
> >       CF    read MasterFile
> >       CF    if %eof
> >       CF       HandleEndOfFile()
> >       CF    endif
> >       CF enddo
> >
> > 3) Option 2 with a commitment from us that no new opcodes will
> >    conflict with any possible variable or procedure name.  For
> >    example, opcode ON-ERROR could never be confused with a var or
> >    proc name.  This may mean some goofy looking opcodes in the
> >    future.  On the other hand, since most enhancements these days
> >    seem to be in BIF's, this may not be too big a deal.
> >
> > 4) Optional EVAL and CALLP, but use some special character to
> >    distinguish opcode names from var or proc names:
> >
> >       CF KeepLooping = *ON
> >       CF /dow KeepLooping
> >       CF    /read MasterFile
> >       CF    /if %eof
> >       CF       HandleEndOfFile()
> >       CF    /endif
> >       CF /enddo
> >
> >    If you don't like "/", what about some other character?
> >
> > 5) Is there some other alternative we've missed?
> >
> > As usual with this kind of poll, comments on the issue are
> > welcome.
> >
> > Cheers!  Hans
> >
> > Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
> >
> > +---
> > | 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
> > +---END
> 
> +---
> | 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
> +---END
> 
+---
| 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
+---END



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.