Linkage Assist circa 1978 
Author Message
 Linkage Assist circa 1978

My assembler background is primarily as a TPF programmer, so I'm a
little puzzled by some ALC  linkage assist programs which were written
in the late '70s thru the mid '80s.  If someone would could explain to
me, in the context of those days, why such modules were written, I'd be
very greatful!

The scenario is this:

A COBOL program executes a dynamic CALL to an assembler program.  Three
variables are passed to the assembler program; an eight character string
which identifies the target module, a full word which contains either
hex zeros or the core address of the target module, and another full
word which doesn't seem to be used.

If the address parameter is hex zeros, the linkage assist program LOADs
the target program specified by the character string parameter, posts
the core address of the target program to the address parameter, and
BALRs to the target program.

If the address parameter is not hex zeros, the linkage assist program
BALRs to the target program.

-------

Is there any value in having such linkage assist programs in today's
Virtual Storage world?



Thu, 13 Dec 2001 03:00:00 GMT  
 Linkage Assist circa 1978
The program you describe is a simple program loader.  If a section of
code is to branched into and it is referenced only by name, it must
first be loaded into memory. This service is performed by the operating
system.  And if a program can be branched into multiple times without
having to be refreshed then it is only necessary to load it once.  That
is the purpose of the test of the address parameter for hex zero. There
is another type of linkage assist program stub which is intended to
allow programs with unknown addressing modes and which do not use the
mode setting instructions to return control to be called. This was as a
result of the introduction of 31 bit machines.


Thu, 13 Dec 2001 03:00:00 GMT  
 Linkage Assist circa 1978

enlightened us:

Quote:
>My assembler background is primarily as a TPF programmer, so I'm a
>little puzzled by some ALC  linkage assist programs which were written
>in the late '70s thru the mid '80s.  If someone would could explain to
>me, in the context of those days, why such modules were written, I'd be
>very greatful!

>The scenario is this:

>A COBOL program executes a dynamic CALL to an assembler program.  Three
>variables are passed to the assembler program; an eight character string
>which identifies the target module, a full word which contains either
>hex zeros or the core address of the target module, and another full
>word which doesn't seem to be used.

>If the address parameter is hex zeros, the linkage assist program LOADs
>the target program specified by the character string parameter, posts
>the core address of the target program to the address parameter, and
>BALRs to the target program.

>If the address parameter is not hex zeros, the linkage assist program
>BALRs to the target program.

>-------

>Is there any value in having such linkage assist programs in today's
>Virtual Storage world?

What you are describing is a technique that was used to save core.
The called Load program was very small so when its object was linked
with the main Cobol program, the resulting object module did not
balloon in size.  The remaining core that was available during
execution of the main program could be used for 1 or more loaded
subroutines.  That is, they could share the same address space.

In this day and age with the advancements in VSE and MVS and core
being much cheaper and much more plentiful, such techniques are seldom
if ever used.

Regards,

          ////
         (o o)
-oOO--(_)--OOo-

         My Law:  You can't fall off the floor

 Steve



Thu, 13 Dec 2001 03:00:00 GMT  
 Linkage Assist circa 1978
However, in addition to saving memory (especially when you mave have
several subroutine some of which almost never get called), the technique
is also useful if you have a common subroutine for several programs that
can change often.

You link the other programs as you would normally except you exclude the
common subroutine.  You link it separately so that you can change it as
needed, and all of the programs will get the current one without needing
to be re-linked themselves.

I have used similiar methods for both purposes.

Lloyd

Quote:

>The program you describe is a simple program loader.  If a section of
>code is to branched into and it is referenced only by name, it must
>first be loaded into memory. This service is performed by the operating
>system.  And if a program can be branched into multiple times without
>having to be refreshed then it is only necessary to load it once.  That
>is the purpose of the test of the address parameter for hex zero. There
>is another type of linkage assist program stub which is intended to
>allow programs with unknown addressing modes and which do not use the
>mode setting instructions to return control to be called. This was as a
>result of the introduction of 31 bit machines.



Thu, 13 Dec 2001 03:00:00 GMT  
 Linkage Assist circa 1978

This is no longer needed. The reason is because this technique is now
the way that COBOL normally works when the program is compiled with the
DYNAM option. When using DYNAM, the "CALL literal" no longer links the
program named "literal" into the load module. Instead a COBOL supplied
subroutine maintains a list of already loaded program and their load
address. When a program is CALLed which is not in this list, the program
is loaded into memory, and its name and address are put into the list.

John



Fri, 14 Dec 2001 03:00:00 GMT  
 Linkage Assist circa 1978
: However, in addition to saving memory (especially when you mave have
: several subroutine some of which almost never get called), the technique
: is also useful if you have a common subroutine for several programs that
: can change often.

Or, if you have sub-routines for individual environments (CICS , Batch ,
ISPF , etc. ).  In this manner, the application coder "just writes the
code" and does not have to concern themselves (much...) with the
environment their program runs in.

At a company where I've worked off and on for the last 25 years, we
developed a stub for just this purpose called: JANUS.  Cute, huh?
It was LINKed with the application program.
Upon the first Call, it would determine the environment it was running
in, LOAD the proper "vector" program for that environment (CICVECT,
BATVECT, etc.), and store the E.P. address of the vector pgm within
itself for subsequent 'fast path' CALLs.
Then, control would be passed to the vector program for further
analysis of what function/procedure was being requested.
It was usable in programs written in any language, and the exact
same module (JANUS) was used across all environments.

Alas, the company was acquired -- the _only_ superior feature of
the acquiring company was that IT WAS LARGER -- and, with the
predictable application of the NIH syndrome, the code base was
neglected and treated with disdain.
It's all gone now.
And, the users within the various departments of the 'old'
company are suffering greatly with severely limiting software
used by the New Compnay.

It appears Darwin was an optimist.

Jonesy
MainFrame since 1966.

--
Marvin L. Jones  jonz<AT>rmi.net
Gunnison, Colorado
186 days to go until the Year 2000 -- So what!
552 days to go until the 3rd Millennium of the C.E.



Fri, 14 Dec 2001 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. MOD or MODE statement, f77 in 1978.

2. Assist me with ASSIST info

3. ANNOUNCE: VisualAge Usability Assist Tool - VA Assist - Free Trial

4. MacForth Circa 1986-1990

5. Quotation from Bob Berkey, circa 1984

6. Standard Fig-Forth - ZX Spectrum circa 1984

7. Hash compression (Hash 'consing') circa 1957

8. Microsoft C, version 4, circa 1985

9. OLD circa 68 COBOL compiler question...

10. VS-COBOL version 1.2 MANUAL (CIRCA 1980)

 

 
Powered by phpBB® Forum Software