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