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



On 17 Aug 2013 14:31, Vernon Hamberg wrote:
I'm thinking there is a new winner!

There isn't a real performance issue - this is a one-sy kind of
thing - not something applied to millions of records - it's in an
add/change program, only affecting one 8-digit "date" value upon
updating a record that fed a subfile.

As to arithmetic - it was Jon's word, applied to my data structure
solution, which takes a couple lines and additional specification.

Again, verrrrrrrrrrrrry eeeeeeeeeenteresting!


Often there is great importance in taking care with replacing code in a manner that ensures the new code works /the same/ as the original, given the same inputs. Sometimes the complexity of prior or later processing and the requirements is not conspicuous. Just like how converting the input values to a date might be an assumption-too-far [*ZERO and *HIVAL most conspicuously], so might be the assumption that the EdtCde(X) is compatible. The 'unedited form' effected with the Edit-Code-X will produce character string values that are incompatible with conversion to decimal via %DEC when the input values are negative. That can be handled with %ABS, but then that also will produce different results than were effected in the past; i.e. the packed decimal result in the past using MOVE would have maintained sign, but new code using %ABS to resolve issues with EdtCde(X) of a negative value would not.

AFaIK what I offered gives the identical results to the MOVE irrespective of the input *except* perhaps if the low-order nibble of the leftmost two bytes of the zoned BCD data are not valid numeric, for which a decimal data error could have been the effect in the old code but for which my example should not. FWiW your original example, I believe, would probably be even more likely to be identical in effect to the old code; i.e. decimal data errors would be consistent, as would all other results.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.