pjfarley3 wrote:
On May 1, 5:11 pm, LesWagner <[email protected]> wrote:
We are belatedly beginning for the third time, an Cobol II to
Enterprise Cobol batch conversion and are encountering problems with
linking above the line, Cobol programs that call assembler
subroutines. The solution being proposed is to continue to call the
assembler routines statically, and link the ECBL programs below the
line. This requires the least amount of recoding.
Are we losing anything important in implementing this solution?
What do we need to do to get this above the line?
Anything else we should be worrying about?
Leslie Wagner
CC'ed to the IBM-MAIN mailing list, where you will get many more
answers than just on the usenet list or google group.
To answer your questions in order, (1.a) you lose the ability to
expand internal tables to take advantage of above the line storage and
(1.b) you lose in having to re-link EVERY module that uses one of the
24-bit routines whenever it changes, and (1.c) you lose in not being
able to reduce elapsed time by increasing buffers below the line
(because all your code is now above the line), or by taking advantage
of moving buffers above the line (for VSAM, at least).
(2) The solutions to this problem that I have seen at several large
enterprises is to interpose a "helper module" between the newer above-
the-line programs and the legacy below-the-line assembler code. There
are several ways of doing this, from the most general (one "helper"
for all 24-bit programs, most efficiently a new assembler module) to
the most specific (a separate 31-bit "helper" for every 24-bit
module). The general idea is that the "helper" module is compiled
with DATA(24) (or AMODE ANY/RMODE 24 for assembler) while the calling
COBOL programs are compiled with DATA(31). The "helper" module moves
the 31-bit parameters to its own working-storage below the line (or to
dynamically obtained below-the-line storage for assembler) and calls
the 24-bit module with it's local 24-bit copies of the passed
parameters, and re-copies the 24-bit versions back to the 31-bit
passed parameters after the call completes. Obviously the "helper"
module(s) needs extra information to do its (their) job (like the name
of the 24-bit module and the number and length of each passed
parameter), so some recoding of the calling COBOL programs is a
requirement of using this solution.
Any of these solutions requires some program changes to every 31-bit
program that calls 24-bit code. I'm afraid any solution that avoids
recoding also avoids getting most of the benefits of converting to 31-
bit in the first place. You just have to bite the bullet and make
some coding changes as you convert, one program at a time. One at a
time is the key, with good "helper" module(s) you can convert in
phases instead of all at once.
The advantages of a "helper" module, are (2.a) that the calling
programs now reside above the line and can use the larger storage area
there for larger tables, etc., while still being able to dynamically
call their 24-bit assembler subroutines; (2.b) the 24-bit subroutines
do not have to change; (2.c) if they do change but still stay below
the line, your new 31-bit code is unaffected and does not need to
change or be relinked.
You really, really want to avoid static links and DATA(24) as much as
you can. The maintenance nightmares of static links are enough to
drive any rational programmer (and their managers) to drink. And IMHO
using DATA(24) removes much of the incentive to do the conversion in
the first place. But that's just my USD$0.02 worth.
HTH, and please feel free to email me privately if you want to discuss
the pros and cons offline. I live in Brooklyn, so your problems are
of great interest to me and I'd love to help you solve them
efficiently and within your budget.
Peter
Our biggest reason for converting to 31bit COBOL was CICS.
Most of our batch COBOL programs aren't big enough to be
constrained by out 24bit region size (approx 11MB), but in
CICS we would have frequent Short On Storage problems.
I think there may also be some (probably small) performance
gain by using the ALL31(ON) option in LE. It reduces the need
for AMODE switching.
If you want to convert to 31bit, the first thing I would look
at is if some/all of the assembler routines might be replaced
with COBOL routines and/or LE callable services.
Any that can't be replaced might be easily converted to 31bit.
It has been quit awhile now, but as I recall the two biggest
issues we had were assembler routines that did I/O (DCB's have
to be below the line), and address fields with flags in the
high order byte. Most of our assembler routines didn't have any
problems, and after checking them could just be relinked to
AMODE/RMODE 31.
One set of routines did I/O. They were re-entrant, so I modified
the getmain to make sure the storage for the copied DCB was
below the line. I also added a DCBE so the EODAD could be above
the line.
--
Richard
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
