home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / vms / 12895 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  5.1 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!mips!sdd.hp.com!hplabs!ucbvax!SHRSYS.HSLC.ORG!simon
  2. From: simon@SHRSYS.HSLC.ORG (Alan Simon)
  3. Newsgroups: comp.os.vms
  4. Subject: Response Summary: How can I limit the number of simultaneous users of
  5.          a DCL program?
  6. Message-ID: <0095E4A4.B301D920.24508@shrsys.hslc.org>
  7. Date: 29 Jul 92 12:52:35 GMT
  8. Sender: usenet@ucbvax.BERKELEY.EDU
  9. Organization: The Internet
  10. Lines: 96
  11.  
  12. On 27 July I asked:
  13.  
  14. > I have a multiple use, captive, restricted account that uses a DCL menu to
  15. > access several unrestricted DCL applications, as well a DCL application that I
  16. > would like to limit.  Is there any way that I can easily check the number of
  17. > current simultaneous accesses when a user of this account tries to access the
  18. > DCL file, and not allow the user to access it if the number of accesses has
  19. > reached the limit that I have set?  Unless someone has already programmed this
  20. > capability and can provide me with the source code and/or the executables, I
  21. > need a DCL solution, since I am not a system programmer.
  22.  
  23. My thanks to the following people who responded:
  24.  
  25. Bob Marshall
  26. Ron Tencati
  27. Rob Young
  28. Brian Reed
  29. Robert Meyering
  30. Steve Gibbons
  31. Eric Zipp
  32. Charles Bailey
  33. Ehud Gavron
  34. J.F. Murphy
  35. Tom Brand
  36. Ian Kitching
  37.  
  38. Here are the ideas I received.  The number of ideas is more than the number of
  39. respondents because of more than one idea from several respondents.
  40.  
  41. Three respondents suggested installing the image and then using INSTALL/LIST to 
  42. check the number of users.  Unfortunately, the application is a database
  43. application used with several different databases, and I only want to limit 
  44. use of one database.
  45. -----
  46. Three respondents suggested checking SHOW DEVICE/FILES and counting the number 
  47. of file accesses by the relevant username.  This would work, as long as I 
  48. created a unique command file name to access the application.
  49. -----
  50. Several respondents suggested using disk files as counters:
  51.  
  52. One respondent suggested creating "n" versions of a file, and then having each
  53. user open one file until all the files are opened, at which time the next user
  54. would be denied access.  This is nice, because OPEN/WRITE will open the first
  55. available version of a file, allowing a middle-numbered version to be re-opened
  56. by a new user after the first user logs off.  However, this means that I would
  57. have to create "n" versions for each username/application combination that I 
  58. wish to restrict (because I want to variably restrict users) and it would mean 
  59. taking up disk space and creating unnecessary disk i/o activity everytime a 
  60. user accessed the application.
  61.  
  62. One respondent suggested creating a new version of a dummy file before 
  63. application execution, and diallowing access if the version number is above 
  64. the access limit.  However, this does not take into account those users that 
  65. log in after other users log off, since the version numbers would continue to 
  66. increment past the limit.
  67.  
  68. One respondent suggested creating a file before application execution 
  69. including the user's PID, such as 'PID'_CAPTIVE.DAT, and then counting the 
  70. number of files created to check the number of current accesses.  This would 
  71. work, although it too involves disk storage and i/o.
  72.  
  73. One respondent suggested incrementing a counter in a new version of a file each 
  74. time the application was accessed, reading the counter from the old version.
  75. Disk i/o problem again.
  76. -----
  77. One respondent suggested setting MAXJOBS in AUTHORIZE.  The user accounts are
  78. not dedicated to this application, so counting the number of processes with 
  79. the same name would give a false reading.
  80. -----
  81. One respondent suggested creating a unique process name/number by a command in 
  82. the account's LOGIN.COM, and then scanning the process name table for all 
  83. occurrences of that name.  As in the previous suggestion, because the user 
  84. accounts are not dedicated to this application, this won't work.
  85. -----
  86. One respondent sent FORTRAN code for limiting access to one login per account,
  87. suggesting that perhaps it could be modified to check for the number of times
  88. an image was running.  This does not solve the problem I posed, but it does
  89. give me the answer to an additional need to limit some users to one login. 
  90. Serendipity strikes again!
  91. -----
  92. Two respondents suggested creating a logical name table at bootup that would
  93. contain a account/application-specific logical set to the current number of 
  94. users of the application.  As each user logged in and out, the user would 
  95. increment or decrement the number by re-defining the logical. This is the 
  96. method I have decided to use, since it accesses fast memory, not slow disk, 
  97. and allows me to see at a glance how many users of that account are accessing 
  98. the application.
  99.  
  100. Thanks again to all who responded.
  101. -------------------------------------------------------------------------------
  102. Alan Simon                                      simon@hslc.org
  103. Associate Director                              VOICE: (215) 222-1532
  104. Health Sciences Libraries Consortium              FAX: (215) 222-0416
  105. 3600 Market Street, Suite 550
  106. Philadelphia, PA  19104
  107. -------------------------------------------------------------------------------
  108.