When using XTEXT from an ATE workstation to edit a file on the server, XTEXT has to determine whether the source file is needs to be transferred to the client for editing (and then transferred back for updating). Otherwise it just opens the file directly. The decision process is as follows:

1. If running locally on Windows (not via ATE), then the source file is assumed to be (has to be) visible directly from the client (no transfer needed). Else...

2. If the TXFF_XFER (&h0800) flag bit (see XTEXT.DEF)in the DOCFMT'SRC field of the TXTCTL parameter is set, then the source file is assumed to be on the server and gets transferred to the client for editing. Else...

3. If the filespec does not contain a backslash, then it is assumed to be on the server and gets transferred to the client for editing. Else...

4. It is assumed to be directly accessible (either local or mapped to a shared network directory) and no transfer takes place.

The main point of confusion occurs when ATE is used to connect to a Windows server, and the filespec is on the server but in native Windows notation, e.g. c:\somepath\somefile.txt. To force XTEXT to recognize that this is a server-based file that must be transferred to the client for editing, you either need to set the TXFF_XFER flag, or you can change the backslashes in the filespec to forward slashes. (Windows accepts either, but the forward slashes will make it look like a UNIX filespec to ATE and thus trigger the transfer logic.)

One other detail about the file transfer that sometimes hangs people up: for UNIX servers, the default transfer method is FTP. If that method is not workable, you can force the alternate method (through the ATE communication channel) by setting the TXFF_RAWBUF (&h0400) flag bit in the DOCFMT'SRC field. For Windows servers, it always uses the RAWBUF method.

Finally, note that if the TXFF_FILE (&h0100) bit is not set, then none of the above applies since XTEXT will assume the source parameter contains the actual text to edit rather than a filespec.