• Keine Ergebnisse gefunden

INITED UBIN WORD INIT(O), BREAK UBIN WORD INIT(O);

Im Dokument PROGRAMMER GUIDE (Seite 169-175)

Guidelines for Alternate Shared Libraries

A: PROC MAIN;

2 INITED UBIN WORD INIT(O), BREAK UBIN WORD INIT(O);

* *

Define the symbols that correspond the the functions supported by the Alternate Shared library

*

References to the AREADEF structure.

SYMREF

*

Highest defined function code Out of range

Pointer to AREADEF structure Have we been entered before

0,0-Call any ASL initialization routines.

TSX1

*

RET

*

MSINTRTN NOP EXIT

INHIB OFF

*

Issue MSXXX if the user passes a bad function code

*

BADFCN MSXXX END

ASL Capabilities

ASLSENTRY

An ASL has the following special abilities:

• the ability to access the *1 file

• the ability to issue an MSSCREECH monitor service request

• the ability to issue an MSXCONRTN monitor service request

• the ability to issue an MSINTRTN monitor service request.

DCBs for ASL

There are no special DCBs for ASLs. However, an ASL may use the DCBs defined by the user, or acquire his own DCBs using the MSGETDCB monitor service. The XONLY option can be used to disallow user programs from accessing the ASL's DCBs. See the discussion of MSOPEN in the Monitor Services Reference Manual for details.

Addressing User Memory from ASL

Each parameter passed by the call to the ASL corresponds to a vector specified as part of the user's call. When the ASL is entered, the hardware builds a descriptor on the parameter stack associated with each of these vectors. Thus to access the first parameter, the ASL uses a pointer with the SEGID

referencing parameter stack entry zero. The pointers for up to nine

parameters are defined in the module B USRPTRS D. These pointers are SYMDEFed as BSPSOS, BSPS1S, BSPS2S ••• BSPS8S.

-Thus in the exampLe above, to access the memory framed by ASLSVECTORS Y.INPUT , BSPS1S wouLd be used. To access

ASLSVECTORS-Y.V.OPTIONS1, BSPSOS wouLd be used. In the second case a

structure must exist that defines the V area of the ASLSVECTORS Y structure, without the additionaL vectors. (The pointer BSPSOS wiLL point-to

ASLSVECTORS Y.V; using this pointer in combination with the ASLSVECTORS structure wilL not work). This can be automaticaLly generated by the X account tooL FPTCON which converts the V areas of FPT-Like structures for use after a CLIMB has been issued.

If the creator of an ASL defines functions that require more than nine parameters, pointers to these parameters may be built as follows:

DCl BSPS9 UBIN CONSTANT INIT(9);

DCl BSPS9S REDEF BSPS9 PTR;

CE62-00 Addressing User Memory from ASL 11-27

Exit from an ASL

When the ASL has completed its functions, it must return to the user. This is done by performing an outward CLIMB, which restores the user environment and returns control to the user program. Note that this is done in the example above. When the PL-6 routine ASLSROUTINE X or ASLSROUTINE Y simply returns, control transfers to 'RET' in the setup routine which performs the outward CLIMB.

ASL Recovery

The key to ASL recovery is the *1 file. This file can only be accessed from the ASL's domain. The existence of the *1 file causes GHOST1 to associate and call the ASL during the recovery procedure with a function code of 1. It is the ASL's responsibility to write records to the *1 that are useful during the rec'Overy process. As an example, I-D-S/II writes before-images of updates to the' *1 and uses them to back out of partial updates if a deadlock, abort or recovery occurs.

As part of the recovery process, the JIT for each user is written to the dump area of the system disk. After the system has re-booted itself, the system ghost, GHOST1, is entered where further recovery functions are performed. One of these functions is to access the user JITs from the dump area to determine if ASL recovery entry is indicated.

If the disk address of the FIT for the *1 file in the user's JIT is non-zero, that address is moved to the *1 entry of GHOST1's BSJIT.STAR.DA and the file is opened (test mode) in order to locate the FPARAMS. The PROCATTR

information in the FPARAM table (if any) ;s assumed to contain the TEXTC name of the ASL that was associated with the user at the time of the Screech.

This name is then used as the NAME parameter of an MSALIB request. If the ASL has been established as a Special Shared Processor via the SPROC command to TIGR, the ASL is now associated with GHOST1.

GHOST1 then causes entry to the ASL via the CLIMB instruction. No parameters are passed; XO is set to 1. The routine to handle recovery must, therefore, correspond to a function code of 1. At this point the ASL may do whatever is required for closing the data base.

CE62-00 ASL Recovery 11-28

Debugging an ASL

An ASL may be debugged using XDELTA as described earlier in this section.

However, since the interface between the user program and an ASL is through the hardware CLIMB interface and not through the monitor, considerable debugging may be accomplished by linking the ASL object units and the user an intra-domain CLIMB through the user's Instruction Segment descriptor. The difference between an inter-domain CLIMB and an intra-domain CLIMB is as follows. The IC is loaded from the 18-bit entry location contained in the Entry descriptor if the CLIMB is inter-domain, and from the address field of the CLIMB instruction if intra-domain.

In order to make an intra-domain call to an ASL, the actual CLIMB instruction

CALL ASFUNCTION X(ASLSVECTORS X);

CALL ASFUNCTION=Y;

* *

Other external references that are required ENTREF X66 AUTO 1

Default to issue inter-domain Issue intra-domain CLIMB

INTRAO

*

ASLENTSID references an entry descriptor that describes

*

the ASL and already contains the start address of the ASL. following-is an updated version of this interface:

*

ENTDEF ASLSENTRY The ASL start address is ASLSENTRY

* *

* *

Define the symbols that correspond the the functions supported by the Alternate Shared Library

*

Im Dokument PROGRAMMER GUIDE (Seite 169-175)