Re: Alternatives to MOVEL - just curious

On 09-Dec-2013 10:29 -0800, Vernon Hamberg wrote:

On 09-Dec-2013 08:31 -0800, Vernon Hamberg wrote:

I'm looking at some code - the purpose is to put the 1st 4 digits
of a 6-digit variable into a 4-digit numeric variable.

It is being done with the MOVEL opcode now.

I'm wondering about efficient alternative methods. One I can think
of is to use a data structure -

dcl-ds dsMoveL qualified;
num4 zoned(4);
num6 zoned(6) pos(1);
end-ds;

Anything simpler? Better performing?

I hope the syntax is right!! But you get the idea, right?

<<SNIP>> we're dealing here with things that will never involve
calculations - IDs stored as zoned data types. MOVEL has the
advantage that it's not really a calculation in the sense of an
expression, it's a kind of memory operation, seems to me. <<SNIP>>

http://archive.midrange.com/rpg400-l/201308/msg00128.html#
Subject: Re: Want to replace MOVE numeric 8 to numeric 6 in free form
From: CRPence <CRPbottle@xxxxxxxxx>
Date: Sat, 17 Aug 2013 13:03:50 -0700

Given the zoned portion [non-sign portion] of Zoned BCD data is the equivalent to the EBCDIC numeric decimal digits zero through nine [0xF1 to 0xF9], just have a declarative [re]mapping of the [portions of the] zoned decimal variable(s) as alpha\char. A[n additional] Data Structure is not even necessary, but is easier to define and use, if the storage is already declared in an internal DS. Surely the simplest and best performing will be had whenever the storage is defined exactly as required, without any requirement to ever /move/ [or copy] the data elsewhere; i.e. data is just referenced exactly as data-typed. But of course, multiply-typed and multiply-named storage is often a bane of /quality/ programming; as Jon suggests is his opinion [in this thread and the older one above], using a nicely named subprocedure is probably most appropriate. Surely, coding the effect once in a [sub]procedure would be the simplest to replace multiple instances of the MOVE\MOVEL statements spanning different declared variables, and the effect on performance would likely be negligible in normal processing.?

Regardless, as I warned in a post in that other message thread, replacing a MOVE or MOVEL statement with another function that does not produce the *identical* results may have unforeseen consequences in later processing... even if they only originate as dependencies on nuances that might be considered either defect or at least possibly undesirable. So while an arithmetic or other similar casting methods might *seem to* give what are *acceptable* results in some specific testing, they will not necessarily be the *required* results for the program to continue working as expected *across all possible data* the program has processed or will process with an assumption of the same effect as in the past. Moving the /fixed-format/ code elsewhere, a subprocedure, to avoid its ugliness remaining inline to the since-modified to free-format code, might best just code the original MOVEL and be done with it.? It all depends of course, on what the code really *needs* to do to make everything work, while avoiding any unnecessary breakage; however /broken/ might be defined :-)
http://archive.midrange.com/rpg400-l/201308/msg00134.html