(2will return the next available packet type code (see PN-159 CDPACK- HFortran callable routines for interprocessor communication) R After the analysis task has requested the event or block of events \from the GTEVNT task in the connected machine it must read the reply fevent or block of events into its chosen data buffer. A routine will pbe provided to handle this communication with the GTEVNT task zin the normal way - making a request then waiting for the reply. Other routines will also be provided which allow the analysis task to specify details of the type of events to be provided. (see PN-160 - GETEVT package of routines for RSX - in preparation)  An analysis task which needs to 'double buffer' and perform analysis of one buffer of events whilst the transfer over the link to another buffer is taking place can do so by using the information in IN-66, together with the CDPACK routines. .sk 2 .tp 30 .fig 28 .b; Fig 2. Requests for events over the link .sk 2 .hl 2 Old analysis tasks on a connected machine  A task which was designed and built to run in the same machine as  the data acquisition and therefore uses the method described in  section 3.1 , can be used unchanged in a connected machine cluster.  It is not the most efficient way to get events for analysis but it $ will work without problems. . A GTEVNT task may run in a machine which has no data acquisition. 8 It will then itself act as an analysis task. B GTEVNT on receiving a request buffer type 1 L from the analysis task attaches to the shared Common region. This V region is now the GTEVNT task's own event buffer. The GTEVNT task ` sends a request buffer type 2 over the link to the GTEVNT task in the j connected data acquisition machine. The event data will be t transferred directly into the shared Common, after which the local ~ GTEVNT can inform the analysis in the normal way, that an event is now available. .sk .b;^&Limitations\& Only one request at one time may be handled in this way. That is, a request from a task must be satisfied and the task informed before a request from another task can be handled. This means that you could never use this mechanism for requests that could not be handled immediately - say for 'rare' events. .sk .tp 30 .fig 28 .b; Fig 3. Requests for events through the GTEVNT task ^& .hl 2 Long term plans for all analysis tasks  \&  When an internal communication driver is available (DS-82 Internal ( Communication Driver for RSX - in preparation), tasks may communicate 2 with each other in an identical fashion whichever machine of a cluster < they are running on. The Internal communication driver will provide F identical functions to the CD communications driver for the DR11W. P This will eliminate the need for Common regions and allow blocks Z of several events to be passed to an analysis program. d Only one type of request buffer will need to be supported. n ^& x .hl 1 Stages of development \& .ls .lit Stage 1 - early summer 1982 .end literal .sk .le;CDPACK routines .le;GETEVT routine and related routines (PN-160 - in preparation) .le;GTEVNT program modified to .literal a) pass on requests to a GTEVNT in a connected machine and receive the reply event b) receive requests from a GTEVNT in connected machine and service them .end literal  .le;Testing of GTEVNT with existing programs - eg.RSXMULTI  .sk  .lit  Stage 2 - late summer 1982  .end lit " .sk , .le;Internal communications driver 6 .le;Modification of existing programs to use new request format @ via either real or internal communications J device and to be prepared to handle blocks of events. T .sk ^ .lit _ Stage 3 ` .end lit h .sk r .le;Modifications to GTEVNT/DA to allow blocks of events to be | transmitted over the link .le;Modifications to GTEVNT/DA to allow greater selection of events on some criteria, and holding of requests which cannot be immediately satisfied, until a suitable event is available. .els ^& .hl 1 Format of the Event \& In the bulk memory data acquisition system used up to the present, space is allowed in every event header for a Physical tape record header. When an event is the first event in a Physical tape record, then the header is reformatted. Space is allowed in the event header itself for user information to be inserted - normally some pointers to data to assist in the online or offline analysis.  Since an event may be copied to the user's buffer either before  or after it has been written to tape, and since an event which  has served as the first event in a physical block is in a different & form to other events; the GTEVNT task always inserts the user 0 information into the copied event, regardless of its previous format. : When events are copied over a link directly into an analysis task's D buffer, as in Section 3.2, N the GTEVNT task does not have access to reformat them in X the user's buffer. An event format and physical record header b format which permits the user information to be inserted in the l raw data buffer, by either GTEVNT or LOG is required for this case. v The event format and physical record format for a Connected machines data acquisition system is described in PN-161.