× 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.



Jon,

>Why not ?  We've waited for years to get the V4R2 built-ins %Found, %EOF, etc.
>so that we could get rid of all those indicators.

>Why on earth would we want to re-introduce them in what promises to be a nice
>"clean" new version of the language ?

Just for the sake of converting existing code.  Like I said in other
postings, I agree using BIFs for new code is the only way to go.

But why not allow legacy code to get the readability of free-format?
And wouldn't you rather have the calcs completely free-format instead
of hybrid?  Why have a fixed-format CHAIN with the factor1 keyfield
starting in col 12, when we could indent it properly if we added
NR(50) Err(51)?

Another reason I think it should be done this way is to minimize the
amount of work for IBM.  Like you and others have said, they should
devote resources to adding additional capabilities.  Adding support
for keyworded resulting indicators (ala RPG/free) should be relatively
trivial, and it means they could make a *very* simplistic conversion
tool and let third-parties deal with more advanced conversions.

It would be possible to make a converter which would try to recognize
when it is safe to change resulting indicators to BIFs, when MOVEs are
compatible with EVALs, etc.  But let third parties do that, and let
IBM spend the money adding new features.

I don't feel it is necessary to inhibit support for I/O resulting
indicators just to encourage people to use the BIFs when writing new
code.  To me, the advantage of getting the code completely free-format
instead of hybrid outweighs the disadvantage of allowing people to
write new code using I/O with resulting indicators instead of BIFs.

If you can convince me that a third-party tool could be written which
could reliably replace all resulting indicators with BIF references,
then I will gladly endorse not allowing them.  Compatability is (was)
my concern.

Come to think of it, I suppose one option would be for a tool to
convert:

      C     KeyFld        Chain     FileName          5051

to

     CF   Chain KeyFld FileName
     CF   Eval *IN50 = %Found
     CF   Eval *IN51 = %Error

or something to that effect.  Hmmm, maybe it wouldn't be so bad to not
allow resulting indicators.  Compatibility is (was) my concern,
without the need to still use the hybrid format.

Doug
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.