close re-entrancies of the 3rd kind

[Truusvlugindewind]

Mainframe cobol & re-entrantcy... always a pain in the <beep>
Batch/CICS/IMS, bmp or mpp, never a dull moment.

Nowadays I'm coding cobol-db2 stored-procedures, a new nail in our re-entrancy coffin. No cics, no batch, no ims but WLM's. Not only working storage fields containing old values, but 'declared global termory tables' still hanging around from the previous call. Like I said: "never a dull moment".

To code as generic as possible I'd recommend:

1) Always "drop" your temp table before declaring. do not care to test your SQLCODE after dropping, the value is not significant at all.
2) Start using local-storage instead of working-storage. It frees you from a lot of uncertain behaviour.

I'd like your comments on this.

 

[Glenn9999]

This concept brings to mind something that most COBOL types never see, recursion. Then there's always the issue of multi-processing, which is coming to the forefront. You have to make most things you code in that way re-entrant simply because it has to run many times at once independently of each other.

To that end:

1) I'd agree with that, simply to make sure the slate is clean since you're bringing an outside service into the picture with your program. In fact, re-entrancy seems to bring back one of issues of programming that most don't think about anymore, initializing all your variables and resources.
2) Agreed. You always want all internal processing of a re-entrant procedure controlled by local variables if you can get away with it. Most languages handle re-entrancy very easily, but like I eluded to with the recursion comment, COBOL is quite a different beast when it comes to the topic.

 

[ceh4702]

SQL is not COBOL.

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

 

[Glenn9999]

SQL is indeed not COBOL. But you can write a stored procedure in COBOL which DB2 can call. This is the issue the original poster is talking about.