From: "Pete Dashwood" 

Richard wrote:
> On Jan 25, 12:19 am, "Pete Dashwood"
>  wrote:
>> Here's a couple of intellectual exercises if anyone is bored or
>> wants to think about something else for a break...
>>
>> Two problems relating to COBOL... (Assume Fujitsu NetCOBOL for both
>> solutions, or whatever version of COBOL you use if you can solve
>> them with your current compiler.)
>>
>> 1. Imagine you have a couple of thousand COBOL programs, all written
>> in ANSI 74 procedural COBOL. Almost every one of these programs
>> makes static calls to a number of subroutines (say there are around
>> 20 of these subroutines).
>>
>> sample call : CALL "X1" using p1, p2, p3, p4.
>>
>> Obviously, because of the static linkage, there is HUGE duplication
>> of these subroutines throughout the environment. (Every other
>> program has the same subroutines statically linked into it, and some
>> of these "subroutines" are "large"...)
Changing any of the called
>> routines means a nightmare of identifying and recompiling every
>> program that uses it.
>>
>> For reasons connected with a new environment, you need these
>> routines to be dynamically called, but you cannot change all the
>> calling programs. (In fact, the client has insisted that the calling
>> program code must remain EXACTLY as it is.)
>>
>> Can you get to a dynamic environment WITHOUT recoding or amending the
>> calling programs?
>
> That is not a COBOL problem but is an implementation issue. Given that
> all CALLs would have to be using a literal to get static linkage then
> it is a matter of specifying the compiler and linking options
> applicable to the particular system being used. For Fujitsu it is
> DLOAD. Recompile and relink as a set of libraries and main program(s).

Yes, that is good. But you forgot to mention the ENTRY file that equates the 
entry point to a .DLL at run time.

DLOAD implements "dynamic program linkage" (as opposed to
"dynamic linkage") 
and is a Fujitsu facility that allows the static calls to be processed 
dynamically at run time, via an ENTRY file which equates the entry points ot 
the respective libraries.

>
> Anyway, identifying the calling programs is not a 'nightmare', a
> simple 'grep -i "call \"name\"" *.cbl' will pick
them up because with
> static linking the CALL must be of a literal.

As the site in question doesn't HAVE grep or an equivalent facility, for 
them, it is a nightmare.

>
> With dynamic linking there may be a problem because the CALL can be a
> variable and the name may come from anywhere:

That's why the ENTRY file is important.


> in the case of most of
> my systems they can come from a system file that holds the menus and
> options, or can even be typed in directly.

The Fujitsu ENTRY file is a text file that can be managed externally in a 
similar way. The PRIMA Toolset analyses any .DLL you specify and generates 
this file for you.

>
>
>> 2. You are replacing a service routine (a called program, not in
>> COBOL) with a new routine, in COBOL. The new routine has the same
>> signature as the old one and receives several parameters from the
>> calling programs. Here is its signature:
>>
>> procedure division using
>> p1, p2, p3, p4.
>>
>> p1, p3, and p4 are always the same type and length.
>>
>> But, p2 can vary in length (it is a record buffer). It could be
>> defined in the working storage of each calling program as anything
>> from 20 to 8000 bytes. (Not with OCCURS... DEPENDING, just different
>> fixed length records.)
>>
>> Your called routine has to update this buffer; if you set a wrong
>> length in the Linkage section you will immediately crash on a
>> storage violation as soon as you try to write the record back.
>>
>> You might think it is pretty easy to pass a record length or some
>> other clue) as another parameter. Nope. The same rules as above; you
>> cannot modify the existing code, and it doesn't have a "p2-length"
>> in its parameter list.
>>
>> Clue: You MIGHT be able to derive the p2 length from an existing
>> "dictionary", accessible by your new program.
>>
>> Any thoughts on how the called program could be coded to accommodate
>> these requirements?
>
> You do it exactly the same way as the original (non-COBOL) program
> does currently.

No. The existing (non-COBOL program) has facilities that COBOL doesn't have, 
so you CAN'T do that.

No more clues... :-)

Pete.
-- 
"I used to write COBOL...now I can do anything." 



--- Internet Rex 2.29