Thoughts of a new Cobol Programmer 
Author Message
 Thoughts of a new Cobol Programmer

I've just started programming cobol on a Vax (about a month now).

I've completed a few programms and am starting to get comfortable with
the language.  Before this I'd done most of my code in C and a little Pascal.

The major weakness I see with Cobol as compared with C is dynamic allocation
of memory.  It is a serious disadvantage to try and guess how many
elements to allocate to an array, as apposed to a linked list structure
with its flexibility.  I can tolerate cobols wordiness, decaring variables
up front, lack of local variables, lack of control structures etc... since
these are more convienence for the programmer than neccessity.  

One advantage I've found in cobol is the positional nature of variables,
which makes it very easy to position printed reports exactly where you
want them etc, also I seem to make many fewer syntax errors since cobol is
much less cryptic than C.  

If sombody has some way I don't know of to dynamically allocate memory I'd
love to hear it.  

Bye,

--
Mike  Urquiola       ,,,          
                    (o o)          

    Some see the world as it is and ask why.  I see the world as it never was and ask why not?   - Robert Kennedy



Thu, 28 Jan 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer

Quote:

>I've just started programming cobol on a Vax (about a month now).

>I've completed a few programms and am starting to get comfortable with
>the language.  Before this I'd done most of my code in C and a little Pascal.

>The major weakness I see with Cobol as compared with C is dynamic allocation
>of memory.  It is a serious disadvantage to try and guess how many
>elements to allocate to an array, as apposed to a linked list structure
>with its flexibility.  << stuff deleted for brevity>>  

>If sombody has some way I don't know of to dynamically allocate memory I'd
>love to hear it.  

>--
>Mike  Urquiola       ,,,          
>                    (o o)          


For batch programming, it generally is not too difficult to design a
program for the typical case, and statically allocate a table.  If you
truly need to dynamically allocate memory from a COBOL program I can
suggest some ways.  But COBOL does not have a built-in language function
to do so.

In an IBM Mainframe CICS environment, you can perform an EXEC CICS
GETMAIN api call.  You tell it how much you want, and optionally what
character to initialize each byte to.  If you don't initialize, you get
whatever was there.  If CICS cannot allocate that much memory for you,
then you get a returncode (or handle condition) indicating your GETMAIN
request failed.  If the request was successful, the address is returned
to you in a 32-bit fullword.

I have never had occasion to dynamically allocate memory from a batch
program in an IBM mainframe environment, but you could easily call an
assembler subroutine which would perform an MVS operating system GETMAIN
request.  You might have to use the Linkage Section to actually
reference the acquired storage.  The GETMAIN request would work somewhat
like a CICS GETMAIN request, but it the storage would come from the
region your job was executing in.  In either CICS or batch, the
termination of your task would result in an implicit FREEMAIN of the
allocated storage, although it is always better to do your own explicit
FREEMAIN.  If you have long-running and/or conversation tasks in a CICS
environment, the lack of explicit FREEMAIN's can result in big-time
storage creep.

In the manuals for CA-Realia COBOL for PC-DOS I recall reading how to
call MS-DOS (or OS/2) to request a block of storage.  Again, this is a
case of COBOL relying on the operating system.  I don't have experience
with MicroFocus COBOL, but you could probably find a documented method
for calling the host operating system to acquire a block of storage
dynamically.

I have always thought it was extremely odd that C has MALLOC and FREE as
native functions in the Language.  It seems more logical to me for the
operating system to own the storage, rather than the executing
program.

I hope this information helps.

Arnold Trembley
Software Engineer I (just a job title, still a programmer)
MasterCard International
St. Louis, Missouri



Fri, 29 Jan 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer

Quote:

> I don't have experience
> with MicroFocus COBOL, but you could probably find a documented method
> for calling the host operating system to acquire a block of storage
> dynamically.

Micro Focus COBOL provides the "CBL_ALLOC_MEM" and "CBL_FREE_MEM" calls on all
environments.

Quote:
> I have always thought it was extremely odd that C has MALLOC and FREE as
> native functions in the Language.

This is a bit off topic for a COBOL group, but I just wanted to say that C
has no "native functions" (possibly with the exception of main()). malloc()
and free() are (standard) library functions, nothing more.

Quote:
> It seems more logical to me for the
> operating system to own the storage, rather than the executing
> program.

I don`t quite understand what you`re saying here. If the memory pool doesn`t
exist within the virtual memory space of an individual process, then logic
errors that overwrite memory not allocated can have severe consequences on the
whole of the machine, not just the process that is in error.

Cheers, Kev.

--

These views are strictly my own. I doubt that anyone else would want them.
STUFF FOR SALE: <A HREF="http://www.mfltd.co.uk/~ked">Here!</A>



Fri, 29 Jan 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer

<snip>

Quote:
> The major weakness I see with Cobol as compared with C is dynamic allocation
> of memory.  It is a serious disadvantage to try and guess how many
> elements to allocate to an array, as apposed to a linked list structure
> with its flexibility.  I can tolerate cobols wordiness, decaring variables
> up front, lack of local variables, lack of control structures etc...

> If sombody has some way I don't know of to dynamically allocate memory I'd
> love to hear it.

I'm not sure what control structures COBOL lacks.  Certainly COBOL prior
to the 1985 standard was short on control structures, but the current
standard provides all of the control structures that I believe are
necessary to easily write well-structured code.

<warning geting on soapbox>
As for dynamic memory allocation, you have a point.  However, in years
of using COBOL, I've rarely run into situations where dynamic memory
allocation was necessary.  Remember that COBOL was pricipally designed
to solve business problems.  I know that many, if not most, of the COBOL
programmers I've worked with over the years haven't got the foggiest
idea of what a linked-list is, never mind any of the more complex data
structures that one runs into these days.  Not to say that they
shouldn't, but traditionally they don't.  As more and more programmers
are coming up with computer science backgrounds and as C and MS Windows
become more and more prevalent, I'm seeing more and more programmers
knowledgeable in complex data structures that lend themselves well to
dynamic memory allocation.
<end of soapbox>

Dynamic memory allocation has generally been available via
implementation dependent subroutine.  E.G. the latest IBM compilers
allow creation/allocation of heaps via Language Environment (LE)
callable services.  The availability/implementation of dynamic
allocation will depend on your environment.
--

Director, Computer Technology   http://www.mmc.org
Maine Medical Center            
Portland, ME  04101



Fri, 29 Jan 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer

Quote:

>>I've just started programming cobol on a Vax (about a month now).

>>I've completed a few programms and am starting to get comfortable with
>>the language.  Before this I'd done most of my code in C and a little Pascal.

>>The major weakness I see with Cobol as compared with C is dynamic allocation
>>of memory.  It is a serious disadvantage to try and guess how many
>>elements to allocate to an array, as apposed to a linked list structure
>>with its flexibility.  << stuff deleted for brevity>>  

>>If sombody has some way I don't know of to dynamically allocate memory I'd
>>love to hear it.  

>>--
>>Mike  Urquiola       ,,,          
>>                    (o o)          


I have always thought it odd that programmers should have to worry about memory
allocation at all.  This should be the job of the compiler or even an assembler.
The original Dartmouth BASIC compiler (yes, the original was a compiler) had a
very clever string memory allocation.  You never had to limit the size of your
strings or reserve memory for them.  At the first use of a string the compiler
set aside at least x amount of memory.  I think the number was eight characters,
but the number is not important.  If in the operation of the program the string
"grows" memory is doubled, the characters reassigned, and "garbage" collected.
I think that Kemeney et. al. based this on LISP, but I am unsure of this.  Many
people questioned the efficiency of this growing string size method, but after
extensive testing very few programmers could beat the system!  Now, the same
scheme never replaced the DIM X(100), but of course that was in the original
BASIC long before strings, well two years before strings.  Original BASIC was
operational in 1965, having run experimentally for a year or two before.
Strings came into the language at Dartmouth in 1966.

BTW, COBOL programmers are very fond of ISAM files.  The allocation of index
space in ISAM is fully automatic and quite efficient.  You can always find good
examples of where the machine makes poor, inefficient decisions, but for the
average joe (or jane) machine optimization of storage will probably win.

Just my two cents.  Cheers.  Bob
Robert Schuldenfrei
S. I. Inc.
32 Ridley Road
Dedham, MA  02026
Voice: (617) 329-4828
FAX:   (617) 329-1696

WWW:    http://www.tiac.net/users/tangaroa/index.html



Fri, 29 Jan 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer

Quote:

>>> The major weakness I see with Cobol as compared with C is
>>> dynamic allocation of memory.  It is a serious disadvantage
>>> to try and guess how many elements to allocate to an array...

Michael's difficulty in guessing array size indicates he is on the
wrong track.  In COBOL (as in many languages) individual items are
declared in memory and files are declared for unlimited numbers of
those items.  Tables are a halfway stage, when there is a known
number of items, and can be held either in memory or in a file.

A linked list _should_ be a file but it is often implemented in
memory "for efficiency reasons".  Let the programmer worry about
logic (first) while the system software worries about efficiency.



Quote:
> memory allocation..should be the job of the compiler/assembler..
> You can always find good examples of where the machine makes
> poor, inefficient decisions, but for the average joe (or jane)
> machine optimization of storage will probably win.

Yes, but compilers only ask; memory is a resource allocated by the
underlying Operating System.  A smart operating system (or even  
Microsoft Windows) _could_ ensure that real resources are used
only when and where necessary.

--

Mine of Information Ltd,  PO BOX 1000,  St Albans AL3 5NY,  GB
=== Independent Computer Consultancy * Established in 1977 ===



Sat, 30 Jan 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer


Quote:

> The major weakness I see with Cobol as compared with C is dynamic allocation
> of memory.  It is a serious disadvantage to try and guess how many
> elements to allocate to an array, as apposed to a linked list structure
> with its flexibility.  I can tolerate cobols wordiness, decaring variables

Perhaps the problem is that you are trying to write C programs in
Cobol.  Dynamic memory is one of the areas in C that leads to
serious problems: wild pointers, memory leaks, subtle corruptions,
and is probably the hardest area in programming to get familiar
with.

I have seen C programmers come up with extremely elegent schemes
for contructing dynamic linked lists that were totally inappropriate.
For example one discussion was a mechanism for short-cutting keyboard
input where, for example, while keying in a customer code the
system would try to guess the rest.  This was all being built as
a tre structure in memory.  Good guesses were saved, bad guesses
were refined.

A complete waste as the whole point was that _many_ people were
entering these codes.  The memory tree structure was private to
each copy of the program and no mechanism had been devised to
share, or even save and recover the work.

A shared file structure was _far_ more appropriate in this case,
and in many other cases.  C programming courses tend to focus
on solving single private, individual problems.  Cobol tends to
be used where problems are shared - an accounting system may be
used by dozens or thousands.

While arrays tend to be fixed in length, the problem set tends
not to be particularly dynamic: invoices have a fixed number of
lines on them, addresses are limited to fit into the address box,

Where there is requirements for more extensive data then it is
usually a function of data analysis: why are you building a
linked list ?  why isn't the data in the correct sequence when
read ?

For example when printing a statement it may be a requirement to
have the transactions in some specific sequence (say the payments
with the matching invoice, but otherwise in date order). It
may seem that this would require a dynamic array (number of transactions
may be large) and a linked list to do the matching.  But proper
data analysis may show that what is _really_ required is a sort
to another file (which would then allow reprints later in the
month as the original file changes with other transactions) or
an alternate key on the transaction file so that the data can
be read directly in the correct sequence.

When most Cobol problems are thought through fully the need for
dynamic arrays usually disappears, which is why they are not part
of the language.  If you feel you need them, go and review the
problem.



Sat, 30 Jan 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer


Quote:
>I've just started programming cobol on a Vax (about a month now).

Poor chap. aren't the editors just awful? Gimmie ISPF/Xedit anyday.

Quote:
>It is a serious disadvantage to try and guess how many
>elements to allocate to an array.

It would be interesting to know how many times you would use an array where
you don't know how large to make it. I must admit I used to use them
frequently but as the years went on - and oh, how they went on - the last time
I "maintained" an array was about 4 years ago. I just don't come accross them
much.

Peter.



Sun, 31 Jan 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer

Quote:


>> I don't have experience
>> with MicroFocus COBOL, but you could probably find a documented method
>> for calling the host operating system to acquire a block of storage
>> dynamically.

>Micro Focus COBOL provides the "CBL_ALLOC_MEM" and "CBL_FREE_MEM" calls on all environments.

It's certainly much nicer when the source code can be ported to a
different platform without changes!

Quote:

>> I have always thought it was extremely odd that C has MALLOC and FREE as
>> native functions in the Language.

>This is a bit off topic for a COBOL group, but I just wanted to say that C
>has no "native functions" (possibly with the exception of main()). malloc()
>and free() are (standard) library functions, nothing more.

Chalk this up to my very limited experience with C.  To this old COBOL
programmer, it's hard to distinguish between a language feature of C and
a library of standard functions for C.  I guess the real question is, how
are malloc() and free() implemented for a particular platform, and how
much storage protection do you get?

Quote:
>> It seems more logical to me for the
>> operating system to own the storage, rather than the executing
>> program.

>I don`t quite understand what you`re saying here. If the memory pool doesn`t
>exist within the virtual memory space of an individual process, then logic
>errors that overwrite memory not allocated can have severe consequences on the
>whole of the machine, not just the process that is in error.

0>Cheers, Kev.

>--


This is probably a perception problem on my part, given that most of my
experience is in an IBM Mainframe environment.  Perhaps I should have
said that storage protection is better performed by the operating system
than by the programmer.  I have to admit that I'm no expert on how
storage protection is actually achieved, but I'm glad it's there.

It is generally pretty difficult to explicitly allocate memory
dynamically from a COBOL program.  That might be a real limitation in
the language, but I think it's more of a safety feature.  

Thank you for your comments!

Arnold Trembley
Software Engineer I (just a job title, still a programmer)
MasterCard International
St. Louis, Missouri



Sun, 31 Jan 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer

Quote:



> >> I don't have experience
> >> with MicroFocus COBOL, but you could probably find a documented method
> >> for calling the host operating system to acquire a block of storage
> >> dynamically.

> >Micro Focus COBOL provides the "CBL_ALLOC_MEM" and "CBL_FREE_MEM" calls on all environments.

> It's certainly much nicer when the source code can be ported to a
> different platform without changes!

True, but when the language doesn't define things like this which people (think
they) need, it's up to vendors to provide these things the best way they can,
and this means proprietary library functions. With the exception of Intrinsic
Functions, the language does not define any library routines.

In the case of dynamic memory, though, it should be generally trivial to
implement one vendor`s call in terms of another`s, making porting simpler.

Quote:
> To this old COBOL
> programmer, it's hard to distinguish between a language feature of C and
> a library of standard functions for C.

With C, the language itself (in terms of reserved words and control flow) is
very small indeed (certainly in respect to COBOL), and nearly everyhing you do
that isn't based around simple flow of control and native object manipulation
(by that I mean bytes, words and longwords) is achieved by calling a set of
(standardised) library functions. Unlike COBOL, a lot of effort goes into
standardizing these libraries rather than adding new syntax to the core of the
language itself.

Having said that, the same situation occurs as with COBOL, as different C
compiler vendors and operating systems define their own proprietary libraries
in addition to the standard ones.

Quote:
> I guess the real question is, how
> are malloc() and free() implemented for a particular platform,

Depending on the o/s, each call to malloc() or free() could be translated
directly onto an o/s function or the library could maintain it's own free memory
pool and add "pages" to that as required by calling the o/s.
So I guess the answer is "it depends". It`s still something the programmer does
not have to worry about though.

Quote:
> and how
> much storage protection do you get?

That`s not a requirement of the library - it depends on the operating system and
specific implementation of malloc() and free() being used.

Quote:
> >I don`t quite understand what you`re saying here. If the memory pool doesn`t
> >exist within the virtual memory space of an individual process, then logic
> >errors that overwrite memory not allocated can have severe consequences on the
> >whole of the machine, not just the process that is in error.

> This is probably a perception problem on my part, given that most of my
> experience is in an IBM Mainframe environment.  Perhaps I should have
> said that storage protection is better performed by the operating system
> than by the programmer.

Oh, OK, we`re saying the same thing in different tongues - in the systems I was
thinking about, the operating system gives a process a virtual memory space (and
memory protection) and the malloc/free calls operate *within* that virtual
memory space (with no defined standard for memory protection). Therefore, a
process running amok will not affect the o/s or other unrelated processes, but a
program running amok has every chance of corrupting it's internally-managed
memory pool and causing the process to die.

Cheers,
Kev.
--

These views are strictly my own. I doubt that anyone else would want them.
STUFF FOR SALE: <A HREF="http://www.mfltd.co.uk/~ked">Here!</A>



Sun, 31 Jan 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer

Quote:

> (explanation of why COBOL programmers usually don't need dynamic
>  memory)

For those remaining occasions when a programmer just has to have a
dynamically growing data structure, COBOL97 will have a standard library
with lists, dictionaries, dynamic arrays, etc.  Even though C++ has
similar library objects, you still have to monkey around with dynamic
memory because of operator overloading, which thankfully COBOL97 does
not allow.  Thus, there will never be a need for COBOL programmers to
explicitly allocate memory.


Tue, 02 Feb 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer

Quote:

>If sombody has some way I don't know of to dynamically allocate memory I'd
>love to hear it.  

I agree with everyone who has answered your request with "you probably
don't need it as badly as you think", but here's how to do it on a
VAX.

identification division.
program-id. vmdemo.
data division.
working-storage section.
  1 bytes-needed pic 9(9) binary value 20.
  1 mem-addr pointer.
  1 return-code pic s9(9) binary.
  1 somedata pic x(20) value "some data".
  1 someotherdata pic x(20) value all "x".
procedure division.
begin.
* allocate some memory
    call "lib$get_vm" using bytes-needed mem-addr giving return-code
    perform check-status
* put something into it
    call "lib$movc3" using bytes-needed somedata by value mem-addr
      giving return-code
    perform check-status
* move contents to someplace else here in cobol-land
    call "lib$movc3" using bytes-needed by value mem-addr
      by reference someotherdata giving return-code
    perform check-status
* show that it worked
    display someotherdata
* deallocate the memory
    call "lib$free-vm" using bytes-needed mem-addr giving return-code
    perform check-status
    stop run.
check-status.
* if call fails, bomb program with error code translation    
    if return-code is failure
        call "lib$stop" using by value return-code
    end-if.

Obviously this depends on OpenVMS COBOL extensions and VMS system
calls. The extensions are the usage POINTER which actually is a VAX
longword -- I suppose that pic 9(9) binary (or comp) would work as
well, but POINTER certainly documents the usage correctly.

IF ... FAILURE is true if the return-code is even, the opposite is a
test for SUCCESS which is true for odd return-codes.

Finally it's in terminal format so if you try to compile it, you may
need the /NOANSI compiler switch (default most everywhere).

The use of lower case, no leading zeros on level numbers, and usage
BINARY instead of COMP are personal choices and not language
extensions.

George Trudeau, Systems Analyst (COBOL!), Town of Falmouth


Visit us at http://www.town.falmouth.ma.us/



Wed, 03 Feb 1999 03:00:00 GMT  
 Thoughts of a new Cobol Programmer


Quote:


>>If sombody has some way I don't know of to dynamically allocate memory I'd
>>love to hear it.  
>I agree with everyone who has answered your request with "you probably
>don't need it as badly as you think", but here's how to do it on a
>VAX.

        etc.

There's a related technique that is a bit more Cobol-user-friendly (though
limited in some ways as well). That is to have a jacket routine that can
allocate the memory array, then call by value into a routine that uses
declares the parameter as a passed array.  The by-value call supplies the
pointer and the subroutine then uses the "dynamic" array with normal Cobol
statements, no need to move memory around.

Haven't tried it on an Alpha but would think it works the same.

--

Mgr. Software Engineering        Voice:  (US) 540/967-0087
ARAMARK Mag & Book Services      



Mon, 08 Feb 1999 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. What's new *and* interesting for IBM mainframe COBOL programmers - in the next COBOL Standard

2. COBOL programmer, learning a new language, which one.

3. new book: CICS for the COBOL programmer

4. New Orleans COBOL Programmer Opportunity

5. COBOL Programmers needed for new division in Atlanta

6. JOBS: New York, Tandem/Cobol programmers

7. Job openings Cobol, CICS, VSAM Programmers in New York City

8. Job openings Cobol, CICS, VSAM Programmers in New York City

9. New COBOL programmer needs help!

10. COBOL programmers needed in New Jersey

11. Fortran/COBOL/MVS programmer wanted - New Jersey

12. Contract Clarion Programmer and Contract Cobol Programmer/Analyst

 

 
Powered by phpBB® Forum Software