A program can monitor the status of a connection in either of two ways: by using the STATE connection attribute or the CHANGE library attribute.

Checking the Current State

The STATE attribute is a read-only attribute that returns the current state of a connection. The possible mnemonic values are NOTLINKED, LINKING, LINKED, or DELINKING. The following ALGOL statement checks the state of connection 4 of connection library CL1:

IF LIBRARY(CL1[4]).STATE = VALUE(LINKED) THEN...

Notification of Changes

The STATE attribute returns the current state of a connection at the time that you interrogate the attribute. By contrast, the CHANGE attribute allows you to arrange for automatic notification whenever any connection happens to change state.

CHANGE Procedure

The CHANGE attribute specifies the name of a procedure called the CHANGE procedure. You must implement this procedure yourself, including the standard set of parameters. The CHANGE procedure, if there is one, must be declared within the connection block of the connection library.

Transition to New State

Whenever the linkage state of any connection to the library changes, the system calls the CHANGE procedure. Note that the connection cannot fully transition to the new state until the CHANGE procedure exits. Therefore, when you design a CHANGE procedure, you should be careful to ensure that the CHANGE procedure exits quickly. For example, the CHANGE procedure should not wait for a port file read or for an event that might never be caused.

Dual CHANGE Procedures

When a particular connection changes state, there can be two different CHANGE procedures involved: one associated with the requesting library and one associated with the responding library. The requesting library is the library that caused the linkage or delinkage. The responding library is the library on the receiving end of the linkage or delinkage. Note that the library that is requesting during the linkage process might be responding during the delinkage process, and vice versa. The CHANGE procedure declared by the requesting library is executed before the CHANGE procedure declared by the responding library.

Parameters to CHANGE Procedure

The system passes the following information as parameters to the CHANGE procedure:

Results Returned by CHANGE Procedure

The CHANGE procedure can read the parameter values, but does not return any value itself. However, the CHANGE procedure can modify globally-declared objects in the connection library program where it is declared. These objects can include event variables. These modifications can be used to inform the connection library of the change in linkage state.

For a description of the CHANGE procedure, refer to the discussion of the CHANGE library attribute under Using Library Attributes later in this section.

CHANGE Procedure Example

The following ALGOL statements declare a connection library called CL1 with a CHANGE procedure called CL1_CHG. An underlying assumption is that each connection of the library might be linked to and delinked from repeatedly. The CL1_CHG procedure increments the value of connection object LINKNUM each time a process completes linkage through that connection. Note that, because LINKNUM is declared in the connection block, the system creates a separate instance of LINKNUM for each connection. Each instance of LINKNUM thus keeps a running count of the number of times that connection has been used to link to CL1.

INTEGER GLOBALINT;
REAL RSLT;

TYPE CONNECTION BLOCK TEST1;
   BEGIN

   INTEGER LINKNUM;
   PROCEDURE CL1_CHG (CONN_INDEX, NEW_STATE, REASON, ACTOR, IMDSED);
         VALUE   CONN_INDEX, NEW_STATE, REASON, IMDSED;
         INTEGER CONN_INDEX, NEW_STATE, REASON;
         TASK    ACTOR;
         BOOLEAN IMDSED;
      BEGIN
      IF NEW_STATE = VALUE(LINKED) THEN
         LINKNUM:= * + 1;
      END;

   PROCEDURE PROC1;
      BEGIN
      % Procedure body statements
      END;

   EXPORT PROC1;
   END;

TEST1 LIBRARY CL1 (INTERFACENAME=“CLTEST.”, CONNECTIONS = 10,
                   CHANGE = CL1_CHG);

RSLT:= READYCL(CL1);

Note that the CL1_CHG procedure in the preceding example updates only a connection object. If CL1_CHG updated a global object (such as GLOBALINT in the preceding example), then the possibility would arise that more than one invocation of CL1_CHG might be attempting to update the global object at the same time. To prevent updates from overwriting each other, you would need to add a timing mechanism involving the use of PROCURE and LIBERATE statements and a shared global event.