Cobol - Re: Moving display to computational items

Author

Re: Moving display to computational items

anguel@web.de

2005-09-20, 7:55 am

Robert Jones schrieb:
> anguel@web.de wrote:
>
> It is usually good practice when posting such questions to specify the
> COBOL compiler being used, including the version, together with the
> version of the operating system being used. A code fragment, or more,
> is often helpful too.

Okay, I'm sorry. The compiler is Compaq Cobol 2.8 on a OpenVMS Alpha
7.3 OS. A code fragment was:

[...]
FILE-CONTROL.
SELECT MYFILE ASSIGN TO SOMETHING
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS REC-KEY.

[...]
FILE SECTION.
FD MYFILE.
01 MYREC.
03 REC-KEY.
05 REC-USER PIC X(12).
05 REC-DATE.
07 REC-DATE-YEAR PIC 9(4) COMP.
07 REC-DATE-MONTH PIC 9(2) COMP.
07 REC-DATE-DAY PIC 9(2) COMP.
03 REC-DATA PIC X(40).

[...]
WORKING-STORAGE SECTION.
77 W-USER PIC X(12).
77 W-DATA PIC X(40).
01 W-DATE.
03 W-DATE-YEAR PIC 9(4).
03 W-DATE-MONTH PIC 9(2).
03 W-DATE-DAY PIC 9(2).

[...]
PROCEDURE DIVISION.
P1.
MOVE "USER " TO W-USER.
MOVE SPACES TO W-DATA.
MOVE 20050920 TO W-DATE.
OPEN OUTPUT MYFILE.
CLOSE MYFILE.
OPEN I-O MYFILE.
MOVE W-USER TO REC-USER.
MOVE W-DATE TO REC-DATE.
MOVE W-DATA TO REC-DATA.
WRITE MYREC INVALID KEY DISPLAY "ERROR WHILE WRITING".
CLOSE MYFILE.
OPEN I-O MYFILE.
MOVE "USER " TO REC-USER.
MOVE 20050920 TO REC-DATE.
READ MYFILE INVALID KEY DISPLAY "ERROR WHILE READING".
MOVE REC-DATA TO W-DATA.
CLOSE MYFILE.
DISPLAY "DATE: " W-DATE.
DISPLAY "USER: " W-USER.
DISPLAY "DATA: " W-DATA.
STOP RUN.

Of course, the original program is somewhat larger, but the problem is
the same: At the final statements, garbage is displayed.

When I change the COMP statements in the FD, it works without a
problem.

I examined the file written by means of a hex editor, and I saw the
REC-DATE portion look like "200509R " - and this looks very strange to
me ;-)

A.

Chuck Stevens

2005-09-20, 6:55 pm

The problem appears to me to be that the MOVE in question, MOVE W-DATE TO
REC-DATE, is a "group MOVE", which is alphanumeric with no translation.

Thus, whatever format REC-DATE-YEAR and the other subfields of REC-DATE are,
what you're moving is not the individual fields but the group as a whole as
a group of characters. Since the elementary items are different formats
what you end up with is garbage in the destination.

Group MOVEs in COBOL are "blind".

Instead of MOVE W-DATE TO REC-DATE, you need to do three individual MOVEs:
MOVE W-DATE-YEAR TO REC-DATE-YEAR
MOVE W-DATE-MONTH TO REC-DATE-MONTH
MOVE W-DATE-DAY TO REC-DATE-DAY.

Alternatively, you could change one of the two sets so that the names are
the same, e.g.,
05 REC-DATE.
07 W-DATE-YEAR PIC 9(4) COMP.
...

and then do MOVE CORRESPONDING W-DATE TO REC-DATE.

-Chuck Stevens

<anguel@web.de> wrote in message
news:1127218474.937776.115700@g44g2000cwa.googlegroups.com...
> Robert Jones schrieb:
>
> Okay, I'm sorry. The compiler is Compaq Cobol 2.8 on a OpenVMS Alpha
> 7.3 OS. A code fragment was:
>
> [...]
> FILE-CONTROL.
> SELECT MYFILE ASSIGN TO SOMETHING
> ORGANIZATION IS INDEXED
> ACCESS MODE IS DYNAMIC
> RECORD KEY IS REC-KEY.
>
> [...]
> FILE SECTION.
> FD MYFILE.
> 01 MYREC.
> 03 REC-KEY.
> 05 REC-USER PIC X(12).
> 05 REC-DATE.
> 07 REC-DATE-YEAR PIC 9(4) COMP.
> 07 REC-DATE-MONTH PIC 9(2) COMP.
> 07 REC-DATE-DAY PIC 9(2) COMP.
> 03 REC-DATA PIC X(40).
>
> [...]
> WORKING-STORAGE SECTION.
> 77 W-USER PIC X(12).
> 77 W-DATA PIC X(40).
> 01 W-DATE.
> 03 W-DATE-YEAR PIC 9(4).
> 03 W-DATE-MONTH PIC 9(2).
> 03 W-DATE-DAY PIC 9(2).
>
> [...]
> PROCEDURE DIVISION.
> P1.
> MOVE "USER " TO W-USER.
> MOVE SPACES TO W-DATA.
> MOVE 20050920 TO W-DATE.
> OPEN OUTPUT MYFILE.
> CLOSE MYFILE.
> OPEN I-O MYFILE.
> MOVE W-USER TO REC-USER.
> MOVE W-DATE TO REC-DATE.
> MOVE W-DATA TO REC-DATA.
> WRITE MYREC INVALID KEY DISPLAY "ERROR WHILE WRITING".
> CLOSE MYFILE.
> OPEN I-O MYFILE.
> MOVE "USER " TO REC-USER.
> MOVE 20050920 TO REC-DATE.
> READ MYFILE INVALID KEY DISPLAY "ERROR WHILE READING".
> MOVE REC-DATA TO W-DATA.
> CLOSE MYFILE.
> DISPLAY "DATE: " W-DATE.
> DISPLAY "USER: " W-USER.
> DISPLAY "DATA: " W-DATA.
> STOP RUN.
>
> Of course, the original program is somewhat larger, but the problem is
> the same: At the final statements, garbage is displayed.
>
> When I change the COMP statements in the FD, it works without a
> problem.
>
> I examined the file written by means of a hex editor, and I saw the
> REC-DATE portion look like "200509R " - and this looks very strange to
> me ;-)
>
> A.
>

SkippyPB

2005-09-20, 6:55 pm

On Tue, 20 Sep 2005 07:26:56 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> enlightened us:

>The problem appears to me to be that the MOVE in question, MOVE W-DATE TO
>REC-DATE, is a "group MOVE", which is alphanumeric with no translation.
>
>Thus, whatever format REC-DATE-YEAR and the other subfields of REC-DATE are,
>what you're moving is not the individual fields but the group as a whole as
>a group of characters. Since the elementary items are different formats
>what you end up with is garbage in the destination.
>
>Group MOVEs in COBOL are "blind".
>
>Instead of MOVE W-DATE TO REC-DATE, you need to do three individual MOVEs:
> MOVE W-DATE-YEAR TO REC-DATE-YEAR
> MOVE W-DATE-MONTH TO REC-DATE-MONTH
> MOVE W-DATE-DAY TO REC-DATE-DAY.
>
>Alternatively, you could change one of the two sets so that the names are
>the same, e.g.,
> 05 REC-DATE.
> 07 W-DATE-YEAR PIC 9(4) COMP.
> ...
>
>and then do MOVE CORRESPONDING W-DATE TO REC-DATE.
>
> -Chuck Stevens
>
>
><anguel@web.de> wrote in message
>news:1127218474.937776.115700@g44g2000cwa.googlegroups.com...
>

Or, you could change the W-DATE definition to:

01 W-DATE-AREA
02 W-DATE PIC 9(8).
02 W-DATE-RDF REDEFINES W-DATE.
03 W-DATE-YEAR PIC 9(4).
03 W-DATE-MONTH PIC 9(2).
03 W-DATE-DAY PIC 9(2).

Then when your code does a MOVE W-DATE TO REC-DATE, the data will be
translated to binary format and stored properly.

Regards,

////
(o o)
-oOO--(_)--OOo-

"Boy, they were big on crematoriums, weren't they?"
--George W. Bush, touring Auschwitz in 1987.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Chuck Stevens

2005-09-20, 6:55 pm

Bottom post. -CCS

"SkippyPB" <swiegand@neo.rr.NOSPAM.com> wrote in message
news:s8c0j1d6gom536jdg75987asio34uqlhdn@
4ax.com...
> On Tue, 20 Sep 2005 07:26:56 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> enlightened us:
>
are,[color=darkred]
as[color=darkred]
MOVEs:[color=darkred]
erroneous.[color=darkred]
the[color=darkred]
more,[color=darkred]
>
> Or, you could change the W-DATE definition to:
>
> 01 W-DATE-AREA
> 02 W-DATE PIC 9(8).
> 02 W-DATE-RDF REDEFINES W-DATE.
> 03 W-DATE-YEAR PIC 9(4).
> 03 W-DATE-MONTH PIC 9(2).
> 03 W-DATE-DAY PIC 9(2).
>
> Then when your code does a MOVE W-DATE TO REC-DATE, the data will be
> translated to binary format and stored properly.
>

< sig deleted>

Are you sure that's what you meant?

Given that the source is a numeric and the destination is a GROUP that has
COMP subfields, I'd expect the MOVE to *still* be an alphanumeric MOVE
without any sort of conversion of format, and the contents of the three
subfields of REC-DATE, interpreted as COMP, to be garbage.

Whether making a parallel redefinition for REC-DATE and doing an
*elementary* MOVE (numeric or not) would work would depend entirely on the
implementor's particular format for COMP, which implementors are free to
make whatever works for them. In our case, this would work, because for us
COMP is equivalent to PACKED-DECIMAL and neither one requires space for a
sign unless one is specified in the PICTURE, but I think we're in the
minority, and the assumption that even the elementary MOVE would work would
be decidedly implementation-specific.

-Chuck Stevens

Binyamin Dissen

2005-09-20, 6:55 pm

On Tue, 20 Sep 2005 11:59:44 -0400 SkippyPB <swiegand@neo.rr.NOSPAM.com>
wrote:

:>Or, you could change the W-DATE definition to:

:>01 W-DATE-AREA
:> 02 W-DATE PIC 9(8).
:> 02 W-DATE-RDF REDEFINES W-DATE.
:> 03 W-DATE-YEAR PIC 9(4).
:> 03 W-DATE-MONTH PIC 9(2).
:> 03 W-DATE-DAY PIC 9(2).

:>Then when your code does a MOVE W-DATE TO REC-DATE, the data will be
:>translated to binary format and stored properly.

Nope.

It is still a group move.

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

HeyBub

2005-09-20, 6:55 pm

anguel@web.de wrote:
> [...]
> FILE SECTION.
> FD MYFILE.
> 01 MYREC.
> 03 REC-KEY.
> 05 REC-USER PIC X(12).
> 05 REC-DATE.
> 07 REC-DATE-YEAR PIC 9(4) COMP.
> 07 REC-DATE-MONTH PIC 9(2) COMP.
> 07 REC-DATE-DAY PIC 9(2) COMP.
> 03 REC-DATA PIC X(40).
>
> [...]
> WORKING-STORAGE SECTION.
> 77 W-USER PIC X(12).
> 77 W-DATA PIC X(40).
> 01 W-DATE.
> 03 W-DATE-YEAR PIC 9(4).
> 03 W-DATE-MONTH PIC 9(2).
> 03 W-DATE-DAY PIC 9(2).
>
> [...]
> PROCEDURE DIVISION.
[...]
> MOVE W-DATE TO REC-DATE.
[...]

This is the culprit. Both are group items and when a group item is moved, no
conversions take place. The move occurs as if the original data items were
defined as:

07 REC-DATE PIC X([4, 6, 7])*
and
01 W-DATE PIC X(8).

*Most compilers treat both 9(2) COMP and 9(4) COMP as 2-byte binary fields.
So, your original definitions:
9(4) COMP = 2 bytes
9(2) COMP = 2 bytes
9(2) COMP = 2 bytes
-------------------------
Total: 6 bytes.

I have seen compilers treat (optionally) 9(2) COMP as a 1 byte binary. So
the total field length for your REC-DATE could be FOUR bytes.

Then there are those compilers that believe COMP = PACKED, so your REC-DATE
would look like:
9(4) COMP = 3 bytes
9(2) COMP = 2 bytes
9(2) COMP = 2 bytes
-----------------------
Total: 7 bytes.

So, then, depending on the compiler, your source group could be 4, 6, or 7
bytes. None of which is equal to your destination of 8 bytes.

It seems you're having trouble not only with the concept of group moves but
also with how data are represented.

Chuck Stevens

2005-09-20, 6:55 pm

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:11j0hndt6e28432@news.supernews.com...
> anguel@web.de wrote:
> [...]
> [...]
>
> This is the culprit. Both are group items and when a group item is moved,
no
> conversions take place. The move occurs as if the original data items were
> defined as:
>
> 07 REC-DATE PIC X([4, 6, 7])*
> and
> 01 W-DATE PIC X(8).
>
> *Most compilers treat both 9(2) COMP and 9(4) COMP as 2-byte binary
fields.
> So, your original definitions:
> 9(4) COMP = 2 bytes
> 9(2) COMP = 2 bytes
> 9(2) COMP = 2 bytes
> -------------------------
> Total: 6 bytes.
>
> I have seen compilers treat (optionally) 9(2) COMP as a 1 byte binary. So
> the total field length for your REC-DATE could be FOUR bytes.
>
> Then there are those compilers that believe COMP = PACKED, so your
REC-DATE
> would look like:
> 9(4) COMP = 3 bytes
> 9(2) COMP = 2 bytes
> 9(2) COMP = 2 bytes
> -----------------------
> Total: 7 bytes.
>
> So, then, depending on the compiler, your source group could be 4, 6, or 7
> bytes. None of which is equal to your destination of 8 bytes.
>
> It seems you're having trouble not only with the concept of group moves
but
> also with how data are represented.
>
>
>

It could also be four bytes in a packed-decimal implementation that does not
add the burden of a sign in the format unless the programmer has expressly
requested that it be present, and does not impose the onerous requirement
that four-bit-oriented elementary items must be aligned on eight-bit
addressing boundaries.

And were the three elementary items declared with signs, in combination they
could occupy five-and-a-half bytes, with a four-bit slack filler at the end
of the group.

As to "most compilers": Most compilers in what environments? Do you have
statistics on this?

-Chuck Stevens

HeyBub

2005-09-21, 3:55 am

X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-RFC2646: Format=Flowed; Original
X-Complaints-To: abuse@supernews.com
Lines: 28
Xref: newsfeed-west.nntpserver.com comp.lang.cobol:118220

Chuck Stevens wrote:
>
> It could also be four bytes in a packed-decimal implementation that
> does not add the burden of a sign in the format unless the programmer
> has expressly requested that it be present, and does not impose the
> onerous requirement that four-bit-oriented elementary items must be
> aligned on eight-bit addressing boundaries.
>
> And were the three elementary items declared with signs, in
> combination they could occupy five-and-a-half bytes, with a four-bit
> slack filler at the end of the group.
>
> As to "most compilers": Most compilers in what environments? Do you
> have statistics on this?
>
>

"Most compilers" = plurality.

Statistics:
47%
9.5%
88%
7 of 9
Bigger than a bread-box.
Purple.

SkippyPB

2005-09-21, 6:55 pm

On Tue, 20 Sep 2005 20:08:42 +0300, Binyamin Dissen
<postingid@dissensoftware.com> enlightened us:

>On Tue, 20 Sep 2005 11:59:44 -0400 SkippyPB <swiegand@neo.rr.NOSPAM.com>
>wrote:
>
>:>Or, you could change the W-DATE definition to:
>
>:>01 W-DATE-AREA
>:> 02 W-DATE PIC 9(8).
>:> 02 W-DATE-RDF REDEFINES W-DATE.
>:> 03 W-DATE-YEAR PIC 9(4).
>:> 03 W-DATE-MONTH PIC 9(2).
>:> 03 W-DATE-DAY PIC 9(2).
>
>:>Then when your code does a MOVE W-DATE TO REC-DATE, the data will be
>:>translated to binary format and stored properly.
>
>Nope.
>
>It is still a group move.

Yep, sure is. I thought that REC-DATE was an elementary PIC 9(8) COMP
field, but on further review.....

In which case, to use my suggestion, you would also need to make the
following changes to REC-DATE:

05 REC-DATE PIC 9(8) COMP.
05 REC-DATE-RDF REDEFINES REC-DATE.
07 REC-DATE-YEAR PIC 9(4) COMP.
07 REC-DATE-MONTH PIC 9(2) COMP.
07 REC-DATE-DAY PIC 9(2) COMP.

Regards,
////
(o o)
-oOO--(_)--OOo-

"Boy, they were big on crematoriums, weren't they?"
--George W. Bush, touring Auschwitz in 1987.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Chuck Stevens

2005-09-21, 6:55 pm

This only works if COMP is designed by the *particular implementation* such
that two PIC 99 COMPs take up the same space as one PIC 9999 COMP, and all
three taken together take up the same space as one PIC 99999999 COMP. Such
may, or may not, be the case. The COBOL standard requires only that COMP
be suitable for numeric items; matters like radix, format, alignment, sign
representation, and permitted range of values are left up to the
implementor. The expectation that an application that made use of such code
would produce the same results on all platforms and in all operating
environments would not be reasonable.

-Chuck Stevens

"SkippyPB" <swiegand@neo.rr.NOSPAM.com> wrote in message
news:s9v2j1do86c893qutb14hapgu7hgu9tpo0@
4ax.com...
> On Tue, 20 Sep 2005 20:08:42 +0300, Binyamin Dissen
> <postingid@dissensoftware.com> enlightened us:
>
>
> Yep, sure is. I thought that REC-DATE was an elementary PIC 9(8) COMP
> field, but on further review.....
>
> In which case, to use my suggestion, you would also need to make the
> following changes to REC-DATE:
>
> 05 REC-DATE PIC 9(8) COMP.
> 05 REC-DATE-RDF REDEFINES REC-DATE.
> 07 REC-DATE-YEAR PIC 9(4) COMP.
> 07 REC-DATE-MONTH PIC 9(2) COMP.
> 07 REC-DATE-DAY PIC 9(2) COMP.
>
> Regards,
> ////
> (o o)
> -oOO--(_)--OOo-
>
>
> "Boy, they were big on crematoriums, weren't they?"
> --George W. Bush, touring Auschwitz in 1987.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Remove nospam to email me.
>
> Steve

howard.brazee@cusys.edu

2005-09-21, 6:55 pm

On Wed, 21 Sep 2005 11:35:55 -0400, SkippyPB
<swiegand@neo.rr.NOSPAM.com> wrote:

>In which case, to use my suggestion, you would also need to make the
>following changes to REC-DATE:
>
>05 REC-DATE PIC 9(8) COMP.
>05 REC-DATE-RDF REDEFINES REC-DATE.
> 07 REC-DATE-YEAR PIC 9(4) COMP.
> 07 REC-DATE-MONTH PIC 9(2) COMP.
> 07 REC-DATE-DAY PIC 9(2) COMP.

PIC 9(8) COMP is stored as a binary field. On an IBM mainframe, this
can be:
Digits in PICTURE clause Storage occupied
1 through 4 2 bytes (halfword)
5 through 9 4 bytes (fullword)
10 through 18 8 bytes (doubleword)

Each binary number is stored separately. The number 5 is stored as
101, preceded by as many zeros as needed to fill out the storage. So
if you moved 5 to REC-DATE-YEAR, REC-DATE-MONTH, and REC-DATE-DAY, the
result might look like this: 000001010000010100000101 which would
translate as 328965. Except there's other house keeping between
each number (just because you didn't have a sign doesn't mean the
computer doesn't treat the number as signed).

Ian Dalziel

2005-09-21, 6:55 pm

On Wed, 21 Sep 2005 11:35:55 -0400, SkippyPB
<swiegand@neo.rr.NOSPAM.com> wrote:

>On Tue, 20 Sep 2005 20:08:42 +0300, Binyamin Dissen
><postingid@dissensoftware.com> enlightened us:
>
>
>Yep, sure is. I thought that REC-DATE was an elementary PIC 9(8) COMP
>field, but on further review.....
>
>In which case, to use my suggestion, you would also need to make the
>following changes to REC-DATE:
>
>05 REC-DATE PIC 9(8) COMP.
>05 REC-DATE-RDF REDEFINES REC-DATE.
> 07 REC-DATE-YEAR PIC 9(4) COMP.
> 07 REC-DATE-MONTH PIC 9(2) COMP.
> 07 REC-DATE-DAY PIC 9(2) COMP.
>

If it's binary, the sub-fields won't work - 20050921 will be held as
131F3E9, which doesn't split in the right places.
--

Ian

Sponsored Links