Interprogram Communication: Core-to-Core (CRCR)

The Core-to-Core (CRCR) data transfer mechanism is a high- performance method for communication between two programs running on the same V Series host system. The CRCR function is the primary means of accomplishing synchronous interprocess control. You can perform similar data transfer functions with STOQUE, but CRCR is more efficient when transactions are handled in a serial mode with no processing overlap.

The CRCR transfer functions are performed by the CRCR extension module.The CRCR module transfers information from a data area in one program to a data area in another program. The data is transferred directly, without using any intermediate storage area, and only when both users acknowledge that they are prepared for the exchange.

Programs can execute two types of calls on the CRCR module. A program can request that data be sent to another program (send), or a program can request acceptance of data from another program (receive).

The CRCR function requires the synchronization of CRCR transfers. Data is moved from the sender to the receiver only when both processes are simultaneously ready to enter into the transaction. Furthermore, at least one of the users to the transfer must be willing to wait until the other is prepared to complete the transfer. This synchronization of the programs is also known as interlocking. The process of synchronizing the programs and accomplishing the data transfer is known as a CRCR hookup.

The two basic requests which can be made of the CRCR function can be illustrated by the COBOL-74 SEND … FROM and RECEIVE … INTO constructs which request, respectively, that data be sent to or received from another program. For example:

SEND program-name FROM data-name ON EXCEPTION imperative- statement.

The data-name references the data to be sent to another program concurrently operating in a mix. The name of that program is specified by the program-name. Another possibility is to specify a six-character program-name of blanks which implies that any program is a candidate for the hookup (Global request).

When the data transfer is completed, the program resumes at the next instruction. The optional ON EXCEPTION clause can be used if the sending program wishes to continue processing (at paragraph- name) when the receiving program is not ready for the data transfer. If this clause is omitted, the sender is suspended until the receiver is prepared to accept the data. The ON EXCEPTION clause is generally omitted for synchronous operations.

To receive data, the COBOL syntax is:

RECEIVE program-name INTO data-name ON EXCEPTION imperative- statement.

This format indicates the readiness of the requestor to receive data. The data is to be transferred from the program-name data field and placed in data-name. The ON EXCEPTION clause functions in the same way as the corresponding option in the SEND…FROM format.

Technical Details

The following details of the CRCR transfer mechanism should be considered before you use CRCR to transfer data.

Data Length and Types

Among the parameters passed to the MCP in a CRCR request is the description of the data to be transferred:

  • Type (digit, bytes, or words)
  • Length (in units of the type)
  • Location (address)

The characteristics of the data to be transferred by the CRCR mechanism is almost unrestricted. The data can be located in any portion of the program's memory and can be of any length up to 9999 digits, bytes, or words.

The description of the data areas do not need to be specified in the same way by both the sender and receiver. If the absolute data lengths (adjusted according to type) are different, only the shorter size is moved. Also, the buffer locations in the two programs do not need to be the same, nor must they be address synchronized in the same manner. The transfer is most efficient when both programs specify a data area which is word aligned and an even number of bytes in length (such as a COBOL 01 record). The declared data type is not important and is used only to determine the meaning of the data length field.

If the data structure does not permit a word move, the transfer is made on a least common denominator method.

A conversion operation (UN to UA or UA to UN) is never performed on the data. The information is always moved as-is, without regard to the data type specified in the parameters.

Program Names

Since several program pairs can use the CRCR functions at the same time, it is required that a job identify the program with which it is to communicate. One of the parameters of the CRCR request is the address of a 6-byte field containing the appropriate program name.

The sender or receiver can place six blanks in the program name field. This format of the parameter means that any program in the appropriate state (ready to send or receive) will be used in the transaction regardless of name. When the program name field contains blanks, the CRCR request is known as a Global FILL. A hookup will not occur between a sender and receiver if both are requesting a Global FILL.

       In many instances the GLOBAL FILL option can be             
       useful. However, caution must be taken when multiple        
       independent programming systems are using CRCR, since   
       transactions from one system could be sent to another.      

Program Synchronization

One of the major features of CRCR is that data transfer does not occur unless both programs involved are prepared to enter into the transaction. This mechanism ensures the integrity of both programs and further allows the system to use the CRCR functions as a means of interprocess synchronization (or interlocking). Because this interlocking is necessary with CRCR, it is often necessary (especially in asynchronous processing) to reinstate a CRCR request when the other program is not ready for the data transmission.

Buzzing in Synchronous Operations (CRCR and STOQUE)

The process of executing the ON EXCEPTION… clause and later reinitiating the request is called buzzing. The system software makes the practice of buzzing unnecessary. One of the reasons buzzing is an undesirable practice is that the buzzing program can have a higher priority than the intended partner program. In this case, since the buzzing program is always ready to run, the partner program will never get a chance to run, so the hookup will never occur. Therefore, whenever possible buzzing should be avoided

Buzzing can generate a significant amount of processing overhead if this operation is required frequently. While the processing requirements for any single unsuccessful request is quite similar for either CRCR or STOQUE, there are different methods for each mechanism to minimize the impact of buzzing.

If you still use buzzing, you should make an attempt to at least minimize the practice for several reasons. If, for example, the program using the ON EXCEPTION option processes a shorter time between transactions than the other program, a significant amount of overhead can be incurred by the execution of repeated unsuccessful FILL requests. Where possible, either the burden of processing must be placed on the program which does not WAIT, or an attempt must be made to balance the processing time between the communicating programs.

When such balancing is not feasible, it is often possible to employ the WAKE-UP facility of CRCR as an alternate interlocking mechanism. This mechanism is most often used by data communication handlers and allows the program to be suspended until any of the three following events take place:

  • A device event that needs servicing occurs.
  • A program attempts a non Global FILL to the waiting program.
  • A specified time period elapses (this is optional and depends on the programmer).

The WAKE-UP facility can be used in certain other areas to reduce buzzing overhead. However, care must be exercised as the order of events is important. One program can WAKE-UP another by a FILL request, but a program will be allowed to SLEEP if it executes a WAIT or SLEEP request, and all other programs WAITing CRCR on this program are in receive mode. For that reason, the WAKE-UP mechanism is generally used in conjunction with the other functions of WAIT or SLEEP, or when proper timing can be assured. The WAKE-UP occurs only on non- Global SEND or RECEIVE requests; the PROCEED TO option can be used or not, as desired.

Note:You can also use the Complex Wait Option to accomplish the same task. This feature is available in the COBOL-74 and BPL compilers and the appropriate reference manual should be referred to for the syntax and explanation of this feature.

A program must never buzz without giving up control to another process. If a program simply loops on one or more FILL requests, you can always reinstate it. Furthermore, if it is the highest priority job on the system, no other program, including the one for which the buzzing job is waiting, can execute. Even if it is not the highest priority job, the program would expend less overhead if other tasks could process between the FILL requests.

The following illustration is an example of synchronous interprogram communication using CRCR.

          COBOL                                   FORTRAN
          COBPRG                                  FORCAL
01 SEND-AREA.                                DIMENSION ITERM (10)
03 TERM1 PIC S9(7) COMP.
03 TERM2 PIC S9(7) COMP.                     INTEGER ANSR
03 TERM10 PIC S9(7) COMP.                    10 CALL FILL (ITERM, 40, 6HCOBPRG)
MOVE ... TO TERM1.                           [process]
...                                          ...

The COBOL program (COBPRG) builds the terms to be used in the calculation.

The SEND…FROM statement causes SEND-AREA to be passed to the FORTRAN program (FORCAL) in array ITERM. (CALL FILL is the FORTIV syntax for a receive request.)

The COBOL data areas are declared S9(7) COMP. Assume that the integer precision in the FORTRAN program is 7.

The following is another example of synchronous interprogram communication. In this example, a COBOL program employs a BPL program as a scanner for free format input. As each record is accessed by the COBOL program, the relevant portion is passed to the BPL program which scans and reformats the data and returns fixed length results.

             COBOL                                  BPL
             COBPRG                                 BPLSCN              

   COBPRG.                             BPLSCN.

   01 SEND AREA.                       ALPHA RECVAREA (70), SENDAREA(100);
   03 FIXED-PART PIC X(10).            
   03 FREE-PART PIC X(70).

   01 RECV-AREA.                       ...
   03 WORD PIC X(10). OCCURS 10     

   GETRECORD.                          GETRECORD:


   MOVE WORD (WORD-IND)...             ...
   ...                                 FILL OUT SENDAREA "COBPRG ";     
   GO TO GETRECORD                     GO GETRECORD:

Asynchronous Operations and Core-to-Core

Core-to-Core (CRCR) provides the ability to have efficient asynchronous process control. However, unlike the STOQUE mechanism, which allows completely asynchronous data exchanges, CRCR provides for synchronized data transfer. Programs using CRCR can process any given transaction asynchronously but must be synchronized at the time of data transfer.

When CRCR is used for asynchronous processing, the ON EXCEPTION … clause of the SEND … FROM and RECEIVE … INTO constructs is often employed. This facility allows a process to pursue other activities while the other program completes processing preparatory to the hookup. This capability is important in applications requiring a handler program. Such a program can be servicing many users (peripheral devices or programs) and cannot wait for a hookup with one program while other users require servicing.

At a later time, the CRCR request can be repeated. The process of executing the ON EXCEPTION… clause and later reinitiating the request is called buzzing (refer to the paragraphs on buzzing earlier in this section). Since CRCR requires that the data transfer be synchronized, only one of the processes involved can specify the ON EXCEPTION… clause for a given transfer; otherwise a hookup would never occur. Therefore, occasionally one process must wait for the other to catch up.

The CRCR requests have another function which is sometimes valuable in asynchronous processing, usually in conjunction with the normal data transfer facility. If a program attempts to SEND…FROM another program and no process of the specified name is prepared to receive or send data, but a program of that name is in a WAIT or SLEEP status, the WAITing/SLEEPing program is marked ready-to-run. Thus, Non-Global CRCR operations can be used to wake up another program. (A WAIT [UNTIL <time>] , WAIT <time> request, or Complex Wait, respectively.)

Refer to the specific language manuals for detailed information on the particular language constructs for Core-to-Core.

programming_ref/crcr.txt · Last modified: 2011/07/25 10:54 by scott
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki