Question on how /[NO]ACCESS should work

[Chris M. Hornbeck_1]

Most of our user accounts are set up with /NOACCESS=(SECONDARY, 18-24)
Secondary is Saturday.
These users cannot log in during this time.
However, users that are logged in stay logged in until they attempt to run an executable.

Is this the way it's supposed to work?
I expected these user sessions to be terminated at 18:00 on Saturdays.
We have a problem when users leave and don't log off on Saturdays. If they have a record locked it interferes with the file conversions we do on Saturday nights.
Is there a way to set up these user accounts so they cannot stay logged in during this time?

[Hein van den Heuvel · Accepted solution]

I think that's the way it is supposed to work.

It must be a rather poorly designed application which allows processes to hold (record) lock over terminal interactions/menues. Yikes.

But I suppose you have to make do with what you have.

Before running maintenance jobs you may want to perform SHOW DEV/FILE and parse the output for PID/proces-names having files open.

You could give those a 5 minute warning first and in a second run execure $STOP/IMAGE to give the code (RMS) a chance to clean up nicely, flushing buffers.

Ideally, applications hold a lock+blocking AST (or Mailbox) to be informed to close files and go away, but that level of sophistication in applications is far and few in between.

hth,
Hein.

[Chris M. Hornbeck_1]

Ok.
Thanks for the help.

We do have a lot of old applications that don't behave well.

[Jan van den Ende]

Chris,

at our site users are SUPPOSED to work 8 hours.
So, with a lee time of 2, we regularly (10 mins) check for interactive processes running for more than 10 hours. Those are just STOP/ID'ed.
IF any user EXPECTS to need more runtime, he can ask in advance to be put on an exception list (usually for 1 day).

It has helped us a lot.

--just a suggestion.

Proost.

Have one on me.

jpe

[Karl Rohwedder]

Freeware V8 (and the other usual locations) contain a tool called WATCHER, which can be used to stop 'idle' processes. It is very configurable to define, what is idle, which user/jobs/images are excluded...

regards Kalle

[John Gillings]

re: Jan,

>Those are just STOP/ID'ed.

Please try to avoid STOP/ID or $DELPRC. They can cause trouble (yes, I know, "you've been doing it for years", but that doesn't make it right! nor does it mean it won't cause you trouble in the future).

A better way of killing a process is to first issue a $FORCEX. If the process is still there after some time (say, 5 minutes), then $DELPRC.

From DCL V7.3-2 and above, issue STOP/IMAGE/ID, as Hein suggested, for $FORCEX or STOP/NOEXIT/ID if that fails.

[it took me almost a decade of lobbying to get that put into DCL, so please use it! Thanks to Elinor Woods for working through all the non-obvious complexities and finally making it happen]

That said, I thought the noaccess times worked exactly as described above. A $FORCEX issued at the transition from the access window to the no access window, then a $DELPRC a few minutes later. I'm therefore a bit surprised by your observation. Does the application have any special exit handing?

I agree with Hein that allowing a process to hold locks for an extended period is asking for trouble. I'd strongly recommend implementing timeout mechanisms in the application that
1) relinquish a lock if held too long and
2) exits the application or process if left idle for too long.
Such timeouts can be very easy to implement. For the exit timeout, choose a reasonably long time, say 4 hours. In your command loop immediately after accepting a command issue a $CANTIM to cancel the previous timer, then a $SETIMR to reset it. In the timer AST call $EXIT with SS$_TIMEOUT. Just a few lines of code in any language.

Timing out a record lock can be a bit trickier, it depends on the logic of the application, but it may not be necessary if you can depend on the application timeout.

Final comment. The heart of this issue is user training. The trouble with automating logouts is it teaches users to not logout. So what starts as an emergency fixup develops into standard practice, increasing your exposure to the rare events where summarily killing a process can result in file corruption.

By all means implement an automatic logout, but try to make it the exception, rather than SOP.
You should be able to identify the users responsible. Send messages informing them they've breached security guidelines by leaving their session logged in. If it's serious enough, set a limit to the number of times they're allowed to be caught without incuring some disciplinary action.

[Wim Van den Wyngaert]

John (or others),

Has /NOEXIT any use if no exit handlers are implemented by the user program ?

I remember from my Unix time that kill -15 would often not stop the stucked process. So we did a -9 a few seconds later. May be this also applies to VMS.

fwiw

Wim

[Jan van den Ende]

@John,

>>>
You should be able to identify the users responsible. Send messages informing them they've breached security guidelines by leaving their session logged in. If it's serious enough, set a limit to the number of times they're allowed to be caught without incuring some disciplinary action.
<<<
If it gives you any peace of mind: that is exactly what we did!
But since that was more related to the security policy as to the locking problem, I left that unmentioned. I probably could/should have anticipated your response :-)

Proost.

Have one on me.

jpe

[Chris M. Hornbeck_1]

Thanks for all the responses. We are working on a safe method of logging off these users.

I wish I had the authority to discipline users that don't follow the rules.
However, upper management will not allow us to do anything that would interfere with their work so there isn't anything that can be done in regards to trainning the users.
We are working on updating our applications to time out when idle for too long but we have a small staff of programmers and management (yes, them again) insist we focus no new application development so progress is slow.

In regards to the no access, even if the user is at a DCL prompt they are not logged off the system. Not what I expected, but then they are'nt interfering with anything in that instance. And, yes, if it were up to me they would never get to a command line.

[Jan van den Ende]

Chris,

>>>
However, upper management will not allow us to do anything that would interfere with their work so there isn't anything that can be done in regards to trainning the users.
<<<

You can try (but I am afraid, with little chance of success, been there too) to explain them, that NOT doing this is what "interferes with users' work".
To wit, the user HOLDING the lock, (and already off the premises) does the interfering with current activities, and YOU are the one with the knowledge and the power to STOP that interference.

Wishing you a lot more of convincingness (or convinceable management) than I was able to show....

Proost.

Have one on me.

jpe