From: simon@SHRSYS.HSLC.ORG (Alan Simon)
Newsgroups: comp.os.vms
Subject: Response Summary: How can I limit the number of simultaneous users of
         a DCL program?
Date: 29 Jul 92 12:52:35 GMT
Organization: The Internet

On 27 July I asked:

> I have a multiple use, captive, restricted account that uses a DCL menu to
> access several unrestricted DCL applications, as well a DCL application that I
> would like to limit.  Is there any way that I can easily check the number of
> current simultaneous accesses when a user of this account tries to access the
> DCL file, and not allow the user to access it if the number of accesses has
> reached the limit that I have set?  Unless someone has already programmed this
> capability and can provide me with the source code and/or the executables, I
> need a DCL solution, since I am not a system programmer.

My thanks to the following people who responded:

Bob Marshall
Ron Tencati
Rob Young
Brian Reed
Robert Meyering
Steve Gibbons
Eric Zipp
Charles Bailey
Ehud Gavron
J.F. Murphy
Tom Brand
Ian Kitching

Here are the ideas I received.  The number of ideas is more than the number of
respondents because of more than one idea from several respondents.

Three respondents suggested installing the image and then using INSTALL/LIST to 
check the number of users.  Unfortunately, the application is a database
application used with several different databases, and I only want to limit 
use of one database.
-----
Three respondents suggested checking SHOW DEVICE/FILES and counting the number 
of file accesses by the relevant username.  This would work, as long as I 
created a unique command file name to access the application.
-----
Several respondents suggested using disk files as counters:

One respondent suggested creating "n" versions of a file, and then having each
user open one file until all the files are opened, at which time the next user
would be denied access.  This is nice, because OPEN/WRITE will open the first
available version of a file, allowing a middle-numbered version to be re-opened
by a new user after the first user logs off.  However, this means that I would
have to create "n" versions for each username/application combination that I 
wish to restrict (because I want to variably restrict users) and it would mean 
taking up disk space and creating unnecessary disk i/o activity everytime a 
user accessed the application.

One respondent suggested creating a new version of a dummy file before 
application execution, and diallowing access if the version number is above 
the access limit.  However, this does not take into account those users that 
log in after other users log off, since the version numbers would continue to 
increment past the limit.

One respondent suggested creating a file before application execution 
including the user's PID, such as 'PID'_CAPTIVE.DAT, and then counting the 
number of files created to check the number of current accesses.  This would 
work, although it too involves disk storage and i/o.

One respondent suggested incrementing a counter in a new version of a file each 
time the application was accessed, reading the counter from the old version.
Disk i/o problem again.
-----
One respondent suggested setting MAXJOBS in AUTHORIZE.  The user accounts are
not dedicated to this application, so counting the number of processes with 
the same name would give a false reading.
-----
One respondent suggested creating a unique process name/number by a command in 
the account's LOGIN.COM, and then scanning the process name table for all 
occurrences of that name.  As in the previous suggestion, because the user 
accounts are not dedicated to this application, this won't work.
-----
One respondent sent FORTRAN code for limiting access to one login per account,
suggesting that perhaps it could be modified to check for the number of times
an image was running.  This does not solve the problem I posed, but it does
give me the answer to an additional need to limit some users to one login. 
Serendipity strikes again!
-----
Two respondents suggested creating a logical name table at bootup that would
contain a account/application-specific logical set to the current number of 
users of the application.  As each user logged in and out, the user would 
increment or decrement the number by re-defining the logical. This is the 
method I have decided to use, since it accesses fast memory, not slow disk, 
and allows me to see at a glance how many users of that account are accessing 
the application.

Thanks again to all who responded.
-------------------------------------------------------------------------------
Alan Simon                                      simon@hslc.org
Associate Director                              VOICE: (215) 222-1532
Health Sciences Libraries Consortium              FAX: (215) 222-0416
3600 Market Street, Suite 550
Philadelphia, PA  19104
-------------------------------------------------------------------------------