Thanks to all those who responded to this question.
The version I ended up with, just before going home on Friday, was very
similar to the suggestion from Paul (shown below). The main difference is
that Paul uses fgrep and I used a 'while...input...if' loop to scan the
contents of the listf,8 output. Have changed it to uses fgrep and it's
dropped from 8 seconds (elapsed) down to around 2 seconds. The CPU seconds
also dropped from 4 to between 1 and zero.
regards,
Robert W.Mills
Systems Development Manager
Windsong Services
(01689) 870622 x3005
Paul H. Christidis wrote:
> Hi Robert,
>
> Are all those 490 users connecting to the same MPE account? If that
> is true then JOBCNT would probably 'overflow'. I have contributed to
> this list a command file that does limit logons by a variety of ways
> including IP-address. It does, however, use JOBCNT and thus would
> not work for your case.
>
> I do have another suggestion, however.
>
> setvar session_limit 1
> purge sesslist >$null
> purge sublist > $null
> file sesslist;disc=10000
> listf CI.PUB.SYS,8 >*sesslist
> fgrep.hpbin.sys "!hpremipaddr" <*sesslist >sublist
> if FINFO("sublist","eof") > session_limit then
> echo **You've exceeded allowed sessions....
> bye
> endif
> purge sublist,temp >$null
>
> You can probably add some 'bells and whistles' to the above. In
> addition the above assumes that CI.PUB.SYS is the 'default' CI for
> every session, and that the variable 'hpremipaddr' is defined for
> every session (not true for users connected through a DTC). You also
> need to do some testing since I seem to remember that in some cases a
> session may open the CI more than once.
>
> Regards
> Paul Christidis
>
>
>
>
> Hi Tad,
>
> I only mentioned MPEX in-case somebody had a method that required it
> and would only have responded if they knew that it was available here.
>
> Had thought of using JOBCNT(job_match,joblist_var) to create a list of
> session numbers but it won't work here. Our session numbers have just
> started to enter the five digit range which results in a maximum of
> 170 session id's being loaded into the joblist_var variable. We
> currently have our session limit at 500 and are running at around 490
> concurrent sessions.
>
> regards,
>
> Robert W.Mills
> Systems Development Manager
> Windsong Services
> (01689) 870622 x3005
>
>
>
> [log in to unmask] wrote:
>> Hi Robert,
>> I am quite a fan of MPEX, but I will also try to use native MPE
>> functions where possible. In this case, I think you may have a much
>> cleaner solution if you use JINFO and JOBCNT instead of the MPEX
>> JSINFO.
>>
>> For example, instead of using SHOWJOB JOB=@S
>> to a file, you can use JOBCNT("@S",allsessions) to
>> put the session numbers into a variable, which you can then
>> easily parse using WORD and XWORD
>>
>> *
>> setvar numsess JOBCNT("@S",allsessions)
>> while setvar(numsess,numsess-1) >=0
>> setvar sessnum "#"+word(allsessions)
>> setvar allsessions xword(allsessions)
>> calc JINFO(sessnum,"IPADDR")
>> endwhile
>> *
>> Regards,
>> Tad.
>>
>>
>>
>>
>> Internet
>> [log in to unmask]@RAVEN.UTC.EDU - 11/10/2002 11:54
>>
>>
>> Veuillez répondre à [log in to unmask]
>>
>> Envoyé par : [log in to unmask]
>>
>> Pour : HP3000-L
>>
>> cc :
>>
>>
>> Objet : Limiting number of session logons
>>
>>
>> Greetings fellow members of the -L,
>>
>> Environment: MPE/iX 6.5 + MPEX (w/out Security and VEAudit)
>>
>> I have been asked to add an additional check to our system-wide
>> logon script to limit the number of sessions from a single IP
>> Address. The method that I have worked out to do this is as follows:
>>
>> 1) Use JSINFO to get the logging on users IP Address. 2) Set
>> logon_count to zero 3) Do a 'showjob job=@S' to a temporary file.
>> 4) Read a record from the temporary file.
>> 5) Use JSINFO to get IP Address.
>> 6) If IP Address from (1) equals IP Address from (5) then add 1 to
>> logon_count. 7) If logon_count > logon_limit then display message
>> and do a :BYE. 8) If not end-of-file on temporary file the go to (4).
>> 9) Continue with logon processing.
>>
>> Does anybody have a better way than this?
>>
>> regards,
>>
>> Robert W.Mills
>> Systems Development Manager
>> Windsong Services
>> (01689) 870622 x3005
>>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>
>>
>>
>>
>>
>>
>> This message and any attachments (the "message") is
>> intended solely for the addressees and is confidential.
>> If you receive this message in error, please delete it and
>> immediately notify the sender. Any use not in accord with
>> its purpose, any dissemination or disclosure, either whole
>> or partial, is prohibited except formal approval. The internet
>> can not guarantee the integrity of this message.
>> BNP PARIBAS (and its subsidiaries) shall (will) not
>> therefore be liable for the message if modified.
>>
>> ---------------------------------------------
>>
>> Ce message et toutes les pieces jointes (ci-apres le
>> "message") sont etablis a l'intention exclusive de ses
>> destinataires et sont confidentiels. Si vous recevez ce
>> message par erreur, merci de le detruire et d'en avertir
>> immediatement l'expediteur. Toute utilisation de ce
>> message non conforme a sa destination, toute diffusion
>> ou toute publication, totale ou partielle, est interdite, sauf
>> autorisation expresse. L'internet ne permettant pas
>> d'assurer l'integrite de ce message, BNP PARIBAS (et ses
>> filiales) decline(nt) toute responsabilite au titre de ce
>> message, dans l'hypothese ou il aurait ete modifie.
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|