GDSX (Extended General Device Support) Manual

DEVICE^HANDLER Example, Design
Extended General Device Support (GDSX) Manual—529931-001
5-15
Device Control Blocks
At the TACL terminal, bring your GDSX process under the control of Inspect by
entering:
> DEBUG $GDS, TERM $TC2
To make the source code visible under Inspect, in high-level Inspect at the Inspect
terminal, enter:
- SOURCE ON
- SCOPE #DEVICE^HANDLER
- SOURCE
Enter a few carriage returns until you see the CASE RQST^TYPE statement. Set a
breakpoint at this line:
- BREAK #line-num
Then press “R” to resume execution of your program.
At the application terminal, enter a short text string followed by a carriage return. This
should force the GDSX process to a breakpoint, which is displayed at the Inspect
terminal. (The requester has issued a WRITE to send the modified text string back to
its OUT file.)
At the Inspect terminal, use the DISPLAY command to find the current value of
rqst^type:
- DISPLAY RQST^TYPE
Check the LITERALs, defined near the beginning of the DEVICE^HANDLER code, to
determine what kind of operation has been initiated by the requester. (It should be a
WRITE.)
Device Control Blocks
Now you can examine some of the pertinent control structures for the
DEVICE^HANDLER task. The DCB is the starting point. A DCB is the internal
representation of an SU and is used to manage a DEVICE^HANDLER task’s
communication with a file. When the requester application in this example opened
terminal $TC1, TSCODE opened the terminal, assigned a DCB to manage the
terminal, and created a DEVICE^HANDLER task that maps to the DCB.
The DCB contains:
•
The variable name that contains the name of the SU object corresponding to the
DCB (this example uses a dynamic SU, so the variable name is set to $TC1)
•
The access name or file name actually opened for the corresponding SU ($TC1 in
this example)
•
The variable tcbaddr, a pointer to the associated task control block (discussed
below)
ULHDECSE contains USKELEX’s dcb^template and is included in Appendix C.