Issue: Errors relating to COMMAND.COM with Citrix WinView Question: "Whenever I log into WinView as a NETWAREDOS autologin user, I receive the messages: 'SYS3015: An attempt to reload COMMAND.COM failed. SYS3016: This session was halted because COMMAND.COM cannot be loaded.' How do I remedy this situation?" COMMAND.COM and COMSPEC Background This is easily one of the most commonly posed questions to Citrix Technical Support. The purpose of this Tech Tip is to clear up any confusion our customers may still have. COMMAND.COM is the DOS command processor. It is the program that allows such DOS commands as DIR, COPY, DEL, TYPE, etc. to execute. These are called "internal" DOS commands as they are part of COMMAND.COM itself. Unlike "external" DOS commands such as FIND, SORT and XCOPY, "internal" DOS commands will not be displayed in a listing of the DOS directory (as they are "in" COMMAND.COM!) COMMAND.COM is the DOS program that is active when you are at the DOS prompt. In fact, COMMAND.COM displays the DOS prompt and parses commands that you type in at the prompt. It always occupies a portion of conventional memory, that is memory below 640k. You can view how much memory it occupies by typing "MEM /C" at a DOS prompt. When another DOS program is executed, COMMAND.COM allows a portion of itself to be overwritten in conventional memory to make room for the new program. The part of COMMAND.COM that is overwritten is called the transient part. The "stub" that stays in conventional memory is called the resident part. When a DOS program is exited, DOS uses the environment variable "COMSPEC" to locate the directory where the COMMAND.COM executable resides. It can then reload the transient part in order to display the DOS prompt. It is important that COMPSEC is set correctly to point to the directory where COMMAND.COM resides or errors will result. Also, with each version of DOS, WinView and MULITUSER, COMMAND.COM changes somewhat from previous versions. It is important that the correct version of COMMAND.COM is reloaded or errors will also occur. The error "SYS3016: This session was halted because COMMAND.COM cannot be loaded", among other errors, is a direct result of the COMSPEC environment variable being set incorrectly. By default under Citrix WinView and MULTIUSER, COMSPEC is set for "x:\OS2\MDOS\COMMAND.COM", where 'x' is the Citrix boot drive. With WinView and MULTIUSER, it is recommended that COMSPEC not be changed! At least 90% of the calls placed to Citrix Technical Support because of COMMAND.COM errors are due to the fact that Netware is involved. Netware has the ability to assign the manufacturer and version of DOS to the login script identifier variables "OS" and "OS_VERSION, respectively. Many times the Netware login script will change COMSPEC to point to a copy of COMMAND.COM that is located on the file server. The following lines were taken from a sample Netware login script to demonstrate how COMSPEC can be changed: WRITE "Your Operating System OEM is %OS" WRITE "The version of your operating system is %OS_VERSION" MAP S1:=SYS:\PUBLIC\%OS\%OS_VERSION COMSPEC=S1:COMMAND.COM This example will change COMSPEC to "Z:COMMAND.COM" If you were using Microsoft DOS 5.0, Z: would be mapped to SYS:\PUBLIC\MSDOS\V5.00. As long as this directory existed and a copy of COMMAND.COM was located there, everything would work fine for a DOS workstation running this version of DOS. Under WinView 2.21, 2.2 with the W220??.ZIP updates and later versions, OS=CITRIX and OS_VERSION=V2.21. With shipped WinView 2.2 and earlier versions, OS=CSDOS and OS_VERSION=V20.00. NOTE: With WinView 2.21 and later, WinView should keep the login script from altering COMSPEC for autologin users under the NETWAREDOS and NETWAREDOSMT groups. It is unnecessary to change COMSPEC in a Netware login script if every LAN workstation boots from it's hard drive. This is because it is much faster and decreases LAN traffic if COMMAND.COM is reloaded from the local drive instead of the file server. The above method of altering COMSPEC is the number one reason users get COMMAND.COM errors with WinView. Here are three ways to alleviate the problem: 1) Remove the lines that change COMSPEC from the login script. This will decrease network traffic for LANs that have only hard drive boot workstations, but make sure you know what this will change in your network setup. 2) RECOMMENDED: Use the DOS environment variable "HOSTNAME". WinView always sets this environment variable in DOS and OS/2 sessions and can be used in a login script so that COMSPEC is only changed when not using WinView. Below is an example login script: WRITE "Your Operating System OEM is %OS" WRITE "The version of your operating system is %OS_VERSION" IF = "" THEN MAP S1:=SYS:\PUBLIC\%OS\%OS_VERSION COMSPEC=S1:COMMAND.COM END This will only change COMSPEC when HOSTNAME has not been set. In other words COMSPEC will not be changed for users that login through WinView. 3) Create a directory structure like SYS:\PUBLIC\CITRIX\V2.21 and copy COMMAND.COM from the WinView \OS2\MDOS directory to this new directory on the file server. This is not really recommended since this method is slower than reloading COMMAND.COM from the WinView drive and it will also increase network traffic. Steps To Troubleshoot COMMAND.COM Errors 1) In order to locate the true cause of the invalid COMMAND.COM errors, you must know what COMSPEC is set to when a DOS session is initially started. Type "SET" at a DOS prompt immediately after the DOS session starts to check the value of COMMAND.COM. The SET command must be used before other programs or commands are executed. This is because another program will cause the transient part of COMMAND.COM to be overwritten, thus causing COMMAND.COM errors when DOS attempts to reload COMMAND.COM. 2) If COMSPEC is still correctly set to "x:\OS2\MDOS\COMMAND.COM", where 'x' is the WinView boot drive, then you may have one of two problems: a) Type "MAP" to see if 'x' is mapped to a Netware directory. For instance, this happens quite often when the WinView boot drive is renamed to M: (or other letter) and the login script maps the same drive letter (in this case M:) to a directory on the file server. If this is the case, you have two options: Either remove the MAP statement for that particular drive letter from the Netware login script(s) OR reformat and reinstall WinView, choosing a drive letter that is ununsed by Netware. b) If 'x' has not been mapped to a Netware directory, then someone has probably changed the accessability of COMMAND.COM in the WinView \OS2\MDOS directory. Type "DIR x: /AD" (again 'x' is the WinView boot drive.) This will show all the directories off the root for the WinView boot drive. In this directory listing, you should see the \OS2, \USR, \WINCRED directories among others. If this is not the case, you may are not be looking at the WinView drive and step 2a should be reviewed. It may be possible that you are looking at the WinView drive, but the user you are logged in as does not have sufficient security to view these directories. Login to WinView as an administrator and check the security access by using the "CONFIG ACCESS" utitlity. It is imperative that all WinView users have read and execute access to the \OS2\MDOS directory. This is the default. Consult Chapter 5 of the "System Administrator's Guide" for more information of configuring system security. If security has not been changed, make sure that COMMAND.COM exists in the \OS2\MDOS directory. You should be able to type "COMMAND" at an OS/2 prompt to start a basic DOS session. 3) If COMSPEC has been changed, for example "COMSPEC=Z:COMMAND.COM", then you must track down where it has been changed. Type "SET COMSPEC=x:\OS2\MDOS\COMMAND.COM", again where 'x' is the WinView boot drive. This will ensure that your session will not halt because COMMAND.COM could not be reloaded. a) Most of the time COMSPEC is being changed in the Netware system login script, although it may be in the user login script. You should probably use the "HOSTNAME" environment variable to keep COMSPEC from changing. Review the discussion at the end of the "Background" section above to fix the problem. b) COMSPEC may be changed in a batch file. Check the AUTOEXEC.BAT file in the user's home directory. If one does not exist there, check AUTOEXEC.BAT in the \OS2\MDOS directory. Remove any occurence of "SET COMSPEC=" from these files. Also check any batch files that may run before a prompt is displayed. For instance, the login script(s) may call a batch file. Check both login scripts and look for lines that begin with the "#" symbol. This symbol instructs the login script to execute a DOS command. If any of these is a batch file, check each batch file for instances of "SET COMSPEC" and remove that line. Summary This tech note does not have all the answers to solve the COMMAND.COM errors, but chances are one of the troubleshooting steps will solve your problem. Remember it is critical that the SET command be used as soon as possible. If your login script runs a menu or other program, temporarily REM this line out, or you cannot troubleshoot the problem.