Re: Setting A Hex Value in COBOL

In article <135sn0achcmu88@xxxxxxxxxxxxxxxxxx>,
Rick Smith <ricksmith@xxxxxxx> wrote:

"gary" <garyinri@xxxxxxxxx> wrote in message
news:%yj7i.172509$nh4.82579@xxxxxxxxxxxxxxx

[snip]

01 CH-NL-BIN PIC S9(4) COMP VALUE +21.
01 FILLER REDEFINES CH-NL-BIN.
02 FILLER PIC X.
02 CH-NL PIC X.
01 CH-FF-BIN PIC S9(4) COMP VALUE +12.
01 FILLER REDEFINES CH-FF-BIN.
02 FILLER PIC X.
02 CH-FF PIC X.
01 CH-1D-BIN PIC S9(4) COMP VALUE +29.
01 FILLER REDEFINES CH-1D-BIN.
02 FILLER PIC X.
02 CH-1D PIC X.
01 CH-56-BIN PIC S9(4) COMP VALUE +86.
01 FILLER REDEFINES CH-56-BIN.
02 FILLER PIC X.
02 CH-56 PIC X.
01 CH-31-BIN PIC S9(4) COMP VALUE +49.
01 FILLER REDEFINES CH-31-BIN.
02 FILLER PIC X.
02 CH-31 PIC X.

My question is this. I need to add a field which would end up containing
a
X'E5'. The decimal equivalent is +229. Since the value of the field is
3-digits, will it still "fit" into the PIC X field? Would it look something
like this?

01 CH-E5-BIN PIC S9(4) COMP VALUE +229.
01 FILLER REDEFINES CH-E5-BIN.
02 FILLER PIC X.
02 CH-E5 PIC X.

This is some old MVS COBOL II code. Is there actually a better way to be
performing this function? Is there anything like MOVE X'E5' to CH-E5?

Whether anything is better may be entirely subjective;
but two other methods come to mind, both of which
seem to have become available with VS COBOL II.

1. Symbolic characters (ANSI 85):
[Note that values given here are 1 greater than the
actual character.]

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
SYMBOLIC CHARACTERS
CH-NL IS 22
CH-FF IS 13
CH-1D IS 30
CH-56 IS 87
CH-31 IS 50
CH-E5 IS 230.

2. Hexadecimal literals (VS COBOL II extension):

DATA DIVISION.
WORKING-STORAGE SECTION.
01 FILLER.
02 CH-NL PIC X VALUE X"15".
02 CH-FF PIC X VALUE X"0C".
02 CH-1D PIC X VALUE X"1D".
02 CH-56 PIC X VALUE X"56".
02 CH-31 PIC X VALUE X"31".
02 CH-E5 PIC X VALUE X"E5".

The use of symbolic characters may generate MVI
instructions and not require any working-storage.
This use of hexadecimal literals in working-storage
may generate MVC instructions; but use less
working-storage than the existing method. Extending
the existing method may be more consistent with
other programs in the system. These are the choices
I see.

Hmmmmm... the program, Mr Plinston, uses a method I was taught lo, those
many years ago, of REDEFINING a two-byte COMP field so that the
lower-order byte contained the hexval that was needed; COBOLII-like
features have obviated the need for this bit of skill. (Being able to
address X'nn' directly and as such was one of the more delightful things I
found in my first copy of MicroFocus... 1.8, I think, I still have a copy,
somewhere, that runs off of three 720K floppies.)

Anyhow... I'd favor your second suggestion over your first; the 'you have
to remember to subtract 1' is something I've seen bite folks unfamiliar
with the intricacies of such things while 'VALUE IS X'0F'' is, to my eye,
a bit harder to misinterpret.

As for the code generated by either... I'd say they'd both be made into
MVIs; even IKFCBL00 was capable of differentiating single- and multi-byte
fields and taking that particular bit of advantage... but I may have some
spare time today and fun a few compiles... I work in a Most Advanced Shop,
you see, and even though I introduced the first VSAM KSDS with an
alternate index into our little chunk of Production in 2004 I'm not only
allowed to submit compiles without the DBA's approval... after a bit of
hunting I was able to make my own compile streams for both OldBOL and
NewBOL.

DD

.