TP Desktop Connector provides the task-link extension by modifying the behavior of the TP Desktop Connector TCP/IP DLL. Whether or not the acmsdiWS.dll behaves normally or in the modified task-link manner is determined when it is first loaded. On a given system, it will act one way or the other. Applications running on a given system are either using the DLL for multi-part applications or they are not. No provision has been made to have some applications use an additional external task and others not within a single user session. The existing acmsdiWS DLL has been modified to be able to work in its normal mode or to communicate to Winsock through an external common task. It will, by default, continue to work as it did in V2.2.
You enable the task-link extension before starting Windows. Define the ACMSDI_TASKLINK environment variable to indicate that the acmsdiWS DLL is to operate in the modified manner.
You can define ACMSDI_TASKLINK to be the name of the common task executable such as "ditsklnk" if the ditsklnk.exe is in the executable path. You can also use ACMSDI_TASKLINK to define a full path name to be used to locate the common task's executable. For example:
If you do not define ACMSDI_TASKLINK, then the diTskLnk executable file is not used.
Find the new task image, diTskLnk.exe and its icon (acms01.ico) in the
directory where you unpacked the msdos.exe self-extracting archive and
stored the DLLs, LIBs, and other object files.
220.127.116.11 Task-Link Extension Functional Description
The approach used to provide the task-link extension was chosen to provide a workaround that does not require any changes to your application. The basic approach is to funnel all network requests originating in the individual executables that make up an application through a common task. Because of the constraint that the solution does not require code changes to the application, the TP Desktop Connector acmsdiWS.dll creates and runs the additional task. It starts an additional task named diTskLnk and runs it with a minimized window. It starts and runs one Windows task for each connection that it establishes to the host.
The connection is established at the time of acmsdi_sign_in. When the acmsdi_sign_out is issued, the connection is removed and the corresponding diTskLnk task is terminated. The diTskLnk.exe task is just a minimal Windows program that looks for a single application unique Windows message. When it receives a message, it calls into the acmsdiWS.dll at a private entry point passing in the value of the message.
All network traffic is from these diTskLnk tasks, not the application task executables. The network requests in the acmsdiWS.dll, running in the context of the calling application task, are passed off to the diTskLnk task. This is what allows Winsock to accept that the task has initialized the connection. The actual data, such as that for the task workspaces, is not moved around by this approach, it is just placed where it normally would be and the DLL deals with it directly. No data other than the requesting message is passed between the application tasks and the diTskLnk task. If the request was for a connection disconnect, once it is completed the DLL deletes the corresponding diTskLnk.
If an executable signs in and establishes a submitter ID that it subsequently passes off to another application, it should no longer make any references to that submitter ID. If a submitter ID is passed, it is up to the executable that received the ID to either sign the ID out, or, in turn, pass the ID on to another executable.
The connection and submitter state continues to be managed by the code
in the acmsdiWS.DLL. However, the part of the code in the DLL that does
the low level Winsock communication runs in the context of the diTskLnk
task, not the calling application task. The diTskLnk task owns the
18.104.22.168 Task-Link Extension Side Effects
The task-link extension causes some changes in the behavior of the
The Tru64 UNIX client supports the TCP/IP that is built into the
library LIBACMSDI.A. The TP Desktop Connector kit includes this code. To build
a TCP/IP-based client, the default DECnet object is removed from the
TP Desktop Connector library and replaced with the TCP/IP transport module.
Refer to Compaq TP Desktop Connector for ACMS Installation Guide for more information on installing
client software and building the samples.
22.214.171.124 Setting Up the Environment for TCP/IP
The following sections discuss setting up the environment to use the
TCP/IP transport with DOS and Macintosh clients.
126.96.36.199.1 Specifying the Gateway TCP/IP Port Number on the Client
The default TCP/IP port number used on the gateway is 1023. If the default is used, no action is necessary.
If the port TCP/IP port number 1023 is unacceptable, you can override
the default by setting an environment variable on the clients, at the
system or program level. However, you must specify the same port number
on the gateway as you do on the client. On a Macintosh system,
you control the specification of the communications tool in the DBInit
188.8.131.52.2 Setting an Alternate TCP/IP Port Number on DOS
On DOS systems (and Microsoft Windows), you can override the default TCP/IP port number in the following manner:
host is the TCP/IP name of the gateway system.
184.108.40.206.3 Setting the TCP/IP Transport on Macintosh
On Macintosh, you can set the TCP/IP transport using the PATHWORKS for Macintosh TCP/IP communications tool (MacTCP), by setting the connection string parameter to the MacTCP tool in DBInit:
#define connstr "\p\"MacTCP Tool\""
See Section 3.2.3 for information the MacTCP tool.
220.127.116.11.4 Setting an Alternate TCP/IP Port Number on Macintosh
On Macintosh, you can override the port number by setting the connection string parameter RemoteTCPPort for DBInit:
#define connstr "\p\"MacTCP Tool\" RemoteTCPPort 1022"
To insure that the gateway is listening for TCP/IP connections, perform the following steps:
$ UCX SHOW DEVICE_SOCKET/PORT=1023/FULL Device_socket: bg2139 LOCAL REMOTE Port: 1023 0 Type: STREAM Host: 0.0.0.0 0.0.0.0 Service: RECEIVE SEND Queued I/O 0 0 Q0LEN 0 Socket buffer bytes 0 0 QLEN 0 Socket buffer quota 4096 4096 QLIMIT 5 Total buffer alloc 0 0 TIMEO 0 Total buffer limit 16384 16384 ERROR 0 Buffer or I/O waits 0 0 OOBMARK 0 Buffer or I/O drops 0 0 I/O completed 0 0 Bytes transferred 0 0 Options: ACCEPTCONN KEEPALIVE State: PRIV RCV Buff: None SND Buff: None
$ SHOW DEVICE BG2139:/FULL Device BG2139: is online, mounted, network device, mailbox device. Error count 0 Operations completed 1 Owner process "ACMSDI$SERVER" Owner UIC [SOFTSUPP,SYSTEM] Owner process ID 5C000234 Dev Prot Reference count 1 Default buffer size 256
If a large number of users are connecting to the gateway using TCP/IP, you need to increase TCP/IP Services quotas. The quotas include:
Refer to TCP/IP Services for OpenVMS System Manager's Guide for more information.
This chapter discusses using serial communications with Compaq TP Desktop Connector software. TP Desktop Connector serial communications allows Macintosh users who are not a part of a network, or are at a remote location, to access ACMS applications over a serial line without the need to manage a network or purchase networking programs. The TP Desktop Connector users hook up their Macintosh systems to modems, start scripts to attach to the TP Desktop Connector gateway for ACMS, and can then interact with ACMS applications.
This interface is ideal for applications such as electronic stores, because the client code can be freely distributed. The advantages of using a native PC application over a terminal emulation application include:
Serial connections to the TP Desktop Connector gateway for ACMS are made through the Serial-DECnet Gateway. Figure 4-1 illustrates the connections.
Figure 4-1 Serial Connections
The following sections discuss how to prepare the gateway to use
serial communications as a transport. See Section 4.2 for information
about preparing the client for serial communications.
4.1.1 Installation Requirements for Serial Communications
The following components must be present on the DECnet node to which the users will attach:
To activate the TP Desktop Connector gateway for ACMS for serial communications, you must have the DECnet network started as a transport, as well as the Serial-DECnet Gateway. To start the Serial-DECnet Gateway, use the following command:
This command starts a detached process ready to connect user links. You
can place optional process parameters in an optional parameter file.
See Section 2.5.3 for information on optional parameters.
4.1.3 Attaching Devices to the Serial-DECnet Gateway
You must attach asynchronous devices to the Serial-DECnet Gateway before TP Desktop Connector software can make serial connections. Attach devices to the Serial-DECnet Gateway as follows:
Serial devices are attached to the Serial-DECnet Gateway by using the
TP Desktop Connector Serial-DECnet Gateway manager after the process has been
started. Permanent connections take over the indicated device for
exclusive use by TP Desktop Connector applications. If the devices are
attached permanently, the device is no longer available for use by
4.1.4 Maintaining Permanent Connections
The following example shows how to attach a device permanently and leave the baud rate unchanged:
$ RUN SYS$SYSTEM:ACMSDI$SERIAL_GATE_MANAGER ACMSDIGW$MANAGER> ATTACH TTA3:/PERMANENT
You can reserve LAT devices for permanent use with the LAT server, LATCP, and the Serial-DECnet Gateway manager. On the LAT server, you must set the port for dynamic or remote access. Remote access allows access to the device only by remote processes, for example, the TP Desktop Connector Serial-DECnet Gateway. Dynamic access allows access to local or remote processes. For example:
local> SET PRIV password> local> set port 5 ACCESS REMOTE local> set port 5 SPEED 2400
Run the LATCP program (which requires the CMKRNL privilege) to create and initialize a terminal port, as in the following example:
$ RUN SYS$SYSTEM:LATCP LCP> CREATE PORT LTA900: LCP> SET PORT LTA900:/NODE=SWELTA/PORT=5
Now that the device is initialized and known to the OpenVMS system, you can attach to the Serial-DECnet Gateway. For example:
$ RUN SYS$SYSTEM:ACMSDI$SERIAL_GATE_MANAGER ACMSDIGW$MANAGER> ATTACH LTA900/PERMANENT
If TP Desktop Connector establishes a connection as an interactive session to the host machine, you can change the device to TP Desktop Connector serial mode. You can suspend the process associated with this device for the duration of the session or you can terminate it.
For example, you can use a captive login account for terminal connections over an X.25 network. The user is an X.29 terminal accessing the host. The script can then log in to the captive account. A command file associated with this account can then have the Serial-DECnet Gateway attach the device and log out the current process. Example 4-1 shows the LOGIN.COM command file for this account.
|Example 4-1 Command File to Attach a Device|
$! $! Attach this terminal to the Serial-DECnet Gateway $! If the user does not attach within 2 minutes $! detach the device $! $ RUN SYS$SYSTEM:ACMSDI$SERIAL_GATE_MANAGER ACMSDIGW$MANAGER> ATTACH TT:/TIMEOUT=00:02:00 $! $! Don't want this process anymore $! $ LOGOUT
An interactive user on the host might want to switch the current device to Serial-DECnet Gateway mode and then resume the current process. In this case, you must use the /SUSPEND switch to suspend the current process for the duration of the connection in Serial-DECnet Gateway mode. The user can then do the following:
$ RUN SYS$SYSTEM:ACMSDI$SERIAL_GATE_MANAGER ACMSDIGW$MANAGER> ATTACH TT:/SUSPEND/TIMEOUT=00:01:00
The current process is then suspended until the Serial-DECnet Gateway detaches the device. The Serial-DECnet Gateway detaches a device under the following conditions:
TP Desktop Connector software supports serial communications for Macintosh
clients with ACMSDI client services. For troubleshooting Macintosh CCL
scripts, refer to Inside CCL, from Apple Computer, Inc.
4.2.1 CCL Scripts
The Calypso Tool reads and processes the CCL scripts. Under control of the CCL script, Calypso invokes the communications tool, such as the Serial Tool, which implements the protocol.
Install both the Calypso Tool and the communications tool in the Communications Toolbox. You must write and save the CCL script as a CCL file in either the application's default directory or the Connection Files folder within the System's Extension Folder.
The CCL script specifies the work necessary to establish the connection between the Macintosh client and the gateway to attach the gateway to the Serial-DECnet Gateway. After the connection is made, both Calypso and CCL remain transparent until the connection closes. The CCL script then specifies the work that is necessary to clean up the connection.
When using the Serial Tool, the CCL script performs the following functions:
After the CCL logs in to the remote node with the ACMSDI$SERIAL_GATE_MANAGER, your LOGIN.COM startup command file can handle the attach and terminate process.
A CCL file automates the attachment of a Macintosh client to the gateway. To accomplish this, the CCL language provides a rich command set that controls the connection and disconnection sequences. Refer to the manual Inside CCL, from Apple Computer, Inc., for a complete explanation of developing CCL scripts.
The following rules apply to writing CCL scripts:
All lines of code in the disconnect section MUST begin with an asterisk (*). This allows the CCL interpreter to distinguish log-off instructions from log-on instructions. The designations --LABEL 0 and *--LABEL 0 are not the same.
Table 4-1 shows the CCL script commands with a brief description of the command. Inside CCL, from Apple Computer, Inc., provides the rest of the CCL commands.
|CTBChoose||Opens a Communications Toolbox dialog box that allows the user to set communication parameters and choose a tool from a directory of installed tools.|
|CTBClose||Closes the currently open Communications Toolbox connection.|
|CTBDown label||Checks the status of the Communications Toolbox connection and jumps to a label, if the connection is down. label is the label to which the interpreter jumps if the CTB connection is down.|
|CTBOpen label||Tells the interpreter to open the Communications Toolbox connection and where to go if it opens successfully. label is the label to which the interpreter jumps after the Communications Toolbox opens successfully.|
|CTBParam label string||
Sets parameters for the Communications Toolbox tool. Here are the rules
for setting parameter values:
label is the label to which the interpreter jumps if an error occurs in the execution of the string. string is one or more pairs of parameters and parameter values.
|CTBTool label1 label2 flags tool||
Selects a Communications Toolbox tool to use to manage the connection.
label1 is the label to which the interpreter jumps if the
requested tool is not installed.
label2 is the label to which the interpreter jumps if any
error occurs while opening the tool.
flags provides the specific internal parameters for the
tool is the requested connection tool. If the
flags field is 0, CCL uses the following default value:
|IfEqJmp " token1" " token2" label||
Compares two tokens and, if they are equal, jumps to a label.
label is the label to which the interpreter jumps if
token1 is equal to
token2. For IfEqJmp and the rest of the IF
xxyyy commands, the token can be any of the following:
If either of the tokens used are numbers, the other token is compared as a number. You can surround string literals by either single or double quotation marks.
|IfEqJSR " token1" " token2" label||Compares two tokens and, if they are equal, jumps into the subroutine beginning at a specified label. The subroutine returns to the command following the IfEqJSR command. label is the label to which the interpreter jumps if token1 is equal to token2. See IfEqJmp for a description of the tokens.|
|IfGTJmp " token1" " token2" label||Compares two tokens and, if the first token is greater than the second token, jumps to a label. label is the label to which the interpreter jumps if token1 is greater than token2. See IfEqJmp for a description of the tokens.|
|IfGTJSR " token1" " token2" label||Compares two tokens and, if the first token is greater than the second token, jumps into the subroutine beginning at a specified label. The subroutine returns to the command following the IfGTJSR command. label is the label to which the interpreter jumps if token1 is greater than to token2. See IfEqJmp for a description of the tokens.|
|IfInJmp " token1" " token2" label||Examines two tokens. If the second token is a substring of the first, the interpreter jumps to a label. label is the label to which the interpreter jumps if token2 is a substring of token1. See IfEqJmp for a description of the tokens.|
|IfInJSR " token1" " token2" label||Examines two tokens. If the second token is a substring of the first, the interpreter jumps into the subroutine beginning at a specified label. The subroutine returns to the command following the IfInJSR command. label is the label to which the interpreter jumps if token2 is a substring of token1. See IfEqJmp for a description of the tokens.|
|IfLTJmp " token1" " token2" label||Compares two tokens and, if the first token is less than the second token, jumps to a label. label is the label to which the interpreter jumps if token1 is less than token2. See IfEqJmp for a description of the tokens.|
|IfLTJSR " token1" " token2" label||Compares two tokens and, if the first token is less than the second token, jumps into the subroutine beginning at a specified label. The subroutine returns to the command following the IfLTJSR command. label is the label to which the interpreter jumps if token1 is less than token2. See IfEqJmp for a description of the tokens.|
|IfSWJmp " token1" " token2" label||Examines two tokens. If the leftmost bytes of the first token match the second token, the interpreter jumps to a label. The value label is the label to which the interpreter jumps if token1 starts with token2. See IfEqJmp for a description of the tokens.|
|IfSWJSR " token1" " token2" label||Examines two tokens. If the leftmost bytes of the first token match the second token, the interpreter jumps into the subroutine beginning at a specified label. The subroutine returns to the command following the IfSWJSR command. The value label is the label to which the interpreter jump if token1 starts with token2. See IfEqJmp for a description of the tokens.|
|IfTries number label||Compares the value of the Tries variable with an integer. Use it with the SetTries, IncTries, and DecTries commands. The value number is the integer with which Tries is compared. The value label is the label to which the interpreter jumps if the two numbers are equal.|
|NoCTB label||Checks to see if the Communications Toolbox is installed. With Calypso, this command never jumps. Calypso always uses the CTB. The value label is the label to which the interpreter jumps if the Communications Toolbox is not available.|
|SerClose||Closes the currently selected port immediately.|