Hex Value Moves
- From: docdwarf@xxxxxxxxx ()
- Date: Thu, 31 May 2007 13:55:23 +0000 (UTC)
All righty... it has been discussed here and I had a few moments to spare
(and some client CPU cycles to burn) so I descended into... The Temple of
Truth. Given the code:
IDENTIFICATION DIVISION.
PROGRAM-ID. SKEL1.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
SYMBOLIC CHARACTERS
SPECNAM-CH-E5 IS 230.
DATA DIVISION.
WORKING-STORAGE SECTION.
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.
01 CH-E5-IN-WS PIC X VALUE X'E5'.
01 TESTCHAR01A PIC X VALUE SPACES.
*
PROCEDURE DIVISION.
DISPLAY ' BEGIN: '.
DISPLAY ' '.
*
MOVE X'E5' TO TESTCHAR01A.
IF TESTCHAR01A = CH-E5-IN-WS AND
CH-E5-IN-WS = CH-E5 AND
CH-E5 = SPECNAM-CH-E5
DISPLAY '!! ALL EQUAL'
ELSE
DISPLAY '!! NOT EQUAL'.
*
MOVE SPECNAM-CH-E5 TO TESTCHAR01A.
MOVE CH-E5 TO TESTCHAR01A.
MOVE CH-E5-IN-WS TO TESTCHAR01A.
GOBACK.
.... and the compiler of IBM Enterprise COBOL for z/OS 3.4.1 ... and a
bunch of invocation parameters including, but not limited to,
'SIZE(MAX),LIB,MAP,DYNAM,LIST,XREF,OPT,FLAG(I,I),NUMPROC(PFD),' (reasons
for said options including, but not limited to, 'I had 'em hangin'
around') ...
.... then the SYSOUT of the job's run included:
BEGIN:
!! ALL EQUAL
Now comes the Deeper Stuff... and, in a nutshell, all MOVEs compiled into
MVI statements...
.... EXCEPT for the next-to-last, MOVE CH-E5 TO TESTCHAR01A; this resulted
in (some editing in an attempt to improve legibility):
000030 MOVE
000342 D200 3010 3001 MVC 16(1,3),1(3) TESTCHAR01A CH-E5
According to the Data Division Map everything winds up as a DS 1C. Since
CH-E5 is subordinate to the group-level FILLER it has a displacement
associated with it that the other WS fields do not, eg (some editing as
above):
CH-E5 . . . . . . . . . . . . . . BLW=00000 001 0 000 001 DS 1C
CH-E5-IN-WS . . . . . . . . . . . BLW=00000 008 DS 1C
.... and this may account for the difference.
Now... the question becomes, of course, 'does any of this make a
difference?'... and the answer is a most definite 'probably not'.
What does the code do? My guess, based on the NewLine and FormFeed
instructions, is that based on an online transaction (it is CICS code)
that something gets spooled to print.
So... what's the volume of printed material?
That is unknown... but given the old standard (Murach, I think) that an
MVC takes three times as long as an MVI then I'd conclude that the
strictly scientific quantity of 'a whole bunch' of printing would have to
be done using this program in order to justify the cost of recoding,
testing and redeploying code that has been tooling along rather nicely for
the past thirteen years or so.
My views are based on the code and my experience... and are, quite
obviously, worth at least double what I have been asking folks to pay for
them here.
DD
.
- Prev by Date: Re: OT: Hoping for a Miracle
- Next by Date: Re: Setting A Hex Value in COBOL [correction]
- Previous by thread: OT: Hoping for a Miracle
- Index(es):
Relevant Pages
|