Converting Cobol programs to PL/SQL packages/Procedures

[jmoore207]

Does anyone have experience converting Cobol programs to PL/SQL? I am having a hard time getting started and was hoping maybe someone had an example Cobol program they had converted. Any help would be greatly appreciated. Thank you!

 

[SantaMufasa]

Back in the "Good Ol' Days", my car's license was "MR COBOL". Now I fancy myself as a PL/SQL aficionado, so I'm happy to be of help.

I'm not aware of any automated method of converting COBOL to PL/SQL.

How many lines of COBOL code are you looking to convert (separated out by DATA DIVISION and PROCEDURE DIVISION)?

If you want to post a sample (minimalist) COBOL program, I'd be happy to convert it over to PL/SQL for you.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
“Beware of those that seek to protect you from harm or risk. The cost will be your freedoms and your liberty.”

 

[jmoore207]

Thank you SantaMufasa. For the moment I am going to keep the displays/accepts that Cobol handles. Unless you know of a better way. The program is the typical batch Cobol program. init-routine (displays/accepts), sort routine, return sort creates report. I tried to pair it down as much as possible. Whenever it is at eof for table 1 it uses the sorted rec to build a report. I have many questions about the portablility from Cobol to PL/SQL. I am so glad I finally found someone to answer them! Thank you very much!

Below is the sort routine.

SORT-ROUTINE
SECTION.
************************************************************
* READS MEMBERDETL TO FIND MBRSEP THEN READS MBRHISTDETL *
************************************************************
SRS-0100-READ-MBRDETL
READ MEMBERDETL UNTIL EOF (Table 1)
IF EOF
GO TO SRS-9999-EXIT.

IF SECONDPARMD(46) = 1
IF SERVTYPE OF MEMBERDETL = 1
GO TO SRS-0100-READ-MBRDETL.
IF SECONDPARMX (85) = "G" AND SERVTYPE OF MEMBERDETL = 2
GO TO SRS-0100-READ-MBRDETL.

MOVE MBRSEP OF MEMBERDETL TO MBRHIST-SEP

GO AND READ TABLE 2

IF BILLTYPE OF MBRHISTDETL = 9 GO BACK AND READ NEXT RECORD OF TABLE 2
IF READTYPE OF MBRHISTDETL = 5 GO BACK AND READ NEXT RECORD OF TABLE 2

IF WW-SELECT = 1 (ANSWERED BY USER)
MOVE BILLDATE OF MBRHISTDETL TO SELECT-DATE
ELSE
MOVE READDATE OF MBRHISTDETL TO SELECT-DATE.

CALL "DATE2Y2K" USING SELECT-DATE, Y2K-SELECT-DATE.
CALL "DATE2Y2K" USING FROM-DATE, Y2K-FROM-DATE.
*Y2K IF SELECT-DATE < FROM-DATE
IF Y2K-SELECT-DATE < Y2K-FROM-DATE
GO BACK AND READ NEXT RECORD OF TABLE 2
ELSE
CALL "DATE2Y2K" USING SELECT-DATE, Y2K-SELECT-DATE
CALL "DATE2Y2K" USING THRU-DATE, Y2K-THRU-DATE
*Y2K IF SELECT-DATE > THRU-DATE
IF Y2K-SELECT-DATE > Y2K-THRU-DATE
GO BACK AND READ NEXT RECORD OF TABLE 2
ELSE
MOVE CORR MBRHISTDETL TO SF-REC.
SRS-0200-LOCINFO.
MOVE LOCATION OF MBRHISTDETL TO LOCATION-LOC
READ TABLE 3 LOCINFO
IF NOT FOUND GO BACK TO TABLE 2.
MOVE SUBSTATION OF LOCINFODETL TO SORT-SUBSTATION.
MOVE SLFILLER30 OF LOCINFODETL TO WS-SLFILLER30.
IF RWS-F30-1 NOT NUMERIC
MOVE ZEROS TO RWS-F30-1.

IF RWS-F30-2 NOT NUMERIC
MOVE ZEROS TO RWS-F30-2.
MOVE YLNBR OF LOCINFODETL (1) TO NBRSLS OF SF-REC.
ADD YLNBR OF LOCINFODETL (2) TO NBRSLS OF SF-REC.
ADD YLNBR OF LOCINFODETL (3) TO NBRSLS OF SF-REC.
ADD YLNBR OF LOCINFODETL (4) TO NBRSLS OF SF-REC.
ADD WS-F30-1 TO NBRSLS OF SF-REC.
ADD WS-F30-2 TO NBRSLS OF SF-REC.
ADD SLCODE4 OF LOCINFODETL TO NBRSLS OF SF-REC.
MOVE CIRCUIT OF LOCINFODETL TO SORT-CIRCUIT.
SRS-0900-RELEASE.
ADD 1 TO WW-CNTR.
ADD 1 TO WW-TEST.
RELEASE SF-REC.
GO TO SRS-0110.
SRS-9999-EXIT.
EXIT.

 

[LKBrwnDBA]

Maybe Quartic can help.





----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[jmoore207]

The company is looking to do this in house w/o training. So I suspect it to be a slow process. The problem is the Cobol programmers have to learn this while they are still working on there daily Cobol work.

 

[SantaMufasa]

Can you post the DATA DIVISION (at least the WORKING-STORAGE SECTION)? Also, can you please post Oracle-related code such as the "CREATEs TABLEs..." and any "INSERT INTO..." statements so that I can test the code conversion?

Thanks,

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
“Beware of those that seek to protect you from harm or risk. The cost will be your freedoms and your liberty.”

 

[LKBrwnDBA]

Dave,

jmoore207 has posted a bad example of COBOL code. This code would be very difficult to re-write because it is building and releasing "sort" records and would require some global temporary table or such to simulate the sort.

I would personally recommend that the COBOL programs be converted to Pro*COBOL, which would be somewhat easier to do and maintain.

On the other hand, the idea of rewriting a bunch of cobol programs to pl/sql would need a very convincing business case for the project (unless someone has a religious aversion to cobol).




----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[jmoore207]

I agree 100% LKBrwnDBA. We have a lot of Cobol programs with embedded sql in them. They seem to be bound and determined to move away from Cobol. I think PL/SQL has its purpose, but I think we should just embed sql in some of these batch programs. I agree we will need some kind of temporary table to do the sort and from what they are saying they do not want to use temp tables. We do use Pro*Cobol, but they want to use straight pl/sql. Believe me this was not my idea. I posted this program because someone thought this would be a good example of a program to convert. You already brought up the temp table issue, also, we would have to figure out how to accept/display from the user and also how to write/format the reports. "unless someone has a religious aversion to cobol" someone does, believe me.

 

[jmoore207]

Santamufasa, I will post the W-S tomorrow morning. This program does not update any tables, it gets the fields it needs from the 3 tables, build s a sort-rec and then build a report-rec from the sort-rec. Not an ideal program to convert. We have 100's of these type programs. I was hoping since you used to use Cobol, you may have some ideas of how to make this work. Please let me know if you need anything else from me. Thank you for everyone's feedback in here. It's pretty refreshing compared to some of the other forums I have posted in.

 

[LKBrwnDBA]

IMHO:

Converting already working COBOL programs to pure PL/SQL will not only be a nightmare but a total waste of time and resources.

Migrating from COBOL to PRO*COBOL would be somewhat less resource intensive and wasteful as the overall business logic of the programs will be conserved and you would only have to deal with the embedded SQL. All "new" development should be done in PL/SQL.

Besides, PL/SQL is a "structured" language while the COBOL coding example you provided is an "un-structured" program (lot's of GO TO's). This alone will force a total re-write of the program logic.

Also, you will not be able to avoid temporary tables or permanent (used as temporary) to simulate the sorts and other intermediate result processing.

The accept statements from the user can be converted to a query on some "parameter" table and the displays to inserts into a log table or dbms_output statements.

If "they" insist on full conversion, I recommend you update your resume and do not get involved in this folly.

Good luck!



----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[jmoore207]

unfortunately with the job market the way it is, I have to ride this train for a little while. I agree with what you posted tho.

 

[LKBrwnDBA]

Well, it's tough luck for you then.

Sorry.






----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[Thargy]

lkbrwn,

I believe I understand why you think it's a bad idea, but isn't the gist of this thread precisely why it should be done? It's getting harder and harder to maintain old code, and those in the field who are expert are fast approaching retirement.

Also, there may be other good reasons for the change, e.g. performance. I surmise that on average PL/SQL will out-perform other third-party languages, especially with recent things like native compilation.

As an aside, I too would like to get on a different train ASAP - sigh.

Regards

T

 

[LKBrwnDBA]

Then perhaps the road to go is not to "convert" the code but actually reverse engineer the business rules, produce a new logical and physical database design and write NEW PL/SQL code from scratch.

It maybe would even be faster and more cost-effective than trying to debug converted code.

Also, there are some utilities out there that will help with reverse engineering a COBOL program.





----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

 

[LKBrwnDBA]

PS: It also seems COBOL will (unfortunaltely) never die!

In the course of 10+ years as Oracle DBA working with different corporations I have found many third party applications (even some sold by Oracle) which have a Pro*COBOL back-end.

On the other hand, with respect to performance, COBOL is also a native compilation.





----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb