Mainframe, MVS and zOS Discussion

We have this program running for OpenCOBOL: 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?

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.

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.

William Collins wrote: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?

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:
That will read up to four lines of SYSIN data in one shot :-)

William Collins wrote: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.

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.

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.

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

What is it supposed to show me?

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 )

Hi William,

Please check your PM.

Anuj Dhawan wrote:

William Collins wrote: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.

William Collins wrote: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)?

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

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

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.