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?

 

[wahlers]

To Dimandja and Crox:

Now I understand! We have different concepts of efficiency!
COBOL is a specialised language. And as such it is difficult or even impossible to do certain things.

For instance, COBOL will not be very efficient processing an audio or video file. But the COBOL language was never designed to handle this.

There are some things you can not compare.
Or to illustrate: It is unfair to say a truck is slow compared to a ferrari as it is unfair to say that you can carry more load in a truck than you can in a ferrari.

I leave the screen design to other langauges (e.g. JAVA...and others...). For encryption I would call or invoke a specialised routine which may be written in assembler for that matter.
Other languages are far more effiecient to handle these kind of things...

When the word 'efficiency' was mentioned I was thinking of attempting optimizing COBOL code or using vendor specific features and, in the process, sacrificing structure or portability. I have yet to see an example that justifies these kind of sacrifices.
(n.b. That is I have to see an example in large(!) scale international(!) projects that justifies these kind of sacrifices.)

Regards, Wim.

 

[Crox]

What companies most of the time are doing is measuring. Only if one part of the process is consuming much time, that part is investigated. In mainframe environments, we did this a lot of times. Most of the time it was about databases but what happens also a lot of times is that newbees don't understand a bit of efficiency. Even changing zoned fields into COMP or COMP-3 can make a difference. A good optimizing compiler can also make a lot of difference. When you optimize, you can look at a few things:


- limit I-O, database-access
- stucture. Better, smarter, better conditions, sometimes combined conditions using groups, etc.
- limit repeated table access.
- Combine fields in one group so that you can get it at once.
- put assigns of constants out of any loop
- initialize with an initialize group-field
- better field definitions like COMP or COMP-3
- reduce instructions
- reduce between-fields

etc. etc. Every compiler has it's own special things. Even compiler settings make a lot of difference. If you use IBM, watch for example TRUNC(OPT) versus TRUNC(STD) and the usage of COMP-5.

Regards,

Crox

 

[Dimandja]

COBOL will not be very efficient processing an audio or video file. But the COBOL language was never designed to handle this.

COBOL running in .NET can do these things. This is a good example of why your OS should not be ignored.

Dimandja

 

[wahlers]

To crox:

I agree you can save a heck of a time optimizing databases (and accessing your database intelligently). I/O always has been a bottle neck. However code optimization is, most of times (IMHO almost always), a waste of time. Your other remarks concern compiler optimalisation. This is correct! Your compiler will optimise your code far better than you can ever code (assuming you are already a competent programmer. Because everybody can write inefficient code).
Again, I disagree with you that you can save a lot by source code optimisation. Of course you should not use a display field for a counter that loops a million times. In that case it is far more efficient to use a binary field. But this I consider normal programming techniques and not optimisation.

To Dimandja:

Have you tried to run the same code on a AS400, Bull system, IBM mainframe, UNIX system (any UNIX system including Linux), Apple or other systems?
Does your code work on all platforms (hardware/OS)? I doubt it! You create a vendor lock-in by using vendor specific features. This is exactly what I always try to avoid.
Having said this...if the customer agrees and accepts the vendor lock-in than by all means use all functionality available.


Regards, Wim.

P.S. I suggest to end this optimisation discussion in this thread because it deviates to much from the original question.

 

[Dimandja]

Wim, I can't stream video on a Bull, so the argument is moot.

 

[ceh4702]

if (num-field in rec-layout is not numeric)
move zero to num-field
end-if.
"This solves the non-numeric part"

This may or may not work.





If you do not like my post feel free to point out your opinion or my errors.

 

[Crox]

Wim,

The environments I am working - big MVS systems with IMS DC - the average costs of one CPU second is about 20 eurocent. It are multiple-processor-systems. With several million transactions a day, the costs of a system are very huge. I am sure if I can work based on no cure no pay and getting only 10% of the savings of the first year after optimizing I never have to work anymore after one year!

With ZisCrypt 64 times faster on an old 133Mhz Intel system with 10Mb to encrypt is the difference between very slow (a few minutes) and ok (a few seconds).

Regards,

Crox