Ending a session remotely to do some maintenance work?

[ngoht20]

Every Thursdays, I always do some maintenance work and updating all the data on an Alpha OpenVMS v7.1-2 server.

Therefore, I want to send a message to all my nodes or my users connected to my server using port 23 that I will be ending their sessions in 10 minutes or so. I want to this on a scheduled basis every Thursdays at 17:00. How can I achieve this option?

thanks

[Hoff]

REPLY/ALL[/BELL] is the typical notification command, and you can use a repeating DCL command procedure to invoke it. Using SUBMIT and a recurring batch job, for instance.

There are numerous examples of self-resubmitting batch jobs around. In this case, I'd tend to use a batch job that resubmitted itself daily for tomorrow at 17:00, and had a second check for "it's Thursday" for the message processing. This because these periodic batch jobs tend to collect various other daily tasks. Off the top, SUBMIT /AFTER="TOMORROW+17:00" is probably going to be the core DCL command.

There are commercial and open-source scheduling packages available, these can make the process easier.

The maintenance menu DCL procedure can also typically be modified to issue the command and to then prompt for the operator-user to wait some interval before commencing the maintenance. This has the advantage of being more closely associated with a manually-triggered process. (A recurring automatic message tends to become noise after a while.)

There are also tools known as Idle Process Killers (IPKs) or terminal timeout programs or such, and these can be used or modified to delete processes. The downside of this approach is that the users can be involved in critical processing and a deletion might not be the best approach.

If the users are themselves operating within a menu system, I've been known to modify that to detect when the system is off-line. When a user enters a command in the menu system and the system is off-line, the menu can detect and display as much and can ignore the command -- pending the system coming back on-line. The flag for the status can be a logical name, or a file on shared storage, or other such. This provides a way to more cleanly synchronize user activity, as well.

The full approach is to completely automate the whole maintenance procedure and related, from the notification onward. This assumes a way to request that tapes loaded or other such exists, either through messages sent to the operator (MAIL or REPLY or otherwise) or through the use of a tape library or loader or sequence of disks. Or whatever media or hardware is required for the particular maintenance task(s).

Stephen Hoffman
HoffmanLabs

[Arch_Muthiah]

We can do this using big com procedure (below) which I never tried. You can do this type of job by writing a DEC Scheduler script to SUBMIT the COm procedure with a single line command REPLY/USERNAME = (all usernames). It also needs DEC Scheduler to do this small job!!!

Otherwise, try this command procedure (schedule.com) from this site...
http://pdv.pdv-systeme.de/users/martinv/

Thanks
Archunan

[ngoht20]

For example: I want to initiate a message like this:

MESSAGE FROM RUEV01 ON RUEL01 AT BEUV01
ENDING SESSION IN 15 MINUTES!

How can I achieve this same message format?

[Hoff]

Here is the REPLY command involved:

$ REPLY/ALL/BELL "MESSAGE FROM RUEV01 ON RUEL01 AT BEUV01 ENDING SESSION IN 15 MINUTES!"

The command assumes OPER privilege.

This certainly isn't the most elegant of DCL commands, as I expect various of the hunks of text from that command are either going to be displayed by the REPLY command by default, or are going to vary by implementation or by time.

The SUBMIT command involved was mentioned earlier.

If you should wish to undertake write the DCL code yourself, the OpenVMS User's Manual is the best spot for DCL information in the OpenVMS manual set. There are DCL-related tutorials and books, referenced in the FAQ, if you wish to further your experience with OpenVMS. There are certainly DCL examples around, such as those cited in this thread, as well.

Various commercial organizations are available and able to contract with your organization to provide a complete solution here, as this is likely going to be rather more than what can fit into the tiny little text input box here at ITRC. The work will undoubtedly require some effort and some investigation to tailor it to your particular environment and your particular requirements; with what applications and tools are available and with what specific behaviors are required. This probably isn't much more than a day of work (for an experienced DCL programmer) to investigate, design, code, debug and integrate into your environment, but that's still rather larger than what fits into this ITRC text box.

Alternatively, there are organizations around which can provide direct DCL training.

[Mrityunjoy Kundu]

$a=F$cvtime(,,"weekday")
$if "a" eqs "thursday"
$then
$this_file= F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
$SUBMIT/AFTER=17:00 F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
$exit
$else
$exit
$reply/all/bell "message"
$exit

[ngoht20]

SO how will I initiate a message like this one below since every Thurs. at 17:00 I have to UPDATE the data on OpenVMS system? And I want to send this message to all my WIndows conected PCs.

Example:

*URGENT* message on RUEV01, from user, PYNSYC at RUEV03 Batch 16:44:55
ESPS SYSTEM CLOSEDOWN IN 10 MINUTES

[labadie_1]

add /urgent to the
$ reply... command
given by Hoff, and you will get /urgent

[Wim Van den Wyngaert]

You can also write a dcl procedure to do for each TNA device :

open/write x tna1:
write x "Please logoff"
close x

(my users get scared when they get "reply received...")

Wim

[Hoff]

Opening up TN devices and writing directly can expose you to a sequencing error with channel assignment and SHARE privilege. It's rare, but it's now probably the most common trigger for the classic dangling ownership problem.

I'd use REPLY.

If the REPLY header text bothers you or your end-user community, you can use $sndopr and generate your own messages.

In the menu software I was supporting, I coded a mechanism within the menu system that would display a nice error when the next command was attempted. (It was a no-brainer: it was a logical name in a shared logical name table, and the logical name translation contained the messages. There are better ways, but this works. As part of the main command loop, it checked for the logical name.) Enable the message, wait five or ten minutes or whatever the duration of the longest menu command might be, and off you go. Anybody that starts a command after the shields are raised, and it displays the message and returns to the prompt.