═══ 1. Managing the Concurrent Use of Licensed Programs ═══ The concurrent use of licensed software applications is provided by a component of NetDoor called Vendor. Vendor is a front-end to licensed software residing on a local area network. The Vendor client is a Presentation Manager program that users must run to gain access to remote vendor software. You can install a licensed application on a remote server so that a user's sole access method to the application is through Vendor. All of the monitoring details are performed by the Vendor Server to ensure that each use of each application is recorded. Vendor is a client/server set of applications to share the use of licensed software in a LAN environment. The vendor client application is discussed in the IBM Network Door/2 User's Guide. The Vendor Server component consists of several programs described in this section. These programs need to be run on a LAN file server. The file server that runs these programs is called the Vendor Server. ═══ 2. Using Licensed Software ═══ Using licensed software accessed via the Vendor program offers many benefits over installing the software locally: o Reduced costs Many software companies provide LAN versions of their programs. A LAN version of a program can be obtained at a substantial cost savings when compared to its stand-alone or local version. Many companies that do not have LAN versions of their products require an additional license fee or some other form of reimbursement for each person using their product. These fees are usually much less than the usual product price. o Maximum use per dollars spent Traditionally the amount of time a user uses an application is limited. For this reason many users own software that lies dormant for hours, days, weeks, or even months. Vendor addresses this problem by providing a mechanism by which users can share licenses. These licenses are referred to as simultaneous or concurrent use licenses. o Instant access to licensed software packages The Vendor program provides users with immediate access to applications. o Reduced installation time and complexity Software applications are often complex and difficult to install. Instead of each user installing the package, the NetDoor administrator can install and test all software accessible by the Vendor program. If needed, the administrator can write additional documentation to aid in the use or setup of packages that are difficult to use or configure. o Remote software saves local hard-disk storage space Application software running under OS/2 often contains many files and requires significant hard-disk storage space. By storing these packages remotely, where users can use one copy of the package, hard-disk storage requirements are greatly reduced. If 20 users frequently use a remote package requiring 10MB of diskette space, the total savings is 190MB. ═══ 3. What You Will Need ═══ Vendor provides all of its functions in both LAN Server and TCP/IP environments. o NetBIOS In a NetBIOS environment the Vendor Server must be running OS/2 Version 1.3 Extended Edition or higher. The Vendor Server must be an additional LAN server or the domain controller in a domain in which all users have access. To be given access to the vendor server, a user must have a user ID and password in that domain. o TCP/IP In a TCP/IP environment the vendor server must have a minimum operating system level of OS/2 Version 1.3 Standard Edition with OS/2 TCP/IP 1.2.1 (service level UN 37938) and LAPS installed. A TCP/IP user with IP access to the vendor server can access software applications. ═══ 4. What the Installation Diskette Contains ═══ Many different files are mentioned in this chapter. Refer to this list to determine the source of a given file. \ (root) directory INSTALL.EXE - Installation program. Run this to install Vendor Server. CONTENTS.CID - Data file indicating title and version information. READ.ME - Important getting started and last minute info. \VNDADMIN subdirectory INSTNET.FIL - Installation commands for NetBIOS vendor server installation. INSTNFS.FIL - Installation commands for TCP/IP vendor server installation. SAMPLE.INF - Sample vendor application information file. SAMPLE.LIC - Sample vendor application license file. VNDADMIN.EXE - Administrators exec. VNDADMIN.HLP - Help Manager documentation for VndAdmin. VNDNET.DLL - Vendor NetBIOS specific DLL. VNDSRVR.ICO - Icon file for VNDSRVR.EXE. VNDTCP.DLL - Vendor TCP/IP specific DLL. \VNDADMIN\NETBIOS subdirectory VNDSRVR.EXE - NetBIOS server daemon which runs on the vendor server. VNDTRACE.EXE - NetBIOS admin utility used to toggle vendor daemon output. VNDKILL.EXE - NetBIOS admin utility used to stop vendor daemon. VNDMON.EXE - NetBIOS admin utility useful for monitoring vendor daemon. VNDSTART.EXE - Utility program used to start vendor server. \VNDADMIN\TCPIP subdirectory VNDSRVR.EXE - TCP/IP server daemon which runs on the vendor server. VNDTRACE.EXE - TCP/IP admin utility used to toggle vendor daemon output. VNDKILL.EXE - TCP/IP admin utility used to stop vendor daemon. VNDMON.EXE - TCP/IP admin utility useful for monitoring vendor daemon. VNDSTART.EXE - Utility program used to start vendor server. \AUXPROGS subdirectory HIDEWIN.EXE - Used to hide package setup sessions (if desired). LIBEDIT.CMD - Utility used by many sample front-ends. \FRNTENDS subdirectory Miscellaneous vendor application installation and execution front ends. \DOCS subdirectory ADMINDOC.INF - OS/2 View compatible Vendor Admin Documentation. ═══ 5. Installing a Vendor Server ═══ The following sections give detailed instructions on how to install or update the components of a vendor server. ═══ 5.1. Using Diskettes ═══ The vendor administration program (VNDADMIN) is used to install or update a Vendor Server. However, before you can install or update the server, you have to install the VNDADMIN program. This section describes how to install the Vendor administration program from the IBM NetDoor Vendor Server installation diskette. Follow the installation instructions: Note: NetBIOS Before starting the installation on a LAN Server, prepare the server by performing these tasks: 1. Start the server by typing NET START SERVER. 2. Log on with an administrator user ID. Note: TCP/IP Before starting the installation on a TCP/IP server, prepare the server by performing these tasks: 1. Install and start TCP/IP for OS/2 1.2.1 or higher. 2. Start the PORTMAP.EXE application. Do not start NFSD.EXE. From the new server place the IBM NetDoor Vendor Server installation diskette in the drive A and type: A:\INSTALL The installation program asks you for a local directory in which to install the Vendor administration program. After installing the VNDADMIN program and supporting files on the local directory, the installation program creates a Vendor Admin program group. Program entries for the Vendor Admin program and online documentation are added to this group. To perform additional maintenance in the future, you can run VNDADMIN from this program group. Then, the installation program starts VNDADMIN so that the vendor server can be installed or updated. VNDADMIN contains online help if you have any questions; see Installing a Vendor Server for details about the installation dialog. Finally, copy the VENDOR\PACKDATA\VENDOR.CTL file into the COUIMAGE alias of all the image servers that will use the server you are installing like a vendor server. If you have a NETBIOS environment and you are already using the Vendor program provided by LAN Server 2.0, you can migrate to without losing your configuration using the following installation instructions: 1. Place the NetDoor Vendor Server Installation Diskette into drive A and copy the following files into the VENDOR\USEDATA subdirectory: o A:\VNDADMIN\NETBIOS\VNDSRVR.EXE o A:\VNDADMIN\NETBIOS\VNDMON.EXE o A:\VNDADMIN\NETBIOS\VNDKILL.EXE o A:\VNDADMIN\NETBIOS\VNDTRACE.EXE o A:\VNDADMIN\NETBIOS\VNDSTART.EXE 2. Copy the VENDOR\PACKDATA\VENDOR.CTL file into the COUIMAGE alias of all the image servers that will use the server you are installing like a vendor server. 3. Start the vendor server running VNDSTART from VENDOR\PACKDATA subdirectory. ═══ 5.2. Using a Code Server ═══ You can install the Vendor Server from diskettes or from a code server. A code server enables you to use the installation diskette in any drive in the system. The entire contents of the installation diskette can be copied intact to any drive and directory on the code server. This procedure allows the contents of the diskette to reside almost anywhere, including a LAN alias, an NFS-mounted drive, or a CD-ROM, and still be used for installation of a Vendor Server. Using Response Files The installation program included with the installation diskette asks what local directory you would like to use for creating a work area to be used when installing and updating Vendor Servers. The installation program supports a response file for getting this information. To call the installation program with a response file, use the following syntax: INSTALL /R: For example: INSTALL /R:a:\install.rsp The response file should contain these keywords and their associated values: WORKDIR = For example: WORKDIR = d:\vndwork ═══ 5.3. Describing Vendor Server Files ═══ The vendor administration program can edit four kinds of Vendor Server files. For information on creating and changing these files, see Editing Files o Control file (CTL) The control file is used by the VENDOR.EXE client program. It must be named VENDOR.CTL and stored somewhere along the user's DPATH. This file tells vendor the name of the Vendor Server to use as well as the name of the catalog file on the server. Note: If VNDADMIN does not have access to the same VENDOR.CTL file that the user population uses (or if the file must exist in more than one place), make sure to copy it manually to wherever it is needed. o License file (LIC) The license file is read by the VNDSRVR.EXE program. This file must be named VNDSRVR.LIC and reside in the \\server\d$\VENDOR\USEDATA (NetBIOS) or d:\VENDOR\USEDATA (TCP/IP) subdirectory along with the VNDSRVR.EXE program. Create this file on every Vendor Server, whether or not the server is a license server. The license file is read when you start the Vendor Server; if it is changed, you can stop the Vendor Server program using VNDKILL and restart it. VNDADMIN also sends a message to the Vendor Server telling it to reread the license file dynamically. o Catalog file (CAT) The catalog file is read by the VENDOR.EXE client program. This file lists all the package categories available. You can group similar packages into one package file. The catalog file is a listing of all package files and their associated descriptions. You can give the catalog file any name; it is created in the directory specified by the VENDOR alias. For example: \\server\d$\VENDOR\PACKDATA or d:\VENDOR\PACKDATA Note: The catalog file name CATALOG.CAT is recommended. o Package file (PKG) A package file is read by the VENDOR.EXE client program. This file lists all the packages contained within a certain package category. Similar packages should be categorized and grouped into one package file. Package files can be named anything, but are created in the directory specified by the VENDOR alias. For example: \\server\d$\VENDOR\PACKDATA or d:\VENDOR\PACKDATA Note: Package files should end with the PKG extension. ═══ 6. Installing Applications on a Vendor Server ═══ Installing software applications on the Vendor Server so that they are accessible with the vendor front-end program is not always trivial. Because many software applications have unique setup and configuration requirements, there is no predefined, absolute method of installing a licensed application in the Vendor environment. Therefore, this section describes what must be done in all cases, and provides pointers on how to install most software packages. The following checklist describes what you need to do before installing a package in the Vendor environment. 1. Get legal permission to use the package Contact the owners of the software application and obtain the required licenses and agreements for running the package in the Vendor environment. 2. Determine where the software application will be installed You can install the application package on any server that the Vendor Server user ID has administrative privileges on or that is running NFSD with TRUSTED privileges. Place the package on any drive and directory on the server. No predefined netname needs to be created for this resource; the Vendor Server creates dynamic netnames as needed. The TCP/IP Vendor Server dynamically export this resource as needed. For example, you may want to install the new package in the subdirectory D:\IBMC2 on the server YKVNS01. 3. Install the package as described by the documentation Most packages will allow you to run some sort of installation program, specifying that you would like to install the package on a certain drive and a certain subdirectory. Therefore, you usually have the following options when installing packages: o Install the package on the server while running from the server. o Install the package onto a redirected or NFS mounted drive, if possible. When logged on as an administrator, you can assign any drive on the server as a local drive with the command: NET USE x: \\server\d$ or MOUNT x: server:d:\ o Install the package on a workstation and use COPY/XCOPY (with directory structure intact) to the server. Be sure to remove the workstation copy. Be cautious when installing packages onto redirected server drives. The installation programs for certain programs understand that the drive you are trying to install the package on is not a physical drive, and will not let you continue. Usually, you can install these packages on a physical drive and then use XCOPY on the remote drive. LAN versions of software applications usually allow installation on a remote drive, but applications written for the stand-alone environment often do not. Note: Contact the owners of the software application if you have any problems installing it in the Vendor environment. 4. Create front-end programs Often, software applications cannot run properly unless certain environment variables are set up, or other tasks have been performed. For this reason, you need to write a front-end program to the actual software program that performs these functions. The standard names for these front-end programs or execs is PACKINST.CMD and PACKRUN.CMD, but they can be called anything as stated by the package file entry. Use the PACKINST.CMD exec to run any configuration or installation tasks for a particular package and the PACKRUN.CMD exec to actually run the application program. These front-end programs can be very different from one software package to the next. Install these front-ends in the same directory in which you installed the software application. Refer to the IBM Network Door/2 Programming Guide for information on writing or using existing front-ends for many software applications. 5. Create a package file entry Use VNDADMIN to create a package file entry for the newly installed package. You may need to create a new package file if you have not installed similar packages before. For example; if you are installing a new compiler and you do not have any other compilers installed, you may want to first create a COMPILER.CAT package catalog file for the package entry. See Editing Package Files for information on editing package files. Note: You may want to test the new package entry by using a local catalog file that points to a local package catalog file before you add the new package entry to the package files to which users have access. 6. Update package license and information files After you create a package file entry for the newly installed package, the following files are created: d:\VENDOR\package\package.LIC d:\VENDOR\package\package.INF where : is the drive letter where the Vendor Server is installed and package is the short package name (such as IBMC2) Make sure to edit these files and add package and site-specific license and usage information. If the newly installed package is not free, then make sure to add a package.WRN file that contains information about the cost of the package to the user. VENDOR.EXE automatically displays this file the first time a user runs a package that costs money. 7. Add package license count information Use VNDADMIN to add license count information about the newly installed package. License information is stored in the VNDSRVR.LIC file. Refer to Editing License Files for information on editing license files. The package should be ready to run. Be sure to test all newly installed Vendor packages fully before providing access to the user population. ═══ 6.1. Installing Vendor Client Program Components ═══ The Vendor client program is included on the The client files are already installed on the NetDoor server image. The Vendor client program is ready to run from any NetDoor workstation. Refer to the IBM Network Door/2 User's Guide for information on using the Vendor client application. ═══ 6.2. Starting the Vendor Server ═══ The VNDSRVR.EXE program must be running for users to have access to application software residing on the server. Always use the VNDSTART.EXE program to start the Vendor Server. Type VNDSTART ? from an OS/2 command line for details on VNDSTART. If you want the Vendor Server starts automatically add the following line to the STARTUP.CMD file of the Vendor Server. D:\VENDOR\USEDATA\VNDSTART Note: Substitute the actual drive letter in place of D: if needed. Note: NetBIOS The LAN Server running the VNDSRVR.EXE is known as the Vendor Server. This server must have an administrator user ID logged on at all times. This ID is needed so that the server can dynamically share resources on itself and other servers in the domain. Note: TCP/IP The TCP/IP workstation running the VNDSRVR.EXE is known as the Vendor Server. Before the Vendor Server is started, CNTRL.EXE, PORTMAP.EXE, and NFSD.EXE TCP/IP services must be running. ═══ 7. Managing Trace Messages ═══ Use the Vendor Database Trace Setting program (VNDTRACE) to debug errors or to view program usage. You can run the Vendor Server with the trace mode on or off. The default mode is off. To start VNDSRVR with the trace mode on, type VNDSRVR -t. In the trace mode, VNDSRVR will echo to the screen all messages received from vendor client programs, all functions executed and their associated return codes, and the output messages sent to clients. Note: Running VNDSRVR with the trace mode on reduces the speed of execution. Use this mode as a debugging aid only. >─────VNDTRACE──┬────────┬──┬────────────────┬────> └─server─┘ ├─OFF────────────┤ └─ON──┬────────┬─┘ ├─SCREEN─┤ ├─FILE───┤ └─BOTH───┘ ═══ 7.1. Parameters ═══ server The name of the server to perform on. (The default is the local machine.) ON Enables tracing. OFF Disables tracing. SCREEN Displays trace messages in the VNDSRVR window. FILE Appends trace messages to the VNDSRVR.TRC file. BOTH Displays trace messages in the VNDSRVR window and appends them to the VNDSRVR.TRC file. ═══ 8. Shutting Down a Vendor Server ═══ You can use the Vendor Server program VNDKILL to shut down a server. >─────VNDKILL───┬────────┬─────> └─server─┘ ═══ 8.1. Parameters ═══ server The name of the server you want to shut down. The default value is the name of the local machine. ═══ 9. Monitoring a Vendor Server ═══ You can use the VNDMON program stand-alone or in REXX execs to determine information about the use of the Vendor Server. >─────VNDMON──server──┬─────────┬──────> └─command─┘ ═══ 9.1. Parameters ═══ server The name of the server you want to monitor. command One of the following query commands: MSG mach msg Sends a specified message to the specified machine. Use an asterisk (*) to send the message to all the machines. NUMPACKS Returns the number of packages in use. NUMUSERS p Returns the number of users using a given package number or name. MAXUSERS p Returns the maximum number of licenses for a given package number or name. PACKNAME p Returns the package name associated with a given package number. QUERY Returns OK if VNDSRVR.EXE is running. RESOURCE p Returns the resource associated with a given package number or name. USER p u Returns the userid, specified by the user number; using the package specified by the package number or name. MACH p u Returns the machine, specified by the user number or name; using the package specified by the package number or name. READ_LIC Rereads the VNDSRVR.LIC file. VER Returns the version number of VNDSRVR.EXE. ═══ 10. Troubleshooting ═══ The following sections give helpful information for troubleshooting Vendor Server problems. Detailed Vendor Server information is also provided for debugging and configuration purposes. ═══ 10.1. Understanding the Vendor Server ═══ The Vendor Server program, VNDSRVR.EXE, is the heart of the dynamic aliasing capabilities of Vendor. The Vendor application running on the user's workstation communicates with VNDSRVR via a NetBIOS named pipe or via a TCP/IP remote procedure call (RPC), depending on the protocol you use. VNDSRVR can execute administrative level network functions because it runs on a server with administrator privileges. The Vendor Server can create and share aliases or exported directories dynamically and grant and drop access on an individual user basis. VNDSRVR also records all package use information in files stored in the DATES subdirectory on the license server. Several files are maintained by the Vendor Server as it operates and tracks licensed application usage. These files are necessary for the execution of the server and can offer some diagnostic information: o Database File - VNDSRVR.DBF VNDSRVR.DBF is a flat file database that represents current software program usage. The Vendor Server program, VNDSRVR.EXE, reads information from VNDSRVR.DBF during initialization. Any aliases or exported directories that were created are created again and access to the appropriate users is granted. The database file provides the ability to restart the Vendor Server without completely dropping user access to applications. When the Vendor Server restarts, it grants access to attached users. However, it is recommended that you execute the VNDKILL program to terminate VNDSRVR.EXE before restarting the Vendor Server. Like any database file, VNDSRVR.DBF can become damaged. You can use a browser to inspect the file to see if DBF file is damaged. Deleting the damaged file and restarting the VNDSRVR.EXE program is the best recovery solution. Note: Access to packages is not carried over a 24-hour period. When VNDSRVR.EXE starts, it does not grant access to users that started applications during the previous day. This helps discourages users from leaving software applications running on their systems when they go home at night. o Error Log File - VNDSRVR.ERR VNDSRVR.ERR contains date- and time-stamped error log entries. Each entry contains a short description of the error followed by the associated application, followed by the associated user ID, if applicable. The error log file is stored in the same directory as the VNDSRVR.EXE file and can be purged manually at any time using the OS/2 DEL command. Refer to Understanding Error Log Entry Descriptions for more information about error log entries. o Queue Log File - VNDSRVR.QUE VNDSRVR.QUE contains a log of queueing actions. Queuing actions include a user waiting to use a package and a user being freed from the queue. The queue log file is stored in the same directory as the VNDSRVR.EXE file and can be purged manually at any time using the OS/2 DEL command. o No Free Licenses Log File - VNDSRVR.FUL VNDSRVR.FUL contains a log of users who tried to use packages when all licenses were in use. This shows when and how often the license counts for particular packages were inadequate to satisfy the user population. This log file is stored in the same directory as the VNDSRVR.EXE file and can be purged manually at any time using the OS/2 DEL command. o Audit of changes to the VNDSRVR.LIC file - VNDSRVR.AUD The VNDSRVR.AUD file audits access attempts to the VNDSRVR.LIC file. The VNDSRVR checks the time stamp of VNDSRVR.LIC when it initializes and when a READ _LIC message is received from the VNDADMIN program. When the time stamp changes (either via VNDADMIN or by manually editing the license counts file), the new license information and the current date are appended to the VNDSRVR.AUD log file. The new VNDSRVR.LIC time stamp is saved in OS2.INI for comparison. This audit log file is stored in the same directory as the VNDSRVR.EXE file. It is recommended that this file not be purged manually at any time. It contains information showing when particular license counts were increased and can be compared against purchasing receipts to prove that valid licenses exist for each application. o Vendor Server Trace Option - VNDSRVR.TRC You can run the Vendor Server with the trace mode on or off. The default mode is off. To start VNDSRVR with the trace mode on, type: VNDSRVR /T In trace mode, VNDSRVR echoes to the screen all messages received from Vendor client programs, all functions executed and their associated return codes, and the output messages sent to clients. Several trace options allow tracing to both file, VNDSRVR.TRC, and console. Note: Running VNDSRVR with the trace mode on drastically reduces the speed of execution. Use this mode as a debugging aid only. o Specifying Vendor Administrator Workstations - VENDOR.ADMINS By default, the Vendor Server program sends send error messages to all Vendor administrator workstations in the Vendor Server's domain. To send error messages to workstations in other domains or on an IP network, you have to tell VNDSRVR.EXE the names of these workstations using the VENDOR.ADMINS environment variable. Set VENDOR.ADMINS to the name of one or more workstations separated by commas. The following example specifies one workstation on another domain or on an IP network: SET VENDOR.ADMINS=wksta The following example specifies two workstations on another domain or on a IP network: SET VENDOR.ADMINS=wksta1,wksta2 ═══ 10.2. Understanding Error Log Entry Descriptions ═══ Where applicable, all error entries in the VNDSRVR.ERR file have the following format: Error_description Server Application User Workstation RC d Many of the function calls issued by VNDSRVR are network functions described in the Operating System/2 LAN Server Version 1.2 Application Programmer's Reference, S01F-0256. The following list includes error log entries and their associated descriptions: o ERROR_APP_NOT_SHARED Attempted to drop an application resource that was not shared. This can happen when a user is returning a license for an application and the Vendor server has already dropped the application resource. This should not happen unless the client and the server lose communications for a period of time thus causing the server to free the user's license. o ERROR_COULD_NOT_SHARE This error occurs if the Vendor Server attempts to share a resource but can not. If the error is greater than 2000, type the following command from OS/2 to get detailed information regarding the failure: HELP NETxxxx where xxxx is the return code error number. o ERROR_LICENSE_TIMEOUT If a user restarts a workstation without stopping a licensed application, or if the user's workstation cannot communicate with the Vendor Server for more than 15 minutes (due to a LAN networking problem), then the Vendor Server frees all licenses used by the user. o ERROR_LIC_SERVER_NOT_RESPONDING If a Vendor Server cannot communicate with its license server, this error is generated. The license server may actually be unavailable, you are experiencing LAN networking problems, or the user ID running on the Vendor server is not known to the domain to which the license server is defined. o ERROR_NETACCESSSETINFO After sharing an application resource, the Vendor Server must set the access permissions for the user desiring to use the application. Setting the access permissions is performed by the NetAccessSetInfo() function. This error reports the exact error return code from the NetAccessSetInfo() function. This error code does not occur if you use a TCP/IP Vendor Server. o ERROR_NETSHAREADD To provide the user with access to an application, the Vendor Server must share a directory as a network resource. This is done by the NetShareAdd() function. This error entry reports the exact error return code from the NetShareAdd() function. This error code does not occur if you use a TCP/IP Vendor Server. o ERROR_NETSHARESETINFO The NetShareSetInfo() function gives a new user access to an existing shared application. This error entry reports the exact error return code. This error code does not occur when you use the TCP/IP Vendor Server. o ERROR_NET_USE After a user is given access to an application, the Vendor client program attempts to use the shared resource. If the attempt fails, this error is generated. Note the return code field. Often the use attempt fails with a return code of 5, which indicates that access was denied. When this happens, ensure that the user is known to the Vendor Server domain and that there are no password conflicts. This error code does not occur if you use a TCP/IP Vendor Server. o ERROR_OPENING_DBF_FILE After every Vendor Server database transaction the Vendor Server writes its database to the VNDSRVR.DBF file. If the Vendor Server cannot open the file, this error is generated. o FATAL_ERROR_NO_LIC_FILE During startup the Vendor Server must read the VNDSRVR.LIC file. This error occurs if the file does not exist or cannot be read. o FATAL_ERROR_BAD_LIC_FILE During startup the Vendor Server reads the VNDSRVR.LIC license file. This error occurs if the file does not include the required line at the top of the file: LICSERVER = server ═══ 10.3. Understanding Usage Statistics ═══ Your site may want to bill users for their first-time use of certain applications, but the actual billing is not done by Vendor. The Vendor server generates logs of all use information. Each site that uses Vendor can process daily usage files generated by the Vendor Server and perform billing tasks as needed. You may want to back up these files periodically so that they can be restored in case of a hardware failure. Two types of statistics files are generated by the Vendor Server program: o The \VENDOR\USEDATA\DATES subdirectory contains usage files for each date on which the Vendor Server runs. The files are stored in the directory under the date on which they were created. For example, the usage file for April 9, 1993 are stored in the file 040993.DAT. These files can be processed by whatever means available to create usage statistics. They are created only on license servers. The entries written in the 040993.DAT file contain two types of usage information: the date and time when the application was used by a user on a workstation (including some additional billing information) and the date and time when the user stopped using the application. 04/09/93 10:48 NONE WPWIN 5.1 JOHNW FARSIDE $0.00 1 YKVNS02 04/09/93 11:14 DROP WPWIN JOHNW FARSIDE YKVNS02 o The \VENDOR\USEDATA\USERS subdirectory contains first-time usage information files for users who have run each software application. The files are stored in the directory under each unique user ID. For example, the first-time use information for user ID JOHNW is stored in the file JOHNW.DAT. These files are used by the Vendor Server program, VNDSRVR.EXE, to determine if a user has previously used a package. These files are created only on Vendor license servers. 10/02/92 14:43 NONE COREL20 2.00A JOHNW FARSIDE $0.00 1 YKVNS03 04/09/93 11:25 NONE WPWIN 5.1 JOHNW FARSIDE $0.00 1 YKVNS02 06/21/93 14:14 NONE 123G 1.1 JOHNW FARSIDE $0.00 1 YKVNS02 07/16/93 09:14 NONE FLG 1.0 JOHNW FARSIDE $0.00 1 YKVNS02 08/04/93 17:31 NONE DESCRIB4 4.0 JOHNW FARSIDE $0.00 1 YKVNS01 ═══ 11. Using the Vendor Administration Program ═══ Use the Vendor administration program (VNDADMIN) to: o Install and update the Vendor server o Send messages to users o Create and update all Vendor server profiles, including: - Control file - Catalog file - Package files - License file Using VNDADMIN to install Vendor servers and create and maintain profiles helps to ensure that the Vendor server environment is configured correctly. To start the VNDADMIN program, open the Vendor Admin group created by the Vendor installation program on the desktop, and then double-click on the Vendor Admin Program icon. The Vendor Admin window appears: You can obtain help on any window by pressing the F1 key or by selecting the Help button. ═══ 12. Selecting a Communication Method ═══ To select the communication or access method that the Vendor Admin program uses to install and manage the Vendor server program (VNDSRVR) on each server: 1. Select the Servers option from the action bar and then Access Method. 2. The Vendor Interprocess Communication Method window appears. 3. Select either NetBIOS or TCP/IP. 4. Select OK to verify your selection or Cancel to exit the window. After you select a method, VNDADMIN saves this information for future instances of the program. ═══ 12.1. Installing a Vendor Server ═══ To install a Vendor server: 1. Select the Servers option from the action bar and then Install Server. 2. The Vendor Server Installation window appears. Note: If you are running the installation program from a NetBIOS workstation, you must have administrative privileges on the Vendor server. 3. Select a server from the Server list box or type the name of a server. If you are running the installation program from a LAN server this server will be the default selection in the list box. You can select another server from the list or enter your own. Note: When you install a TCP/IP server, the list contains only the current host name of the server you are running from. You cannot install on a remote server. 4. For Drive on Server type the drive letter of the Vendor server on which to install the Vendor Server software and on which to create the Vendor resource. 5. For Path to Control File type the fully qualified Vendor control file name. The control file can reside anywhere, but must be accessible along the DPATH of workstations running the VENDOR.EXE client program. The control file tells the Vendor client program which Vendor server to access and which catalog file to load. 6. Select OK to install the software or Cancel to exit the window without installing. If the control, license, catalog, and package files do not exist for each server, VNDADMIN asks if you want to create them now. If you answer Yes, the windows you need for creating these files are displayed. ═══ 13. Modifying Vendor Server Definitions ═══ To add, delete, or change a Vendor server: 1. Select the Servers option from the action bar and then Define Servers. 2. The Vendor Servers window appears. 3. Select a server from the list or type the name of the server. 4. Fill in the appropriate information in the Server Details section: o In the Drive with Vendor Resource field enter the drive letter on which the Vendor Resource (alias) will be created. o In the Path to Control File field enter the fully qualified name of the control file. The file name must end with VENDOR.CTL. o Check This is a License Server if this Vendor Server is a master license server. 5. To add or change a new definition, select Add. 6. To delete an existing definition, select Delete. Select Save to save the definition in the VNDADMIN.INI file. If any server information has been created or changed, the Install Servers window appears. The server list shows all the servers that are currently defined. Select a server and: 1. Select Install to install or reinstall a server. The installation program: o Creates the directory structure on the server. o Copies the Vendor server programs to the server. o Creates and shares a VENDOR alias (NetBIOS). o Creates and exports a d:\VENDOR\PACKDATA directory (TCP/IP), where d: is the drive on which the server is installed. Note: You have to start the Vendor server program, VNDSRVR, manually on each Vendor server, and copy the VENDOR.CTL file to the COUIMAGE alias of the image servers. 2. Select Don't Install to end the program. A maximum of 25 Vendor servers can be defined by the VNDADMIN program. ═══ 14. Editing Files ═══ You can edit control files, license files, catalog files, and package files. To edit a file: 1. Select File from the action bar and then Open. 2. The Vendor Admin File Selection Menu appears. 3. The Vendor servers list contains the names of all the Vendor servers that are defined. Select a server to see a list of files associated with that server in the control, license, and catalog file list, and the package file list. 4. Select a file and then Edit to begin editing, or Cancel to return to the previous window. ═══ 14.1. Editing Control Files ═══ The control file provides the Vendor program with the names of the Vendor server and the catalog file to use. The Vendor client program running on user workstations requires that a control file be accessible along the DPATH. To edit a Vendor server control file: 1. On the Vendor Admin File Selection Menu select a control file and then Edit 2. The Vendor Admin Control File Editor appears: 3. Type the name of the Vendor server in the Server field. 4. Type the name of the catalog file in the Catalog File field. The catalog file will reside in the directory shared or exported by the VENDOR alias of the specified server. If the file does not exist, it is created when you select Save. A default name of CATALOG.CAT is recommended. 5. Select Save to write the control file or Cancel to leave the window without making any changes to the file. 6. After the control file is created or modified, copy it to a location in the user's PATH. ═══ 14.2. Editing License Files ═══ The VNDSRVR program running on the Vendor server requires the license file to determine which Vendor server is the license server and how many licenses are allocated for each of the packages that are installed. To edit a Vendor server control file: 1. On the Vendor Admin File Selection Menu select a license file and then Edit. 2. The Vendor Admin License File Editor appears: 3. The name of the current license server appears. If the license server and the Vendor server are the same, you cannot change this field. Note: It is assumed that the license server was defined on the Vendor Servers window. 4. The All Packages List shows all packages known to the Vendor Server. When you select a package from the list, the information in the Selected Package box changes to show the current information about the selected package. 5. Update the information and select Update to refresh the list. 6. To delete the license count for a package, select Delete. 7. Select Save to save your changes or Cancel to return to the previous window. 8. Use the Package field to view the package you selected. This name cannot be changed. 9. Use the Count field to change the license count for the package. Valid ranges include numerical values in the range 0-999 or * if there are no license restrictions. 10. Select Update to refresh the information in the Package List. 11. Select Delete to delete the license count for a package. The updated license count information will be saved to the license file when you select the Save button. VNDADMIN informs the Vendor Server to reread its license count information. ═══ 14.3. Editing Catalog Files ═══ Use the Vendor Admin Catalog File Editor dialog to edit a Vendor Server Catalog file. The Catalog file contains a list of package files and descriptions. Note: Package files should end with the .PKG extension. To edit a catalog file: 1. On the Vendor Admin File Selection Menu select a license file and then Edit 2. The Vendor Admin Catalog File Editor appears: 3. The Package File list shows all the package files on the server. These files reside in the directory shared by the Vendor alias or exported directory of the specified server. If a package file does not exist, it is created when you select Save. You might want to create a different package file for all similar packages. For example, all of the spreadsheet applications, 123/G, 123R3, and Excel can be contained in the package file SPREAD.CAT or SPREAD.PKG. To create a new package file, type the name of the new package file in the Package File field. 4. In the Description field type a new description or change the existing one. Note: The description should be meaningful to users of the type of applications defined in the package file. 5. Select Add to add the package file information to the Package File list. Changes are not saved until you select Save. 6. Select Delete to delete a package file from the Package File list. Changes are not saved until you select Save. 7. Select Cancel to leave without making any changes to the catalog file. ═══ 14.4. Editing Package Files ═══ A package file contains a list of applications along with all the required information for each application. It is a good idea to group similar applications into one package file with a meaningful description such as "Word Processors" or "Drawing Applications". To edit a package file: 1. On the Vendor Admin File Selection Menu select a package file and then Edit. 2. The Vendor Admin Package File Editor appears. 3. The Package File field contains the name of the package file currently being edited. You can change this name before selecting Save to make a backup copy or a new version of a package file without overwriting the original. 4. The Package Name list contains all the currently defined packages in the package file. o To add a new package, enter the package name, fill in all the necessary information, and select Add. o To change information about a currently defined package, select the package from the list, change the necessary information, and select Change. o To delete a package, select the package from the list, and select Delete. For each package, a directory of the same name is created in the directory shared by the Vendor alias on the specified server. This directory is the repository of the license, information, and optional warning file for this package. Note: The short package name is used as a convenience to both users and the Vendor program. For each package, a directory of the same name will be created in the directory shared or exported by the Vendor alias on the specified server. This directory will be the repository of the license, information, and optional warning file for this package. (NEW) The .LIC, .INF and .WRN files with the short package name prefix can be displayed by the Vendor client. 5. In the Name field enter the full, descriptive name of the package. This should include the application title as specified by the software vendor whenever applicable. 6. In the Desc field enter a short description of the package. 7. In the Vendor field enter a the name of the software vendor that supplies the package. 8. In the Path field enter the drive and path on the Vendor server in which the actual package has been installed. This directory will be shared or exported by the Vendor server whenever the Vendor program requests use of the package. 9. In the Server field type the name of the server on which the package is installed. The server specified can be any server on which the Vendor server has administrative privileges. Usually, however, it is the Vendor server itself. If this is the case, use the name of the Vendor server, or an asterisk (*) interchangeably. Note: See the Path field for a description of the path on the server in which the package is installed. 10. In the Access field enter the access permissions for the package. For LAN Server enter the access permission to use when creating the alias. Possible NetBIOS permissions include: R - Read access. W - Write access. C - Create access. X - Execute access. D - Delete access. A - Attribute access. P - Change Permissions access. * - All of above. The TCP/IP access permissions to use when creating the NFSD exported directory include only: R - Read access. W - Write access. Note: Usually, all that is required for an application is RX permissions. It is generally undesirable to give users write, delete, attribute, or permissions access, since it is then possible for them to make the package unusable, or delete it altogether. 11. In the Cost field enter the cost of the package to the user. When you define a new package, this field is set to a default amount which represents a cost of nothing. In the United States this would be $0.00. This field can contain any string up to 9 characters. However, if the package is to be considered free, this field must be exactly equal to the default amount which represents a cost of nothing. 12 .In the Version field type the version number of the package. 13. In the Date field type the date the package was installed or upgraded on the Vendor server. 14. In the Bill field type the billing category for this package. This can be any number or string that can be processed by billing software. For example, the billing numbers might be: o 0 - Free, non-tracked uses o 1 - Free, tracked uses o 2 - Pay first use o 3 - Pay each use For more information on Billing info see Understanding Usage Statistics Note: The actual billing of Vendor software is not addressed by Vendor programs. It is up to the LAN administrators to make sure the daily usage statistics are processed, and that software is billed for as needed. 15. In the Install Program field enter the installation program for the package. The executable or command file specified must reside in the directory indicated by the Path field. If this field contains None, there is no installation program for the package. Some applications do not contain any type of install program. However, some installation tasks must be performed before the user can use a specific application through Vendor. See the IBM Network Door/2 Programming Guide for information on writing installation programs. 16. In the Install Program Window Type field select the type of OS/2 session the installation program should run in. The selections include: Default Allow OS/2 on the user's machine to decide what type of session to use. FS Run in a full-screen OS/2 or DOS session. Win Run in a windowed OS/2 or DOS session. PM Run in Presentation Manager session. FS/Win Use either a full-screen or windowed OS/2 or DOS session, allowing the user to choose. Note: Selecting the wrong session can cause Vendor to halt when running the program. 17. Select the Install 2.0 Setup button to specify OS/2 2.0 setup data to use when running the installation program on the user's machine. 18. Select the Reboot After Install Required check box to specify if users need to restart their machines after installing the package. If the box is checked, the user gets a message stating that the machine should be restarted. 19. In the Run Program field enter the program or command file to be run when executing the package. If this field contains None, there is no program for the package. For many packages, this is an executable provided by the vendor as part of the application. However, you may want to provide a front-end program for the regular executable. See the IBM Network Door/2 Programming Guide for information on writing package run programs. 20. In the Run Program Window Type field enter the type of OS/2 session the Run program should run in. 21. Select the Run Program 2.0 Setup button to specify OS/2 2.0 setup data to use when running the package on the user's machine. 22. Select the Drive Dependency radio buttons to indicate how sensitive the package is to the drive letter it will be assigned on the user's machine. There are three categories: Independent The package can be attached to any free drive on the user's system. Same Drive The user can choose the drive letter during package installation, but the package must always use that drive letter. Use Drive: The package must use the drive letter specified for all users. Valid drive letters are between C: and Z:. It is advisable to use drive letters below G: to avoid conflicts for users with many devices attached to their workstations. 23. Select Save to write all modifications to the package file. 24. Select Add to add the new package description to the package file. 25. Select Change to change the current package description. The actual text of the button changes, depending on whether the package already exists. Changes are not saved until you select Save. 26. Select Delete to remove the currently selected package from the package name list. 27. Select Cancel to leave without making any changes. ═══ 15. Specifying Setup Data ═══ To select setup data to use when running a package or package installation on a user's machine: 1. The 2.0 Setup window appears when you select one of the two 2.0 Setup... buttons in the Vendor Admin Package File Editor panel. 2. The Setup Data list box shows all the current settings for the package. o To add a new value, type the setting name and value in the setting and value entry fields and select Add. o To change a value, select it from the list, edit the value, and select Change. o To delete a setting, select it from the list, and select Delete. For a list of DOS or WIN-OS2 Settings that can be specified, see a DOS or WIN-OS/2 program object in the OS/2 2.0 Command Prompts Folder. 3. Select OK to accept the settings for the selected package or Cancel to leave the window without making any changes. The settings are not saved permanently until you select Save in the Package File Editor window. ═══ 16. Sending Messages ═══ You can send messages to machines on the current domain or IP network that are running the VENDOR or VNDADMIN programs. It is often helpful to send a message to a user who is having difficulty (as seen by incoming error messages) or to all users when you are about to bring down a Vendor server for maintenance. To send messages: 1. From the Vendor Admin window select Send messages. 2. The Vendor Admin Message Facility window appears. 3. In the Machine Name field enter the machine name to send the message to. Enter an asterisk (*) to send the message to all machines running the VENDOR or VNDADMIN program on the current domain or IP network. 4. Enter the message to be sent in the Message field. 5. Check the Send to Administrators Only box to send the message to machines running the VNDADMIN program on the current domain or IP network only. 6. Select Send to send the message or Cancel to exit without sending a message.