topic Re: help with dcl script in Operating System - OpenVMS

help with dcl script

sandy test — Wed, 30 Dec 2015 13:00:54 GMT

I would like to write a script to send the equivalent of pf1 or pf2 or pf3 or pf4 keys, and a control key+letter (like control key+R).

Any help greatly appreciated.

thanks

Re: help with dcl script

Steven Schweda — Wed, 30 Dec 2015 15:11:01 GMT

> [...] a script to send the equivalent of pf1 or [...]

   Define "send"? Send how, exactly? Send to what, exactly?

   It might be more helpful to describe the actual problem
which you are trying to solve than to ask how to implement
some specfic "solution" to that problem.

   A VT terminal (or equivalent) sends a particular escape
sequence for each PFx key. A Web search for, say:
      vt escape sequence
or:
      pf1 escape sequence
should find many documents which explain what such terminals
send when keys like PFx are used.

   Generally, a Control/x combination masks off the high two
or three bits of the usual ASCII code for "x", leaving the
low five bits. So, for example, Control turns "C", 0x43,
into ETX, 0x03; or "[", 0x5B, into ESC, 0x1B. (Or "R", 0x52,
into DC2, 0x12.)

Re: help with dcl script

H.Becker — Wed, 30 Dec 2015 15:39:54 GMT

I'm not sure what you mean with "send the equivalent of". You may want to give some details.

For what it is worth, have a look at the VTxxx documentation, for example the VT220 Programmer Reference Manual, which is available at http://vt100.net/docs/vt220-rm/. Chapter 3 is about Transmitted Codes.

On the DCL side, you can define symbols for non-printable ASCII (and ISO-Latin-1) characters with

$ DC2[0,8]=%x12
$ ESC[0,8]=%x1b
$ PF1=ESC+"OP"

and then you can use WRITE to "send" them to a file, opened by DCL,
SYS$OUTPUT, ...

Re: help with dcl script

Hoff — Wed, 30 Dec 2015 18:57:30 GMT

Programmable Function PF keys and many other keyboard keys are just ANSI control sequences. An escape character or a CSI character, and a few other characters, using a specific format. These are then set to whatever device is on the other end of the connection. From the termianl or terminal emulator to the host. There are analogous ANSI control sequences that are sent from the host to the terminal or terminal emulator, causing the output device to use bold text or position the output text or the input cursor somewhere, or such.

These go from host ot device, or device to host.

What this I/O doesn't do is go from a DCL procedure to an application program, which is what I suspect you're looking to do here. DCL output goes to the null device, or to a log file of some sort, or to a user via a terminal or terminal emulator. Input from the user goes from the terminal or terminal emulator to DCL or to the application, depending on what is performing the read I/O request.

What doesn't happen is DCL output to application input. Not under normal circumstances.

Which means you're probably looking to wrap or test or otherwise automate some application program that's probably screen-based, and you now want to have a DCL command procedure or some other application software that you can control to perform the key-pressing and related tasks.

Unfortunately for your quest, OpenVMS and its command language has no analog of the bash expect command, so the usual analogs used here are the use of DECset and its DEC Test Manager package, or the use of an application program and the OpenVMS construct known as a pseudo-terminal and running the application via your own application-controlled terminal device (that's not a DCL API), or reworking the target application to have a callable API. None of which is particularly trivial.

For some related discussions and additional background,, see here here here or here.

If I've guessed wrong here, When asking questions, please provide some additional background to your question. Background and details and examples and/or software versions or related — investing a little time into the question that you're asking — can mean you'll get the answer you need, and much more quickly, too. Thanks!

Re: help with dcl script

sandy test — Thu, 31 Dec 2015 06:21:17 GMT

Thanks for all your imput, and yes I should have been more specific.

Basically I am looking for a way to "gently" logoff inactive users. We have been using watcher, but just doing a dcl stop pid causes RDB to do

a recovery, and also bothers our standby database. I also tried the other options which were suggested in the watcher help, but those also caused

problems.

As all of our users are captured accounts running to same application, I would like to send a series of "pressed keys" to each inactive terminal

to basically do what the actual user does when he logs off from the application. We have a program like "peek and spy" which allows us to connect

to the user's terminal. I thought to write a dcl script to start control on the terminal, and then send a sequence of pf and control keys to logoff

the user. I will consult the links mentioned as see if I can get something that works.

Thanks again for your help and suggestions.

Re: help with dcl script

Hoff — Thu, 31 Dec 2015 22:31:37 GMT

Ah, so some details. Okay. As for the "pressed keys" approach, set up a pseudo-terminal or the rest. That's how the "pressed keys" stuff works, irrespective of what you want to do with your key presses. Doesn't do what you want, not easy to deal with,. not particularly applicable here. Same answer as before, in short.

Likely the easiest answer is to switch the tool that you are using over to using $forcex calls and not $delprc calls, and get on with life. That's a trivial change in most applications, too. The $forcex invokes whatever exit handlers the application has established, and which should allow RMS and Rdb to run their cleanup processing.

The ancient OpenVMS FAQ has various discussions of idle-process killers other than MadGoat Watcher, too. There's what looks to be an updated Watcher version available via Github, too — if that's not what you're using here.

Tried WATCHER_LOGOUT procedure and a sequence involving a STOP /EXIT=USER /ID=pid or such? Work your way up to an inner-mode exit after a delay, as the user-mode exit can be ignored if the user-mode developer was inclined to code the application to do so. Also within the current Watcher code, I'd very likely extend the delta between the $forcex and the $delprc from the current two seconds to maybe 30 seconds or so, to give Rdb time to do... whatever. You're not in a hurry here, after all. Based on a very quick look at the source, make the following change in force.b32 or whatever replaced it in the version you're using locally:

DELPRCDLY : VECTOR [2,LONG],

goes to

DELPRCDLY : VECTOR [30,LONG],

The best solution is to use timers in the application you're working with. Asynchronous exits and asynchronous process kills have always tended to be problematic, as they can arrive at particularly inopportune moments, even in an idle process. Either have the timer fire within the application, or set up a doorbell lock or a mailbox or other interprocess comms to allow you to send an exit request.

As for the general "everybody out of the database" sequence, there's a way to kick everybody out of the database from the Rdb RMU level, too. RMU /CLOSE /ABORT=forcex or some such. I've used that prior to starting up certain maintenance processing.

FWIW, asking specific questions will usually get you the right answer to the question that you are asking, but can entirely entirely miss a better or easier or different solution to the problem you are solving.

Re: help with dcl script

John Gillings — Sun, 03 Jan 2016 20:31:27 GMT

Sandy,

A different approach.

I find that Idle Process Killers train your users to not logout. After all, why should they bother? Let the machine do it. That just exacerbates the issue.

My suggestion is to train your users the other way. Assuming you have the logic to detect idle processes, instead of attempting to kill the process, with all the headaches that causes, instead send an email to the culprit, reminding them of company policy to not leave open terminals/sessions, and a count of how many times they've been in breach of the policy in the past day/week/month/year. If they exceed some threshold, include a CC to their manager. Offer an incentive, something trivial like movie tickets, for anyone who has a zero breach score over 6 months or a year.