Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!cos!hadron!decuac!felix!chuck
From: chuck@felix.UUCP (Charles Vertrees (Chuck))
Newsgroups: comp.os.vms,comp.edu,comp.sys.dec
Subject: Re: DAL (a stupid language on VMS)
Message-ID: <15541@felix.UUCP>
Date: Mon, 7-Dec-87 12:23:49 EST
Article-I.D.: felix.15541
Posted: Mon Dec  7 12:23:49 1987
Date-Received: Sun, 13-Dec-87 02:44:50 EST
References: <516@naucse.UUCP>
Sender: daemon@felix.UUCP
Reply-To: chuck@felix.UUCP (Charles Vertrees (Chuck))
Organization: FileNet Corp., Costa Mesa, CA
Lines: 44
Keywords: VMS, DAL, Keypad Reading
Summary: Really about problems reading characters
Xref: mnetor comp.os.vms:3780 comp.edu:857 comp.sys.dec:489

In article <516@naucse.UUCP> jdc@naucse.UUCP (John Campbell) writes:
>We're stuck.  We are trying to use Digital's Authoring Language (DAL)
>on VMS and we want to read keypad keystrokes.  There is an example
>in the manual that we can not get to work.  All attempts to use
>the DAL INPUT facility (a terminal read routine) have failed to
>put escape sequences into the proper string descriptor (RESPONSE).
>
>Does anyone out there have a piece of DAL code that uses INPUT or
>QUERY and can find keypad or cursor key strings?

I know nothing about DAL but this sounds like a similar problem I came across
once.  When VMS went from V3.x to V4.0, DEC added command line editing and
recall.  If you have a VT100 type terminal then you can use the arrow keys
(among others) to use these new features.  The problem is that these keys
generate escape sequencies.  Command recall was implemented in DCL, but the
command line editing was implemented in the terminal driver.  As a result, the
terminal driver now interprets all escape sequences, discarding invalid ones
(an error condition is actually returned I believe).  The problem arises if you
want to grab escape sequences yourself.

We had several utilities that used escape as a command attention key.  These
programs stopped working when we upgraded to V4.0.  The only solution we could
come up with at the time was to disable command line editing.  When this was
done, the terminal driver stopped trying to mung the characters and everything
went back to normal.  Of course command line editing was no longer available in
the utility, but a utility that works was better than one that did not.  

The simple solution was to wrap invocation of the utility in a DCL script
which turned command line editing off prior to starting the utility and then
re-enabled it upon exit.  I believe the commands to do this are $ SET TERMINAL
/NOEDIT and $ SET TERMINAL /EDIT.

These utilities were written in Pascal, and were performing their own QIO's
for input on a character basis.  With editing turned on, everything worked
fine except we couldn't capture escapes or any following characters until the
driver determined it was an invalid escape sequence.  Turning off editing
provided a quick fix after much more sophisticated experimentation proved
futile.

There may be some other more elegant solutions available now, but it has been
about a year since I was on a VMS machine, and I have not been following it
very closely.  Hope this helps you solve your problem.

Chuck Vertrees.