|
Mark, >Then you could make a function called MOVE, use it in /free and everyone >would be happy. :-) Actually, if we had operation descriptors for numeric fields that could do that. However, I'm with IBM on this one. I think it was a good decision to leave MOVE out of /free supported opcodes. While MOVE may be easy to "read" and code initially, it is *not* easy to understand by just reading the code unless you have an in-depth knowledge of the fields involved. And that can't always be taken for granted. You can get some very subtle program bugs by field defintions changing and MOVE not working the way the original programmer intended. And they can be very hard to spot when perusing a program using the "readable" MOVE opcode. Aside to Joe: In terms of converting legacy code where 50,000 lines are using MOVE, the vast majority of those will be with compatible field sizes. So I'd write a utility which analysed the fields involved and replaced MOVE with the equivalent code which may be as simple as changing: MOVE X Y to Y = X or it may require adding substringing, a routine to convert char to numeric or vice versa, etc. In the end you have the readability of a simple assignment when that is what the code is doing, and explicit substring or casting when that is necessary. And *that* to me makes the program *more* readable than if it continued to use MOVE with its various ambiguities. IMHO Doug
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.