Function

1. If there is no RELEASE instruction, the departing of a message from the IL is automatically made as follows: when the depart event pointing to the node is executed, the message with the time of depart XT equals to the actual value of TIME (i.e., the time of the departing event) is extracted from the IL and sent to the successor nodes. If there are more than one successor node, copies are sent to all of them. The value of the freed and used resource account is updated (see 3 below) The part of the code used by the system to process the departing message is only executed one time in the event and is not repeated during the scanning of the network.
2. The user can control the departing process of the message by means of a RELEASE instruction. This is only executed if the R type node is activated by an event that refers to the node. The associated instruction is executed only one time at the beginning of the event and not repeated during the scanning of the network.
   The execution begins, as in the automatic case, by seeking the first message with an exit time XT equal to the actual TIME. If it is not found, a message error of "empty list" is given. If it is found, the message is extracted, the fields are copied in the field variables and the user's code in the associated instruction is executed. This code must have a SENDTO instruction to send the message to one (or various) successor nodes. Before this sending, the fields of the message are updated at the values of the field variables.
3. After the sending of the message the capacity of the node is updated adding the value of the USE field to the free capacity (variable F_<node>) and subtracting the value of USE to the used capacity (variable U_<node>). This resource freeing can be inhibited if a NOTFREE procedure appears in the associated instruction of the RELEASE instruction. This is used in applications in which some items abandon the resource, but this requires an additional time to be available again. The freeing is made elsewhere by a FREE procedure at a latter time.
4. The part of the code that passes the messages to the EL (accepting function) is executed when the EL is not empty. It examines the messages in the EL starting from the first. For each examined message the fields are passed to the field variables. and the user's instructions in this part are executed. One of them may be a STAY := <expression> instruction. The required amount of resource (USE field) is compared with the available resource (F_<node> variable). If USE is greater than F_<node>, the message remains in the EL and the scanning of the EL continues. Otherwise, the message is extracted, the event of its future departing is scheduled (if there was an STAY instruction) and the message is added at the end of the IL.
   The capacity of the R node is updated subtracting the value of the USE field of the message to the free capacity (variable F_<node>) and adding the value of USE to the used capacity (variable U_<node>). The scan of the EL continues to look for other candidates to use the resource. If there is not STAY instruction and one message enters the IL, no departing event is generated. The message will remain in the IL until it is extracted by an instruction REL (see 6.18), that refers to the IL of the node. It extracts the first message without assigned exit time; it updates the quantity of free and used resource and it sends the message to the desired node.
   It is important to remark, that the EL is examined and the user's code executed even if there is not resource available. If the user wants to avoid repetition of all the code or part of it, she or he must program the conditions for that omission.

   Example:

   IF F_Parking > 0 THEN STAY := LOGNORMAL(TPark, DTPark)

   avoids to compute the STAY if there is no room in Parking.

5. If there is the instruction PREEMPTION (see 6.17), some of the above operations are modified.
6. If the capacity of the node was defined as MAXREAL, it is assumed to be infinite and no update is made in the free or used capacity.