GDSX Manual

Service Routines
Extended General Device Support (GDSX) Manual–134303
8-34
GET^ITC^FCB
Considerations
•
No mechanism for queuing of allocation requests or timeout is provided. For private
storage such a facility has no purpose because each task has its own individual pool.
•
A call to ^CHECKPOINT(2) checkpoints all local and extended memory pools
acquired by the calling task.
•
If poolcheck^flag of the DEBUGFLAGS configuration parameter is set, each time a
task is dispatched, TSCODE checks the buffer pool, message pool, extended buffer
pool, and extended message pool for corruption. If corruption is detected, GDSX
stops with abend error 230 or abend error 231. This pool checking is in addition to
that always done when the GETLOCALPOOL and GETEXTPOOL[X] procedures
are called.
The poolcheck^flag can be set when debugging a program and turned off during
production to allow GDSX to run more efficiently.
GET^ITC^FCB
This procedure allows a task to send ITC messages to other tasks. A task can send an
ITC message to another task only after it has the FCB address of the receiving task. To
obtain the FCB address, the sending task calls GET^ITC^FCB once for each task it will
send an ITC message to.
To send an ITC message, the sending task calls SEND^ITC^MSG[X], using the FCB
address in that call to identify the receiving task.
status returned value
INT:value
indicates the outcome of the call. The value of status is one of the following:
buffer:length input:input
INT(32):ref, INT:value
is a pointer to the buffer that contains the SU name of the receiving task to search
for, and the length of the buffer in bytes. See “Considerations” later in this
subsection for more information about specifying the SU name.
status := GET^ITC^FCB ( buffer:length !
i:i
,fcb-address ! o
,[ dcb-address ] ); ! o
-1 One or both of the addresses were not found
0 The FCB and DCB addresses were found