Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

COBOL features

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
Hi, can anyone give me some info on COBOL?

Does it support parallel programming?
Does it support distributed computations?

Also, I know about calling subprograms by using the CALL command but does COBOL have functions, procedures etc or is it just subprograms.

One more thing does COBOL support seperate compilation?

Thanks alot for any help you can give me
 
You might do well to post this to the COBOL General Discussion group.

1. COBOL as such doesn't support parallel or distributed computation.

2. COBOL does not support user-written functions in the sense that one can invoke the function and have it return a value (e.g. y = f(x)). It does have a number of built-in (or intrinsic) functions. Prior to the 1985 standard, COBOL did not offer procedures as I think you mean the term (callable routine that can both be passed data as arguments and have access to global data). I believe that with nested subprograms that has changed. If so, only a very small minority of COBOL programmers would be familiar with and use that facility.

3. COBOL most certainly supports separate compilation. In fact, until the 85 standard, that was the only type of compilation supported.

Glenn
 
About parallel/distributed programming, this is an option that your operating environment should provide.

You probably used the 'thread' object in languages such as java; but true/efficient threading is done as described above.

Before I bore you with the following details, let me say that I have used COBOL in parallel/multithreaded applications for years: doing this was possible because the operating environment was accommodating.

When you use a 'thread object', you are still going through the same 'pipeline' to distinguish between the threads. (multiple users through essentially the same executing code)

When you use the operating environment to 'thread', your 'single thread' code is duplicated whenever a 'new thread' is needed. (multiple users through as many executing copies of the same code as your operating environment allows)

It does make a difference. For 'thread object' you must code for the multiplicity of users (can get complex), while for the other option, you code for one user and let the system multiply/distribute your code as needed (very simple).

Dimandja
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top