This article is a complilation of many different questions about licensing. Some of this information may already be in other articles as well. A.k.a. "the mother of all licensing articles" Last updated 5-Sept-1996. For most recent version, see the DSNlink article [PW] Licensing: How Does it Work? What are the Common Problems? (FAQ) PROBLEM: My PC is unable to obtain a license. SOLUTION: On the server ... OpenVMS Digital UNIX $ SHOW LIC /BR (is it even loaded?) % lmf list | grep -i pw $ MCR PWRK$LICENSE_MANAGER % pwlsadmin Check under products to see if you have any free licenses available. Also note the license server's name (lower left corner of the screen); it can be different from the file server's name. This name will be used on the client. Also, check PWRK$LOGS:PWRK$LICENSE_SERVER_node.LOG or /usr/net/servers/pathworks/logs/pwlicsrv.log to be sure that the License Server is using the transport(s) that your client is. On the client ... Add an entry to define an address for the License Server's name, prefixed by 'PWRK$L'. For example, if you've got a server named SPOCK that has a license server running on it named TREK you'd do something like this: If DECnet: C:\PW> NCP NCP> DEFINE NODE SPOCK ADDRESS xx.xx NCP> DEFINE REMOTE-ADAPTER-NAME PWRK$LTREK NODE SPOCK If PATHWORKS' TCP/IP: C:\PW> INETNAME PWRK$LTREK xxx.xx.xx.xx If Microsoft's TCP/IP, edit the LMHOSTS file xxx.xx.xx.xx SPOCK #PRE xxx.xx.xx.xx PWRK$LTREK #PRE Next, specify the name of the license server for the license requester to use. Real-mode license requester: C:\PW> PWLICLM TREK Protected-mode license requester & WfW: Edit SYSTEM.INI and add a [DECLICL] section: LICENSESERVER = TREK Protected-mode license requester & Win95: Control Panel, Network, PATHWORKS License Agent, Properties. Edit the License Server field... License Server [TREK ] If the client still does not obtain a license, use PWRK$LICENSE_SHUTDOWN.COM and PWRK$LICENSE_STARTUP.COM to restart the License Server (this will NOT affect your users) then try the PC again. To aid troubleshooting, you may also want to use $PWRK$LICENSE_MANAGER to enable all logging before doing this, then re-check the log file after restarting & having the PC attempt to obtain it's license again. Please see the following related article: [PW-DOS]V5: FASTD: OBTAINING A LICENSE FROM A CLUSTER OVER A WAN QUESTION: How can I specify which type of license my client requests? ANSWER: First you need to be sure to use the right name in any of these places. The first three characters in the license value are the PAK "Producer" code and the remainder is the "Product" code. For example, a PAK with producer = "DEC" and product = "PWLMDOSCC06.00" would use LICENSE00=DECPWLMDOSCC06.00 Real-mode license requester: Run the license requester with the "/file:licfile.txt" switch. The "licfile.txt" file should contain the following format: LICENSEnn = XXXPWaabbbccMM.mm For example: LICENSE00 = DECPWLMDOSCC05.00 Protected-mode license requester & WfW: Edit SYSTEM.INI and add a [DECLICL] section LICENSE00 = XXXPWaabbbccMM.mm Protected-mode license requester & Win95: Control Panel, Network, PATHWORKS License Agent, Properties. Edit the License Pak 1 field. Refer to the following related article: [PW-DOS]V5 & V6: LOADING PWRKS LICENSE WITH WINDOWS FOR WORKGROUPS (WFW) PROBLEM: You have multiple Win95 clients with PATHWORKS for Win95 installed. The first client successfully gets a license and connects to the PATHWORKS server. Other Win95 clients fail to connect. SOLUTION: Installing the dial-up adapter in Win95 before a PATHWORKS license is obtained causes problems with network station addresses. All PCs with dial-up adapters will have the address of 44-45-53-54-00-00. Remove the dial-up adapter, then add PATHWORKS for Win95 and reboot. After successfully obtaining a license, re-add the dial-up adapter (if needed). PROBLEM: I'm dialing into my network and cannot get/use a license. What can I do? SOLUTION: The troubles with dial-up networking & licensing are about over... The following combinations work for both obtaining and using a license over a TCP/IP dial-up connection: this client... needs contents of... 5.1 dos/win/wfw 5.1 eco6 6.0 dos/win/wfw 6.0 eco1 win95 PW95 1.0A eco1 QUESTION: What makes the license it has invalid? How does a server determine if the client has a license and if it's valid? ANSWER: The client license software is composed of two parts; the transponder and the requestor. The transponder's always available; as a TSR on a DOS PC, as a VXD on Windows95, and a service on Windows NT. When the requestor obtains and/or validates the license from the license server, it places information into the transponder. When the client then makes a connection attempt to any PATHWORKS v5 server, the file server asks the license registrar (PWRK$LICENSE_R process) if the client's licensed. This process checks with the transponder on the PC. If the transponder has a valid license, the registrar allows the file server to accept the connection. If the transponder is not loaded and/or does not have a valid license loaded, then the registrar checks for a server license; if one exists then the registrar allows the file server to accept the connection. If none of this exists, then the file server will not allow a connection (and $ADMIN/ANALYZE/SINCE should show an event). This message 15-MAY-1996 07:18:38.00 CLIENT_LICENSE_INVALID: Client Id = unavailable, Client Addr = "RCCP02 ", Transport = TCP/IP, Product = unavailable, Group = unavailable, Reason = No Licenses Available shows that, for some reason, the client's transponder either dosn't have a license loaded or the license is believed to be invalid by the registrar process. QUESTION: Shouldn't it be possible for a client to "broadcast" for a server and for a license server to respond? It seems to work that way when the protocol on client is DECnet. ANSWER: Yes, as long a the server can hear the client's broadcast. TCP/IP subnets are often smaller than DECnet areas; anytime you pass through a router (normally) broadcasts will be stopped. It's at this point that you need to define the license server's NetBIOS name to the client. For a DECnet client, this is done via DEFINE REMOTE-ADAPTOR-NAME, for PATHWORKS' TCP/IP, the INETNAME command, and for Microsoft's IP, the LMHOSTS file or a WINS database. After making this definition, you then specify to the license requestor the name of the license server. For example, on a Windows95 client attempting to obtain a license from a single system called PW_S1, I would add an entry to the LMHOSTS. file (no extension; there's a sample called LMHSOSTS.SAM (also, be sure not to use Notepad - it always puts '.TXT' on the end of the filename)) something like this: xxx.xx.xx.xx PWRK$LTREK #PRE then, in the license requstor property sheet (Control Panel, Network), I would specify TREK as the license server name. Note that, in a cluster, the license server may have the name of one of the single systems (even when it's running on another system in the cluster) or of the cluster alias. Also note that the PWRK$LICENSE_S process will be in HIB on ONE node - that's the one that's actually serving licneses at that point - and in LEF on the other nodes. If you've used INETNAME/LMHOSTS to define the name to point at one of these nodes, clients will not be able to get/validate their licenses when the active process is on the other system, hence the article and the recommendation to use the logical PWRK$LICENSE_SERVER_INHIBIT to be sure that the license server process always runs on one known system. See the following related article: [PW-DOS]V5: FASTD: OBTAINING A LICENSE FROM A CLUSTER OVER A WAN QUESTION: Where does the registrar check for a server license? ANSWER: On the server to which you're connecting - the server licenses are specific to the server. When you connect to PW1, it would check PW1's LMF database; when you connect to PW2, it would check PW2's. QUESTION: So, if for some reason the license responder on the client isn't responding then the client would have had to have been granted a license by the particular server where the connection is being attempted? ANSWER: Not "granted a license" in the same sense as with client licenses. The server licenses (which you don't have - the PWLMVMSCU05.00 ones) are specific to each server. If a client with no client license attempts a connection, it can still connect to a file server if _that_ server has a server license. The LICENSE_S is the license server - this is ONLY needed for distribution of CLIENT licenses - dosn't apply in the above situation. You normally only have one license server in a LAN, the clients all get client licenses from this one server and then are checked by the LICENSE_R (registrar) on each of the file servers as previously described. QUESTION: Of the two machines NOT running LICENSE_S one of them has PAK's and one of them doesn't. I was planning to remove the PAK's from the one that has them because I didn't think they were necessary unless LICENSE_S was running. ANSWER: This is correct - no need to have them there. QUESTION: I was looking in the license server log files, I found some communication errors, reported on various protocols. If one protocol reports an error, the license request has succeeded over another protol. It seems either transport can report the error on a client. The errors all look something like this: 12-AUG-1996 07:25:48.00 MESSAGE: t_rcv failure over Transport TCP/IP Client Address: "MY_PC L", WAN: XTI error in IC at line 2271 XTI error code t_errno = 9 ("event requires attention") XTI event code = 0X0010 ("disconnect received") ANSWER: These are actually expected. The newer client license code (including that for Windows 95) tries all available protocols at the same time. The license server responds over the first request it sees, at which point the client cancels the "other" reqeust(s). The license server has no way of knowing that this request was cancelled on purpose or if there was a communication problem, hence the message. In 99 44/100% of the cases, this message is not an indication of a real problem.