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
midrange.com
