f



anomalous COMMAND-LINE behaviour in GnuCOBOL

I have reported this in the SourceForge forum. Forgot to log in, 
unfortunately, so it's sitting in a bucket awaiting moderation.

The version of cobc I'm using is
~~~
cobc (GNU Cobol) 2.0.20140821
Copyright (C) 2001,2002,2003,2004,2005,2006,2007 Keisuke Nishida
Copyright (C) 2006-2012 Roger While
Copyright (C) 2009,2010,2012,2014 Simon Sobisch
This is free software; see the source for copying conditions.  There is 
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.
Built     Aug 27 2014 21:51:20
Packaged  Aug 21 2014 18:37:07 UTC
C version (Microsoft) 1700
~~~

Given the following code
~~~
        IDENTIFICATION DIVISION.
        PROGRAM-ID. BINATANG.
        DATA DIVISION.
        WORKING-STORAGE SECTION.
        01  CHAR_ARG     USAGE BINARY-CHAR.
        01  SHORT_ARG    USAGE BINARY-SHORT.
        01  LONG_ARG     USAGE BINARY-LONG.
        PROCEDURE DIVISION.
        MAIN-PROCEDURE.
            ACCEPT CHAR_ARG FROM COMMAND-LINE.
            ACCEPT SHORT_ARG FROM COMMAND-LINE.
            ACCEPT LONG_ARG FROM COMMAND-LINE.
            DISPLAY CHAR_ARG.
            DISPLAY SHORT_ARG.
            DISPLAY LONG_ARG.
            STOP RUN.
        END PROGRAM BINATANG.
~~~
when I execute that from the Windows command line with a space between 
numeric arguments, I get a variety of different behaviours, viz
~~~
 >binatang.exe 1 2345
+001
+12345
+0000012345

 >binatang.exe 12 345
+012
+00012
+0000012345

 >binatang.exe 123 45
+123
+00123
+0000012345

 >binatang.exe 1234 5
-046
+01234
+0000001234

 >binatang.exe 12345
+057
+12345
+0000012345
~~~
I don't know how many people use GnuCOBOL for command line tools, but 
that behaviour is going to make things tricky.

P.S. Binatang as a word occurs in a large number of South East Asian 
(human) languages. I'm using it here with its Tok Pisin (from Papua New 
Guinea) meaning: insect, pest, bug.
0
Bruce
9/12/2016 12:35:58 AM
comp.lang.cobol 4278 articles. 1 followers. Post Follow

8 Replies
420 Views

Similar Articles

[PageSpeed] 38

On Monday, September 12, 2016 at 12:36:06 PM UTC+12, Bruce Axtens wrote:

> Given the following code
> ~~~
>         IDENTIFICATION DIVISION.
>         PROGRAM-ID. BINATANG.
>         DATA DIVISION.
>         WORKING-STORAGE SECTION.
>         01  CHAR_ARG     USAGE BINARY-CHAR.
>         01  SHORT_ARG    USAGE BINARY-SHORT.
>         01  LONG_ARG     USAGE BINARY-LONG.
>         PROCEDURE DIVISION.
>         MAIN-PROCEDURE.
>             ACCEPT CHAR_ARG FROM COMMAND-LINE.
>             ACCEPT SHORT_ARG FROM COMMAND-LINE.
>             ACCEPT LONG_ARG FROM COMMAND-LINE.
>             DISPLAY CHAR_ARG.
>             DISPLAY SHORT_ARG.
>             DISPLAY LONG_ARG.
>             STOP RUN.
>         END PROGRAM BINATANG.
> ~~~
> when I execute that from the Windows command line with a space between 
> numeric arguments, I get a variety of different behaviours, viz

COMMAND-LINE is one thing, not a series of 'arguments'. Each ACCEPT is equivalent of a MOVE of the complete line following the program to the fields. 

Values in BINARY-CHAR may be -128 to 127. Any value > 127 may be reported as negative or as mod(256).

1) If you want separate arguments then break up the command-line into those parts and MOVE them separately, preferably from edited numeric.

2) Do not use BINARY, use DISPLAY COMP.

0
Richard
9/12/2016 5:06:47 AM
On 12/09/2016 1:06 PM, Richard wrote:
> COMMAND-LINE is one thing, not a series of 'arguments'. Each ACCEPT is equivalent of a MOVE of the complete line following the program to the fields.
Yes, I understand that.

> Values in BINARY-CHAR may be -128 to 127. Any value > 127 may be reported as negative or as mod(256).
Yes, I get that also.

> 1) If you want separate arguments then break up the command-line into those parts and MOVE them separately, preferably from edited numeric.
Yes, I was heading that way. It's more that the response of BINARY-SHORT 
and BINARY-LONG to the incoming data from the COMMAND-LINE was ... well 
.... a bit odd.

> 2) Do not use BINARY, use DISPLAY COMP.
Shall look into that.

Thank you.


0
Bruce
9/12/2016 7:20:52 AM
On Monday, September 12, 2016 at 7:20:58 PM UTC+12, Bruce Axtens wrote:

> Yes, I was heading that way. It's more that the response of BINARY-SHORT=
=20
> and BINARY-LONG to the incoming data from the COMMAND-LINE was ... well=
=20

Many of your samples included a space character, this makes the data an inv=
alid numeric (it does _not_ make it two numeric values). The ACCEPT was att=
empting to process invalid numeric input, the results are undefined. Once y=
ou have undefined result it can be 'anything'.

GIGO
0
Richard
9/12/2016 7:30:28 AM
On Monday, 12 September 2016 15:30:29 UTC+8, Richard  wrote:
> Many of your samples included a space character, this makes the data an i=
nvalid numeric (it does _not_ make it two numeric values). The ACCEPT was a=
ttempting to process invalid numeric input, the results are undefined. Once=
 you have undefined result it can be 'anything'.
>=20
> GIGO
I'm not disputing GIGO (something I am exceptionally good at).=20

In my original posting I said, "I don't know how many people use GnuCOBOL f=
or command line tools, but that behaviour is going to make things tricky". =
I was actually trying to write a command-tool and now I realise that I'm go=
ing to have to be more careful with numeric values in the command-line. In =
fact it's obvious to me now that I need to keep the command-line to PIC X(1=
28) or similar rather than expect GnuCOBOL to pick up the pieces.=20
0
Bruce
9/12/2016 7:43:30 AM
Is is nice, though I can't think of an immediate use, that ACCEPT FROM 
COMMAND-LINE does make the following possible

        IDENTIFICATION DIVISION.
        PROGRAM-ID. GUTPELA.
        DATA DIVISION.
        WORKING-STORAGE SECTION.
        01  CMD-ARG2.
            03  p1  pic 9.
            03  filler pic x.
            03  p2 pic 9.
            03  filler pic x.
            03  p3 pic 9.
        PROCEDURE DIVISION.
        MAIN-PROCEDURE.
            ACCEPT CMD-ARG2 FROM COMMAND-LINE.
            DISPLAY P1 SPACE P2 SPACE P3.
            STOP RUN.
        END PROGRAM GUTPELA.

 >gutpela 12345
1 3 5
0
Bruce
9/12/2016 8:49:54 AM
In article <626e3015-947f-4499-8bda-4444931ad9f9@googlegroups.com>,
Bruce Axtens  <bruce.axtens@gmail.com> wrote:
>On Monday, 12 September 2016 15:30:29 UTC+8, Richard  wrote:
>> Many of your samples included a space character, this makes the data
>an invalid numeric (it does _not_ make it two numeric values). The
>ACCEPT was attempting to process invalid numeric input, the results are
>undefined. Once you have undefined result it can be 'anything'.
>> 
>> GIGO
>I'm not disputing GIGO (something I am exceptionally good at). 

This grammar is uncertain... disputing GIGO is something you are 
exceptionally good at?

(parenthetic question: is your Native Programming Language a vriant of C?)

>
>In my original posting I said, "I don't know how many people use
>GnuCOBOL for command line tools, but that behaviour is going to make
>things tricky". I was actually trying to write a command-tool and now I
>realise that I'm going to have to be more careful with numeric values in
>the command-line. In fact it's obvious to me now that I need to keep the
>command-line to PIC X(128) or similar rather than expect GnuCOBOL to
>pick up the pieces. 

Languages do not pick up pieces; it is part of the programmer's job is to 
design the box into which the pieces will fit.  An ACCEPT provides an 
input of uncertain provenance; next step is to edit.

DD

0
docdwarf
9/12/2016 10:13:14 AM
On 12/09/2016 6:13 PM, docdwarf@panix.com wrote:
>>> GIGO
>> I'm not disputing GIGO (something I am exceptionally good at).
>
> This grammar is uncertain... disputing GIGO is something you are
> exceptionally good at?
It was attempting to be self-deprecating. Australians are supposed to be 
good at that.

> (parenthetic question: is your Native Programming Language a vriant of C?)
I wonder sometimes if I have a native programming language. When I 
started studying programming full-time in 1983, the languages were 
MSBASIC, COBOL (on a DEC Vax 11/750), dBaseII and 8080 assembler.

These days it's C#, JavaScript and PHP. There have been a pile of others 
in between, including Ada, Fortran and Perl.

> An ACCEPT provides an
> input of uncertain provenance; next step is to edit.
Good point.

Thanks for your patience.

Bruce/bugmagnet.

0
Bruce
9/12/2016 11:12:08 AM
In article <nr62i8$hdu$1@dont-email.me>,
Bruce Axtens  <bruce.axtens@gmail.com> wrote:
>On 12/09/2016 6:13 PM, docdwarf@panix.com wrote:
>>>> GIGO
>>> I'm not disputing GIGO (something I am exceptionally good at).
>>
>> This grammar is uncertain... disputing GIGO is something you are
>> exceptionally good at?
>It was attempting to be self-deprecating. Australians are supposed to be 
>good at that.

I am attempting to have sufficient humility to be a source of pride. 
Sometimes there is success at something.

>
> > (parenthetic question: is your Native Programming Language a vriant of
> > C?)
> Hmm... my first programming languages (back in 1983) were MSBASIC, COBOL
> (on a DEC Vax 11/750), dBaseII and 8080 assembler. Most recently I've been
> working with JavaScript, C# and PHP. Is the question asking me where my
> head is at? It's probably (sadly) more in curly-brace land than anywhere
> else.

What one has learned to speak might give insight into what one expects a
language to do... some languages have specific formal and informal forms,
some languages have cases used only when two people are involved (dual).
Your use of underscores indicates that OldBOL is not to be assumed.

>
> > An ACCEPT provides an
> > input of uncertain provenance; next step is to edit.
> Good point.
>
> Thanks for your patience.

It's free advice so it's worth at least double what you've paid. 
Command-line utilities are, in most cases, not designed for 
unsophisticated users but certain basics - eg, 'Any Time Data Can Be 
Entered Data Can Be Entered Erroneously' - remain.

DD

0
docdwarf
9/12/2016 11:39:44 AM
Reply: