TSX & FoxPro TSX is an ideal environment for running most DOS based programs including FoxPro. As with any program, there are a couple of potential problems that you need to be aware of to successfully run FoxPro applications under TSX. In some cases, the configuration issues relate to the overall configuration of FoxPro in any multi-user environment (such as Novel NetWare & LANtastic) and in others, specific to TSX. Taming FoxPro Before running FoxPro on TSX, it is important to identify the version of FoxPro that you plan to run. TSX then needs to be told to "tame" the application by setting up various parameters using the PMAN program or the TSX install command. The following is the command used to tell TSX about FoxPro. Replace the device and directory with the program that you plan to use. install add DHA0:\FPD26\FOXR.EXE /DOSNET/NOCFIN/NODEBUG- /SCCA/TTCKIO/TTWAIT/TTHANGTIME=20/PASSCHAR=0xC77FFFFF PMAN may also be used to set the above parameters. For the screen that prompts for the characters to pass to the program, it is easiest to set all values to Y and later un-do the ones that you want TSX to act on. Configuration In a typical multi-user environment, FoxPro has certain environmental requirements that you must be aware of. The primary requirement is for each user to have their own resource (FOXUSER) files. A method of setting up the user resource files is discussed below. Another requirement is for sufficient file handles for your application. Please review the FoxPro documentation on the required number of file handles. Under TSX, you do not need to worry about file handles because they are allocated dynamically as needed. In most cases, it is desirable to have a single application that runs in all environments, DOS, TSX, or a Networked environment. It is easy to do if you keep this goal in mind when writing the application. In general, if the application is developed with multi-user syntax (set exclusive off, rlock(), unlock, etc..), you should have no problem running in all environments. Default Configuration Path FoxPro requires that a unique default configuration path be set up for each user. In a network environment, this usually happens automatically because the local workstation drive is the default drive. In the TSX environment, however, it is necessary to create a directory for each user that contain the configuration files, and make assignments to point FoxPro to those directories. The following examples deal with the following runtime directory structure. C:\ |__APPDIR |______DATA |______TTA0 |______TTB0 |______TTC0 |______TTD0 |______TTD1 |______TTxx The APPDIR directory is the directory in which all of the application specific program files are stored. DATA is the directory where all of the shared data is stored. The TTxx directories are the user resource directories that need to be setup for each user that runs FoxPro. Each of the TTxx directories contain the user specific configuration files CONFIG.FP, FOXUSER.DBF and FOXUSER.FPT. This structure is only a sample but represents the minimum structure that needs to be established to properly run FoxPro in a TSX environment. The CONFIG.FP file must be manually created in the user directory to reference the correct directories (see the section on FOXR Runtime below for contents). The FOXUSER files can be copied from the FoxPro installation directory, or from your development directory. The FOXUSER files contain color schemes and other information used by the application. If FoxPro is unable to open the FOXUSER files, the screens are usually displayed in black & white because it cannot get the default color scheme information. The following is a sample TSX command file (MYAPP.CMD) that sets the appropriate environment for each user. _path ;c:\fpd26 !Set the FoxPro directory in the path user = $jobinfo("ttname")[1:5] !determine the port the user is running on _if user[5:5] .eqs. ":" then user = user[1:4] !trim trailing colon if any _set foxprocfg=c:\appdir\'user !FoxPro looks for the environment variable foxprocfg when looking for its CONFIG.FP file. If user is logged onto TTD2, this line gets set to set foxprocfg=c:\appdir\TTD2 _set data=c:\appdir\data\ !Point data to common data directory _assign print: lpt1: !Make logical printer assignments _assign tp: lpt2: !If terminal supports printing, redirect LPT2 to the terminal. This allows remote printing with NO programming effort. _cd \appdir !change directory to application directory foxr -t -x my.app !FOXR is the FoxPro runtime. Foxpro may be substituted for foxr if using the full version of FoxPro instead of the runtime. Lets look at the above command file in a bit more detail. The first path line adds the FoxPro directory to the program search path for TSX. This is similar to the DOS command set path=%path%;c:\fpd26 The second command creates a local variable that contains the terminal port name that the user is logged into. Each connection into TSX gets a unique port name. The third line makes sure that the colon at the end of the port name gets removed. Network connections are assigned TTNx where x is the next sequential network connection to the system. If you anticipate a large number of network users, it is important to create enough TTNx directories to accommodate the maximum number of simultaneous network connections you expect. For example, if you expect no more than 6 network connections, you would create TTN1, TTN2, ... TTN6 to hold the configuration files for each network connection. The fourth line creates the environment variable foxprocfg to point into the configuration directory for that particular user port. For example, if a user is logged onto TTD23, foxprocfg is set to C:\APPDIR\TTD23. The fifth line creates the environment variable data and sets it to C:\APPDIR\DATA. The next two assignment lines tell TSX what to do with output sent to the LPT ports. Each DOS printer port can be set to go to any TSX device or spooled port, even a printer that may be attached to the remote terminal. In this example, LPT2 is set to TP: which is the remote printer port. The next command changes the default directory to appdir, which is where MYAPP.APP exists. The last command runs the FoxPro application MYAPP.APP. The FOXR runtime Now, lets look at what happens when the last command (foxr -t -x myapp.app) is executed. First, FOXR looks for the environment variable foxprocfg to determine where the users configuration file (CONFIG.FP) is at. CONFIG.FP contains commands that configure the behavior of FoxPro, including where to find the user resource files FOXUSER.DBF and FOXUSER.FPT. These two files contain the user profile and preference settings when in FoxPro. Also, since FoxPro opens the FOXUSER files for exclusive access, they cannot be shared between users. Other configuration items in CONFIG.FP consist of settings to control where FoxPro opens its work files (see below for example). If foxprocfg is not set, it looks in the default directory (c:\appdir). If not there, it looks at its executable directory (c:\fpd26). CONFIG.FP contains commands that point FoxPro to its working directories. The following is a sample CONFIG.FP file for the user logged onto port TTD23. resource=c:\appdir\ttd23\ !where to find FOXUSER editwork=c:\appdir\ttd23\ !where to create temporary editor files sortwork=c:\appdir\ttd23\ !where to create temporary sort files progwork=c:\appdir\ttd23\ !where to create program cache files mvarsiz=15 !15K of memory allocated to FoxPro variables mvcount=500 !allow up to 500 application variables The command switch -t tells FoxPro to not display its signon banner. The -x switch tells FoxPro to run in standard mode instead of extended mode (more on this later). The application (MYAPP.APP) is then executed. In many cases, this includes prompting the user for a logon name or displaying a menu or opening files. One of the first command in the program should be to include the data path into the default file open path for FoxPro. The following is a code snippet from one of my programs that sets the FoxPro file path to include the one set for the application. * * Set Exclusive off to allow shared access to files * set exclusive off * * Get data environment variable if set. * m.Path = alltrim(getenv('data')) * * Since DOS treats the environmental variables * differently depending on whether a space is * attached, I need to look for one with an * extra space.. * if empty(m.Path) m.Path = alltrim(getenv('data ')) endif * if empty(m.Path) m.Path = '.\data' endif * * Attach additional directories where programs * or libraries may be * m.Path = m.Path + ';.\;.\bin' * set path to (m.Path) All subsequent opens (or USE's to be more precise) search for files in directories in the order specified. Opening Files It is important to remember that TSX is a multiuser environment, and that all files that are shared must be opened accordingly. Before opening any files, set exclusive off. This tells FoxPro that subsequently opened files are shareable. Before updating or replacing any values, the record that you are working on must be locked using rlock(). When your application is done updating the record, it must be unlocked. Please read the FoxPro documentation on developing multi-user applications. TSX will run a FoxPro application that doesn't have multi-user commands in it but only one user will be able to execute the application at once. All files that are opened are opened exclusively, and the second user will get an "access denied" error. TSX allows logical drives that are similar to (but more powerful than) the DOS subst command. For example, if you choose, you can create a logical device called DTA: that points to the data directory, _assign c:\appdir\data\ dta: From the FoxPro program, you may open files on the logical device using the standard use command, use dta:myfile Please keep in mind that while TSX understands the above command, DOS does not. I don't recommend this syntax unless you are certain that your application is not going to run under DOS. Also, if opening files on a different networked TSX system, it is convenient to specify the network drive as follows, _assign net::c:\data\ n: From any DOS application including FoxPro, if you open files on n:, the files are opened through the network. In the above command file example, if the shared data exists on a separate network drive, the set data command may look like this, _set data=n: Memory Model FoxPro comes in essentially two memory models; the standard version and the extended version. Unless it is absolutely necessary, I do not recommend running the extended version of FoxPro under TSX. Since TSX usually allocates more usable conventional memory than DOS, it often is not necessary to run the extended version. An application that gets an "insufficient memory" error under DOS will often run under TSX without generating the same error. The standard version of FoxPro takes up about 700 to 800 Kb per user to run, while the extended version consumes about 3000 to 4000Kb per user. This means that 10 users on the system running the standard version take up about 8Mb of RAM. On the other hand, if those 10 users run the extended version, they will take up about 40Mb of RAM. If you only have 16Mb of memory, you can easily run all 10 standard users without TSX having to page memory to disk. 10 extended users would cause the page file to be accessed after the third or fourth user. Excessive access of the page file adversly affects overall system performance. When FOXR is executed, it determines which model to run depending on the available memory the memory manager reports back. Under TSX, this value can be configured. If more than 2Mb of XMS memory is available, FOXR loads the extended version of the runtime. Otherwise, the standard version is run. In order to force the execution of the standard model, the -X can be specified on the command line. To force the execution of the extended version, the +X can be specified. If running the full version of FoxPro, the FOXPRO command runs the standard version while FOXPROX runs the extended version. You may choose the appropriate model to run depending on the memory needs of the application. But keep in mind that the extended version will generally cause the entire system to run slower. TSX Benefits There are many TSX features that can be used to greatly enhance the your FoxPro applications. For specific details, please refer to the TSX documentation, which covers in detail how to utilize the features. TSXCMD TSXCMD is a 16 bit program that allows 16 bit DOS programs to run 32 bit TSX programs from within the application. If your program needs to check who is on the system, or to detach a process to do some cleanup work, TSXCMD can be used. The output from the process you run can be re-directed to a file and retrieved from your application. If you wish, you can develop a FoxPro application that allows the user to access the queue manager or any other TSX without requiring the user to switch to another task or exit the application. The syntax to run the queue manager using TSXCMD from within FoxPro is as follows, !/0 TSXCMD QMAN Mail Boxes Mail boxes are a convenient method of having several tasks communicate with each other. These tasks can be dedicated server jobs, or other user jobs on the system. The mail box is essentially a bi-directional pipe where data can be transferred back and forth. One simple implementation may be to write a server application that does time consuming processing in the background. When it is done, the server application notifies the initiating application that it is done. In doing so, the initiating user does not have to wait for the lengthy process to complete. The user can continue to perform other tasks on the system while the server is processing the data. In FoxPro, the mailboxes can be opened using the fopen() function. The following example reads data from a mail box. fd = fopen("mba0:fred", 10) && Open unbuffered do while .t. data = fread(fd, 100) if len(data) <= 0 exit endif ?? data enddo Support Libraries There is a TSX support library (free of charge) available from myself or from S&H that allows you to write FoxPro applications specifically for the TSX environment. Among other things, this library can be used to see if the application is running under TSX, and if so, do something different than if running under DOS. For example, if you have FoxPro code that interfaces with a DOS CAS manager for faxing, you could change it to make calls to the FAX-32 process for faxing under TSX. The sample program should be enough to get you going on how to interface with TSX. Additionally, you will need a copy of the TSX-System Services manual for the specific syntax of each system service. Not all of the system services can be called from FoxPro. Specifically, system service calls that install completion routines is not supported. If using FoxPro 2.0, rename TSX_SY20.PLB to TSX_SYFN.PLB. FoxPro 2.5 and 2.6 need TSX_SY25.PLB renamed to TSX_SYFN.PLB. Please review the READ.ME and TSX_SYFN.C routine for a better understanding on what the routines do. FoxPro & TSX-BBS FoxPro can run from the TSX-BBS menuing system just as any other program. The main thing to keep in mind is that FoxPro wants a screen to talk to, and thus may not run well in a standard TTY mode without cursor control. If the remote terminal supports the ANSI escape sequences (such as ProComm or RIPterm), you should be able to develop color, windowed applications with little difficulties. It is also important to remember that many of the ANSI terminal emulators do not support sending the paging keys (PgUp, PgDn, Home, End), nor do they support any of the function keys. Unless you can dictate the emulation software the remote users are using, you should refrain from using any of keys that may not work in all cases. From the menu system or TPL, the command to launch a FoxPro program is as simple as tsxcmd("@sy:myapp.cmd",1) where sy:myapp.cmd is the command file described earlier. Problems Multi-tasking As mentioned in the Configuration section above, each user must have their own resource (FOXUSER) file. If users are allowed to multi-task (have more than one "screen" going at once), it is important to remember that each session is another user as far as FoxPro is concerned. If a user that is running a FoxPro task on his primary line starts up another task and attempts to run FoxPro again, there is a conflict with the resource files the user is pointing to. If this is allowed, you may need to come up with a more elaborate scheme of assigning users a unique set of FOXUSER files. VT100 and ANSI Terminal Access TSX allows VT100 and ANSI terminals or ter minal emulators to run FoxPro. When using one of these emulations, it is important to remember that these terminals do not support the ALT key. TSX supports the mapping of ALT keys when running on VT220 terminals, but it is not easy to communicate to an end user what to do. It is much easier to either avoid the ALT keys entirely, or to allow the first four function keys to access all functions via menus or popups. (Why only the first four function keys? Because the VT100 only supports F1 through F4. These keys correspond to the PF1 - PF4 on the VT220.) If F1 is used for help, F2 can be used to display the main popup menu. F3 and F4 can be use as user-definable function keys.