Newsgroups: vmsnet.networks.desktop.pathworks
Subject: FIX for Harvard Graphics Windows 1.0 LAN Version
From: "John F. Cargill" <SYSJOHN@UTOROCI.BITNET>
Date: Wed, 29 Jul 1992 13:07:00 EST
Original_To:  BITNET%"lanworks@miamiu"
Original_cc:  SYSJOHN

To: LANWORKS List
Subject: Problems with Harvard Graphics for Windows under Pathworks
 
 
We have discovered that Harvard Graphics for Windows version 1.0 does
not work properly when installed on an application file service under
Pathworks 4.1.
 
The package uses a file called "HGW.NET" to control the number of
simultaneous users of the package. The administrator sets the maximum
number of users with a program called "HGWCOUNT.EXE". Harvard Graphics
then uses byte range file locking on the file HGW.NET to keep track of
how many people are using the package. One byte in the file is locked
each time a user opens Harvard Graphics for Windows. When the maximum
number of users is reached the next user receives an error message.
 
When installed on a Pathworks 4.1 file service the lock file "HGW.NET" is
locked when when the first user opens Harvard Graphics for Windows. Then no
further access to the file is allowed by Pathworks. This means that any
subsequent user of Harvard Graphics for Windows sees an error message about no
access to the file:
 
                 "No access to HGW.NET - See Your System Manager"
 
There is a known fix - install Harvard Graphics for Windows on a common
file service and set the DOS readonly attribute on the file.
 
I have followed a variant of the above solution. Here are the steps I have
followed:
 
1) Install HGW for a network as per the manual, on an applications file service
2) Create a common file service called HGW10
3) Copy the following files from the applications file service to
   the common file service HGW10
     A) HGW.EXE
     B) HGW.HLP
     C) HGW.NET
4) Set the following files on the common file service HGW10 to readonly
   with the DOS command "attrib"
     A) HGW.EXE
     B) HGW.HLP
5) In Windows click on the HGW icon, select "properties" from the "file"
   menu of the program manager, change the "Command Line" from
 
        drive:\subdir\hgw.exe
 
   to
 
        \\server\hgw10\hgw.exe
 
   where "server" is the name of your VAX pathworks server and "hgw10" is the
   common file service we setup in step 2.
 
Now when the HGW executable is accessed it will be on a common file service
and HGW.NET will be accessible. All the rest of the HGW package will remain
on the applications file service as before.
 
Interesting Note:
 
Suppose you followed the above steps and then set the maximum simulaneous
connections to file service "HGW10" to 10? You now can have no more than
10 users accessing HGW. This is of no interest in this case since HGW.NET
enforces license restrictions - but this scheme is used here at OCI to set
license limits for ALL of our WINDOWS 3.1 software, such as EXCEL, WORDPERFECT,
and so on.
 
Why doesn't HGW.NET work?
 
I don't know. It could have something to do with the way DEC handles byte
-range locking on application file services. I think it is because all files
on an application file service show up with the DOS readonly attribute set
REGARDLESS OF WHETHER IT IS REALLY SET OR NOT. Note that you can cause
the HGW.NET file locking scheme to fail by setting the readonly attribute
on the HGW.NET file on the common file service we created above in step
2. This leads me to think that the "readonly" attribute may be causing
the problem.
 
I will be interested to hear if others can come up with a better fix
to this problem. If you do - don't forget to post it! :)
 
 
---------------------------------------------------------------------------|
John Cargill                     | Bitnet:   CARGILL@UTOROCI               |
Manager of Research Computing    | Internet: CARGILL@OCICL.OCI.UTORONTO.CA |
Ontario Cancer Institute         |-----------------------------------------|
(Department of Medical Biophysics, University of Toronto)
500 Sherbourne Street, Toronto Ontario Canada, M4X 1K9
Tel. (416) 926-4546   Fax. (416) 926-6529
---------------------------------------------------------------------------