Hex Value Moves

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,F
LAG(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

It would be (sort-of) interesting to see what changes in
NUMPROC
and
TRUNC

do to the pseudo-assembler (if anything)

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:f3mk4b$ms0$1@reader2.panix.com...
>
> 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,F
LAG(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
>

In article <DZH7i.194382$865.167087@fe05.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>It would be (sort-of) interesting to see what changes in
>  NUMPROC
>    and
>  TRUNC
>
>do to the pseudo-assembler (if anything)

Hmmmm... I usually leave such things to folks better-versed in such
matters than I am but I'm willing to try.  Can you provide a list of
combinations of various NUMPROC and TRUNC possibilities you'd like to see
fed in?

DD

TRUNC(OPT),NUMPROC(NOPFD)

TRUNC(STD),NUMPROC(MIG)

and what you already did, should show if this make any difference.

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:f3nmqg$ip7$1@reader2.panix.com...
> In article <DZH7i.194382$865.167087@fe05.news.easynews.com>,
> William M. Klein <wmklein@nospam.netcom.com> wrote: 
>
> Hmmmm... I usually leave such things to folks better-versed in such
> matters than I am but I'm willing to try.  Can you provide a list of
> combinations of various NUMPROC and TRUNC possibilities you'd like to see
> fed in?
>
> DD

Well, of course, everything is solved with
BINARY-CHAR UNSIGNED :-)

"Roger While" <simrw@sim-basis.de> wrote in message
news:f3p28o$mfb$02$1@news.t-online.com...
> Well, of course, everything is solved with
> BINARY-CHAR UNSIGNED :-)

"Solved?"  There never was a 'problem' to 'solve' in the first place

A numeric literal is a numeric literal is a numeric literal regarless of the
written form or radix thereof and there are rules applying to the use of
numeric literals as the source operand in a MOVE statement. (As in "RTFM").

Whether or a not a specific make and model of a compiler accepts those
numeric literals in decimal, hexadecimal, octal, binary or purple is
compiler-dependent (Also as in "RTFM") .

No one dealt with the real 'problem' here: The USE of inline numeric
literals rather than constants (if supported by compiler) or VALUE clauses
in the DATA DIVISION is just begging for a maintenance nightmare.

MCM

In article <ufN7i.196678$865.96862@fe05.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>TRUNC(OPT),NUMPROC(NOPFD)
>
>TRUNC(STD),NUMPROC(MIG)
>
>and what you already did, should show if this make any difference.

Well, let's see... what I already did used NUMPROC(PFD) and TRUNC(STD);
that resulted in everything being an MVI except for the subordinate item.

Using TRUNC(OPT),NUMPROC(NOPFD) gives the same result.

Using TRUNC(STD),NUMPROC(MIG) gives the same result.

DD

In article <UiU7i.7095$C96.6580@newssvr23.news.prodigy.net>,
Michael Mattias <mmattias@talsystems.com> wrote:
>"Roger While" <simrw@sim-basis.de> wrote in message
>news:f3p28o$mfb$02$1@news.t-online.com... 
>
>"Solved?"  There never was a 'problem' to 'solve' in the first place

[snip]

>No one dealt with the real 'problem' here: The USE of inline numeric
>literals rather than constants (if supported by compiler) or VALUE clauses
>in the DATA DIVISION is just begging for a maintenance nightmare.

Leaving aside the logic of 'There never was a 'problem'... the real
'problem' here'... the way the program was written and used allowed for it
to run untouched for almost a decade-and-a-half... and when it came time
to change it I'd say that the skills required should be well within the
set carried by a three-to-nine year programmer... well, closer to nine
than to three, granted, but still within the 'journeyman' level.

Given that level of skill (and access to a standard development
environment, without 'Please, DBA, compile my code?') then I would
estimate resource use to be four hours of the programmer's time (excluding
time to fill out paperwork to check out and check in the source, notify
the testing team that the code is ready, etc.) and enough machine time to
allow for a half-dozen compiles and tests.

As to whether or not a program has been written in a fashion which
requires this kind of personnel/resource allocation for enhancement after
thirteen years of acceptable performance is 'begging for a maintenance
nightmare'... that conclusion will be left to the reader.  I, personally,
would think it to be a rather... choosy beggar, but that, quite obviously,
is a matter of opinion.

DD

On Fri, 1 Jun 2007 12:52:12 +0000 (UTC) docdwarf@panix.com () wrote:

:>In article <ufN7i.196678$865.96862@fe05.news.easynews.com>,
:>William M. Klein <wmklein@nospam.netcom.com> wrote:
:>>TRUNC(OPT),NUMPROC(NOPFD)

:>>TRUNC(STD),NUMPROC(MIG)

:>>and what you already did, should show if this make any difference.

:>Well, let's see... what I already did used NUMPROC(PFD) and TRUNC(STD);
:>that resulted in everything being an MVI except for the subordinate item.

:>Using TRUNC(OPT),NUMPROC(NOPFD) gives the same result.

:>Using TRUNC(STD),NUMPROC(MIG) gives the same result.

Of course.

I don't see any numeric non-literal operations.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Interesting (and a little surprising) to me - but that's why "try it and see
" is
always better than guessing.

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:f3p4ps$biq$1@reader2.panix.com...
> In article <ufN7i.196678$865.96862@fe05.news.easynews.com>,
> William M. Klein <wmklein@nospam.netcom.com> wrote: 
>
> Well, let's see... what I already did used NUMPROC(PFD) and TRUNC(STD);
> that resulted in everything being an MVI except for the subordinate item.
>
> Using TRUNC(OPT),NUMPROC(NOPFD) gives the same result.
>
> Using TRUNC(STD),NUMPROC(MIG) gives the same result.
>
> DD