Interactive COBOL Windows Readme 4.89 15-Dec-2015 Introduction ------------ This readme file provides additional information that pertains to the Windows deployment of ICOBOL. Section 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 under Windows --------------------------------- Interactive COBOL on Windows is a 32-bit application for Windows. Most of the executables present a console interface. Interactive COBOL on Windows was built using the Microsoft Visual Studio .Net 2003 (C++ 7.1 compiler). Interactive COBOL on Windows requires: Windows 2000: Professional, Server, Advanced Server Windows XP: Home, Professional Windows Server 2003: all editions Windows Vista: all editions Windows Server 2008: all editions Windows 7: all editions Windows Server 2012: all editions Windows 8: all editions Interactive COBOL on Windows places some of its code in .DLL modules. These modules are used by various executables. Some of these modules are shown below: BIVBX11.DLL (Used by SP2 runtime) BIVBX11C.DLL (Used by SP2 runtime) BIVBX11S.DLL (Used by SP2 runtime) ICODBC32.DLL (ICODBC) ** ICODBCSU.DLL (ICODBC setup) ** ICOE702AS.DLL (Used by ICIDE) ICOT802AS.DLL (Used by ICIDE) ICRUN.DLL (Used by runtimes) ICSFL202AS.DLL (Used by ICIDE) ICSHELLX.DLL (Used for shell extensions) ICSYS.DLL (Used by many IC executables) ** INETWH32.DLL (Used by ICIDE) link_kit\ICBLTN.DLL (Optionally used by runtimes, user modules) MFC71.DLL (Microsoft) ** MSVCP71.DLL (Microsoft) ** MSVCR71.DLL (Microsoft) ** QPE.DLL (Used by ICQPRW) QPR.DLL (Used by FormPrint runtime) QPRCLI.DLL (Used by ThinClient (gui) client-FormPrint runtime) QPRIMA32.DLL (Used by ICQPR and FormPrint runtime)(JPEG) QPROCX32.DLL (Used by ICQPRW and FormPrint runtime)(ActiveX) QPRTVW32.DLL (Used by ICQPR and FormPrint runtime) QPRW.DLL (Used by ICQPRW) ROBOEX32.DLL (Used by ICIDE) RWUXTHEMES.dll (Used by ICIDE) SP2.DLL (Used by SP2 runtime) SP2CLI.DLL (Used by ThinClient (gui) client-SP2 runtime) SP2IMA32.DLL (Used by ICSP2 and SP2 runtime)(JPEG) SP2OCX32.DLL (Used by ICSP2 and SP2 runtime)(ActiveX) SP2TCSOK.DLL (Used by ThinClient (gui) client) SP2THRED.DLL (Used by SP2 runtime) SP2TVW32.DLL (Used by ICSP2 and SP2 runtime) SP2UNBUF.DLL (Used by ThinClient (gui) client) SP2VBX.DLL (Used by SP2 runtime) SP2VBX32.DLL (Used by SP2 runtime) tcs\AES.DLL (Used by ThinClient (gui) server) tcs\QPR.DLL (Used by ThinClient (gui) server) tcs\QPRSRV.DLL (Used by ThinClient (gui) server) tcs\SP2.DLL (Used by ThinClient (gui) server) tcs\SP2LOCAL.DLL (Used by ThinClient (gui) server) UIB.DLL (Used by ICSP2, ICQPRW) user_lib\ICUSER.DLL (Used by ICAPI applications) user_lib\ICUSERS.DLL (Used by ICAPI applications) VIC32.DLL (Used by ICSP2/ICQPRW and SP2/FormPrint runtimes)(JPEG) ** Copied to the system directory. 64-bit Windows Information -------------------------- This section provides information about running ICOBOL on the Windows x64 platforms. Windows XP Professional x64, Windows Server 2003 x64, Windows Vista (x64), Windows 7 (x64), Windows 8 (x64), and Windows Server 2012 all use an emulation layer called Windows on Windows x64 (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 the differences between 32-bit Windows and 64-bit Windows must be noted. For more information on differences between 32-bit Windows and Windows x64: For Windows XP x64: http://www.microsoft.com/windowsxp/64bit/default.mspx For Windows Server 2003 x64: http://www.microsoft.com/servers/64bit/overview.mspx For more information about Windows on Windows x64 (WOW64), see: http://msdn.microsoft.com/en-us/library/aa384274.aspx Installation on Windows x64 The installation process for Windows x64 is the same as that for 32-bit editions of Windows, though because of the WOW64 emulation layer, some installation prompts may default to different values. For instance, the default installation location for the files on Windows x32 is: C:\Program Files\ICOBOL For the installation running under Windows x64 edition, this becomes: C:\Program Files (x86)\ICOBOL (For 32-bit programs, Windows x64 provides new default installation targets for Program Files and Common Program Files): C:\Program Files (x86) C:\Program Files (x86)\Common Files Windows x64 Redirection The Windows x32 on Windows x64 (WOW64) platform provides 32-bit application services in a native 64-bit environment. To make sure that the 32-bit applications are kept separate from the 64-bit applications, WOW64 does some file and registry redirection. File System Redirection Windows x64 editions use file redirection for 32-bit programs to ensure that they work correctly in the 64-bit Windows environment. For instance, if you attempt to copy a 32-bit program or DLL file into the WINDOWS\SYSTEM32 folder on a Windows x64 system, the file will appear to be copied to the SYSTEM32 folder, and file properties may even report the file is in the SYSTEM32 folder, but the file will actually be copied to the WINDOWS\SysWOW64 folder. Registry Redirection Windows x64 editions use registry redirection for 32-bit programs to ensure that they work correctly in the 64-bit Windows environment. The registry in 64-bit versions of Windows is divided into 32-bit and 64-bit keys. Many of the 32-bit keys have the same names as their 64-bit counterparts, and vice versa. The default 64-bit version of Registry Editor (Regedit.exe) that is included with 64-bit versions of Windows displays both 64-bit keys and 32-bit keys. The WOW64 registry redirector presents 32-bit programs with different keys for 32-bit program registry entries. In the 64-bit version of Registry Editor, 32-bit keys are displayed under the following registry key: HKEY_LOCAL_MACHINE\Software\WOW6432Node You can view or edit both 64-bit and 32-bit registry keys and values by using the default 64-bit version of Registry Editor. To view or edit 64-bit keys, you must use the 64-bit version of Registry Editor (Regedit.exe). You can also view or edit 32-bit keys and values by using the 32-bit version of Registry Editor in the %systemroot%\Syswow64 folder. There are no differences in the way you perform tasks between the 32-bit version of Registry Editor and the 64-bit version of Registry Editor. To open the 32-bit version of Registry Editor, follow these steps: Click Start, and then click Run. In the Open box, type %systemroot%\syswow64\regedit, and then click OK. For instance, any registry entries written by a 32-bit program to the HKEY_LOCAL_MACHINE\Software registry key will actually get redirected to the HKEY_LOCAL_MACHINE\Software\Wow6432Node registry key instead. When a 32-bit application attempts to read from HKEY_LOCAL_MACHINE\Software, it gets redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node instead. Windows x64 ODBC changes 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 the %WINDIR%\SysWoW64 folder. The 64-bit version of the Odbcad32.exe file is located in the %WINDIR%\System32 folder. The ODBC Data Source Administrator has remained visually unchanged, but, being a native 64-bit application, it only sees native 64-bit ODBC Drivers. Few native 64-bit ODBC drivers are currently available for Windows x64. The ICODBC Driver is only 32-bit. 32-bit ODBC drivers can still be installed as on 32-bit Windows. These do not display in the 64-bit ODBC Data Source Administrator, but can still be accessed from the 32-bit ODBC Administrator, and by any 32-bit programs that use ODBC connectivity. The 32-bit ODBC Administrator is located: %WINDIR%\SysWOW64\ODBCAD32.EXE (Where %WINDIR% is the folder Windows is installed in, - often C:\Windows or C:\WIN). NOTE: The 64-bit and 32-bit ODBC Administrator programs are visually identical, and both show ODBC Data Source Administrator on their Window title bars. 32-bit User Data Source Issues As previously discussed, Windows x64 redirects registry reads and writes by 32-bit programs to ensure compatibility. However, it does NOT do this for the HKEY_CURRENT_USER key, since applications (both 64-bit and 32-bit) will still need to read and write data to this area. Because WOW64’s redirection of HKEY_LOCAL_MACHINE\Software registry key, the 32-bit ODBC Administrator will only display 32-bit System Data Source names, and the 64-bit ODBC Administrator will only display 64-bit System Data Source Names. However, 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. When you click Configure or Remove on any 32-bit User Data Source from the 64-bit ODBC Administrator, or vice versa, you will see errors. 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 Microsoft Internet Explorer (IE). ********************************************************************* ********** IMPORTANT. FOR WINDOWS ICNETD USERS ********** ********** UPGRADING FROM PRE-3.00 REVISIONS ********** Under Windows, when ICNETD started i/o surrogate processes for remote users, it previously (ICOBOL 2.63 and before) used a logon option that did not allow access to remote files or even to files on the local machine using a UNC name. After much debate we have decided to change this behavior to allow remote file access and the use of a local UNC name. ICNETD will start i/o surrogate processes with the LOGON_BATCH logon option. THIS WILL REQUIRE 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 200x Server with ACTIVE DIRECTORY ----------------------------------------------- If you have ICNETD running on a Windows 200x 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.) ********************************************************************* 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 if an Invalid Parameter (oserr=87) is received when trying to print make sure that the Microsoft print driver is not set to print directly. ICOBOL cannot send data to a print spooler that is set to Not spool but print directly. 3. Under Windows, when a user logs on using a serial line driven from ICEXEC to run COBOL programs, the environment for that particular user is not the same as if he had logged on to the Master Console. The working directory is set to the default ICOBOL working directory specified at ICOBOL installation and no other user-specific parameters are configured. In addition, there are probably no "mapped" drives for that user. Notes and Warnings under Windows -------------------------------- 1. 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. 2. 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 the ICSYS.DLL. The ICOBOL runtimes (ICRUN.EXE, ICRUNW.EXE, ICRUNRS.EXE, and ICRUNCGI.EXE) require the ICRUN.DLL. The ICBLTN.DLL is loaded if it is found. 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. 3. After installing Interactive COBOL, it's folder (directory) should NOT be renamed. To place the installation in a new directory, you should uninstall and re-install while saving any modified files. If the installation directory is renamed, uninstalling from the Control Panel will not work, certain shortcuts set up by the installation script will not work, and any service entries may not work. 4. 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 MS-DOS support and/or some UNIX support. These indicate that the printer will accept standard ASCII data and not need a special print driver that only works in specific Windows environment(s). 5. When using Printer Control Queues from the runtime, the user must have write access to the Windows spool directory. Under Windows it defaults to "\winnt\system32\spool\printers" or otherwise an access denied (exception 5) is returned when you try to print from the runtime system. 6. After installation, the Interactive COBOL screen will be shown with all the installed shortcuts. This is the best time to change any needed startup parameter by selecting the shortcut and right-clicking to properties. 7. When running ICRUN on a machine that serves up 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. If specifying COM ports on Windows, COM ports above 9 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. Under Windows, 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 or regedt32. **** The above registry entry is set with ,512 automatically **** **** when installing ICOBOL on a Windows machine if not **** **** already set. **** 10. Under Windows, automatic 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.) When doing a client install on a Windows NT machine, this "Service username/password" is prompted for at installation time. 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.) "When doing a client install on a Windows machine, these dependencies are set by the install program." 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. NOTE: Under Windows 2000, services CANNOT use executable files (.EXE, .DLL) stored on a network drive. The error "Access is denied" is reported. 11. Under Windows, 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. Under Windows, 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 (either server or local) and to place 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. If this is true and the username/password option was prompted for in the ICOBOL install then the Audit directory for the services is set to a Read-Only directory for this username. Either use ICSVCMGR or REGEDIT to change the command line to the particular service to may the Audit directory a different directory. Generally we recommend setting it the system directory (usually "C:\WINDOWS"). 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. Best Case A. The best case is to use ThinClients, ICRUNRC (Then all file access is local) Next best case, network Thick clients 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, when doing a client install, if the error "Unable to start runtime executive service is given" then ICEXEC was installed as a service but it could not start. See the Event log for more specifics but in most cases it will be that the username/password given on the client machine does not match that on the server. 16. If the ICOBOL User Library is being used, the icuser.dll or icusers.dll that the application program uses must be kept in sync with the released version of ICOBOL installed on the machine. This can be done by manually copying the appropriate icuser.dll or icusers.dll from the icobol\user_lib release directory into the application's release directory replacing the one already there. This is especially needed if the shared area changes from one revision to the next. 17. Under Windows 200x Server editions, if the Terminal Services package is installed then use of the "Change User /INSTALL" command may be required 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". 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. If this is true then the Audit directory for the services is set to a Read-Only directory. Either use ICSVCMGR or REGEDIT to change the command line to the particular service to make the Audit directory a different directory. Generally we recommend setting it to the system directory (usually "C:\WINDOWS"). OR uninstall and re-install after executing the "Change User /Install" command. Windows 200x/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. 18. 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). 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. Under Windows, these values must be set in the registry as: 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. Under Windows, ICINFO will report this value. 2. Under Windows, if serial lines are being used to run COBOL programs you cannot push to CMD.EXE. An error 128 is returned. You can push to CMD.EXE and execute a command or .bat file that does not require input and sends all its output to a listing file. For example, the command "cmd /c dir >lll" will execute the "dir" command sending its output to the file "lll" and returning to the COBOL program. We will continue to investigate running the command processor on serial lines but we currently do not know of a mechanism to allow input and output to come from the serial lines directly into the command processor. In addition, you must be careful when pushing off from serial lines that you do not start a GUI program that requires input since there is no desktop that is available to allow for input. If this happens you will need to terminate that process from the Task Manager. 3. Under Windows, to open a network printer you can use redirected LPT ports. I.E., a "NET USE LPT9 \\machine\printer" can be done and 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 that a real direct connect (like a serial or parallel 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. 4. Under Windows, after installation, to change the username/password value for any configured services you must use the ICSVCMGR utility (either command line or GUI). You CANNOT do an upgrade as it will NOT prompt for a new username/password. 5. Under Windows, when using a modem connected to a serial line, use the fastest (56K) baud setting for the COM port. Using slower baud settings tend to cause the connection to terminate. 6. If ICNETD is running on a Windows 200x server that is using Active Directory. If using thick clients (ICRUN, ICODBC) that cause ICIOS surrogates to be invoked, then those users must have the "log on as a batch job" privilege assigned to them. If using thin clients (ICRUNRC) that cause ICRUNRS servers to be invoked, then those users must have the "log on locally" privilege assigned to them. These can be set under the Domain Security policy object. However, if the Windows 200x 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. 7. 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. 8. With the release of Microsoft's Windows Services for UNIX 3.5 (SFU) and the inclusion of the telnet server in Windows XP, telneting into a Windows machine using just Microsoft components is easier. 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. 9. Under Windows, specific user environment variables can be created that will be available each time that user logs on. Windows XP ---------- These can be set by selecting "Control Panel" -> "System" -> "Advanced" tab -> and then selecting "Environment Variables". 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. Installation Planning for Windows --------------------------------- ICOBOL requires Windows 2000 and up. A. Single machine. (Simplest case) Install the software Configure the software Run B. Multiple machines. Is one machine going to be a server for executables, licenses, or data? Having one license server is much easier to support. Yes. Server ------ Install the software using the server option Configure the software Run Server and Client ----------------- To do Windows client installs, make sure that the Windows client machine has a profile (username/password) that has the correct privileges to start services on the client machine and has the privilege to use files on the server machine. The privileges needed on the client: a) Act as Part of the operating system, b) Debug programs, c) Log on as a service, and d) Replace a process level token. The privileges needed on the server: a) Access the computer from the network. Client ------ Now install the software (network option) on each client. Configure the software. Each machine should have a separate configuration file although all the configuration files could reside on the server machine with unique names for ease of support. Having separate configuration files allows for only those consoles enabled for a particular machine (this allows for unique terminal numbers across a network). It also allows for any machine differences (parallel ports, serial ports, printer names, different logical device defaults, etc.) to be taken into account. Run Repeat above Client for all clients. 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. 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 implies 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 greatly cutting down on 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 simple names to client open type 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, 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 200x 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) Pragma Systems (www.pragmasys.com) SeattleLab (www.seattlelab.com) Microsoft Available with XP and 2000 Server and up Also available as part of the Windows Services for UNIX End of readwin