#3. Procedures. Procedures are written in a special language whose primitives are actions in the net described earlier and also other actions. This implementation uses OS assembly language enhanced with special macros (the extensions of the macros include calls to auxiliary routines performing the net primitives). There are macros to be used at the beginning and at the end of a procedure which take care of storage allocation for procedure variables and system data, return to the calling program, support further calls (including unrestricted recursion).

In a procedure internal variables may be declared that may take any vertex in the net as a value (repeated assignment, as usually, cancels the effect of the previous one). Inside the procedures the values of the variables can be accessed by names of the variables; outside the procedure, as well as inside another procedure called from this procedure the variables are invisible (though the same objects can be assigned to variables of other procedures). The values of internal variables are preserved only within a single run of the procedure; if the procedure is called again (possibly in a recursive way, i.e., before the current run is completed), the internal variables of the new call will have nothing to do with the internal variables of the current run (irrespective of identical names).

Values of internal variables can be nodes. Since nodes (unlike atoms) have no way of being identified uniquely in the whole net, the only way to specify an action on a particular node is by means of internal variables of the procedure. Having a node one can find the value of some attribute of this node (by giving the attribute name), and this value (which can be another node) may be assigned to some variable. Thus the set of accessed nodes can extend, but to do this one has to access some node in advance and to know names of attributes (these names must be either built into the procedure or obtained in the same way by walking through the net). On the other hand, any atom can be accessed immediately if its name has been built into the procedure.

A procedure has two initial sources for accessing nodes, viz., its own context and its calling context (in ALGOL-like languages the former corresponds to global identifiers in the procedure, the latter to actual parameters of a call). The procedure's own context is defined together with the procedure, and consists of a set of vertices built into this copy of the procedure (the set may be empty). The calling context is set independently at each call to the procedure and is defined by the caller. In the simplest case it consists of a single vertex passed as the parameter (parameter is optional). The fact that at most one parameter may be passed is not a serious limitation because the procedure can obtain any additional information by walking through the net starting from the parameter value. Here is an example of a procedure.
* entering the procedure
BIRTH NETBEGIN PARAM=M
* making record of a newborn baby, the parameter value is
* the mother
DECL M,F,BABY,C
* internal variables are declared, the variable M gets
* the parameter value, viz., the mother
NEWNODE TO=BABY
* a new node is created and assigned to the variable BABY
SETATTR BABY,NAME=MOTHER,VALUE=M
* the baby gets a "MOTHER" attribute with the value M
GETATTR M,NAME=CHILDREN,TO=C,GOYES=L1
* if a set of children is attached to the mother (by means
* of a "CHILDREN" arc) assign the set to the variable C and
* go to L1
NEWNODE TO=C
* if there were no children assign to the variable C a fresh
* node
SETATTR M,NAME=CHILDREN,VALUE=C
* link the new node to the mother by a "CHILDREN" arc and
* continue as if it existed before
L1 ADDELEM C,VALUE=BABY
* add the new baby to the set of this mother's children
GETATTR M,NAME=HUSBAND,TO=F,GONO=L2
* find her husband and assign to F, otherwise go to L2
SETATTR F,NAME=CHILDREN,VALUE=C
* draw a "CHILDREN" arc from the father to the same set of
* children; this arc may have existed before
SETATTR BABY,NAME=FATHER,VALUE=F
* attach the father to the baby
L2 NETEND RESULT=BABY
* exit from the procedure; the BABY node is returned to the
* caller

As the example shows a procedure not only can receive a parameter from the caller but can also return it a vertex as the result. A call to this procedure from an external program may look like this
CALLMOD BIRTH,PARAM=MM,TO=BB (MM and BB are caller's internal variables, BIRTH is the name of the procedure called).

It is an important feature of this system that, in order to arrange access to objects defined in the caller, the procedure uses a single node received from the caller to retrieve the needed objects by means of names ("HUSBAND" and "CHILDREN") built into this procedure, whereas whoever writes the caller does not need to know which particular objects will be used by the procedure called. In this the system differs from ALGOL-like languages, that require a complete list of passed objects (parameters) in a specific order to be agreed upon between the caller and the callee. The experience has shown that even passing a single parameter may lead to misunderstanding because the two procedures have to agree on the role of the parameter object in the situation in question (what should be passed as the parameter in the last example: the mother, the father, or the baby?). For this reason the system provides an additional facility enabling a procedure to access the own context of the caller without explicit parameter passing.