From Newsgroup: comp.lang.cobol

Hi Folks. It's me again.

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.




COBOL - the elephant that can stand on its trunk...

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Mon, 14 May 2018 08:09:35 -0700 (PDT), Kellie Fitton <KELLIEFITTON@yahoo.com> wrote:

Hi Folks. It's me again.

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

Which compiler? I am fairly certain that the IBM compilers would flag
a PIC X to PIC 9 MOVE and probably fail the compilation. I don't have
a system available to me to verify this.

Clark Morris

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.

COBOL - the elephant that can stand on its trunk...

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 5/14/2018 11:42 AM, Clark F Morris wrote:

On Mon, 14 May 2018 08:09:35 -0700 (PDT), Kellie Fitton <KELLIEFITTON@yahoo.com> wrote:

Hi Folks. It's me again.

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

Which compiler? I am fairly certain that the IBM compilers would flag
a PIC X to PIC 9 MOVE and probably fail the compilation. I don't have
a system available to me to verify this.

Clark Morris

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.




COBOL - the elephant that can stand on its trunk...

I just tested this on IBM COBOL FOR VSE/ESA 1.1.1

The compiler does not flag the move of PIC X to PIC 9. Here is a sample
output I cobbled together to summarize what happens in a couple of cases:

SOURCE-FIELD 12345
DEST-FIELD 12345
SOURCE-FIELD ABCDE
DEST-FIELD ABCD5

Here is the code (at least relevant bits):

WORKING-STORAGE SECTION.

01 FILLER.
05 SOURCE-FIELD PIC X(5).
05 DEST-FIELD PIC 9(5).

PROCEDURE DIVISION.

0000-MAINLINE.
MOVE '12345' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
MOVE 'ABCDE' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
.

9000-END.
STOP RUN
.

I think the COBOL manuals explicitly state what happens in these mixed situations and indeed a LOT of old code is written to depend on that
specific sort of behaviour...


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Monday, May 14, 2018 at 11:09:36 AM UTC-4, Kellie Fitton wrote:

Hi Folks. It's me again.

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

Well, it's not a 'red' flag, but the compiler can check for an invalid
'move' -- if it can do so during compilation. (See 'alpha1', below.)

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

I am sure some do and others don't. I don't have a list.

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

With COBOL, it is the programmers responsibility.
(See 'alpha2' and 'alpha3', below.)

Your feedback is very much appreciated.

Using Micro Focus COBOL 3.2.50 with ANS85 flagging in effect.
-----
1$set ans85 flag"ans85" flagas"s"
2 identification division.
3 program-id. alpha1.
4 data division.
5 working-storage section.
6 1 a pic x(4).
7 1 n pic 9(4).
8 procedure division.
9 begin.
10 move "1234" to a
11 move "1234" to n
12 display a space n
13 move "abcd" to a
14 move "abcd" to n
*1026-E********************* ( 0)**
** Source literal is non-numeric - substituting zero
15 display a space n
16 stop run
17 .
18 end program alpha1.
-----
'alpha1' does not compile because the compiler caught the error.
-----
19
20 identification division.
21 program-id. alpha2.
22 data division.
23 working-storage section.
24 1 a pic x(4).
25 1 n pic 9(4).
26 procedure division.
27 begin.
28 move "1234" to a
29 move a to n
30 display a space n
31 move "abcd" to a
32 move a to n
33 display a space n
34 stop run
35 .
36 end program alpha2.
-----
1234 1234
ALPHA2 Segment RT : Error 163 at COBOL PC 0054
Description : Illegal character in numeric field (Error 163)

'alpha 2' failed because the programmer did not catch the error!
-----
37
38 identification division.
39 program-id. alpha3.
40 data division.
41 working-storage section.
42 1 a pic x(4).
43 1 n pic 9(4).
44 procedure division.
45 begin.
46 move "1234" to a
47 move a to n
48 display a space n
49 move "abcd" to a
50 if a is numeric
51 move a to n
52 else
53 display "a is not numeric: " a
54 end-if
55 display a space n
56 stop run
57 .
58 end program alpha3.
-----
1234 1234
a is not numeric: abcd
abcd 1234

'alpha3' ran because the programmer caught the error and did not
try to store the illegal characters in 'n'!
-----
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

Using Micro Focus COBOL 3.2.50 with ANS85 flagging in effect.
-----
1$set ans85 flag"ans85" flagas"s"
2 identification division.
3 program-id. alpha1.
4 data division.
5 working-storage section.
6 1 a pic x(4).
7 1 n pic 9(4).
8 procedure division.
9 begin.
10 move "1234" to a
11 move "1234" to n
12 display a space n
13 move "abcd" to a
14 move "abcd" to n
*1026-E********************* ( 0)** ** Source literal is non-numeric - substituting zero
15 display a space n
16 stop run
17 .
18 end program alpha1.
-----
'alpha1' does not compile because the compiler caught the error.
-----
19
20 identification division.
21 program-id. alpha2.
22 data division.
23 working-storage section.
24 1 a pic x(4).
25 1 n pic 9(4).
26 procedure division.
27 begin.
28 move "1234" to a
29 move a to n
30 display a space n
31 move "abcd" to a
32 move a to n
33 display a space n
34 stop run
35 .
36 end program alpha2.
-----
1234 1234
ALPHA2 Segment RT : Error 163 at COBOL PC 0054
Description : Illegal character in numeric field (Error 163)

'alpha 2' failed because the programmer did not catch the error!
-----
37
38 identification division.
39 program-id. alpha3.
40 data division.
41 working-storage section.
42 1 a pic x(4).
43 1 n pic 9(4).
44 procedure division.
45 begin.
46 move "1234" to a
47 move a to n
48 display a space n
49 move "abcd" to a
50 if a is numeric
51 move a to n
52 else
53 display "a is not numeric: " a
54 end-if
55 display a space n
56 stop run
57 .
58 end program alpha3.
-----
1234 1234
a is not numeric: abcd
abcd 1234

'alpha3' ran because the programmer caught the error and did not
try to store the illegal characters in 'n'!
-----

Rick,

Thanks for your feedback.

My code is using the compiler directives $set ans85 flagas"s" but the
compiler is not flagging the invalid mismatch move. When I add the
directive flag"ans85" to match your code, the compiler gives me tons
of errors and red XXX flags. My NetExpress does not like flag"ans85".

The COBOL compiler should flag this error by default in case the
programmer mistakenly references the wrong variable, this is just
a simple safety net to guard against unintentional oversight.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Monday, May 14, 2018 at 9:43:05 PM UTC-4, Kellie Fitton wrote:

Using Micro Focus COBOL 3.2.50 with ANS85 flagging in effect.
-----
1$set ans85 flag"ans85" flagas"s"

[snip]

20 identification division.
21 program-id. alpha2.
22 data division.
23 working-storage section.
24 1 a pic x(4).
25 1 n pic 9(4).
26 procedure division.
27 begin.
28 move "1234" to a
29 move a to n
30 display a space n
31 move "abcd" to a
32 move a to n
33 display a space n
34 stop run
35 .
36 end program alpha2.
-----
1234 1234
ALPHA2 Segment RT : Error 163 at COBOL PC 0054
Description : Illegal character in numeric field (Error 163)

'alpha 2' failed because the programmer did not catch the error!
-----

[snip]

Rick,

Thanks for your feedback.

My code is using the compiler directives $set ans85 flagas"s" but the compiler is not flagging the invalid mismatch move. When I add the
directive flag"ans85" to match your code, the compiler gives me tons
of errors and red XXX flags. My NetExpress does not like flag"ans85".

It 'likes' it just fine. The flag is used for strict ans85 conformance.
That means that all Micro Focus extensions will be flagged as errors.

The COBOL compiler should flag this error by default in case the
programmer mistakenly references the wrong variable, this is just
a simple safety net to guard against unintentional oversight.

Moving an alphanumeric field to a numeric field has been part of
standard COBOL for 50 years. It works fine as long as the
alphanumeric field contains only numbers.

If you are not getting an 'error 163' when testing a program,
there is likely a directive forcing the runtime from recognizing
the error. It is likely that directive is HOST-NUMMOVE.

'alpha4' is the same as the previous 'alpha2', but I changed the directives. -----
1$set ans85 flagas"s" host-nummove
2 identification division.
3 program-id. alpha4.
4 data division.
5 working-storage section.
6 1 a pic x(4).
7 1 n pic 9(4).
8 procedure division.
9 begin.
10 move "1234" to a
11 move a to n
12 display a space n
13 move "abcd" to a
14 move a to n
15 display a space n
16 stop run
17 .
18 end program alpha4.
-----
1234 1234
abcd abcd
-----

The HOST-NUMMOVE directive emulates behavior of the MOVE statement in
IBM mainframe COBOL. Though 'alpha2' and 'alpha4' have the same
COBOL statements, only 'alpha2' will report the error during testing.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

Kellie Fitton wrote:

Hi Folks. It's me again.

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.

COBOL - the elephant that can stand on its trunk...

COBOL is a dinosaur. It was one of the first computer languages, and
back when it was developed nobody thought about such things. Its
structure is such that compile time checking would be quite difficult
without disturbing some desirable qualities. But some limited checking
may be possible where specifically numeric types are involved. First
note that all the data used in the examples is USAGE DISPLAY. That, by definition, is just printable characters. Moving a string to a BINARY
COMP variable may produce a different result. You are supposed to be
able to move any numeric value to an alphanumeric (PIC X) field. That
is how you format things. Moves of alphabetic (PIC A, who remembers
that?) or alphabetic edited field to a numeric or numeric edited field
is illegal and should be caught by the compiler, as is moving a numeric
(PIC 9) or numeric edited field to an alphabetic field. Others are
pretty much up for grabs.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

Hello Kellie!

Monday May 14 2018 16:09, Kellie Fitton wrote to All:

Hi Folks. It's me again.

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.

Using GnuCOBOL compiler v3.0 (rc-1) it produces :
--
GnuCOBOL 3.0-dev.0 test1.cbl Tue May 15 14:14:28 2018 Page 0001

LINE PG/LN
A...B............................................................

000001 $set ans85 flag"ans85" flagas"s"
000002 identification division.
000003 program-id. alpha1.
000004 data division.
000005 working-storage section.
000006 01 a pic x(4).
000007 01 n pic 9(4).
000008 procedure division.
000009 begin.
000010 move "1234" to a
000011 move "1234" to n
000012 display a space n
000013 move "abcd" to a
000014 move "abcd" to n
000015 display a space n
000016 stop run.
000017 end program alpha1.
warning: numeric value is expected


_GnuCOBOL 3.0-dev.0 test1.cbl Tue May 15 14:14:28 2018
Page 0002

Error/Warning summary:

test1.cbl:17: warning: numeric value is expected

1 warning in compilation group
0 errors in compilation group
--

This was run with : cobc -x -Wall test1.cbl -t test1.lst

How ever when run without '-Wall' it will compile without comments.

Programmer if in doubt should add the extra commands to validate their
code.

There are also additional commands (flags) that can be supplied to verify during execution that there is no equivilent OC7 error will get produced
and no on a PC under Linux or Windows it will not happen without such.

Bye the bye on the above code the $set is prob. ignored -- hmm test this... Yep, it is ignored as remarking it out there is no change to the warning message/s.


Vince


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

In article <9de1242e-0d3d-4de2-b0cd-e5f5cf7b6c1c@googlegroups.com>,
Kellie Fitton <KELLIEFITTON@yahoo.com> wrote:

[snip]

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

This is because there is no 'the COBOL compiler'. There are different compilers for different environments written by a variety of teams over a half-century-and-change's worth of time.

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

Maybe.

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

This has been discussed since CODASYL days and earlier; the concept is one
of 'manual over-ride'.

DD
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Tuesday, May 15, 2018 at 3:09:36 AM UTC+12, Kellie Fitton wrote:

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

Alphabetic is 'PIC A' and only allows the alphabet. Alphanumeric is 'PIC X' and allows the full character set including numeric.

Which were you actually testing ?

In fact it can be quite useful to 'de-edit' an alphanumeric that only contains numeric characters, spaces, and full stops into a numeric field. Various compilers have allowed this, usually depending on compiler options.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Tuesday, May 15, 2018 at 1:53:41 PM UTC-7, Richard wrote:

On Tuesday, May 15, 2018 at 3:09:36 AM UTC+12, Kellie Fitton wrote:

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

Alphabetic is 'PIC A' and only allows the alphabet. Alphanumeric is 'PIC X' and allows the full character set including numeric.

Which were you actually testing ?

In fact it can be quite useful to 'de-edit' an alphanumeric that only contains numeric characters, spaces, and full stops into a numeric field. Various compilers have allowed this, usually depending on compiler options.

I moved the string "x64 INTEL PROCESSOR ARCHITECTURE" to PIC A variable,
then I moved it to a numeric variable PIC 9(9) COMP-5 VALUE 0 TYPEDEF.
the compiler directive flag"ans85" would have issued a warning, but it does
not like the other directives that are included in the file:
$set filetype"4" idxformat"4" and it does not like the level-78 variables
and level-01 numeric variables typedef...

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On OpenVMS the move is tolerated in HP COBOL. However, when the target field is referenced in some instances it can cause a "decimal digit error" at run time.

By the way, C came into existence in 1972. If it isn't a dinosaur now, I do not know why. It certainly has adversely impacted language design ever since.

Like my grandfather used to say, "The fish is always last to see the water." --- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

In article <87476ae2-0660-4af7-b8a0-1e58c9199a0d@googlegroups.com>,
Kellie Fitton <KELLIEFITTON@yahoo.com> wrote:

[snip]

When I add the
directive flag"ans85" to match your code, the compiler gives me tons
of errors and red XXX flags. My NetExpress does not like flag"ans85".

The COBOL compiler should flag this error by default in case the
programmer mistakenly references the wrong variable, this is just
a simple safety net to guard against unintentional oversight.

So 'the COBOL compiler' should, by default, do things that your NetExpress does not like?

DD
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

When I add the
directive flag"ans85" to match your code, the compiler gives me tons
of errors and red XXX flags. My NetExpress does not like flag"ans85".

The COBOL compiler should flag this error by default in case the
programmer mistakenly references the wrong variable, this is just
a simple safety net to guard against unintentional oversight.

So 'the COBOL compiler' should, by default, do things that your NetExpress does not like?

DD

Moving an alphabetic variable to a numeric binary variable is an illegal
move in COBOL and should be flagged by the compiler. This is unsafe code
that will cause errors during run-time and will have unpredictable
behavior. This is like saying compute (1000 + ABC), where ABC is not
a numeric variable in the working storage area, ABC is just a string.
Mighty COBOL is not C language or C++. :-)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

In article <cde27dbd-b1dc-49bb-8923-91d4b9bc7e0e@googlegroups.com>,
Kellie Fitton <KELLIEFITTON@yahoo.com> wrote:

When I add the
directive flag"ans85" to match your code, the compiler gives me tons
of errors and red XXX flags. My NetExpress does not like flag"ans85".

The COBOL compiler should flag this error by default in case the
programmer mistakenly references the wrong variable, this is just
a simple safety net to guard against unintentional oversight.

So 'the COBOL compiler' should, by default, do things that your NetExpress >> does not like?

DD

Moving an alphabetic variable to a numeric binary variable is an illegal
move in COBOL and should be flagged by the compiler.

As demonstrated, it will be flagged as such when the compiler defaults are
set as such.

This is unsafe code
that will cause errors during run-time and will have unpredictable
behavior. This is like saying compute (1000 + ABC), where ABC is not
a numeric variable in the working storage area, ABC is just a string.

Anyone who codes an arithmetic operation that is not predicated on fields passing an IF NUMERIC test deserves to be on the weekend third-shift call roster permanently.

It used to be taught 'most of your code should consist of edits to make
sure your data are clean'. Has the assumption that 'all data are filthy' changed?

Mighty COBOL is not C language or C++. :-)

Mighty hammer is not tall-standing screwdriver or lively torque-wrench; different tools are used for different tasks.

DD
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 17/05/2018 11:11 AM, Kellie Fitton wrote:

When I add the
directive flag"ans85" to match your code, the compiler gives me tons
of errors and red XXX flags. My NetExpress does not like flag"ans85".

The COBOL compiler should flag this error by default in case the
programmer mistakenly references the wrong variable, this is just
a simple safety net to guard against unintentional oversight.

So 'the COBOL compiler' should, by default, do things that your NetExpress >> does not like?

DD

Moving an alphabetic variable to a numeric binary variable is an illegal
move in COBOL and should be flagged by the compiler.

I believe it IS "flagged by the compiler".
Did you check what level the target field is? (see below...)

This is unsafe code
that will cause errors during run-time and will have unpredictable
behavior.

No, it MAY do that. It is this "sometimes" effect that leads compiler
writers to flag it.

This is like saying compute (1000 + ABC), where ABC is not
a numeric variable in the working storage area, ABC is just a string.
Mighty COBOL is not C language or C++. :-)

I watched this thread with interest but refrained from comment until now.

1. I have never used a COBOL compiler (and I have used them for IBM, Burroughs, NCR, Honeywell, ICL, CDC, and PCs (both Micro Focus and
Fujitsu), which did NOT flag a move from alphabetic to numeric as
illegal. (Maybe I was lucky and every place I worked had the right
compiler options in place, but I don't think so...)

2. You may have missed the point that if your target field is an 01
level, it is implicitly a group and, as such, it MAY be treated as PIC
X. This will vary with different compilers and options.

3. I was amazed that people expected a PIC X source field moving to a
numeric target to be flagged as illegal. Why would it be? The source is expected to be alphaNUMERIC. Some platforms will crash with a data
exception at runtime (the famous S0c7 on IBM mainframes) if you do this
move and the contents of the source are NOT acceptably numeric, but it
should not be flagged as an error at compile time. (Nevertheless, I
wouldn't do this move myself...) Neither would I ever attempt to
"de-edit" an edited field...just because you CAN do something, doesn't
mean it is always wise to do so...

4. COBOL is neither "mighty" nor "puny". Only programmers make it appear so.

Pete.
--
I used to write COBOL; now I can do anything...
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 5/16/2018 9:08 PM, docdwarf@panix.com wrote:

In article <cde27dbd-b1dc-49bb-8923-91d4b9bc7e0e@googlegroups.com>,
Kellie Fitton <KELLIEFITTON@yahoo.com> wrote:

(snip)
Moving an alphabetic variable to a numeric binary variable is an illegal
move in COBOL and should be flagged by the compiler.

As demonstrated, it will be flagged as such when the compiler defaults are set as such.

This is unsafe code
that will cause errors during run-time and will have unpredictable
behavior. This is like saying compute (1000 + ABC), where ABC is not
a numeric variable in the working storage area, ABC is just a string.

Anyone who codes an arithmetic operation that is not predicated on fields passing an IF NUMERIC test deserves to be on the weekend third-shift call roster permanently.

Been there, done that, got the T-Shirt.

It used to be taught 'most of your code should consist of edits to make
sure your data are clean'. Has the assumption that 'all data are filthy' changed?

Input data must always be validated before it is accepted into the
system. The compiler cannot do that as well as a good programmer can.

Mighty COBOL is not C language or C++. :-)

I would certainly prefer COBOL to C/C++ for any application that deals
with business financial accounting. But I also wouldn't want to use
COBOL to write system utilities, device drivers, or low-level
communications code.

Mighty hammer is not tall-standing screwdriver or lively torque-wrench; different tools are used for different tasks.

DD

--
http://www.arnoldtrembley.com/

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

Which compiler? I am fairly certain that the IBM compilers would flag
a PIC X to PIC 9 MOVE and probably fail the compilation. I don't have
a system available to me to verify this.

Clark Morris

Hi Clark,

You are correct. The IBM compiler will flag the move as you said. Please
see table # 44 below.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/Connected/BOOKS/IGY3LR10/6.2.24.1?SHELF=&DT=20020920180651

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

I just tested this on IBM COBOL FOR VSE/ESA 1.1.1

The compiler does not flag the move of PIC X to PIC 9. Here is a sample output I cobbled together to summarize what happens in a couple of cases:

SOURCE-FIELD 12345
DEST-FIELD 12345
SOURCE-FIELD ABCDE
DEST-FIELD ABCD5

Here is the code (at least relevant bits):

WORKING-STORAGE SECTION.

01 FILLER.
05 SOURCE-FIELD PIC X(5).
05 DEST-FIELD PIC 9(5).

PROCEDURE DIVISION.

0000-MAINLINE.
MOVE '12345' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
MOVE 'ABCDE' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
.

9000-END.
STOP RUN
.

I think the COBOL manuals explicitly state what happens in these mixed situations and indeed a LOT of old code is written to depend on that specific sort of behaviour...

Hi Kerry,

Please see table # 44 below. I wonder if the IBM compiler will flag
the move if you define the variable as PIC A ?

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/Connected/BOOKS/IGY3LR10/6.2.24.1?SHELF=&DT=20020920180651

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

Moving an alphabetic variable to a numeric binary variable is an illegal move in COBOL and should be flagged by the compiler.

I believe it IS "flagged by the compiler".
Did you check what level the target field is? (see below...)

Hi Pete,

I am just conducting a simple test. Moving a 01-level alphabetic variable
to a 01-level binary numeric variable.

1. I have never used a COBOL compiler (and I have used them for IBM, Burroughs, NCR, Honeywell, ICL, CDC, and PCs (both Micro Focus and
Fujitsu), which did NOT flag a move from alphabetic to numeric as
illegal. (Maybe I was lucky and every place I worked had the right
compiler options in place, but I don't think so...)

Please see the link below from Microfocus:

https://supportline.microfocus.com/documentation/acucorpproducts/docs/v6_online_doc/gtman3/gt36122.htm

3. I was amazed that people expected a PIC X source field moving to a numeric target to be flagged as illegal. Why would it be? The source is expected to be alphaNUMERIC. Some platforms will crash with a data
exception at runtime (the famous S0c7 on IBM mainframes) if you do this
move and the contents of the source are NOT acceptably numeric, but it should not be flagged as an error at compile time. (Nevertheless, I
wouldn't do this move myself...) Neither would I ever attempt to
"de-edit" an edited field...just because you CAN do something, doesn't
mean it is always wise to do so...

Please see table # 44 below from IBM:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/Connected/BOOKS/IGY3LR10/6.2.24.1?SHELF=&DT=20020920180651

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

OS-390 COBOL will do so. I had it happen just today! :O :D It refused
to compile until I fixed my error.

Mike

---
* SLMR 2.1a * It's time for the Possum Lodge Word Game!!!
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 5/17/2018 4:21 AM, Kellie Fitton wrote:

I just tested this on IBM COBOL FOR VSE/ESA 1.1.1

The compiler does not flag the move of PIC X to PIC 9. Here is a sample
output I cobbled together to summarize what happens in a couple of cases:

SOURCE-FIELD 12345
DEST-FIELD 12345
SOURCE-FIELD ABCDE
DEST-FIELD ABCD5

Here is the code (at least relevant bits):

WORKING-STORAGE SECTION.

01 FILLER.
05 SOURCE-FIELD PIC X(5).
05 DEST-FIELD PIC 9(5).

PROCEDURE DIVISION.

0000-MAINLINE.
MOVE '12345' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
MOVE 'ABCDE' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
.

9000-END.
STOP RUN
.

I think the COBOL manuals explicitly state what happens in these mixed
situations and indeed a LOT of old code is written to depend on that
specific sort of behaviour...

Hi Kerry,

Please see table # 44 below. I wonder if the IBM compiler will flag
the move if you define the variable as PIC A ?

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/Connected/BOOKS/IGY3LR10/6.2.24.1?SHELF=&DT=20020920180651

When I change DEST-FIELD to PIC A(5)
the compiler did not complain about anything BUT it produced slightly different result (!?) "ABCDE" instead of the previous "ABCD5":

SOURCE-FIELD 12345
DEST-FIELD 12345
SOURCE-FIELD ABCDE
DEST-FIELD ABCDE
1S55I LAST RETURN CODE WAS 0000

Note that I am using non level-01 fields since level 01 fields are
(rightly) considered group items and PIC X by default.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 17/05/2018 8:49 PM, Kellie Fitton wrote:

Moving an alphabetic variable to a numeric binary variable is an illegal >>> move in COBOL and should be flagged by the compiler.

I believe it IS "flagged by the compiler".
Did you check what level the target field is? (see below...)

Hi Pete,

I am just conducting a simple test. Moving a 01-level alphabetic variable
to a 01-level binary numeric variable.

1. I have never used a COBOL compiler (and I have used them for IBM,
Burroughs, NCR, Honeywell, ICL, CDC, and PCs (both Micro Focus and
Fujitsu), which did NOT flag a move from alphabetic to numeric as
illegal. (Maybe I was lucky and every place I worked had the right
compiler options in place, but I don't think so...)

Please see the link below from Microfocus:

https://supportline.microfocus.com/documentation/acucorpproducts/docs/v6_online_doc/gtman3/gt36122.htm

It confirms what I said above.

(Line 1 of the permitted moves table shows that a move of alpha to
numeric is illegal.)

What's your point?

3. I was amazed that people expected a PIC X source field moving to a
numeric target to be flagged as illegal. Why would it be? The source is
expected to be alphaNUMERIC. Some platforms will crash with a data
exception at runtime (the famous S0c7 on IBM mainframes) if you do this
move and the contents of the source are NOT acceptably numeric, but it
should not be flagged as an error at compile time. (Nevertheless, I
wouldn't do this move myself...) Neither would I ever attempt to
"de-edit" an edited field...just because you CAN do something, doesn't
mean it is always wise to do so...

Please see table # 44 below from IBM:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/Connected/BOOKS/IGY3LR10/6.2.24.1?SHELF=&DT=20020920180651

Confirms the same as above.

Not sure what your point is in referencing these tables. There is no
argument from me that you cannot legally move alphabetic to numeric in
COBOL.

You seem to have missed or ignored my point that if the receiving field
is an 01 level, it MAY be considered as a group field and the move is
then legal. (I remember this happening on at least one occasion in my
career but I'm not sure what platform it was on.)

Did you try changing the level number of the receiving field?

Pete.
--
I used to write COBOL; now I can do anything...
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On 17/05/2018 8:21 PM, Kellie Fitton wrote:

I just tested this on IBM COBOL FOR VSE/ESA 1.1.1

The compiler does not flag the move of PIC X to PIC 9. Here is a sample
output I cobbled together to summarize what happens in a couple of cases:

SOURCE-FIELD 12345
DEST-FIELD 12345
SOURCE-FIELD ABCDE
DEST-FIELD ABCD5

Here is the code (at least relevant bits):

WORKING-STORAGE SECTION.

01 FILLER.
05 SOURCE-FIELD PIC X(5).
05 DEST-FIELD PIC 9(5).

It will NEVER flag these moves because they are LEGAL.

You have missed the difference between ALPHANUMERIC (PIC X) and
ALPHABETIC (PIC A).

It is ALPHABETIC whichis illegal, NOT ALPHANUMERIC.

PROCEDURE DIVISION.

0000-MAINLINE.
MOVE '12345' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
MOVE 'ABCDE' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
.

9000-END.
STOP RUN
.

I think the COBOL manuals explicitly state what happens in these mixed
situations and indeed a LOT of old code is written to depend on that
specific sort of behaviour...

Hi Kerry,

Please see table # 44 below. I wonder if the IBM compiler will flag
the move if you define the variable as PIC A ?

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/Connected/BOOKS/IGY3LR10/6.2.24.1?SHELF=&DT=20020920180651

I agree with the poster...

Pete.
--
I used to write COBOL; now I can do anything...
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

It confirms what I said above.
(Line 1 of the permitted moves table shows that a move of alpha to
numeric is illegal.)
What's your point?

Yes that's what we all said. The move of alpha to numeric is illegal.
The point was moving an AlphaNumeric variable to a Numeric variable is
legal if it consist Only of Numeric characters, because it will be
considered a numeric field and it will be treated as a numeric integer.

Did you try changing the level number of the receiving field?

no, not yet...
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

Kellie Fitton <KELLIEFITTON@yahoo.com> wrote in news:9de1242e-0d3d-4de2-b0cd- e5f5cf7b6c1c@googlegroups.com:

Hi Folks. It's me again.

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

Stop right there.

You *said* "alphabetic string" but the example you provided down-thread uses an
*alphanumeric* string.

I think the main problem here is that you misunderstand the function of the various Cobol
datatypes.

Any competent Cobol compiler should issue a diagnostic when attempting to move an
*alphabetic* string e.g. PIC A(5) to a numeric variable, because the contents of an
alphabetic string cannot possibly be valid numeric data: PIC A(n) can hold a-z, A-Z, and
space -- and NOTHING ELSE.

There is no inherent problem in moving an *alphanumeric* string e.g. PIC X(5) to a numeric
variable: PIC X(n) can hold *any* bit pattern, including the digits 0-9, and thus it is
*impossible* to determine *at compile time* whether such a move is valid or not.

For PIC X(n) variables or strings, the determination of whether a move to a PIC 9(n) variable
is valid or not can be made *only* at run time.

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

Most other languages don't make the distinction between alphabetic and alphanumeric
data.

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Because the only "bug" here is your failure to understand the distinction noted above.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

Stop right there.

You *said* "alphabetic string" but the example you provided down-thread uses an
*alphanumeric* string.

Doug,

I never provided any example code in this thread whatsoever.

Did you look at the link I provided in this thread ?

Did you read table # 44 with its clause # 3 ?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

Hello All!

I need to make a wee point regarding attempting to move AN to N and even
more so if N = in any way binary.


Running such a program that escapes from a compiler warning/error and it
then attempts to move a non numeric value to a numeric area but
specifically binary of any sort AND running this on a mainframe and here I think of IBM but others come also to mind including ICL you will end up
with a core dump issued because of an exception that issues (on IBM) an OC7 ERROR.

programs written in the 60's and say running on IBM 1401 / 7094 and even
ICL (was ICT) 1900's did not complain and many of us used this to create program tricks. Clearly such programs when moved to more modern kit would break and so a check was put in to Cobol to ensure the risk of this
happening was reduced and/or stopped.

It can however, still happen :(

By the way I can if the right flags are set when compiling using GnuCOBOL
make the running program do similar which was the only way to test some
very old code that I considered to be added to my cobxref program that
would print out sizing information for an 01 level but as the code mis-used
a 9(4) field by placing a space in the first (or last char - forgotten what one) under certain conditions the o/p was un-usable and more importantly
unsafe if used on a IBM and as I have a version that runs with MVS as the
ANSI compiler is broken when doing cross reference listing I had to remove
its usage.

So YES it still can happen today and no doubt one or more system in the
world does more than once per day.


End cap : Compiler must be able to check (subject to the right flag
settings etc) if some one is mis-typing data.


Vince


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

In article <1526737509@f1.n250.z2.fidonet.ftn>,
Vince Coen <VBCoen@gmail.com> wrote:

[snip]

programs written in the 60's and say running on IBM 1401 / 7094 and even
ICL (was ICT) 1900's did not complain and many of us used this to create >program tricks. Clearly such programs when moved to more modern kit would >break and so a check was put in to Cobol to ensure the risk of this
happening was reduced and/or stopped.

It can however, still happen :(

Perfectly good code gets broken by upgrades to The Compiler... anyone ever
use ON 1 for a FIRST-TIME-IN switch?

DD

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Monday, May 14, 2018 at 10:09:36 AM UTC-5, Kellie Fitton wrote:

Hi Folks. It's me again.

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.

COBOL - the elephant that can stand on its trunk...

Unisys OS2200 cobol compiler will issue a warning.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Tuesday, May 15, 2018 at 1:09:36 AM UTC+10, Kellie Fitton wrote:

Hi Folks. It's me again.

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

Yes. PL/I does.

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Tuesday, May 15, 2018 at 2:13:18 AM UTC+10, Kerry Liles wrote:

On 5/14/2018 11:42 AM, Clark F Morris wrote:

On Mon, 14 May 2018 08:09:35 -0700 (PDT), Kellie Fitton
<K.....@yahoo.com> wrote:

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

Which compiler? I am fairly certain that the IBM compilers would flag
a PIC X to PIC 9 MOVE and probably fail the compilation. I don't have
a system available to me to verify this.

Clark Morris

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.




COBOL - the elephant that can stand on its trunk...

I just tested this on IBM COBOL FOR VSE/ESA 1.1.1

The compiler does not flag the move of PIC X to PIC 9. Here is a sample output I cobbled together to summarize what happens in a couple of cases:

SOURCE-FIELD 12345
DEST-FIELD 12345
SOURCE-FIELD ABCDE
DEST-FIELD ABCD5

Here is the code (at least relevant bits):

WORKING-STORAGE SECTION.

01 FILLER.
05 SOURCE-FIELD PIC X(5).
05 DEST-FIELD PIC 9(5).

PROCEDURE DIVISION.

0000-MAINLINE.
MOVE '12345' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
MOVE 'ABCDE' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
.

9000-END.
STOP RUN
.

I think the COBOL manuals explicitly state what happens in these mixed situations and indeed a LOT of old code is written to depend on that specific sort of behaviour...

I ran the same task in PL/I (the code follows, with results beneath):--

test: procedure options (main);

declare source_field pic 'xxxxx';
declare dest_field pic '99999';

source_field = '12345';
dest_field = source_field;
put (dest_field);

source_field = 'ABCDE';
dest_field = source_field;
put skip list (dest_field);
end test;

Output:

12345
IBM0032I ONCODE=0612 The CONVERSION condition was raised
because a conversion error occurred when converting from character
to arithmetic.
At offset +00000159 in procedure with entry TEST
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Tuesday, May 15, 2018 at 4:13:18 AM UTC+12, Kerry Liles wrote:

SOURCE-FIELD 12345
DEST-FIELD 12345
SOURCE-FIELD ABCDE
DEST-FIELD ABCD5

The reason that the last digit is modified to a 5 is that the high bits of the last byte are used to indicate the sign (unless sign separate is specified) and these bits would be cleared for a positive or unsigned move.


--- Synchronet 3.20a-Linux NewsLink 1.114