|
Its not IBM's responsiblity to write legacy converters, but if they want to encourage people to migrate systems, they have to make it an easy path. -----Original Message----- From: eric.delong@pmsi-services.com [mailto:eric.delong@pmsi-services.com] Sent: Wednesday, May 12, 1999 3:52 PM To: MIDRANGE-L@midrange.com Subject: Re[2]: X-Spec (was: "RPG isn't cool") HELLO!!!!! Wake up! There's no requirement that you have to use CF coding specs. If you want to use them, fine. Otherwise forget about it. I do NOT thing it's IBM's responsibility to convert your (or my) old garbage into CF. Someone would write a conversion utility to do this (Bradley <g>) eventually. BTW, have you already converted all of your RPG to RPGIV? Did you use IBM's tools, or third party? eric.delong@pmsi-services.com ______________________________ Reply Separator _________________________________ Subject: Re: X-Spec (was: "RPG isn't cool") Author: <MIDRANGE-L@midrange.com > at INET_WACO Date: 5/12/99 3:12 AM Carsten/David, >4) No - I'd rather see the ++ function added and as for overflow >issues I'd prefer to code defensively where appropriate - this >will also make my intentions clearer for the next >programmer having a look at the code. While I agree with you on new code, how do you propose IBM should convert legacy code to CF for us? You'd need a conversion option like some of the third party tools to enhance CVTRPGSRC where you could choose whether or not to convert to EVALs. But when you didn't, wouldn't you still rather have the arithmetic opcodes be free-format so the code can be indented properly? I sure would. Another dilemma occurs with the I/O opcodes. I fully agree that new code should use the BIFs instead of resulting indicators. And where a conversion utility can recognize that it is safe to drop I/O resulting indicator(s) and change conditioning indicators to a BIF, I'm all for that too. But what should a conversion utility do when I/O resulting indicators cannot be reliably dropped and conditioning indicators changed to a BIF? We all have seen plenty of legacy code which would fall into this camp because references to the indicator were not localized to the code following the I/O, and the same indicator was used as a resulting indicator for something else in another part of the program. Or what if the I/O resulting indicator was used as a conditioning indicator in an external DSPF or PRTF? Should the conversion utility check the DDS to see if it is used? I'm all for using BIFs with new code, but wouldn't it be nice to have legacy code nicely formatted too? To me, it seems "cleaner" to have the conversion indent it properly and add EOF(50) or whatever than to switch to fixed format for the line. What do you think? +--- | 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 +--- +--- | 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 +--- +--- | 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.