Interactive COBOL Windows Readme 5.2x 21-Oct-2016 Introduction ------------ This readme file provides additional information that pertains to the Windows deployment of ICOBOL. Sections in this readme include: General Information 64-bit Windows Information Known Problems Notes and Warnings Helpful Hints Installation Planning Frequently asked Questions Additional Third Party Software General Information ------------------- ICOBOL is installed from a single installer that contains both the 32-bit and the 64-bit versions of ICOBOL. The installer will automatically detect the version of Windows and install the appropriate version of ICOBOL. The 32-bit version will be installed on a 32-bit version of Windows. The 64-bit version will be installed on a 64-bit version of Windows, with the addition of certain 32-bit pieces. In some cases, a 32-bit piece corresponds to a 64-bit piece and is present in order to run that piece in either mode - e.g., the runtime system itself. In other cases, a 32-bit piece is present because it is only available in a 32-bit version. The 32-bit pieces will be installed under a folder named 'x86' within the main installation folder. Interactive COBOL was built using Microsoft Visual Studio Professional 2012, except for the ICIDE, which was built with Visual Studio .NET 2003. Interactive COBOL requires: Windows Vista: all editions (Service Pack 2 and up) Windows Server 2008: all editions (Service Pack 2 and up) Windows 7: all editions Windows Server 2008 R2: all editions Windows 8: all editions Windows Server 2012: all editions Windows 8.1: all editions Windows Server 2012 R2: all editions Windows 10: all editions 64-bit Windows Information -------------------------- The 64-bit versions of Windows all use an emulation layer called Windows on Windows x64, or WOW64, to enable 32-bit applications to function as if they were running under 32-bit Windows. WOW64 provides interoperability between 64-bit and 32-bit applications for scenarios such as cut / copy / paste and COM. WOW64 is very nearly invisible to applications and to users, but there are a few instances where knowing the differences between 32-bit Windows and 64-bit Windows may be helpful. For more information see: http://www.microsoft.com/servers/64bit/overview.mspx http://msdn.microsoft.com/en-us/library/aa384274.aspx The WOW64 emulation layer uses two main techniques to allow 32-bit applications to access system resources as if they were running on 32-bit Windows: file system redirection and registry redirection. File system redirection occurs when a 32-bit program or DLL is copied to certain system folders reserved for 64-bit components. The WOW64 layer intercepts these and actually copies the files to its own folder. For example, a file copied to Windows\System32 is copied to Windows\SysWOW64. Similarly, registry redirection occurs when a 32-bit program accesses the system registry. Certain parts of the registry have 32-bit and 64-bit versions of common keys and values. The WOW64 layer automatically redirects the registry references to the 32-bit copies. For example, an attempt to read from HKEY_LOCAL_MACHINE\Software, is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node instead. As we mentioned, this was designed to invisible to the end user and so you shouldn't have to be concerned about it. Windows x64 ODBC ---------------- One of the areas where the 32-bit / 64-bit difference is visible is with ODBC. The Open Database Connectivity (ODBC) driver interface has been revised for Windows x64. x64 Windows platforms include two versions of the Microsoft Open Database Connectivity (ODBC) Data Source Administrator (odbcad32.exe): The 32-bit version of the Odbcad32.exe file is located in %WINDIR%\SysWoW64 The 64-bit version of the Odbcad32.exe file is located in %WINDIR%\System32 These locations reflect the file system redirection mentioned above. As a result of the registry redirection that takes place when each of these versions of the administrator run, the 64-bit version only "sees" 64-bit ODBC drivers and data sources; and, the 32-bit version only "sees" 32-bit ODBC drivers and data sources. When ICOBOL is installed, shortcuts are built to both of the ODBC administrators so that you can work with the appropriate drivers and data sources. Also both the 32-bit and the 64-bit versions of the ICOBOL ODBC driver are installed. This makes it possible to access your ICOBOL data from third party applications that are 32-bit or 64-bit as needed. As previously discussed, Windows x64 redirects registry reads and writes by 32-bit programs to ensure compatibility. However, it does NOT do this in the same way for the HKEY_CURRENT_USER key, which is where applications store user-specific data. As a result, data sources created in the User DSN tab of the ODBC Administrator are created in the HKEY_CURRENT_User\Software key, which is shared for 64-bit and 32-bit programs. This means that any User Data Source created from either the 64-bit or 32-bit ODBC Administrator will display on both ODBC Administrator screens. However, the data source is still 32-bit or 64-bit specific, and so if you click Configure or Remove on any 32-bit User DSN from the 64-bit ODBC Administrator, or vice versa, you will see errors. It is recommended that you incorporate a bit-width indicator of some sort into the User DSN name so that you can be sure you manage them properly. DLL's An important WOW64 limitation is that 32-bit applications cannot load 64-bit dynamic-link libraries (DLLs) and 64-bit applications cannot load 32-bit DLLs. This means that 32-bit ActiveX® controls, for example, cannot be run in the 64-bit version of the ICOBOL Runtime using SP2. This restriction is one reason why ICOBOL installs both the 32-bit and 64-bit versions of the runtime system. There may be times when the use of third-party components may require that you run the compatible version of the runtime system. ********************************************************************* Known Problems under Windows ----------------------------- 1. The runtime currently has no way to detect a modem such that at OPEN time the open should pend until CD (Carrier Detect) goes high. 2. When trying to use Microsoft printers through the ICOBOL Printer Control System you may experience the error "Invalid Parameter (oserr=87)". This can be caused because the Microsoft print driver is set to print directly instead of spooling the data. Notes and Warnings under Windows -------------------------------- 1. ****************************************************************** ********** IMPORTANT. FOR WINDOWS ICNETD USERS ******** ********** UPGRADING FROM PRE-3.00 REVISIONS ******** Under Windows, ICNETD will start i/o surrogate processes with the LOGON_BATCH logon option. THIS REQUIRES THAT ALL USER PROFILES ON THE ICNETD SERVER MACHINE THAT WILL USE ICNETD SURROGATES MUST HAVE THE "log on as a batch job" USER RIGHT. To add this user right, do the following on the machine on which ICNETD is running: Under Windows ------------- Click Start, Select Settings, and Open Control Panel, Open Administrative Tools, Open Local Security Policy which runs as Local Security Settings, Open Local Policies, Open User Rights Assignment, Open Log on as a batch job, Use Add to assign the users/groups with the right. Under Windows Server with ACTIVE DIRECTORY ----------------------------------------------- If you have ICNETD running on a Windows server that is using Active Directory and is a member server, then you need to assign the 'log on as a batch job' privilege to users under the Domain Security policy object. However, if ICNETD is running on the domain controller itself, then assign the privilege under the Domain Controller Security policy object. ICNETD users are encouraged to ONLY use files local to the machine on which the surrogate is running. (Do not hop multiple times.) 2. Serial device default baud rate settings: The runtime uses the last setting for serial devices to set up the default parameters (baud, parity, data, etc.) on an open. The MODE command can be used to perform these settings if needed. This MODE will be remembered until another setting is stored. In addition, extended open options can be used to set the needed values. 3. Interactive COBOL on Windows uses .DLLs to load portions of its code at run time. The following rules apply as to how a .DLL is found. A. First the system searches the set of pre-installed DLLs. B. Next, the directory where the executable module for the current process is located is searched. C. The current directory is searched. D. The windows system directory is searched. E. The windows directory is searched. F. The directories in the PATH environment variable are searched. If a specific .DLL cannot be located, the system terminates the process and displays a dialog box that reports the error. Almost all ICOBOL executables require ICSYS32.DLL or ICSYS64.DLL. The ICOBOL runtimes (ICRUN.EXE, ICRUNW.EXE, ICRUNRS.EXE, and ICRUNCGI.EXE) require the ICRUN32.DLL or ICRUN64.DLL. The SP2.DLL is loaded when required for SP2. The QPR.DLL is loaded when required for FormPrint. ICPERMIT.EXE requires the appropriate Sentinel drivers if a parallel or usb protection device is being used. ICSP2.EXE and ICQPRW.EXE require the UIB.DLL. 4. After installing Interactive COBOL, it's folder (directory) should NOT be renamed or moved. If the installation folder is renamed or moved, uninstalling from the Control Panel will not work, shortcuts set up by the installation script will not work, and the ICOBOL services will stop working. To rename or move the installation to a new folder, you should first save any files that were modified inside the installation folder, then uninstall the current installation. Next, re-install in the new location and restore any of the modified files you saved earlier. Note that ICOBOL must be installed on a non-removable, non-network drive in order for the services to work properly. The layout of ICOBOL 5 has changed such that it should never be necessary to modify any files in the installation folder. 5. When trying to get printing to work under Windows use Notepad to see what printers are available on this machine and if you can print a sample file to that printer. This can be done by starting Notepad and then select File > Page Setup. In Page Setup select printer and then pull-down the name box to see all the valid printer names. These are the names that can be entered into the PCQ device selection in ICCONFIG. Now select the printer to send some test output to and go back to the Notepad screen. Enter some data and then select File > Print. If the data does not print, work with Windows to get it to print before preceeding to ICRUN. ICINFO can also be used to see the default and current printer selections. If after setup, the runtime prints to a printer with no error but no paper comes out of the printer, do the following: A) pause the Windows print spooler, B) re-print the file from the runtime, C) check the Windows print spooler and make sure the file is there, D) if so, that says that ICOBOL did get the data to the Windows printer, now un-pause the printer, E) if the file "prints" and disappears from the screen but no paper comes out of the printer, then this probably means that the printer in its current state does not handle ASCII data. Its running in "GDI" mode. You can confirm this if the printer is connected to a parallel port by going to the local machine with the printer and from the command prompt do a "dir >lpt1". If nothing comes out on the printer then its a GDI printer (or Windows printer). When buying printers, look for ones that say they will work with Apple MacOS, or versions of Unix or Linux. This typically indicates that the printer will accept standard ASCII data and does not require a special print driver that only works in Windows. 6. When using Printer Control Queues from the runtime, the user must have write access to the Windows spool folder; otherwise, an "access denied (exception 5)" will be returned when you try to print from the runtime system. The default location for the spool folder is "%WinDir%\system32\spool\printers". 7. When running ICRUN on a machine that shares its disks to the network, local files are known as "drive:\directory...\filename". When using the ICOBOL Printer Control Utility, files created on this machine by a local runtime will place these "locally-centric" names into the .pq file. No runtime running on a remote machine will have access to these files. A workaround for simple filenames is to set the ICPCQDIR environment variable to the UNC name of the directory on the local machine where these print files will be stored. In this way, the full UNC name will be stored in the .pq file. I.E., set ICPCQDIR=\\mainmachine\c\prints. 8. When using COM ports above 9, the name must be given as \\.\COMx. COM1-9 can also be specified with this format. Also note that most command line programs cannot handle COM10 or greater. (See Microsoft article Q115831 - HOWTO: Specify Serial Ports Larger than COM9) 9. If you get one of the following errors: A. "Initialization of the dynamic library ...\system32\user32.dll failed", B. In the ICEXEC log, you get an exit code 128 when starting a runtime, C. In the ICNETD log, you get an exit code 128 when starting an icnetd surrogate (either icios, icrunrs, or iclogs), or D. you just cannot seem to get more than 4-10 runtimes running on serial lines or telnet sessions or ICNETD surrogates logged on, then look at the Microsoft Article ID Q184802 which gives information on updating the registry for a particular value for heap memory. WARNING: USING REGISTRY EDITOR INCORRECTLY CAN CAUSE SERIOUS, SYSTEM-WIDE PROBLEMS THAT MAY REQUIRE YOU TO REINSTALL WINDOWS TO CORRECT THEM. USE THIS TOOL AT YOUR OWN RISK. This article describes updating the following subkey under the HKEY_LOCAL_MACHINE subtree: \System\CurrentControlSet\Control\Session Manager\SubSystems\Windows Where there is a "SharedSection=1024,3072" in the data for this value you must replace it with "SharedSection=1024,3072,512". You must reboot for the new value(s) to take effect. The "512" causes each heap allocation to be smaller to keep from overflowing the Windows Heap space which is fixed allocated. This value should increase the number of allowed processes. To further increase process count continue to decrease this number to 256 and then 128, if needed. Please read the Microsoft Article Q184802 for more information on this setting. NOTE: ICINFO prints out the value for this registry entry as "NT Heap:" so you can see the setting without starting regedit. 10. The ICOBOL services must be careful in their use of network files at startup. The following rules must be followed: A. Mapped drive names cannot be used, use a UNC name. (No drive mapping is available to the service manager.) B. A specific username/password must be specified for the service that allows running as a service AND has network access to the remote machine(s). (The default username for a service does not allow remote access of network files.) C. The service must have a dependency set that prevents it from starting until after the network is available. (In the default case, services are started in basically alphabetical order.) ICSVCMGR can be used to set or change the username/password and the dependency settings if needed. This applies to the .lic file for ICPERMIT and the .cfi and .pq files for ICEXEC and to any needed executables. 11. If, when using standard Microsoft networking (i.e., you open files using drive letters that have been mapped to shared drives/directories on another machine) you experience file corruption then make the following change to the Windows registry. Follow the steps below to make the change. WARNING: USING REGISTRY EDITOR INCORRECTLY CAN CAUSE SERIOUS, SYSTEM-WIDE PROBLEMS THAT MAY REQUIRE YOU TO REINSTALL WINDOWS TO CORRECT THEM. USE THIS TOOL AT YOUR OWN RISK. A. Start the Registry Editor and go to the following subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\LanmanServer\Parameters B. Add or change the following: Value name: EnableOpLocks Data Type: REG_DWORD Data: 0 (Default: 1) (This entry defaults to 1 (True) if no value is specified.) C. Exit the Registry Editor EnableOpLocks specifies whether the server allows clients to use oplocks (opportunistic locking) on files. Oplocks are a performance enhancement, but have the potential to cause lost cached data on some networks, particularly wide-area networks. **** The above registry entry is set automatically when **** **** installing ICOBOL, but other program installers **** **** can reset this value. **** On a Windows machine only being used as a client, opportunistic locking can be disabled just on that machine as follows. (If you have made the above change to the server machine this change is unnecessary.) Follow the steps below to make the change. WARNING: USING REGISTRY EDITOR INCORRECTLY CAN CAUSE SERIOUS, SYSTEM-WIDE PROBLEMS THAT MAY REQUIRE YOU TO REINSTALL WINDOWS TO CORRECT THEM. USE THIS TOOL AT YOUR OWN RISK. A. Start the Registry Editor and go to the following subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\LanmanWorkstation\Parameters B. Add or change the following: Value name: UseOpportunisticLocking Data Type: REG_DWORD Data: 0 (Default: 1) (This entry defaults to 1 (True) if no value is specified.) C. Exit the Registry Editor UseOpportunisticLocking specifies whether the workstation redirector should use opportunistic-locking (oplock) performance enhancement. ICINFO has been updated to show these values under Windows. More information on this can be found by reading Microsoft Articles Q129202 or Q102967. 12. If an environment variable (like ICROOT) is placed in the system environment then if you change its value you must remember to re-boot to allow all the processes (especially the service manager) to see the change. This is especially true if ICROOT was placed in the system environment and then a new revision is loaded into a different directory. NOTE: Setting ICROOT in the system environment is generally not recommended as it is always available from the registry entry set by the ICOBOL installation for all ICOBOL executables. 13. Under Windows Terminal Server edition, we recommend doing a full install and placing the configuration and printer control queue files locally. If you do not follow the above then the following may be required: A. You may need to run the REGISTER command with the /SYSTEM option on the icexec.exe executable if you get an error when starting the runtime about no shared area when logged in using Terminal Server Clients but the runtime works when run from the master console. For example: REGISTER ICEXEC.EXE /SYSTEM B. Services may not start and give a error code 4 in the Event Log. This may be caused because the user does not have write access to the folder containing the log. Windows Terminal Server is a good platform for ICOBOL since the applications actually run on the server and only the screen/keyboard is run on the client. 14. Performance Hints on a network. A. For best performance, use ThinClient (ICRUNRC) to the server (Then all file access is local on the server) The second best case is to use network thick clients where the programs are local to the client machine and data files are accessed in client-servoer mode (ICNETD+ICIOS). The worst case is to access programs and data files via mapped folder from the server. B. Set ICTMPDIR to a local directory. C. If using a link file, make the link file local. D. If using a library file, make the library file local. E. Use ICNETD to access remote files. F. If possible, open a file EXCLUSIVELY, it will process much, much faster as local buffering will be performed. 15. Under Windows Server editions with the Terminal Services package installed, use the "Change User /INSTALL" command before doing an ICOBOL install. This allows files to be placed in the correct Windows system directories. Return the system to the correct mode by doing a "Change User /Execute" command. To check to see what mode the system is in you can do a "Change User /Query". If you do not follow the above then the following may result: A. Services may not start and give a error code 4 in the Event Log. Uninstall and then re-install after executing the "Change User /Install" command. Helpful Hints under Windows --------------------------- 1. When using network connections (ICNETD to ICIOS, ICRUNRS, or telnet), TCP/IP Keepalives are used to detect client/server unexpected terminations. Each side of a connection will use its Keepalive time to determine when to start querying the other. NOTE: Most TCP/IP implementations default to 2 hours (7200 seconds) before the first keepalive is sent and then it generally takes 10 minutes before the connection is closed. For more information on Keepalives please see your operating system documentation. These values must be set in the registry at: Hkey_Local_Machine\System\CurrentControlSet\Services\TCPIP\Parameters Value KeepAliveTime (in milliseconds) default: 7200000 (2 hours). (Dword) See Microsoft Articles ID Q120642, Q140325 for more information. ICINFO will report this value. 2. To open a network printer you can use redirected LPT ports. For example, if we used the command "NET USE LPT9 \\machine\printer" then LPT9 can be entered as the device name for an @PRN or @SER logical device. When using shared printers in this fashion remember that they are no longer "DIRECTLY CONNECTED". There will be some buffering and/or queueing that is done by the sharing entity that will cause WRITEs to the device to act differently from a directly connected device (like a serial, parallel, or USB port) that physically resides in the current machine. In most cases a CLOSE must be done to the device to ensure that all data has been written. Also in some cases an implicit CLOSE will be done automatically (not by ICOBOL) but by the sharing entity if there is no activity for some time period (like a minute) on that file. This is done to ensure that remote processes will not tie up a network resource. 3. When using a modem connected to a serial line, use the fastest available baud rate setting for the COM port. Using slower baud settings tend to cause the connection to terminate. 4. If ICNETD is running on a Windows server that is using Active Directory certain user privileges may have to be granted in order for the server-side surrogate processes to run properly. The user accounts used by ICIOS, ICLOGS, and ICSQLS surrogates must have the "log on as a batch job" privilege assigned to them. The user accounts used by ICRUNRS surrogates must have the "log on locally" privilege assigned to them. These can be set under the Domain Security policy object. However, if the Windows Server is also a domain controller, then you need to assign the privilege under the Domain Controller Security policy object. Please note that it usually takes some time for any new privileges to take affect unless a re-boot is performed. 5. The ICINFO program can be used to detect usage of semaphores by Interactive COBOL. ICINFO will display whether it can acquire each of the semaphore's that are used. If it cannot acquire a particular semaphore then Interactive COBOL could be hung. Rerun ICINFO at least one more time to give the semaphore a chance to clear. Any hangs that occur in which icinfo reports a hang should be reported to your supplier or ENVYR Corporation. 6. The character mode runtime (ICRUN) can be used with many telnet servers. (as of 2/1/2016 the latest Microsoft Telnet servers do not appear to be compatible with ICOBOL. Please conside one of the products list at the end of this reame if you need a Windows Telnet Server.) If you are coming from another Windows machine using the standard Microsoft telnet then you probably want to run both the client and the server in "Console" mode. This will be like the "Advanced" mode documented under ICEXEC. If you are using another telnet client or coming from a UNIX machine then you probably want to run the telnet server in "Stream" mode. In this case the telnet server does no interpretation on the data stream, it is like the "Simple" mode documented under ICEXEC and it requires that ICTERM be set to the appropriate terminal type for ICRUN. You must also set up some special environment variables to "trick" the runtime into detecting this mode since it cannot be detected normally. Set an environment variable "REMOTEADDRESS=xxxx" and then make sure the environment variable TERM is set before calling the runtime. 7. One way to customize the behavior of Interactive COBOL is through the use of Environment Variables. Windows has two sets of environment variables, system-wide environment variables and per-user environment variables. These named values are set up by the operating system when a user logs into Windows. Setting the sytem-wide environment variables requires administrator privileges. Setting a particular user's environment variables required being logged in as that user. Windows Vista/Windows 7 ----------------------- These can be set by selecting "Control Panel" -> "User Accounts" -> "User Accounts" -> and then selecting "Change my environment variables". (all) ------ The "User variables for ", allows specific environment variables to be set for particular users. For example ICRUNDIR=\home\mary. These environment variables will be set each time that user logs on. The system environment variables can also be seen in this screen. 8. Entering characters above decimal 127 with the ALT key. To input characters that are not on your keyboard. Press and hold the ALT key, and then press the keys on the numeric keypad that represent the decimal code value of the character you want to input. After you finish typing, release the ALT key. Windows generates the character you specified. Note: If the first digit you type is 0, the value is recognized as a code point, or character value, in the current input language. For example, when your current input language is US-English (Code page 1252: Windows Latin-1), pressing ALT and then typing 0163 on the numeric keypad produces £, the pound sign (U+00A3). When your current input language is Russia (code page 1251: Windows Cyrillic), the same key sequence produces the Cyrillic capital letter JE (U+0408). If the first digit you type is any number from 1 through 9, the value is recognized as a code point in the system's OEM code page. The result differs depending on the Windows system language specified in Regional and Language Options in Control Panel. For example, if your system language is English (US), the code page is 437 (MS-DOS Latin US), so pressing ALT and then typing 163 on the numeric keypad produces ú (U+00FA, Latin lowercase letter U with acute). If your system language is Greek (OEM code page 737 MS-DOS Greek), the same sequence produces the Greek lowercase letter MU (U+03BC). Installation Planning for Windows --------------------------------- ICOBOL requires Windows Vista or Windows Server 2008 and up. A. Single machine. (Simplest case) Install the software Install Licensing Configure the software Run Frequently asked questions under Windows ----------------------------------------- 1. How do I have unique terminal numbers across the network? There is no automatic way of enforcing unique terminal numbers across a network. On a single Windows machine, ICEXEC controls providing unique terminal numbers on that ONE machine. Currently the only way to provide unique terminal numbers across the network with multiple machines running ICOBOL is to have different configuration files for each machine with different (unique) consoles enabled for each configuration. These configuration files could all reside on one machine for ease of maintenance. By using ThinClient's this problem can be solved as all runtimes will be running on the server machine. 2. How do I see other runtimes on the network, they do not show up in my Terminal Status screen? Currently the only way to see other runtimes is on a single Windows machine where ICEXEC has created a shared area that all runtimes use. The Terminal Status screen uses this shared area to show the information on the runtimes in use. By using ThinClient's this problem can be solved as all runtimes will be running on the server machine. 3. What does ICNETD do for me? Normally when the COBOL program accesses data over a network using standard Microsoft networking, disk blocks must be moved back and forth to allow the runtime on a client machine to get at the needed data from the server. This causes much network traffic. By running the ICNETD server on the server machine and using a client open (like "@\\machine\c:\mydata\file87") to open the file, only record requests and responses are sent over the network, which greatly reduces network traffic. In most cases, this provides a performance boost to the whole network and particularly to the COBOL application. The drawback to this approach is that OPEN's to files that have just been closed are slower. In addition, icnetd encodes the data it sends over the network to provide additional security against packet snooping and it runs over standard TCP/IP and is routable - meaning it can run over a wide area network or even the internet. NOTE: ICLINK can be used to map local names to client-server names. 4. What does the IC ODBC driver do for me? The IC ODBC driver allows you to use standard personal productivity tools like Crystal Reports, Excel, etc. to access (and optionally modify) data from ICISAM files. 5. What does the sp2 package do for me? The sp2 product allows for GUI screen development. A particular window (panel) can be developed and then COBOL source can be generated to be included in COBOL programs to allow for access to the GUI screen under the Windows environment. 6. What does the FormPrint package do for me? The FormPrint product allows for GUI-type print forms to be developed, much like the screen GUI's developed by the SP2 product but with no keyboard/mouse interaction. With FormPrint, the COBOL programmer has total control of how the data will be presented on the printer device. 7. What is Windows Terminal Server edition? Windows Terminal Server edition is a special package of Windows Server along with a special "Terminal" package that allows client logins from "Client Sessions" running the Remote Desktop Protocol from another computer or thinclient device (often called Winterms). These sessions actually run the programs on the Windows Terminal Server machine with only the screen part being reflected out to the client. This provides multi-user operation of the base machine just like UNIX machines. The network and/or serial connection is only used to send compressed screen data to the client and receive keyboard/mouse data from the client. All disk I/O is done at machine/memory speeds on the base machine. In addition, WinTerms (a fancy dumb terminal or a very simple pc, depending on how you look at it) can also be used as a client. Also a company by the name of Citrix makes additional add-ons that allow UNIX clients among others to be added. Terminal Services is an installable option included as part of Windows Server editions, but additional terminal server licenses are required from Microsoft. 8. Under Windows, when using Event Viewer to view the System Log there are messages by the Service Control Manager about the ICOBOL services (icexec, icpermit, icnetd), what do they mean? In the event log if there is a message like: "The icnetd service terminated with service-specific error 6." or "The icexec service failed to start due to service-specific error 6." The service-specific error is the exit code from that executable. Exit codes are documented in the Installing and Configuring on Windows Manual in the Introduction chapter. Also in most cases there should a log file (icexec.lg, icpermit.lg, or icnetd.lg) in the system directory (usually "C:\WINDOWS") that gives the specific error message. If there is a message like: "The icexec service failed to start due to the following error: The service did not start due to a login failure." Then you need to look at the next message in the event log. It should be the actual logon error. It should tell you that the username that you were using does not have the appropriate privilege setting. Please check that the username has the needed privileges on this machine and on any network machine that it is trying to access. Several Telnet Servers are available for Windows from: (Alphabetical order) Ataman (www.ataman.com) Georgia SoftWorks (www.georgiasoftworks.com) GoodTech Systems (www.goodtechsys.com) KpyM (www.kpym.com/2/kpym) Pragma Systems (www.pragmasys.com) SeattleLab (www.seattlelab.com) Microsoft (Control Panel->Programs and Features) (as of 2/1/2016 the latest Microsoft Telnet servers do not appear to be compatible with ICOBOL. Please conside one of the above products if you need a Windows Telnet Server.) End of readwin