Re: linking to libraries on A series
- From: Paul Kimpel <paul.kimpel@xxxxxxxx>
- Date: Sun, 14 Dec 2008 13:49:13 -0800
On 12/13/2008 1:25 AM, dvdconroy@xxxxxxxxxxxxxx wrote:
On Dec 10, 12:44 am, HVlems <hvl...@xxxxxxxxxx> wrote:On 9 dec, 07:48, One Second Burden <1SecBur...@xxxxxxxxx> wrote:
On Nov 3, 6:02 am, Paul Kimpel <paul.kim...@xxxxxxxx> wrote:Binder also allows replacement of procedures with a newer version.I loved that you could also redirect which library was used at runYou link to library either by title (file name) or by function (the function
name to file title is established through the SL command). By title is easier
during program development, and by function is easier when the program is in
production, because you don't have to recompile to point it at a different
file.
time, the same as you could for files. Such a nice feature. Not to
mention that all library linkages and attempted linkages, as well as
file opens and closes, were logged, so it was quite easy to find out
what a program did.
So elegant. So much nicer than what is available on modern systems.Both of these are declared in the program source, the exact syntax beingi.e., what initiates it?
language dependent. Some languages cannot directly talk to system libraries
(like C), and you need to write a jacket library to translate parameters and
results from one environment to the other.
An A series library is akin to a Windows DLL, BTW, not a Windows .lib file.
The answer is: on first reference. There is no explicit library linkage
call, at least in COBOL (there are some explicit linkage controls
available in Algol, but these are normally used only with connection
libraries). The first time a program calls an entry point in a server
library, the MCP traps the call, checks for compatible parameter
sequences, sets up the address linkage, and restarts the call.
Subsequent calls suffer only a one-level address indirection, which is
handled by the hardware without further MCP involvement.
The Binder is something like a link editor on other systems -- itAs I recall, Binder tended to only be used in mixed-language
combines separately-compiled object files into a single executable. It
is a form of compiler. In my experience, it hasn't been used much since
libraries came along almost 30 years ago, except perhaps in FORTRAN and
C environments. Libraries are so easy to use and so efficient that MCP
applications tend to use those instead.
environments, and the most common of these was when the primary
program is written in C (or, in the old days, Pascal) for portability,
and then support libraries needed to be written in ALGOL to handle
various things.- Tekst uit oorspronkelijk bericht niet weergeven -
- Tekst uit oorspronkelijk bericht weergeven -
This removes the need to
recompile large, complex programs. Very useful and *SYSTEM/BINDER
really is your friend if
somebody lost the sources of a program that needs maintenance and all
you have is the printed
version. Now you only have to enter the procedure(s) that need
changes!
And yes, it allows a programmer to select programming languages that
are best suited for each part of a program.
Say, Fortran for handling complex numbers (before type COMPLEX was
introduced in Algol), Cobol for file handling and Algol for the rest.
Very very useful tool!
Hans- Hide quoted text -
- Show quoted text -
Please see my comments in context below:
Yes furthur to this entry-COBOL 85 implementation supports multiple
entry points.
does the DCILibrary also does that? and why do we have seperate entry
points named as dcientrypoint1,dcientrypoint2 in the code?
I'm not familiar with these references to DCIENTRYPOINT1 and -2. Which DCILibrary interface are you referring to -- the ANSI COBOL-74 standard one that is related to the COMMUNICATIONS SECTION, or the one that is supported by Transaction Server (COMS)? Is this something you are seeing in the documentation or in an existing program?
as also can we-- not declare library procedures in ALGOL and still
explicitly bind and use the library?
I am not completely sure what you are asking here, but in Algol, everything must be declared before it can be referenced. Whether procedures are dynamically bound from a server library or statically bound using the BINDER, they still must be declared in the calling program (although using somewhat different syntax). The reason for this is that the system needs to know the data types and sequences of parameters so that it can validate that the caller's representation of the procedure interface is compatible with the way it was declared by the callee.
Are these defintions of procedures only needed for byfunction
libraries and not forbytitle libraries(if I am correct)?
If I understand this question, library procedure entrypoints must be declared in the calling program regardless of the LIBACCESS attribute setting (BYFUNCTION, BYTITLE, or otherwise).
also what is the difference between an agenda and a Processing Item
List.
A Processing Item List is an attribute of an Agenda. An Agenda in COMS defines how a message will be handled once its routing is determined. Agendas may be associated with both input and output messages, but are usually more significant for input.
Input to COMS (except for control messages) is always interpreted in the context of the COMS Window from which it was entered. If COMS recognizes a transaction routing key (a Trancode) in the message, the definition of that Trancode identifies an Agenda for processing the message. If a Trancode is not recognized in the message (or none have been defined in COMS Utility for the Window), a Window can -- and usually does -- have a default input Agenda to which the message will be routed. Multiple Trancodes can be associated with the same Agenda and a Window may have multiple Agendas.
An Agenda has two main attributes: a destination (usually an application Program written to use the COMS Direct Window API) and an optional Processing Item List. The Processing Item List, perhaps obviously, specifies a list of Processing Items. Each Processing Item defines an entry point into a library -- a procedure -- that will be called by COMS prior to the message being delivered to its destination. Since there is a list of these, COMS calls each Processing Item in the sequence specified in the Processing Item List.
A Processing Item entry point can do whatever it wants to the text of message, and has some limited control over the metadata that COMS maintains for the message in the header structure. The output of one Processing Item is effectively piped as the input to the next one. Typical uses for Processing Items are formatting, translating, blocking/unblocking, logging or auditing, and maintenance of session state (usually through the header's Conversation Area). Processing Items are typically written in Algol, although it is possible to write an Algol wrapper routine that can call code written in some other language.
In summary, input arrives for a COMS Window. Trancodes defined for the Window route the input to an Agenda, which in turn defines the destination Program that will process the input. The Agenda optionally defines the Processing Items that will pre-process the input prior to it arriving at the Program.
Output Agendas work in a similar fashion, specifying an output destination (typically either a Program or the station network), and optionally specifying a Processing Item List that will apply Processing Items to the message after the Program does its SEND, but before the message is delivered to its destination. Output Agendas are set in the output header by the sending Program. A Window may have a default output Agenda as well.
much grateful
David
--
Paul
.
- References:
- Re: linking to libraries on A series
- From: One Second Burden
- Re: linking to libraries on A series
- From: HVlems
- Re: linking to libraries on A series
- From: dvdconroy@xxxxxxxxxxxxxx
- Re: linking to libraries on A series
- Prev by Date: Re: make me wiser for the following
- Next by Date: Re: Need advice
- Previous by thread: Re: linking to libraries on A series
- Next by thread: Re: linking to libraries on A series
- Index(es):
Relevant Pages
|
