Re: Want to replace MOVE numeric 8 to numeric 6 in free form

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.