COBOL <-> java behaviour 3

[Truusvlugindewind]

Just saw the following construction in a mainframe COBOL program:

if (num-field in rec-layout numeric) and
   (num-field in rec-layout not equal zero)
then perform this
else perform that 
end-if.

"Look" I said to a collegue
"When the num-field actually contains a non-numeric value, the program will dump with a S0C7. In java (I followed a java course the other day) the program will stop testing because the numeric part of the IF is false, so the rest needs no evaluation. The program will not check if the field is equal zero or not, it servers no purpose. The IF is false anyhow.".
My collegue stated that for the old COBOL (OS/VS) that was true, an error would occur, but the new compiler (cobol for OS/390 2.2.0) will check the same way as java and will NOT dump.
Is this true? how about your compiler?

 

[Crox]

Hi,

I am sure that the statement above is never causing a S0C7 because the numeric part is first evaluated so the if is false, no matter what compiler you use. OS/VS COBOL did this right. I even think such a statement was used in 1979 with the Volmac course. At that time OS/VS COBOL was state of the art.

Regards,

Crox

 

[wahlers]

Just to confirm...
Since 1990 I have always used the (COBOL) condition construction, such as:

IF x IS NUMERIC AND x > ZERO

I never encountered any logical problem for any combination of compiler/OS platform/hardware platform.

However(!) be aware of nested logical constructions, such as:

*// condition 1
IF (x IS numeric AND x < minimum) OR x > maximum THAN
...valid number(maybe!), but out of range

*// condition 2
IF x IS numeric AND (x < minimum OR x > maximum) THAN
...valid number(yes!), but out of range

*// condition 3
IF x IS numeric AND x < minimum OR x > maximum THAN
...valid number(????), but out of range

(Notice the use of brackets...( x or y)...)

Assume that x is NOT numeric than:

*// condition 1 will fail/abend (is logically incorrect)
*// condition 2 will work (is logical correct)
*// condition 3 ??????? <--- see official syntax rules!!!

(...without brackets 'AND' and 'OR' are validated on basis of equal priority from left to right. Consequently: 'condition 3' is, in this case(!), logically correct!).

Logical condition errors can be (are!) hard to detect and hard to solve.
I always use brackets exactly because I want to avoid the above 'condition 3' situation.
Yes, it is more coding but it makes live so much easier for the programmer that has to understand and maintain your program after you!

Regards, Wim Ahlers.

 

[COBOLKenny]

condition 3 has a problem. S0C7 can occur.

*// condition 3
IF x IS numeric AND x < minimum OR x > maximum THAN
...valid number(????), but out of range

This is equivalent to writing
*// condition 3
IF (x IS numeric AND x < minimum) OR x > maximum THAN
...valid number(????), but out of range


If x is numeric but fails the minimum test, the maximum test will be done. Since x is numeric, no S0C7.

If x is not numeric, the first compound condition fails. The maximum test is then done resulting in S0C7.

 

[webrabbit]

The original construct can never cause a problem in a valid COBOL compiler. The rules of COBOL are that when the condition of an IF statement can be determined, the rest of the condition is not evaluated. I started programming in COBOL on IBM mainframes in 1968, frequently use this construct and have never had a problem.

The "condition 3" above fails because the condition cannot be determined until the OR is evaluated. "condition 1" fails for the same reason. "condition 2" does not fail as the OR will not be evaluated if x is not numeric, due to the parentheses.

 

[COBOLKenny]

You are right, Webrabbit. I've been programming nearly as long and it has always been my practice to first check the field for NUMERIC before checking for any specific values. Because, as you say, if it fails the NUMERIC test, there is no reason to do the test for a specific value.

 

[Truusvlugindewind]

I just checked using the (open source) TinyCOBOL compiler:
It accepts everything. Whatever I code does not abend. More reason to code safe-code. This will always be correct, safe and clear:

if num-field    in rec-layout numeric
   if num-field in rec-layout equal zero
      display "numeric and zero"
   else
      display "numeric other than zero"
   end-if
else 
   display 'NOT numeric"  
end-if

 

[WMK]

Slight "side" comment,

The ISO 2002 Standard has an "odd" (to me) enhancement and requirement.

If you define a BINARY field and do an IF NUMERIC test against it (newly allowed NUMERIC check). However, the standard requires that to PASS, the value of the field *must* match the PICTURE decimal places. In other words

+1000
would never pass "IF NUMERIC" for a
Pic S9(3) Binary field

EVEN THOUGH (most) compilers at least have an option to allow this to "work as expected".

Bill Klein

 

[3gm]

Bill -

Does this avoid some coding situations where one might edit the field thus: IF XXXX > +999 or XXXX < -999 . . .?

If the field were provided via a file for instance, it might exceed the logical defined size and get you into trouble down the road if you were assuming it fit into its PICture. An IF NUMERIC edit would seem to avoid coding in fixed constants like 999 or using some obscure code, e.g.

COMPUTE XXXX = XXXX ON SIZE ERROR ...

Regards.

Glenn

 

[webrabbit]

When I first used the Micro Focus COBOL compiler (in 1985), it rejected IF NUMERIC on a COMP-3 field. I wondered how one would avoid errors in processing non-numeric data, so I tried a test case. I initiaized a PIC S9(3) variable (through redefinition) to X'00FF' and added one to it. The result was 16 (X'016C')!

Of course, Micro Focus has since permitted a numeric test on COMP-3 fields, and added a test to the internal subroutines that process COMP-3 and display numeric arithmetic to fail on non-numeric data.

 

[k5tm]

Is this true? how about your compiler?

If one's compiler claims to be compliant with any ISO/ANSI COBOL standard since 1985, then it must be true. There is even a FAQ about such things: faq209-1604

Tom Morrison

http://www.liant.com

 

[wahlers]

Just back from a short holiday...

1. I have used the word brackets where it should have been parentheses (brackets are [] and parentheses are (), of course). I apologise for that mistake...english is not my native language).

2. Remarks were made regarding certain compilers and vendors. It is my honest opinion not to use vendor dependent features (and therefore not mention them).

3. I am very pleased with the critics on the '*// condition 3' example in my original reply by COBOLKenny (which results in a S0C7 abend (=packed-decimal error)).
Personally I never work without parentheses, therefore I never use this construction myself. I honestly thought that the rules for the logical condition is on a equal, left to right, base. I should have tested this first!!!! (n.b. I was used to equal, left to right evaluation in assembler).

The original '//* condition 3' example shows once again how parentheses could and (IMHO must be used) to avoid abiguity.


To truusvlugindewind:

Of course you can split your compounded condition logic in a serie of individual IF statements. However, there is no such thing as a free lunch! By doing this you quickly end up with deeply nested IF statements.

I still stick with my original remark to always(!) use parentheses in compounded condition statements to avoid abiguity.

Regards, Wim Ahlers.

 

[Truusvlugindewind]

Wim, your'e right, no argue about that.
But from this angle (

http://www.netnam.vn/unescocourse/se/12.htm):

Here is says that potability and robustness are a quality attributes. Im my eyes this means that "the more portable" your program, "the higher" the quality of your work. Well, that's our ultimate goal.....

Concerning the nested if's: it enables you to specify the error more accurate (in each else branch). Your support/maintenance collegues will appriciate that.

 

[joepiemeloenie]

incredible basic question!

 

[wahlers]

To joepiemeloenie:
1. Even incredible basic questions needs to be addressed and answered.
2. Some programmers don't know or forget the basics.


To truusvlugindewind:

Portability and robustness AND clearity are a quality attributes...plus some other characteristics (such as usability , reusability and timely delivery).
...or as the saying goes...:
I can make it cheap, fast and stable...choose any two!

How to achieve:
1. Stick to the standards.
2. Keep it simple #$@& (KISS approach).
3. Avoid abuigity.
4. Use proven techniques in analysis, design, implementation and (test)procedures (see amazon.com for the various literature).
5. Document it (that is document it usefully!...preferable using some automatic documentation system).
6. Or...don't code at all! Use(buy) standard(commercial) packages and solutions.

If you are interested...I wrote a general (COBOL oriented) paper on 'the complexity of object-based programming'.
See link:

http://www.programmersheaven.com/2/Art_ObjBasedSystems

Regards, Wim Ahlers.

 

[Dimandja]

About portability vs efficiency, I'll take efficiency any time. This is why.

Almost every program I have ever run accross, tries to make maximum use of the OS and the harware it is running on. All of my clients would cringe if I told them I was going to ignore their expensive OS and hardware for the sake of portability.

Portability to what? COBOL code is usually tightly bound to business requirements that are also tightly bound to hardware. Why you would think of separating those ties defies logic.

Although COBOL is among the most portable of languages, there is little if anything to be gained by insisting on coding code portable (to nowhere).

Dimandja

 

[3gm]

Dimandja -

Hmmm. Your post set me back on my heels a bit. I am a great believer in coding for portability but I also believe in efficiency. Most of us who make a living out of coding in COBOL know that it's all about trade-offs. Portability versus efficiency is just another one of those areas where we get to wield the sword of Solomon.

I've programmed for many years in a multi-vendor shop and have come to appreciate the portability of COBOL. Certainly it is not frequent that I have programs that move from one platform to another, but it does happen. (Perhaps the most obvious example, and perhaps a fairly simple one, is moving from VSE to MVS. Many folks have done that. They can probably attest that migrating code that took advantage of operating system features or that was written in a non-standard way was 95% of the effort.)

More importantly, I move from platform to platform. The more closely I adhere to standard usage, the easier it is for me to move back and forth and be productive.

On the other hand, for years I've decried the programming "bloat" that has overtaken the industry. No one seems to care about efficiency any more - just throw more/faster hardware at the problem.

Certainly one can strive for a reasonable balance of efficiency and portability.

Regards.

Glenn

 

[wahlers]

This deviates from the original question, but...

Efficiency over portability?
I always challenge efficiency over portability, because I have never met a programmer who actually measured his 'cleaver trick' against a normal, standard, well structured program.
I once did (which costed me a lot of time!) and I found no measurable differences between 5 or 6 so called 'clever' programs and equivalent(!) structured programs.
However, maybe you have different experiences. In that case I am interested in your sources and the comparable equivelent(!) structured programs.
(notice the emphasis on equivalent!).

N.B. Of course I can always write a dumb ineffient program, even a dumb (and therefore non-equivalent) structured program, that is noticebly slower than any other program.

Regards, Wim.

 

[Dimandja]

wahlers, the efficiency I am talking of has nothing to do with structured programs.

It has to do with writing code that exploits the target OS and hardware.

For example, you can strive to write code that will run "unchanged" on IBM, Windows, Unix, PC, mainframe, etc...

However, if you look at the requirements for running the same code accross those platforms, you may find that portability does have its crippling limitations: if you write screen handlers, there is no portability to speak of; if you write batch programs, the JCL will hold you to a single OS, etc...

You may get away with writing a calculation routine or even a date routine, though. But, don't get me started on single vs double quotes, or computational fields, or SELECT statements...

Dimandja

 

[Crox]

I found many differences. I made once an encryption program to encrypt backups and make it inaccessible to people that intercepts is when it is send by mail. It is known as ZISCRYPT. When the tests were succesful, I wanted to see if it was possible to make it faster. I measured the speed of statements like INSPECT .. CONVERTING on several lenghts of data. With small amounts of data until the length of 64 bytes, an approach using a table and COMP-5 subscriptors was faster. With larger amounts, the inspect was faster. I measured the timing of loops, using indexes, subscriptors, fieldtypes, etc. etc. In the end the program was 64 times faster than the first one. I used some very specific Realia possibilities so it is not portable at all anymore but making it 64 times faster was very important. If it has to run with an other COBOL compiler, I will probably have to do all this measuring all over, but it is worth it. 64 times!!!