I have converted a COBOL program to Natural.
Functionally it is working correctly.
The issue is with run time.
Can anyone suggest any COMPOPTS or NATPARMS I could try or anything else that may improve the performance.
There is no database I/O, it is just reading two work files and doing array handling but the arrays are massive.
The dir info looks like this
Op-System … MVS/ESA Transaction … N823
NAT-Ver … 8.2.3
Used GDA … Options … DBSHORT PSIGNF GFID TQMARK V42COMP MAXP+
GDA Date … Size of global data … 0 Bytes
Size in buffer pool … 11088 Bytes Size in DATSIZE … 7654576 Bytes
The use of the word “converted” rather than something like “re-wrote”, may be a part of the problem.
You probably have what is called “Natbol”; a term originally coined to characterize Natural written by Cobol programmers, who had no previous training in Natural.
What is efficient in Cobol is often not efficient in Natural.
I have often seen production code which resets Natural arrays thusly:
FOR #LOOP = 1 TO 1000
MOVE ’ ’ TO #ARRAY (#LOOP)
END-FOR
In Natural even RESET #ARRAY () is far faster, while REDEFINING #ARRAY as a string, say #STRING (A1000), then RESET #STRING, is orders of magnitude faster than the RESET #ARRAY ().
Similarly, any FOR loops whose purpose is to test each character for a specific value, can be re-coded, much more efficiently, by using EXAMINE (again of #STRING rather than #ARRAY (*).
Natural and Cobol are NOT the same language. A re-write would probably prove very valuable performance wise. In addition, if you are not using the Natural Optimizer, you are comparing object code (from Cobol), with interpretive code (Natural). It should not be a surprise if object code wins (although more and more object code now exists in Natural even without the optimizer), especially with Natural code that does not take advantage of efficiencies in Natural and Cobol code that perhaps was written efficiently.
Just to add on to what Steve said, he mentioned using EXAMINE with strings, but EXAMINE also works with arrays and may be more efficient than your own FOR loops.
Thanks for you replies.
The program is definitely NATBOL but the original COBOL is well written in structured COBOL 2 and mapped to Natural quite easily. Unfortunately I dont have the budget for a re-write the exercise was to convert the code as is, i.e. replacing PERFORM VARYING with FOR loops etc. Changing the code will take a lot more time and money and risk.
Risk? No. If you (or someone in your shop) is truly conversant with Natural, eliminating silly FOR loops (and probably other constructs, like lots of subprograms with two or three statements, same for external subroutines with 2- statements) is truly trivial. No more “risk” than changing a MOVE to an ASSIGN.
Time and Money? Yes, clearly so. But, the time and money is “upfront, and miniscule” compared to the time and cost of running the resultant NATBOL for the life of the program.
Adding to what Steve said, you are running in circles already, trying to speed it up, so there’s effort (time and thus money) right now - why not do it right ?
You may find yourself spending more time (and thus money) trying to just tweak it in several iterations while you could achieve the same - or better - result with less effort.
Are you waspish with paying customers Steve?
There is no problem with “running the resultant NATBOL for the life of the program”, if the converted program does not perform it won’t replace the Cobol.
“Waspish” is a term I am totally unfamiliar with (english english as opposed to american english). :oops:
“There is no problem with “running the resultant NATBOL for the life of the program”, if the converted program does not perform it won’t replace the Cobol”.
Suppose I have an old car that is getting expensive to maintain/run. I take a test drive in a different car. However, I never take the test car out of third gear (it has five forward gears). I conclude that I should stick with the old car since the new car doesn’t go as fast as the old car; makes lots of noise (100 kph in third gear), and burns petrol at a far greater rate than the old car.
Not only do I not buy the new car, but in all future car decisions (other programs that need re-writing), I never even consider the new car.
I have to agree with the others on this. You are replacing one language with another, this means that if you want efficient programs you will have to follow the new language’s rules. Of course Cobol programs written in Cobol will in most cases outperform Cobol programs written in Natural - although I’m sure Steve could find an example to confirm the opposite
