1. Introduction

This document describes how a Finite Message Machine (FMM) or a System Support Machine (SSM) is structured using the Multiple Problem Oriented Language (MULTIPOL) and its subsets. These subsets, and other related definitions and terms applicable to FMM and SSM skeletons are dicussed in the following clauses.

2. SOURCE CODE STUCTURE FOR FMMS AND SSMS

When stucturing an FMM or SSM MULTIPOL is used, together with CHILL. Within MULTIPOL are the subset languages described in the following subclauses.

2.1 Program Skeleton Language (PSL)

This provides a uniform structure for the System 12 CHILL programs. It identifies to the MULTIPOL preprocessor the descriptor name for the particular program. The descriptor is used by the preprocessor to access the software Components Libary so that details on the interface used for the program are obtained. As a result, the preprocessor is able to access the Meta Database (MDB) and generate appropriate CHILL statements, for all modes and declarations to support communications via messages to other support machines (FMMs or SSMs).

The use of PSL enables FMMs or SSMs to be stuctured within a defined framework. Basic skeletons that define the framework are available for FFMs and SSMs. The terms FMM skeleton and SSM skeleton apply primarily to to the basic skeletons described in Clauses 3 and 4. The source code for an FMM or SSM is normally arranged in single parent file. If Assembly Language is used to stucture part or all of the FMM or SSM, the source code may be divided into more than one file. However, most FMMs or SSMs will be coded in MULTIPOL and are structured as shown in the following text. FMMS and SSMs are treated in the same way by the MULTIPOL preprocessor Figure 1 shows a simplified sequence of events in the production of an exchange load tape from a MULTIPOL source file.

2.2 CCITT High Level Language (CHILL)

The MULTIPOL language includes certain CHILL statements for which the MULTIPOL preprocessor does contents checks before passing them to the CHILL compiler. The remaining CHILL statements (which, in a typical FMM comprise most of the code) are passed to the compiler, unprocessed.

2.3 Data Manipulation Language (DML)

This language is used to support uniform data requests to the MDB during MULTIPOL preprocessing. The MDB forms part of the Software Development Support System (SDSS) for a System 12 exchange. It provides the Data Base Administrator (DBA) with the means for insertion, modification and deletion of data model definitions in the MDB in response to user requests for data structures or as part of the DBA managment function.

                        -----------------------
                        |  MULTLPOL PROGRAM   |
                        |                     |
                        |        FOR          |
                        |       CHILL         |
                        |     FMM or SSM      |
                        -----------------------
                                   |
                                   |  MULTIPOL SOURCE
                                   |
                            ----------------
MDB ------------------------| MULTIPOL     |
(STANDARD DATA DEFINITIONS) |              |
SCDL------------------------| PREPROCESSOR |
(MESSAGE DEFINITIONS)       ----------------
                                   |
                                   |    CHILL SOURCE
                            ----------------
                            |     CHILL    |
                            |   COMPILER   |
                            ----------------
             ASM MODULES (IF ANY)  |    RELOCATABLE BINARY CODE
                   |               |
                   |        ----------------
                   |        |   LINKAGE    |
                   |--------|   EDITOR     |
                            ----------------
                                   |
OPERATING SYSTEM ROUTINES          |    GSM       OTHER FMMs or SSMs
      AND SSM               ----------------                |
         |                  |   SEGMENT    |                |
         |------------------|              |----------------|
                            |   MAPPER     |
                            ----------------
                                   |
                                   |    GLS
                                   |
                            ----------------
                            |   SYSTEM     |
                            |   BUILDER    |
                            ----------------
                                   |
                                   |
                                   |    EXCHANGE LOAD TAPE

The access rights model and the data submodel definition for the program, are accessed in the MDB to verify that data requests in DML are valid. If a data request is valid, the correct CHILL statements are generated. These statements include calls to the Database Management System, which, at run time, will execute the required data manipulation in the System 12 data base for the related processor.

2.4 Operating System Nucleus Language (OSNL)

This language is used to access operating system functions for message handling. When an OSNL statement is encountered by the MULTIPOL preprocessor, the Software Components Description Libary (SCDL) descriptor is checked. If the request is valid for the message identified, the necessary CHILL statements are generated including call statements to the Operating System Nucleus (OSN) procedures.

2.5 Use of Skeletons - General

Because FMM and SSM skeletons both use PSL, there are a number of common features. These are described in the following subclauses.

2.5.1 Descriptor Name

In both skeletons, there is a statement that identifies the descriptor to be used for the FMM or SSM. This statement includes the Partitioned Data Set (PDS) member name in the following format:

IIIIVVXX

The IIII characters are replaced with the base 20 four-letter equivalent of the number of the descriptor. When a skeleton is complete, this is replaced by the appropriate base 20 number but with the Product Change Status field set to joker characters XX. An example of how a number is converted is shown below:

• The decimal number 37061 converts to 4 12 13 1 (base 20)

By using the following table the base 20 number is then translated to become FPQB.

2.5.2 Identifier Names

FMMs and SSMs both contain identifiers that are in accordance with the Software Development Rules. The following constraints apply to the use of identifier names:

• Each identifier must be given the correct initial letter, followed by an underscore. The letter indicates the identifier type (e.g.,M indicates system mode, P indicates procedure).
• When referencing the MDB or SCDL for data structures or source components (e.g., mode definitions and SSM descriptors) the identifier must have a name that is compatible with the name used by the MDB or SCDL.
• Names given to the supervisor and application parts of an FMM must be the same as the supervisor and application names specified in the associated Interface Description Language (IDL) program.

Many of the identifiers used must include the identity of the source file in which they are declared. The characters IIII are used in this document to represent the file identity. In each case, the IIII characters are replaced by the base 20 four-letter equivalent of the source file number.

All identifiers normally end with a descriptive name that is preceded by an underscore but in some cases this is optional. In this document, this descriptive name is represented by "name". An example is where the application module of an FMM has in the skeleton, the identifier, H_A_IIII_name. If the source file has the number 211 12345 PQRS this number will become H_A_BMVG_name in the coded FMM.

2.5.3 Access to Data Base

Access to the data base from an FMM or an SSM is by the Data Manipulation language (DML). To gain access, a Data Sub Model Definition (DSMD) is invoked by a DML command in the following format:

INVOKE DSMD Y_name

The data relations listed in the DSMD can then be manipulated using the DML primitivies. An alternative version of the INVOKE command is:

INVOKE RELATION (< relation name list >);

This version lists directly the data relations to which access is required.

To access data modes or synonyms that are defined in the data base, two further types of the INVOKE command are used:

INVOKE MODE (< mode list >);
INVOKE SYNONYM (< synonym list >);

These commands give the name of the mode or synonym to which access is required.

3. FMM SKELETON

Figure 2 shows the basic structure of an FMM and the types of CHILL and POL statements allowed at various points within the PSL framework. Upper case characters are used for PSL statements, and for CHILL and MULTIPOL key words. Lower case characters are used for such items as labels, which are used within the FMM where needed. Each skeleton has the following elements, some of which are not shown in the figure.

DEFINE_FMM USING DESCRIPTOR IIIIVVXX;
app_mod: APPLICATION_MODULE;


                                   |-----------------
CHILL and POL                      | NEWMODE
statements                         | SYNMODE 
allowed                            | INVOKE mode
                                   | INVOKE synonym
                                   | SEIZE
                                   | SYN
                                   | INCLUDE
                                   |-----------------

app_proc: APPLICATlON_PROCESS
                                   |-----------------
CHILL and POL                      | Any CHILL
statements                         | Any DML
allowed                            | Any OSNL
                                   |   (but not WAIT_CASE
                                   |    for basic messages)
                                   |-----------------
             END app_proc;
          END app_mod;
 sup_mod: SUPERVISOR_MODULE;

                                   |-----------------
CHILL and POL                      | NEWMODE
statement                          | SYMODE
allowed                            | INVOKE mode
                                   | INVOKE synonym
                                   | SEIZE
                                   | SYN
                                   | INCLUDE
                                   | DCL
                                   |-----------------

sup_proc: SUPERVISOR_PROCESS;
                                   |-----------------
CHILL and POL                      | Any CHILL
statements                         | Any DML
allowed                            | Any OSNL
                                   |-----------------
          END sup_proc;
                                   |-----------------
CHILL and POL                      |
statements                         | GRANT
allowed                            |
                                   |-----------------
        END sup_mode;
END_FMM;

1. A header comment that identifies the FMM and briefly outlines its functions, (not shown).
2. A change history comment block, (not shown).
3. A PSL statement in the following form identifying the FMM descriptor to be used:
   

   DEFINE_FMM USING DESCRIPTOR IIIIVVXX;

   The descriptor is decribed in Subclause 2.5.1.
4. An optional applications module is also available having the following parts:
   • The PSL statement

     H_A_IIII_name: APPLICATION_MODULE;

   • Statements, in accordance with Clause 5. that define connections of the application part of the skeleton to other software items, and local mode definitions applicable throughout the application part.
   • The PSL statement

     G_A_IIII_name: APPLICATION_PROCESS;

     The label G_A_IIII_name, is the same as the used in the application statement in the FMM descriptor.
   • Declarations of data used by the application processand possibly an INVOKE statement for a DSMD. For more information refer to Subclauses 2.5.3 and 3.1.
   • Definitions of each of the procedures that are local to the application part of the FMM. These are coded in CHILL and may also include DML and POL statements. Each procedure will start with a PROC statement and finish with an END statement, in accordance with normal CHILL syntax.
   • A definition of the main part of the application process, which has statements in CHILL and, if needed, in DML or POL.
   • The statements

     END G_A_IIII_name;
     END H_A_IIII_name;

5. A supervisor module comprising:
   • The PSL statement

     H_S_IIII_name: SUPERVISOR_MODULE;

   • Statements, in accordance with Clause 5, that define the connections of the supervisor part of the skeleton to other software items and local mode definitions applicable throughout the supervisor part.
   • Declarations of data used in the supervisor process and possibly INVOKE statements for DMSD, data base relations or modes. For more information refer to Subclauses 2.5.3 and 3.1.
   • The PSL statement

     G_S_IIII_name:  SUPERVISOR_PROCESS;

     The label, G_S_IIII_name, is the same as the < CHILL identifier> used in the supervisor statement in the FMM descriptor.
   • Definitions of each procedure that is local to the supervisor process. Each procedure coded in CHILL, starts with a PROC statement and finishes with an END statement. DHL or POL statements can be added if needed.
   • A definition of the supervisor process structure which comprises action statements in CHILL, and if needed in DML or POL.
   • The PSL statements

     END G_S_IIII_name;
     END H_S_IIII_name;

   • The PSL statement

     END_FMM.

3.1 FMM Data Areas

data area A see Subclause 3 (4).

data area B see Subclause 3 (5).

Data area A defines data for the application part only and is replicated for each instance of the applications process. There is only one copy of data area B, which defines data for the supervisor part of the skeleton.

Each data area may have CHILL declarations for local data and, if required, a DML INVOKE statement which allows access to the data base.

4. SSM SKELETON

Figure 3 shows the basic structure of an SSM and Figure 4 shows its constituent parts. The figures also show the type of CHILL and POL statements allowed at various points in the PSL framework. Upper case characters are used for PSL statements and for CHILL and MULTIPOL keywords. Lower case characters are used for such items as labels which are used within the SSM as needed. Each skeleton has the following elements, some of which are not shown in the figure.

DEFINE_SSM USING DESCRIPTOR IIIIVVXX;
ssm_reg: SSM_REGION;
                             |----------------------
CHILL and POL                | NEWMODE
statements                   | SYNMODE
allowed                      | INVOKE mode
                             | INVOKE synonym
                             | SEIZE
                             | GRANT
                             | SYN
                             | INCLUDE
                             | DCL
                             | CLOCKED_PROC
                             | INTERRUPT_PROC
                             | EVENT_HANDLER
                             |----------------------
                 END ssm_reg;
ssm_mod: SSM_MODULE;
                             |----------------------
CHILL and POL                | NEWMODE
statements                   | SYNMODE
allowed                      | INVOKE mode
                             | INVOKE synonym
                             | SEIZE
                             | GRANT
                             | SYN
                             | INCLUDE
                             | DCL
                             | CLOCKED_PROC
                             | INTERRUPT_PROC
                             | EVENT_HANDLER
                             | INTERFACE_PROC
                             |----------------------
                  END ssm_mod;
END_SSM;

proc_name: CLOCKED_PROC ();
                           |---------------------
CHILL and POL              | Any CHILL statement
statements allowed         | TRANSMIT_BASIC_MSG
                           |         OR
                           | TRANSMIT_DIRECTED_MSG
                           |---------------------
END proc_name:

proc_name: INTERRUPT_PROC ();
                           |---------------------
CHILL and POL              | Any CHILL statement
statements allowed         | TRANSMIT_BASIC_MSG
                           |         OR
                           | TRANSMIT_DIRECTED_MSG
                           |---------------------
END proc_name:

proc_name: INTERFACE_PROC (< parameters >)
           RETURNS (< mode >);

                           |---------------------
CHILL and POL              | Any CHILL
statements                 | Any DML
allowed                    | Any OSNL
                           |    (but no WAIT_CASE
                           |     for basic messages)
                           |---------------------
END proc_name:

proc_name: EVENT_HANDLER ();
                           |---------------------
CHILL and POL              | Any CHILL statement
statements allowed         | TRANSMIT_BASIC_MSG
                           |         OR
                           | TRANSMIT_DIRECTED_MSG
                           |---------------------
END proc_name:

1. A header comment which identifies the SSM and gives a short description of its functions, (not shown).
2. A change history comment block, (not shown).
3. A PSL statement in the following form, identifying the SSM descriptor to be used:

   DEFINE_SSM USING DESCRIPTOR IIIIVVXX

   The descriptor is described in Subclause 2.5.1.
4. A MULTIPOL and CHILL region, for procedures where mutual exclusion is to apply, that comprises the following items.
   • The statement

     H_R+IIII_name: SSM_REGION

   • Statements in accordance with Clause 5, that define connections of the REGION to other software items and local mode definitions applicable throughout the REGION.
   • A common data area containing CHILL data declarations and, if required, a DML INVOKE statement in the form described in Subclause 2.5.3. The following facts should be noted:

     MULTIPOL, generates INVOKE MODE statements automatically for all the parameter modes (other than built-in CHILL modes) for each interface procedure defined in the REGION. These INVOKE MODE statements do not appear in the source code.

     If any procedure in the REGION transmits messages, a pointer to the message buffer has to be declared as shown:

     DCL T_MSG_BUF PTR;

   • Definitions of any procedures local to the REGION, that are in normal CHILL syntax.
   • Definitions of each of the externally accesible procedures in the REGION. These procedures start with the related PSL statement, that is:

     P_IIII_name: EVENT_HANDLER ();
     P_IIII_name: INTERRUPT_PROC ();
     

     or

     P_IIII_name: CLOCKED_PROC ();

     The statement is followed by the procedure body. The procedure finishes with the statement

     END P_IIII_name;

     In the procedure name, the IIII characters are replaced with the four-letter equivalent of the number of the SSM, as described earlier. The name is unique to the procedure and remains unchanged. The following fact should be noted.
     Calls to the Operating System Nucleus (OSN) primitives, ENTER MONITOR also appear in the source code at the point required. The primitive (in this case ENTER_MONITOR) must however have been seized earlier in the SSM module.
   • The statement

     END H_M_IIII_name;

5. A CHILL MODULE that consists of the following:
   • The statement

     H_M_IIII_name: SSM_MODULE

   • Statements in accordance with Clause 5, that define the connections of the MODULE to other software items, and local definitions applicable throughout the MODULE.
   • A common data area for items common to the procedures in the MODULE which contains CHILL data declarations and, if required, DML INVOKE statements for a Data Sub Model, for data base relations or modes. The following fact should be noted. If any procedure in the MODULE transmits or receives messages, a pointer to the message buffer, has to be declared as shown:

     DCL T_MSG_BUF PTR;

   • Definitions of each procedure in the MODULE that can be called from outside the SSM. Each procedure starts with the related PSL statement that is:

     P_IIII_name: INTERFACE_PROC (< parameters >)
           RETURNS_ (< modes>);
     

     or

     P_IIII_name: CLOCKED_PROC ();

     or

     P_IIII_name: EVENT_HANDLER ();

     or

     P_IIII_name: INTERRUPT_PROC ();

     Where < parameters > is replaced with a formal parameter List in normal CHILL syntax. Sometimes the formal parameter list may be empty. RETURNS (< mode >) is the CHILL result mode specification, and is required if the procedure in a function is returning a value. If the procedure is not returning a value, it is sometimes omitted. Each procedure finishes with the following statement.

     END P_IIII_name

     In the procedure name the IIII characters are replaced with the four-letter equivalent of the number of the SSM, as described previously. The name is unique to the procedure and remains unchanged.
   • The statement

     END H_M_IIII_name;

   • The statement

     END_SSM;

5. CONNECTION TO OTHER SOFTWARE ITEMS

In the source code for FMMs and SSMs, provision has been made for incorporating definitions from linkages to other software items. Particular instances are message definitions and Operating System Nucleus (OSN) primitives. Explicit statements are required at the positions defined in Clauses 3 (4), 3 (5), 4 (4), and 4 (5) for the application and supervision parts of an FMM and the CHILL REGION and CHILL MODULE of an SSM.

When required, connections are provided to some or all of the following:

1. Data Base modes. These mode definitions are incorporated using INVOKE MODE statements or INCLUDE statements.
2. OSN primitives. These primitives are incorporated by SEIZE statements that have the following format:

   SEIZE OSN-primitive <> NON-LINKED (NN, MM) 
   (< parameter List >) 
   [RETURNS (< result mode >)];

   Where NN is the procedure type and MM is procedure number. These primitives can also be incorporated by INCLUDE statements for one or more members containing such SEIZE statements.
3. Other Linkages. Some other connections may be required for particular FMMs or SSMs, for example, to parts of an FMM coded in Assembly Language. These connections are made when required by using SEIZE statements having the following formats.
   • To incorporate assembly code modules into the GSM via the linkage editor:

     SEIZE Q_KKLY_INPUT <> ASM ()

     or
   • To incorporate OSN procedures into the GLS via segment mapper:

     SEIZE DB_DAREQ_ <> NON_LINKED () (M_DB_PARMS LOC);

     or
   • To incorporate SSMs via the segment mapper:

     SEIZE INTF_TICP03_1 <> NON_LINKED ()
     (INT, BOOL, CHAR (8), LOC, MORE_NAME)

6. FMM CODING

Several methods for the structure of an FMM are possible. For example a hierarchical structure of nested loops and IF statements or a Finite State Machine (FSM) based on a CASE statement. The following subclauses, describe three models and some of the corresponding coding. The choice of code structure depends on the functions to be performed by the particular FMM.

6.1 Hierarchical Nested Model

This model is used both for the supervisor and application parts of an FMM. It conforms to the classic concepts of structured programming, where part of an FMM is built up from simple statements and the IF, DO, CASE and WAIT_CASE constructs. These can follow each other in sequence and can also be nested within one another.

6.2 State based FSM Model

This model is uses the variable STATE, the value of which is tested by a CASE statement within an everlasting loop. Each CASE alternative is a WAIT_CASE statement and receives the messages that are to be handled for the corresponding value of STATE. The WAIT_CASE clause for each message contains CHILL and POL code, as required to handle the message and concludes with a statement that sets STATE to the next value.

Both the supervisor part and application part of an FMM can be coded in this way, although it is more suited to the application part of the FMM. In either part, the local data declarations include a declaration of the STATE variable in the form shown below:

NEWMODE Z_STATE_MODE = SETS (S_101 IDLE,....);
DCL STATE Z_STATE_MODE;

Figure 5 shows the code for the main part of the supervisor or application process. Local procedures are incorporated as required.

        STATE:=  S_010_IDLE;              /*PUT TO IDLE AT PROCESS START*/ 
FSM:    DO FOR EVER;
          CASE STATE OF
          
          
   /****************************************/
   /*            STATE HEADER              */
   /*                                      */
   /*      NAME: S_010_IDLE                */
   /*      FUNCTION:                       */
   /*                                      */
   /****************************************/

                    (S_010_IDLE):
   L_010_IDLE:      WAIT CASE;
                     MMM1_MSGNAME (Z_PAR1,....):
                     /* MMM1_MESSAGE ROUTING NUMBER */
                     /* MSGNAME-ABBREVIATED MESSAGE NAME IN LIBRARY*/
                     
                       
                       STATE:= S_OXX STATENAME;
                    END_WAIT_CASE_CLAUSE;

                    MMM2_MSGNAME (................):
                      
                      STATE: = S_OXX_STATENAME;
                    END_WAIT_CASE_CLAUSE;

                 ESAC_TIAW L_010_IDLE;
   /****************************************/
   /*            STATE HEADER              */
   /*                                      */
   /*      NAME: S_020_STATENAME           */
   /*      FUNCTION:                       */
   /*                                      */
   /****************************************/

                        (S_020_STATENAME):
                         /* Similar code for state 020 */
                         /* Similar code for further states */
                         
                         ESAC;  /* OF STATE */

                      OD FSM;

6.3 Message based FSM Model

In this method, the supervisor or applications part of the FMM, at the outer level, comprises a WAIT_CASE statement for all messages that are received by the FMM part. Again, within each WAIT_CASE clause, the variable STATE is tested, usually by a CASE statement. The statements are executed according to the value of the STATE variable and finish with a statement that sets the STATE variable to the next state value.

This model, although similar to the state-based FSM model, differs in one respect - each message is handled explicitly as it is received. Because messages are not deferred, it is easier to take action for messages received out of sequence.

Есть вопросы или дополнения, конструктивная критика? Пишите!