Home > Archive > Cobol > September 2005 > Re: Unorthodoxed usage of FUNCTION SUM in CICS/COBOL
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Unorthodoxed usage of FUNCTION SUM in CICS/COBOL
|
|
| William M. Klein 2005-09-18, 6:55 pm |
| Don't ask me whether this would or would not perform "better", but it certainly
seems more "self-documenting" to me, but wouldn't a
Move all X"0001" to BMSGT001-LINE
followed by the COMPUTE ... SUM .... (ALL)
work "as well" and not rely on moving signed valued to unsigned receivers?
(This would, of course rely on
MAP-DESCR-LEN
remaining as the first field under the OCCURS and remaining a two-byte COMP
field AND there being an "even number of bytes" under the OCCURS. This may be
too many assumptions, but it still seems "clearer" to me that you are counting
all occurrences of "1".
--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:2zjXe.39$8B6.30@newssvr24.news.prodigy.net...
> "wobconsult" <wobconsult@sprynet.com> wrote in message
> news:1127072226.544567.283750@g49g2000cwa.googlegroups.com...
>
>
> HIGH-VALUES on your system is presumably all x'FF' (this *is* program
> dependent, but you knew that, right?)
>
> MAP-DESCR-LEN PIC S9(04) BINARY when set to all x'FFFF' will equal -1
> (decimal).
>
> That makes the sum (ALL) equal to -15.
>
> When you move that to an unsigned field (PIC 9(08) ) you get...... ????
>
> MCM
>
>
>
| |
| Michael Mattias 2005-09-18, 6:55 pm |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:EYlXe.94749$vo5.7513@fe01.news.easynews.com...
> Don't ask me whether this would or would not perform "better", but it
certainly
> seems more "self-documenting" to me, but wouldn't a
>
> Move all X"0001" to BMSGT001-LINE
> followed by the COMPUTE ... SUM .... (ALL)
>
> work "as well" and not rely on moving signed valued to unsigned receivers?
> (This would, of course rely on
> MAP-DESCR-LEN
>
> remaining as the first field under the OCCURS and remaining a two-byte
COMP
> field AND there being an "even number of bytes" under the OCCURS. This
may be
> too many assumptions, but it still seems "clearer" to me that you are
counting
> all occurrences of "1".
Um, how about something a tad less esoteric...
....
03 BMSGT001-LINE OCCURS 15 TIMES.
05 MAP-DESCR-LEN PIC S9(04) BINARY.
05 MAP-DESCR-ATTR PIC X(01).
05 MAP-DESCR-DATA PIC X(65).
* NOTE THIS NEXT VALUE MUST EQUAL THE NUMBER OF OCCURS IN ABOVE TABLE.
01 NUMBER-OF-OCCURS PIC S9(04) USAGE BINARY VALUE + 15.
Or, with Microfocus or other compilers supporting 'constants'
78 NUMBER-OF-OCCURS PIC s9(04) USAGE BINARY VALUE +15.
....
03 BMSGT001-LINE OCCURS NUMBER-OF-OCCURS TIMES.
05 MAP-DESCR-LEN PIC S9(04) BINARY.
05 MAP-DESCR-ATTR PIC X(01).
05 MAP-DESCR-DATA PIC X(65).
or if you don't mind a little wasted memory space and don't mind a MOVE
statement located somewhere else in the program
77 NUMBER-OF-OCCURS PIC s9(04) USAGE BINARY.
* Make sure to change the move statement in paragraph MAIN if you change the
size of this table
03 BMSGT001-LINE OCCURS 1 TO 200 DEPENDING ON NUMBER-OF-OCCURS.
05 MAP-DESCR-LEN PIC S9(04) BINARY.
05 MAP-DESCR-ATTR PIC X(01).
05 MAP-DESCR-DATA PIC X(65).
MAIN.
MOVE +15 To Number-of-occurs.
(The whole 'initialize with HIGH-VALUES' thing seemed a bit strange to me
to start with).
MCM
|
|
|
|
|