ACCEPT in OpenCOBOL.

[BobP]

We have this program running for OpenCOBOL:

Code: Select all

IDENTIFICATION DIVISION.
PROGRAM-ID. SOMEPGM.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-INPUT1 PIC Z(8).
01 WS-INPUT2 PIC 9(9).
PROCEDURE DIVISION.
PARA.

ACCEPT WS-INPUT1.
DISPLAY WS-INPUT1.
ACCEPT WS-INPUT2.
DISPLAY WS-INPUT2.
INITIALIZE WS-INPUT1.
INITIALIZE WS-INPUT2.
STOP RUN.

When we provide the following input:
5
2
9

It shows the 5 and 000000002 which is correct but there is no error showed up for 9. Why does this happnen? And how would it behave in the Enterprise COBOL?

[Robert Sample]

Since you only accept two values of input, the third and any subsequent values will be lost. INITIALIZE and ACCEPT have totally different uses and are NOT interchangeable. Enterprise COBOL will behave the exact same way.

[William Collins]

OpenCOBOL is now called GnuCOBOL and it would be best to get the equivalent release of GnuCOBOL (it is more up-to-date).

Bear in mind that the way ACCEPT behaves in GnuCOBOL is not the way it behaves in Enterprise COBOL, even when using a relevant-to-mainframe configuration file.

[Anuj Dhawan]

OpenCOBOL is now called GnuCOBOL and it would be best to get the equivalent release of GnuCOBOL (it is more up-to-date).

Bear in mind that the way ACCEPT behaves in GnuCOBOL is not the way it behaves in Enterprise COBOL, even when using a relevant-to-mainframe configuration file.

I have not tested it but it's only Monday so can brave to be a rookie - I think, for the given example and question it should behave the way it did and the GnuCOBOL will be in line with Enterprise COBOL, no?

[William Collins]

No, Enterprise COBOL just ACCEPTS by byte, left-to-right, up to the length of the field. So it will not perform "editing" of a number. The only leading-zeros that you'll see is if they are entered.

An interesting thing is:

Code: Select all

01  some-data PIC X(320).

ACCEPT some-data

That will read up to four lines of SYSIN data in one shot :-)

[Anuj Dhawan]

That will read up to four lines of SYSIN data in one shot :-)

That's a differnt behavior. I was thinking that to run the above program on maifnrames one would need a JCL. 5, 2 and 9 as inputs from SYSIN, which will be treated as FB/80 dataset so an input like
5
2
9

are three seperate inputs of type FB/80. And as WS-INPUT2 is defined as PIC 9(9)- having leading zeros is just fine!

Looks like I need to really simulate the environment now. My wife was correct - I'm getting old, memory does not seem to serve well.

[William Collins]

Taking the original definitions by BobP, the result would be two nine-byte fields containing a single digit in the left-most byte and space in all the remaining bytes.

[Anuj Dhawan]

William,

Please try this:

https : / / codepair dot hackerrank dot com / paper/ qdl2CLqZ

In above please remove the spaces and the word "dot" with "." to reach to the URL.

It runs a GnuCOBOL to see the code. Key in any dummy name and e-mail.

[William Collins]

Well, all I get to is a 404, so I've pickled something :-)

What is it supposed to show me?

[enrico-sorichetti]

it works for me
it just shows the behaviour of ACCEPT when using open cobol

and the url lets You write and test Your programs
( quite a few languages available )

[Anuj Dhawan]

Hi William,

Please check your PM.

[BobP]

That will read up to four lines of SYSIN data in one shot :-)

That's a differnt behavior. I was thinking that to run the above program on maifnrames one would need a JCL. 5, 2 and 9 as inputs from SYSIN, which will be treated as FB/80 dataset so an input like
5
2
9

are three seperate inputs of type FB/80. And as WS-INPUT2 is defined as PIC 9(9)- having leading zeros is just fine!

Looks like I need to really simulate the environment now. My wife was correct - I'm getting old, memory does not seem to serve well.

This is my understanding also.

Taking the original definitions by BobP, the result would be two nine-byte fields containing a single digit in the left-most byte and space in all the remaining bytes.

But with PIC 9(9), we'll get leading zeros or it it with PIC X(9)?

[William Collins]

In (OpenCOBOL)/GnuCOBOL the ACCEPT takes account of the field definition, so acts appropriately, even for "edited" PICtures.

In Enterprise COBOL, the field on ACCEPT is treated as alpha-numeric, no matter how it is defined. There isn't even really space-padding, because the spaces come from the SYSIN data, I think, though I've never tried to demonstrate it. There will be nor right-justify-left-zero-fill for numbers, which is what GnuCOBOL will do for a PIC 9(9). In Enterprise COBOL, the content of a PIC 9(9) and PIC X(9) would be identical, given the ACCEPT of a value of "1".

[BobP]

I am still getting the same results. As this is for learning only... I shall do some more experiments.

[William Collins]

I'm using GnuCOBOL 2.0. You should use at least GnuCOBOL 1.1 (current release). OpenCOBOL is no longer supported as that.

When I run your program I get the expected (for GnuCOBOL) results, which is if I enter a single digit, I get seven blanks followed by the digit for the numeric-edited field and eight zeros followed by the digit for the 9(9) field.

ACCEPT in Enterprise COBOL is treated as a PIC X(n) field in these cases.