OS/2 Shareware BBS: 26 Fixes1x

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Shareware BBS: 26 Fixes1x / 26-Fixes1x.zip / 1301read.zip / README.LAN < prev next >

Wrap

Text File | 1991-05-02 | 48KB | 1,061 lines

│ Page i │ │ │ OS/2 LAN Server 1.30.1 README.DOC │ │ │ │ │ OS/2 Commands ......................................................... 1 │ DOS LAN Requester │ Upgrading disked workstations .................................... 1 │ Upgrading remote IPL workstations ................................ 2 │ Migrating from PCLP to DOS LAN Requester ......................... 2 │ IBM PC 3270 Emulation ............................................ 2 │ DOS 3.3 Tree Command ............................................. 2 │ Publications │ Additional NET ACCOUNTS command parameter ........................ 2 │ NET USER /TIMES .................................................. 3 │ Using Replicator service to back up the DCDB...................... 3 │ Description of workstation heuristic 24 .......................... 3 │ Maximum value for numbigbuf parameter ............................ 3 │ Using the IBM LAN Support Program Configuration Aid .............. 3 │ OS/2 LAN Server │ Caching changes .................................................. 4 │ Home directory changes ........................................... 5 │ When to disable opportunistic locking ............................ 8 │ Changing server heuristic 7 (srvheuristic) in large networks ..... 8 │ Keyboard response time on heavily used servers ................... 8 │ Renaming directories ............................................. 8 │ Installation of LAN Server if a domain control database exists ... 8 │ Cleanup parameter not included in default IBMLAN.INI ............. 8 │ Re-establishing connection to dynamically shared resources ....... 8 │ Migration Utility information on migration utility diskette ........... 9 │ Network Printing │ Presentation Manager printing .................................... 9 │ Remote set up of printers and queues ............................. 9 │ Refresh interval .................................................10 │ Local security ...................................................10 │ DOS compatibility mode ...........................................10 │ Printing to a LAN Server 1.2 .....................................11 │ Interoperability │ Interoperability of IBM LAN Servers and Requesters ...............11 │ Interoperability of Novell NetWare and IBM DOS LAN Requesters ....12 │ Interoperability of Novell NetWare and IBM OS/2 LAN Requesters ...14 │ Miscellaneous │ Handshaking for a COM device should be specified .................16 │ Sending files terminated by CTRL-Z ...............................16 │ Making a remote IPL image not containing the DOS LAN Requester ...16 │ Remote IPL definition file for low density 5.25 diskette .........16 │ Removing the OS/2 LAN Requester ..................................16 │ At, NET RUN, and NET ADMIN command execution .....................16 Page ii ┌─────────────────┐ │Trademark Notices│ └─────────────────┘ ■ The following terms, denoted by an asterisk (*) in this file, are trademarks of the IBM Corporation in the United States and/or other countries: IBM OS/2 Presentation Manager ETHERAND PC Network ■ The following terms, denoted by a double asterisk (**) in this file, are trademarks of other companies as follows: Novell Novell, Inc. NetWare Novell, Inc. Internetwork Packet Exchange (IPX) Novell, Inc. Page 1 ┌─────────────┐ │OS/2 Commands│ └─────────────┘ ■ The following OS/2* commands do not support UNC names or redirected drives: DISKCOPY LABEL RESTORE CHKDSK RECOVER SHELL JOIN FDISKPM The following OS/2 commands do not support UNC names: XCOPY BACKUP ┌──────────────────┐ │DOS LAN Requester │ └──────────────────┘ │■ UPGRADING DISKED WORKSTATIONS │ │ Users of DOS LAN Requester (DLR) disked workstations can upgrade │ their DOS LAN Requester by copying files from a server machine │ that has DOS LAN Requester and DOS Image Support installed. │ Installing DOS Image Support on one server is required before │ running the Corrective Services Installation tool if you intend │ to upgrade DOS requesters on your network. Information on │ installing DOS Image Support on the server is located in Chapter │ 3 of "Getting Started". After the system administrator installs │ the OS/2 Extended Edition Corrective Services Diskette on the │ server machine, the \IBMLAN\DOSLAN\NET directory on the server │ machine contains upgraded DLR files. │ │ A batch file called INSTDLR.BAT is installed in the │ \IBMLAN\DOSLAN\NET directory and is to be used to copy │ all upgraded DLR files from the server machine to the │ disked workstations. The network administrator can │ define this batch file as a public DOS application and │ add it to users' application selectors. Proceed as │ follows: │ │ 1. Log on as an administrator. │ │ 2. Define the \IBMLAN\DOSLAN\NET directory as a files │ alias on the server installed with DLR. │ │ 3. Modify the access profile of this alias to ensure │ that the USERS group has READ access. │ │ 4. Define a public DOS application: │ │ DOS command line ...... INSTDLR.BAT │ Program location │ Alias ...... [(name of alias created in Step 2)] │ Remaining path to program ...... [\ ] │ Assigned drive ...... [*] │ Prompt user for parameter? No Page 2 │ 5. Add this application to users' application selectors. │ │ After logging on from a disked DOS workstation, the │ user can upgrade DOS LAN Requester on the fixed disk by │ selecting the application from the Served Applications │ group. │ │ If the Receiver configuration is used, the user also needs to edit │ the CONFIG.SYS file to ensure that the C= or COMMANDS= parameter │ value specified on the DEVICE=DXMT0MOD.SYS line is sufficient. The │ minimal value is 14. │ │ The user should restart the machine when the application │ completes. After logging on again, the user can delete │ the upgrade application from the Served Applications │ group. │ │ │■ UPGRADING REMOTE IPL IMAGES │ │ Remote IPL images should be upgraded whenever the │ remote IPL server is updated. ■ If you have been using shared resources in a LAN Server 1.3 domain from a PCLP requester, then that domain contains a user ID matching your PCLP requester machine name. Ensure that the user ID matching your PCLP requester machine name is deleted from the LAN Server 1.3 domain before you run DLRINST. If you attempt to run DLRINST and your machine name is defined as a user ID in the LAN Server 1.3 domain, an error message is displayed. Refer to "Downloading DOS LAN Requester" in Chapter 3 of "Getting Started" for more information on the DLRINST service. ■ The IBM* PC 3270 Emulation Program Version 3.05 should not be started from the DOS LAN Requester Application Selector. After DOS LAN Requester has been started, exit to the command line before starting 3270 emulation. ■ The DOS 3.3 TREE command returns only the first subdirectory tree path if the specified drive is redirected to the OS/2 LAN Server. ┌────────────┐ │PUBLICATIONS│ └────────────┘ ■ The description of the NET ACCOUNTS command in both the printed and online "Command Reference" should include the following description of the MINPWLEN parameter: MINPWLEN:length Sets the minimum number of characters for a user account password. LAN Server 1.3 requires that passwords be from 4 to 8 characters in length. The default value for MINPWLEN is 4. Page 3 ■ The example of the /TIMES option of the NET USER command in the online "Command Reference" is incorrect. The example should be: NET USER THOMAS READBOOK /TIMES:M-F,8:00-17:00;S,8:00-12:00 │■ Step 4 of the procedures to use the Replicator service to back up │ the domain control database (DCDB) on page 3-9 of the "Network │ Administrator's Guide" is incorrect. Step 4 should be: │ │ Edit the IBMLAN.INI file of the additional server to include │ the following: │ │ replicate = import │ importpath = C:\IBMLAN\DCDB │ importlist = DCSERV │ tryuser = no │ logon = userid │ password = password │ │ where username and password are the userid and password of an │ administrator ID that will be used in the replication process │ when no one is logged on at that additional server. This ID must │ be an administrator since a user privilege user cannot read the │ DCDB information on the domain controller. │ │ On page 3-10, the paragraph that begins "Make sure the machine ID │ (ADDSERV in this example) .... " should be deleted. ■ The description of workstation heuristic 24 (wrkheuristic) for the IBMLAN.INI file described in Appendix A of the "Network Administrator's Guide" is incorrect. Wrkheuristic 24 controls the buffering of files whose ATTRIBUTE is R (read-only). The file access MODE does not come into consideration. │■ The maximum value for the numbigbuf parameter described on page A-35 │ of the "Network Administrator's Guide" is incorrect. The maximum value │ should be 80. ■ Chapter 2 of the "LAN Support Program User's Guide," "Using the Configuration Aid," should be updated as follows: 1. To install the LAN Support Program in a subdirectory on a fixed disk, you must make sure the DOS prompt indicates that subdirectory before you run the Configuration Aid from a diskette as explained in step 2a. 2. Perform one of the following steps: a. If you plan to run the Configuration Aid from a diskette, insert the backup copy of the LAN Support Program Install diskette (3.5-inch or 5.25-inch) into the diskette drive and set it as the DEFAULT DRIVE. b. If you copied the LAN Support Program onto a fixed disk and plan to run the Configuration Aid from that disk, set it as the DEFAULT DRIVE and make sure the DOS prompt indicates the subdirectory where the Configuration Aid is located. 3. Type DXMAID and press ENTER. Page 4 ┌───────────────┐ │OS/2 LAN SERVER│ └───────────────┘ │■ There are changes in Standard Edition 1.30.1 that enable a LAN │ Server administrator to greatly extend the existing caching │ capabilities. If a primary function of the LAN Server is either │ application program load or database I/O that accesses small │ records randomly, there will likely be a significant performance │ improvement from taking advantage of these changes. │ │ The size and caching characteristics of the cache for the FAT file │ system (DISKCACHE) have been changed. In Standard Edition 1.2 and │ 1.3, the maximum size of DISKCACHE was documented to be 7.2MB. A │ change in design architecture now allows a maximum value of 14.4MB. │ Another change to DISKCACHE is that the threshold has been increased │ from a maximum of 32 sectors to a maximum of 128 sectors. Threshold │ defines the maximum size of a read request that will be placed into │ DISKCACHE memory. This means that the administrator could add into │ the CONFIG.SYS file the statement: │ │ DISKCACHE=4096,128 │ │ and thereby cause all read requests, including program loads, to │ be placed into DISKCACHE memory. The next requester to load this │ program would likely find the program in DISKCACHE and be able to │ load it from memory instead of from disk, improving server │ performance. The length of time the program stays in DISKCACHE is │ a function of DISKCACHE size, the amount of I/O activity, and the │ frequency of usage of that particular program. │ │ A related change has been made that affects caching of requests │ to an HPFS drive. The HPFS cache, called CACHE, has a maximum │ value of 2MB and a threshold of 2KB. This threshold value is not │ changeable. Sometimes it is desirable to cache large I/O requests │ such as program loads or even database I/O that use record sizes │ larger than 2KB. Standard Edition 1.30.1 makes a change in the │ file system such that all read requests to an HPFS drive, greater │ than 2KB and less than or equal to the FAT DISKCACHE threshold │ will be placed into DISKCACHE memory. HPFS is not aware that the │ read requests greater than 2KB have been cached; the caching is │ performed by the DISK02.SYS file which manages DISKCACHE. │ │ The combination of these two changes allows the LAN Server │ administrator to use all available server memory for performance │ improvements, if necessary. It will now be necessary to more │ carefully examine the server's need for big buffers (numbigbufs) │ and trade off server memory between big buffers and caches. NET │ STATISTICS provides a report when big buffers have been exhausted; │ this information can be used to find an optimum value for big │ buffers and use the remaining available memory for the caches. │ For more performance tuning information, see Appendix B of the │ LAN Server 1.3 "Network Administrator's Guide." Page 5 │ │■ In OS/2 LAN Server 1.3, aliases were used to define the home │ directories for users. The default path was │ d:\IBMLAN\USERS\username. In order to change the location of the │ home directory, the alias definition had to be changed. Groups of │ users could not easily share home directory spaces since a resource │ could be defined only once by an alias. If many users were defined │ on a system, each with home directories, the number of aliases │ defined would also grow. Having a large number of aliases caused │ several problems including: │ - Extended time required to list aliases for users │ - Extended time required to read the files alias definition │ file to find the definition for a single alias. │ │ In OS/2 LAN Server 1.30.1, significant changes have been made to │ the home directory format to improve performance and enhance the │ usability of the home directory for users. The main change is to │ remove the requirement that aliases be defined for home │ directories. Because of this change, the following enhancements │ are available: │ │ - The addition of the /HOMEDIR switch to the NET USER │ command to allow for command-line definition of home │ directories for users │ - Ability to store the home directory in almost any location │ on a server │ - Ability to share home-directory space among a group of │ users │ - Reduced time needed for users to list aliases since the │ number of aliases has decreased significantly │ - Full-screen interface changes to allow full path │ specification of the home directory. │ │ To allow for home directories to be defined without the use of │ aliases, the use of the usri?_home_dir field in the user_info_?? │ structure has been modified. │ │ In OS/2 LAN Server 1.3, the format of this field was as follows: │ │ - To define a fixed drive specification for the home │ directory: │ │ p:\server\username │ │ where p = drive to be assigned │ server = server location of home directory │ username = user name of the user │ │ - To define a first available drive specification for the │ home directory: │ │ \\server\username │ │ where server = server location of home directory │ username = user name of the user │ │ │ In OS/2 LAN Server 1.30.1, the format of the field is now as │ follows: Page 6 │ - To define a fixed drive specification for the home │ directory: │ │ - For a home directory in the root of the drive: │ │ p:\server\q$ │ │ where p = drive to be assigned │ server = server location of home directory │ q$ = drive letter where home directory │ will be │ │ - For a home directory not in the root of the drive: │ │ p:\server\q$\subdir1\subdir2\subdir3 │ │ where p = drive to be assigned │ server = server location of home directory │ q$ = drive letter where home directory │ will be │ \subdir1\subdir2\subdir3 = path to home │ directory │ │ - To define a first available drive specification for the │ home directory: │ │ - For a home directory in the root of the drive: │ │ \\server\q$ │ │ where server = server location of home directory │ q$ = drive letter where home directory │ will be │ │ - For a home directory not in the root of the drive: │ │ \\server\q$\subdir1\subdir2\subdir3 │ │ where server = server location of home directory │ q$ = drive letter where home directory │ will be │ \subdir1\subdir2\subdir3 = path to home │ directory │ │ To modify this field, an administrator may use the /HOMEDIR switch │ at the command prompt as follows: │ │ c:\>net user userid /homedir:string │ │ where userid = the user to be modified │ string = the home directory field in one of │ the formats described above. │ │ *** Note: It is very important to ensure that this field follows │ the correct format or users may not get their home │ directory at logon time. An access control profile must │ also be created, giving users access to the home directory. │ For these reasons, administrators may find it better to │ use the full-screen interface (FSI) to define a user's home │ directory. The FSI automatically takes care of both concerns. Page 7 │ All OS/2 Extended Edition 1.3 LAN Requesters and DOS LAN Requesters │ will recognize either format of the home directory specification. │ │ The OS/2 LAN Server 1.30.1 domain controller will respond to │ and share the home directories for all types of requesters. │ │ Many users make drive assignments involving their home directories │ with the command NET USE X: USERID (where USERID is their own user │ ID/home directory alias). This command is still supported by the │ 1.30.1 servers. The servers will cause the connection to complete as │ if the alias still exists for the home directory. │ │ Some users have become accustomed to the existence of the alias from │ use of previous versions of LAN Server. If these users still need │ the alias, it can be created in one of two ways. The first is │ through the normal process for creating files aliases. However, │ this method could be time consuming so a conversion utility is │ is provided for this purpose. │ │ HDCON.EXE (Home Directory Conversion utility) will change users back │ and forth between the old and new home directory formats as described │ above. If a user is converted to the new format, the data concerning │ the home directory will be pulled out of the alias and placed in the │ user's home directory field and the alias will be deleted. When │ converting from the new format to the old format, the process is reversed. │ An alias is created using the information from the home directory │ information, and the home directory field is placed back in the proper │ format. │ │ HDCON can convert all users in a domain at once, or it can convert a │ list of users provided at the command line. For example: │ │ c:\>hdcon -o * │ │ where -o = convert to the old format │ * = all users │ │ In this example, all users on this domain would be │ converted to the old home directory format, and an │ alias would be created for each user. │ │ │ c:\>hdcon -n user1 user2 user3 │ │ where -n = convert to the new format │ user1.. = the list of users to be converted │ │ In this example, the three users listed would be │ changed to the new home directory format and the │ alias for each of these users' home directory would │ be deleted. │ │ Note: If users are "converted" to a format in which they already │ exist, then no action will be taken. Users can be converted │ back and forth so if users changes their mind about how they │ want to be defined, it will not cause problems. │ │ The conversion utility can only be run by an administrator, because │ only administrators have the authority to assign home directories. │ The utility must also be run on the domain controller. Page 8 │ To use the new home directory format, the domain controller (DC) must │ be at least version 1.30.1. If the DC is at a lower version, the │ requesters will still use the old format when creating or using home │ directories. ■ In some DOS environments, especially DOS remote IPL, it is preferable to disable opportunistic locking (Oplock) on the requester. This can be accomplished by changing heuristic 'i' of the /WRK parameter in the DOSLAN.INI file from 1 to 0. Refer to "Adding a DOSLAN.INI File to Your Image Definition File" in Appendix D of the "Network Administrator's Guide" for more information on modifying DOSLAN.INI in a remote IPL environment. ■ For large networks with DOS LAN Requester workstations, server heuristic (srvheuristic) 7 should be changed from 1 to 0 and the server parameter maxsearches should not exceed 1200. Refer to Appendix A of the "Network Administrator's Guide" for information about the IBMLAN.INI file and these parameters. ■ If keyboard response time is a concern on a heavily used server, you can change srvheuristic 6 in the IBMLAN.INI file from 4 to 5. This change allows other applications to have more CPU access. However, be aware that changing the priority from 4 to 5 causes the server to respond more quickly to commands typed at the keyboard but lowers network response performance. ■ If you rename a directory, you should manually delete and recreate any access control profiles that exist for any subdirectories under the renamed directory. Renaming a directory will not cause the access control profiles for any subdirectories under the renamed directory to be updated. ■ During installation of a LAN Server 1.3 domain controller, if a domain control database (DCDB) already resides on the domain controller, the install program allows you either to keep the current DCDB or to initialize (erase) its contents. Initializing the DCDB does not replace the user/group information stored in the IBMLAN\ACCOUNTS\NET.ACC file. Refer to Chapter 3 in "Getting Started" for more information on LAN Server installation. ■ The cleanup parameter is not included in the default IBMLAN.INI file. It can be added anywhere in the Server section of the file. Refer to Appendix A of the "Network Administrator's Guide" for more information on the cleanup parameter. │■ If the OS/2 LAN Server has ended the connection to a resource that │ was dynamically shared because of an inactivity timeout, the │ connection to the alias can be deleted and re-established using │ the NET USE command for the device to which the alias is assigned. │ Refer to the NET USE command in the "Command Reference" for details. Page 9 ┌─────────────────┐ │Migration Utility│ └─────────────────┘ ■ Information about the Migration Utility is in the file named MIGRATE.DOC on the Migration Utility diskette. You should review this file before migrating from either a PCLP 1.3 or a LAN Server 1.0 environment to a LAN Server 1.3 environment. ┌────────────────┐ │Network Printing│ └────────────────┘ ■ For Presentation Manager* printing such as that done from File Manager, a local printer must be set up with the same printer device driver and options as the remote printer that will be used. For instance, if you want to issue NET USE LPT3: \\SRVNAME\HPLASER, then you must set up a local printer for the port LPT3 with the same driver as \\SRVNAME\HPLASER. │■ Remote Setup of Printers or Queues │ │ The ability to set up printer definitions and queue definitions on │ a remote server is now provided through the print manager. │ │ If you are logged on as an administrator at a requester or server: │ │ 1. Go to the OS/2 Print Manager window. Select Setup from the │ action bar. │ │ 2. Select Printers or Queues from the Setup pull-down. │ │ 3. Select Browse. │ │ A list of available servers is displayed. │ │ 4. You may enter a server name (this can be a server outside │ your current domain; however, administrative privileges must │ also exist in that domain for this user ID) or you may select │ a server from the list. │ │ At this point, actions performed will be directed at the │ selected server. │ │ 5. Select ESC=Cancel or OK to bring you back to the OS/2 Print │ Manager window with the local computer's information │ displayed again. │ │ A user also has the ability to select the Browse button, but can only use │ it to view details about server queues or printers. No administrative │ functions can be performed by a user. Page 10 │■ Refresh Interval │ │ Refresh interval is the rate at which the print manager will refresh (or │ repaint) the screen for network print jobs. The default is 60 seconds, │ which means that every 60 seconds the print manager will refresh the status │ of network jobs. Local jobs will be updated as their status changes. │ │ To change the refresh interval: │ │ 1. Go to the OS/2 Print Manager window. │ │ 2. Select Refresh from the action bar. │ │ 3. Select Refresh interval. │ │ 4. Specify the desired rate (in seconds). │ │ To turn this refresh interval off, use the Spacebar to remove the X in │ the box associated with Refresh for network queues. │ │ │■ Local Security │ │ Local security is provided on a per server basis. When local security is │ disabled, anybody physically located at the server can manipulate jobs │ or manage printers and queues at that server. When local security is │ enabled, only administrators physically located at the server can │ manipulate jobs or manage printers and queues. (Users can always │ manipulate their own jobs). │ │ To turn local security on or off: │ │ 1. Go to the OS/2 Print Manager window. │ │ 2. Select Setup from the action bar. │ │ 3. Select Disabled or Enabled. │ │ The change takes affect immediately. ■ In the DOS compatibility mode, the predefined file handles 0003H (Stdaux) and 0004H (Stdprn) have static attachments. The first time the DOS mode is entered, Stdaux and Stdprn are attached, respectively, to the devices that COM1 and LPT1 currently represent. These attachments are permanent until the OS/2 workstation is rebooted. Changing or removing the redirection of COM1 and LPT1 after the DOS mode has been entered will not affect Stdaux and Stdprn. The following examples illustrate: Example 1: 1. COM1 is not redirected; it represents a local serial port. 2. The DOS mode is entered for the first time. 3. A program that reads input from Stdaux is run in the DOS mode; this input comes from the local serial port. 4. COM1 is redirected to a remote serial port by entering the command NET USE COM1: \\SERVER\COMMQ in an OS/2 session. 5. A program that reads input from Stdaux is again run in the DOS mode; this input again comes from the local serial port, not the remote port. Page 11 Example 2: 1. A local printer is attached, but LPT1 is redirected to \\SERVER\PRINTQ. 2. The DOS mode is entered for the first time. 3. A program that writes output to Stdprn is run in the DOS mode; this output is printed on the remote printer \\SERVER\PRINTQ. 4. Redirection of LPT1 is stopped by entering the command NET USE LPT1: /DELETE in an OS/2 session. 5. A program that writes output to Stdprn is again run in the DOS mode; this output is not printed on the local printer, and since the redirection to the remote printer has been deleted, it is not printed on the remote printer either. ■ When a 1.3 LAN Requester prints to a remote LAN Server 1.2 print queue, the print data is processed and spooled twice, once at the requester and again at the server. Not all printer or plotter device drivers can process jobs twice. To avoid this situation, share the printer or plotter as a serial device and redirect the device port (LPT1, LPT2 ..., COM1, COM2 ...) associated with the local print queue definition on the requester to the shared serial device. This configuration will bypass spooler-queue processing at the server. Reminder: If a resource is shared as a serial device, it cannot be associated with a print queue at the server. To print locally at the 1.2 server in this configuration, define a print queue for an unused local device port and redirect that port to the shared serial device. ┌────────────────┐ │Interoperability│ └────────────────┘ ■ INTEROPERABILITY OF IBM LAN SERVERS AND REQUESTERS When OS/2 Extended Edition Version 1.3 is installed on a LAN Requester, the LAN Server supporting it is required to have one of the following combinations installed to support the levels of interoperability defined in the tables: 1. OS/2 LAN Server 1.3. 2. OS/2 LAN Server 1.2 with Corrective Service Diskette (CSD) level WR04098 or greater. 3. OS/2 LAN Server 1.0 with Corrective Service Diskette (CSD) level WR03089 or greater. Table 1 indicates the supported logon and administration combinations for the IBM LAN Server and LAN Requester products. Within a given domain, when multiple servers are used, the servers must be the same version and the same Corrective Service Diskette (CSD) level. Page 12 Table 1. ┌────────────────────────────────────────┬───────────────────────────┐ │ LAN Requesters │ LAN Servers │ ├──────────────────────┬────────┬────────┼─────────┬────────┬────────┤ │ │ Logon │ Admin. │ PCLP │ OS/2 │ OS/2 │ │ Product │ Func- │ Func- │ V1.3 │ LAN │ LAN │ │ │ tion │ tion │ │ Server │ Server │ │ │ │ │ │ V1.0 │ V1.2, │ │ │ │ │ │ │ V1.3 │ ├──────────────────────┼────────┼────────┼─────────┼────────┼────────┤ │ │ │ │ │ │ │ │ PCLP V1.3 (BS & ES) │ X │ │ X │ X │ │ ├──────────────────────┼────────┼────────┼─────────┼────────┼────────┤ │ │ │ │ │ │ │ │ PCLP V1.3 (ES) │ │ X │ X │ │ │ ├──────────────────────┼────────┼────────┼─────────┼────────┼────────┤ │ │ │ │ │ │ │ │ OS/2 EE V1.1 │ X │ X │ │ X │ │ ├──────────────────────┼────────┼────────┼─────────┼────────┼────────┤ │ │ │ │ │ │ │ │ OS/2 EE V1.2 │ X │ X │ │ │ X │ ├──────────────────────┼────────┼────────┼─────────┼────────┼────────┤ │ │ │ │ │ │ │ │ OS/2 EE V1.3 │ X │ X │ │ │ X │ ├──────────────────────┼────────┼────────┼─────────┼────────┼────────┤ │ │ │ │ │ │ │ │ DOS LAN REQ. │ X │ │ │ │ X │ ├──────────────────────┴────────┴────────┴─────────┴────────┴────────┤ │ PCLP = PC Local Area Network (LAN) Program │ │ BS = Base Services │ │ ES = Extended Services │ │ EE = Extended Edition │ │ V = Version │ └────────────────────────────────────────────────────────────────────┘ ACCESSING EXTERNAL RESOURCES ACROSS DOMAINS Cross-domain access of resources can be accomplished by one of the following methods: - External resource definition, which is a full-screen interface function - Use of appropriate APIs - Using explicit NET SHARE and NET USE commands. Once a user's ID and password are validated, that user can access resources outside of the logged-on domain provided the network administrator has shared the resources and provided the appropriate access permissions. │■ INTEROPERABILITY OF NOVELL NETWARE AND IBM DOS LAN REQUESTERS │ │ From a single DOS requester, a user can log on to both IBM and Novell** │ servers and access resources available on both servers. To enable │ this capability, changes are required to the CONFIG.SYS file and the │ AUTOEXEC.BAT file on the DOS workstations. Page 13 │ The following example lists a sample CONFIG.SYS file for a Token-Ring │ attachment of a Redirector configuration and highlights the │ statements that allow concurrent connection to IBM and Novell servers: │ │ BREAK=ON │ BUFFERS=20 │ FILES=50 │ ==> LASTDRIVE=R │ FCBS=16,8 │ SHELL=C:\COMMAND.COM /E:2000 /P │ DEVICE=\DXMA0MOD.SYS │ DEVICE=\DXMC0MOD.SYS │ ==> DEVICE=\DXMT0MOD.SYS S=12 C=12 ST=12 ES=1 O=Y │ ==> DEVICE=C:\DOSLAN\HIMEM.SYS │ │ The first change is the O=Y and ES=1 parameters that were added to │ the DXMT0MOD.SYS device driver. This extra service access point (SAP) │ (ES=1) allows the NetWare** protocol stack to coexist with NETBIOS │ within the DOS workstation. Open=Yes (O=Y) ensures that this extra SAP │ is available when CONFIG.SYS is installed and opens the token-ring │ adapter. │ │ The concurrent connections to IBM and NetWare servers are handled through │ a single token-ring adapter card. The extra SAP acts as the plug into │ the second software stack; that is, the IPX**/NET4 shell. In this way, │ the IBM requester and the Novell requester each has its own SAP that │ allows the two shells to communicate to their respective servers. │ │ While the above example is specific to the IBM Token-Ring adapter, IBM │ ETHERAND* and IBM PC Network* hardware are also supported. When │ using ETHERAND* specifying Open=No (O=N) rather than Open=Yes is required. │ Refer to the "LAN Support Program User's Guide" for more information │ about configuring network adapters. If ETHERAND* is used, then NetWare │ ODI drivers must be used. The most recent version of LANSUP.COM │ is required. Do not use the NetWare 3.11 version. Note that for │ ETHERAND*, 802.2 support must be installed on the NetWare server. │ │ Note: When generating the Novell IPX.COM file (using WSGEN.EXE) │ Select "IBM LAN Support Program Driver" as the driver for the │ IBM-supported network adapter to generate the workstation │ shell. Do not select the "IBM Token Ring" or "IBM PCN II & │ Baseband" drivers. For ETHERAND* the ODI driver LANSUP.COM is │ used instead. │ │ The second change is an administrative one. By changing the LASTDRIVE= │ statement in the CONFIG.SYS file, NetWare now has drives available for │ its use. If the default CONFIG.SYS value for LASTDRIVE (LASTDRIVE=Z) │ is used, it does not allow for NetWare drive mapping. IBM DOS LAN │ Requester looks at LASTDRIVE as the final virtual drive to assign, while │ NetWare uses LASTDRIVE as a starting point to assign virtual drives. If │ they both used the same drive assignment convention, this interoperability │ would not be possible. │ │ The last line of the example CONFIG.SYS file shows the use of the │ HIMEM.SYS driver found in the DOSLAN subdirectory. This will move │ approximately 40KB of DOS LAN Requester into extended memory, which │ allows more room for applications in conventional memory. Page 14 │ The second example is a sample AUTOEXEC.BAT file for the DOS workstation │ running DOS 4.0 (For DOS 3.3 NET4 would be replaced with NET3): │ │ @ECHO OFF │ SET COMSPEC=C:\DOS\COMMAND.COM │ PATH=C:\DOSLAN;C:\DOS;C:\NETWARE │ PROMPT $P$G │ YNPROMPT Y N 30 START DOS LAN REQUESTER (Y/N)? │ IF ERRORLEVEL 1 GOTO NODLR │ NET START │ IF ERRORLEVEL 1 GOTO NODLR │ CALL INITFSI.BAT │ NET │ :NODLR │ YNPROMPT Y N 30 START NETWARE REQUESTER (Y/N)? │ IF ERRORLEVEL 1 GOTO NONW │ IPX │ ROUTE │ NET4 │ PROMPT $P$G │ S: │ LOGIN WS1 │ :NONW │ │ In the above example, DLR has been started, the user logs on, and then │ exits to DOS. The NetWare IPX and Network shell (NET3/NET4) are loaded, │ logon takes place and the AUTOEXEC.BAT sequence is completed. At this │ point, the user is logged on to both servers concurrently and can get │ access to the resources on them. │ │ In an environment that consists of IBM Token-Rings and the IBM Token-Ring │ Network Bridge program, Novell source-routing drivers are required in │ both the NetWare requesters and servers. In the above example, source │ routing is selected on the NetWare DOS requester by the ROUTE statement. │ │ │■ INTEROPERABILITY OF NOVELL NETWARE AND IBM OS/2 LAN REQUESTERS │ │ As with the DOS requester, a user can log on to both IBM and Novell │ servers from a single OS/2 requester and access resources available on │ both servers. The example below is for NetWare 3.11. Installation │ using the current maintainence fixes for NetWare may not require all of │ the steps below. To enable this capability on a workstation that has the │ 1.30.1 level the OS/2 Extended Edition and the LAN Requester installed: │ │ 1. Edit the CONFIG.SYS file and remark out the NETBDD.SYS │ statement. For example: │ │ REM DEVICE=C:\CMLIB\NETBDD.SYS CFG=C:\CMLIB\BASIC.CFG │ │ 2. Reboot the workstation. │ 3. Insert the Netware requester for OS/2 into drive A:. │ 4. Make A: the default drive, type INSTALL and then press Enter. │ This starts a Presentation Manager program that installs the │ NetWare OS/2 requester. Refer to the installation section of │ "Novell NetWare Requester for OS/2" for more information on the │ NetWare install program. Page 15 │ 5. Follow the helps provided by the installation program to select │ the appropriate network driver and install subdirectory, and to │ copy the files to the fixed disk. Do not use the directory │ C:\MUGLIB\DLL as the target. │ 6. Exit the installation program and edit the CONFIG.SYS file. │ Remove the REM from the NETBDD.SYS line. Move the line │ "IFS=C:\IBMLAN\NETPROG\NETWKSTA.SYS ..." to the end of │ the config.sys file. │ 7. Reboot the workstation. │ │ During the installation of the NetWare requester for OS/2, the CONFIG.SYS │ file is modified to contain all the necessary drivers for both IBM and │ NetWare. │ │ │ In an environment comprised of IBM Token-Rings and IBM's Token-Ring │ Network Bridge Program, Novell source-routing drivers are required in │ both the NetWare requesters and servers. Source routing can be selected │ on the NetWare OS/2 requester by modifying the driver statement as │ follows: │ │ DEVICE=C:\NETWARE\TOKENEE.SYS 1=SOURCE │ │ Note: Starting with version 1.3C of the NetWare requester for │ OS/2, the file CMGRLAN.SYS may be used instead of TOKENEE.SYS. │ │ The LIBPATH statement in CONFIG.SYS is used to search for drivers. A │ conflict exists in the system with respect to the two sets of network │ drivers used. These are: │ │ NETAPI.DLL and NETOEM.DLL │ │ Both OS/2 Extended Edition and NetWare have these two files; however, │ the appropriate set of drivers for this interoperating environment is │ the IBM set. The way to avoid this conflict is to ensure that the IBM │ library is specified first in the LIBPATH statement before the NetWare │ library. This can be done as follows: │ │ LIBPATH=C:\MUGLIB\DLL;.....C:\NETWARE;.... │ │ In this configuration, a NETBIOS application on the workstation will be │ unable to communicate with a NETBIOS application on other NetWare │ requesters (both DOS and OS/2) that are using NetWare NETBIOS support. │ NETBIOS applications running on workstations using IBM NETBIOS │ will be able to communicate with other machines running IBM NETBIOS. │ To avoid NETBIOS communication problems, install IBM NETBIOS on all │ machines that require NETBIOS support. │ │ The NetWare netbios driver, NETBIOS.SYS, is disabled by default. │ Do not remove the REM statements from that line of the CONFIG.SYS │ │ Do not start IBM LAN Server on a machine with NetWare requester │ drivers installed in config.sys. │ │ The order in which the two network installable file systems, NWIFS.IFS │ for NetWare and NETWKSTA.SYS for IBM LAN requester, are loaded in │ CONFIG.SYS involves tradeoffs. If any IBM OS/2 LAN Server names are │ duplicates of NetWare server names on the same network then resource │ access by UNC name will result in connection to the first one mentioned Page 16 │ in CONFIG.SYS. For example, if NWIFS.IFS is before NETWKSTA.SYS then │ NetWare servers will be searched first for UNC names, resulting in │ quicker initial connection for Novell resources, but slightly slower │ connection to IBM server resources. In most cases it is preferable │ to install NWIFS.IFS before NETWKSTA.SYS in the CONFIG.SYS file. │ The order of path elements that refer to network drives or │ UNC names can also affect performance. If references to NetWare │ path elements are after references to drives redirected to IBM │ LAN Server, some users may encounter problems when the system │ automatically searches for files on that NetWare path. ┌─────────────┐ │Miscellaneous│ └─────────────┘ ■ In general, if handshaking for a COM device is not specified on the control panel, device errors (for example, device offline) are not reported to the user. If you want device errors to be reported, ensure that handshaking is specified. ■ If a file terminated by CTRL-Z is sent by the 'Send from a file...' or 'Broadcast from a file...' actions in LAN Messaging, the CTRL-Z causes the remainder of the message log to be invisible when it is typed to the screen. The message log can be viewed and edited using the System Editor. ■ To make a remote IPL image that does not contain the DOS LAN Requester, do not use the standard definition files, because they attempt to start DOS LAN Requester in the AUTOEXEC.BAT file. Ensure that the model definition file that you use does not attempt to start the DOS LAN Requester. For more information on creating remote IPL images, refer to Chapter 8 in the "Network Administrator's Guide." │■ The remote IPL definition file STD5L400 cannot be used to make a │ low density (360KB) 5.25-inch diskette, as all required files no │ longer fit on a single diskette. │ │■ When removing the LAN Requester using the REINST command, files │ in the IBMLAN subdirectory that are open will remain │ on your fixed disk. These files should be removed from your │ LIBPATH by editing your CONFIG.SYS file after deinstallation. │ │■ The AT, NET RUN, and NET ADMIN commands require that the programs │ they execute be detachable, non-interactive, and use standard input, │ output, and error. To determine if a program can be run using these │ commands, type: │ │ DETACH command <NULL >outfile 2>&1 │ │ where command is the program to be run and outfile is the name of the │ file to contain the output. Upon completion, outfile will contain any │ standard output or standard error messages generated by running the │ program. The target commands execute with no path information, so all │ path references must be fully qualified.