Odd behavior on ctrl-y

[Tom Adams]

This is on VMS 7.3-2

I have a program that use SMG$SET_OUT_OF_BAND_AST to run an AST for ctrl-y and ctrl-c.

The AST dequeues all locks and runs SYS$EXIT.

It works correctly in response to ctrl-y if I run it on the command line

It works correctly if I run it from a command procedure.

But if I add the qualifier /OUTPUT=X.X to the command procedure the
locks remain queued and other programs end up waiting for locks.
If I type in STOP and hit return then the locks are freed up.

If I add ON CONTROL_Y THEN EXIT to the command procedure, it works
correctly even with /OUTPUT=X.X

The latter is a fix of sorts, but I would like to know why it
hangs. Is there any way to keep a programmer from having to
remember to add ON CONTROL_Y to any command procedure that
runs this image?

[Steven Schweda]

I've never used SMG, so I know nothing, but ...

> [...] If I type in STOP and hit return then the locks are
> freed up.

To me, that sounds as if _you_ are not handling the Ctrl/Y
-- the OS is.

> I have a program that use SMG$SET_OUT_OF_BAND_AST to run an
> AST for ctrl-y and ctrl-c.

Does your (invisible) program check for success/failure
when you set up the AST? If the SMG stuff fails when you
redirect the output, then that might explain this behavior.

> [...] I would like to know why it hangs.

Because Ctrl/Y does not always kill the job? Have you
tried CONTINUE instead of STOP?

[Stephen Hoffman]

On 2015-11-11 18:35:09 +0000, Tom Adams said:

> {usual plea for help expurgated.}

Post your code. Or preferably, post a cut-down reproducer.

From my own experience, I've found that creating the reproducer often
isolates and identifies the bug, too.

On no evidence, likely either erroneous error handling, or the wrong
I/O channel, or the DCL — you've not posted code — disables CONTROL_Y
handling.

If the code is not using SMG for anything else — SMG deals with I/O all
on its own, and that may well be a factor here — then there are easier
ways to capture ^Y.

FWIW, most program-debugging questions will degenerate into "post a
reproducer", too.


--
Pure Personal Opinion | HoffmanLabs LLC

[VAXman-]

SMG$CREATE_PASTEBOARD looks at what the output device is. You can define
the output device as an argument in the SMG$CREATE_PASTEBOARD call.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[VAXman-]

He doesn't need a reproducer. I've already explained why and what he can do
to correct it.

[Louis Krupp]

On Wed, 11 Nov 2015 19:08:58 GMT, VAXman- @SendSpamHere.ORG wrote:

>In article <n2031b$4t4$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>>On 2015-11-11 18:35:09 +0000, Tom Adams said:
>>
>>> {usual plea for help expurgated.}
>>
>>Post your code. Or preferably, post a cut-down reproducer.
>>
>>From my own experience, I've found that creating the reproducer often
>>isolates and identifies the bug, too.
>>
>>On no evidence, likely either erroneous error handling, or the wrong
>>I/O channel, or the DCL — you've not posted code — disables CONTROL_Y
>>handling.
>>
>>If the code is not using SMG for anything else — SMG deals with I/O all
>>on its own, and that may well be a factor here — then there are easier
>>ways to capture ^Y.
>>
>>FWIW, most program-debugging questions will degenerate into "post a
>>reproducer", too.
>
>He doesn't need a reproducer. I've already explained why and what he can do
>to correct it.

That depends on your definition of "already." Your explanatory reply
has an apparent posting time of 19:02 UTC, which is three minutes
*after* Stephen's apparent posting time of 18:59.

See:

http://afeinberg.github.io/2011/06/17/replication-atomicity-and-order-in-distributed-systems.html

Louis

[JF Mezei]

A couple of generic questions:

If one runs executable under a command procedure with a ON CONTROLY
statement, is it possible that the executable's handler AST not get
called and it is purely the DCL ON CONTROL Y that does the job ?


Secondly, when running an interactive executable from a command
procedure, isn't it best practice to DEFINE SYS$INPUT TT: (or
F$TRNLNM("TT") to ensure that the program sees the terminal as input ?

[VAXman-]

Clueless. Sorry, my newsfeed isn't as up-to-the second as yours.

[osuv...@gmail.com]

Are you using the pasteboard for displaying output or just capturing the control-Y? If not using it for output, simply specify SYS$COMMAND as the output device in the SMG$CREATE_PASTEBOARD call so you don't have to deal with redirection of SYS$OUTPUT.

BTW, when interrupting a program, it's usually cleaner to use the EXIT command rather than STOP.

[tadamsmar]

On Wednesday, November 11, 2015 at 2:02:07 PM UTC-5, VAXman- wrote:

Not sure exactly what you are suggesting I do. The output device argument is not specified on the call to SMG$CREATE_PASTEBOARD. Some else suggested setting it to SYS$COMMAND, go you agree? What should I set it to?

This particular SMG$CREATE_PASTEBOARD call is just used to get a pasteboard id for the other call that sets out of band asts. It is not used for output.


I am just getting back to solving this problem.

[Stephen Hoffman]

On 2015-12-08 15:45:04 +0000, tadamsmar said:

> Not sure exactly what you are suggesting I do. The output device
> argument is not specified on the call to SMG$CREATE_PASTEBOARD. Some
> else suggested setting it to SYS$COMMAND, go you agree?

What's to agree to? Try it.

> What should I set it to?

Well, you could set it to "HOFF DISLIKES HIDING CONFIGURATION SETTINGS
IN LOGICAL NAMES" if you wanted, but I'd try a valid local filename
there first.

> This particular SMG$CREATE_PASTEBOARD call is just used to get a
> pasteboard id for the other call that sets out of band asts. It is not
> used for output.

Mr Schenkenberger appears to be suggesting modifying the source code to
write to the desired output to a file by specifying the target output
file in the SMG call, or by redirecting via logical name. Not
performing the I/O redirection through DCL's already very hackish and
rather poor "support" for I/O redirection.

For code that is used more widely, the usual approach is to further
modify the program to accept the output specification from the command
line (via foreign command or DCL CLD or otherwise), and defaulting to
the current behaviour, and opening the specified file via the SMG call
in response to the presence of an output specification on the command
line. Rolling your own /OUTPUT or -o or --output support, depending
on local syntax preferences.

[VAXman-]

In article <9f43067d-391e-4646...@googlegroups.com>, tadamsmar <tada...@yahoo.com> writes:
>On Wednesday, November 11, 2015 at 2:02:07 PM UTC-5, VAXman- wrote:
>> In article <60b75771-3948-430f...@googlegroups.com>, Tom Adams <> writes:
>> >This is on VMS 7.3-2
>> >
>> >I have a program that use SMG$SET_OUT_OF_BAND_AST to run an AST for ctrl-y and ctrl-c.
>> >
>> >The AST dequeues all locks and runs SYS$EXIT.
>> >
>> >It works correctly in response to ctrl-y if I run it on the command line
>> >
>> >It works correctly if I run it from a command procedure.
>> >
>> >But if I add the qualifier /OUTPUT=X.X to the command procedure the
>> >locks remain queued and other programs end up waiting for locks.
>> >If I type in STOP and hit return then the locks are freed up.
>> >
>> >If I add ON CONTROL_Y THEN EXIT to the command procedure, it works
>> >correctly even with /OUTPUT=X.X
>> >
>> >The latter is a fix of sorts, but I would like to know why it
>> >hangs. Is there any way to keep a programmer from having to
>> >remember to add ON CONTROL_Y to any command procedure that
>> >runs this image?
>>
>> SMG$CREATE_PASTEBOARD looks at what the output device is. You can define
>> the output device as an argument in the SMG$CREATE_PASTEBOARD call.
>>
>> --
>> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
>>
>> I speak to machines with the voice of humanity.
>
>Not sure exactly what you are suggesting I do. The output device argument is not specified on the call to SMG$CREATE_PASTEBOARD. Some else suggested setting it to SYS$COMMAND, go you agree? What should I set it to?

Right. So where/how do you think SMG$CREATE_PASTEBOARD knows what the output
device will be? Did you read the documentation WRT SMG$CREATE_PASTEBOARD? If
the [output-device] argument is omitted SMG$CREATE_PASTEBOARD uses SYS$OUTPUT.

>This particular SMG$CREATE_PASTEBOARD call is just used to get a pasteboard id for the other call that sets out of band asts. It is not used for output.

Right. So, you need to specify a device for SMG$CREATE_PASTEBOARD. If you've
redirected output via /OUTPUT, then SYS$OUTPUT is no longer the terminal that
was initially associated with SYS$OUTPUT. You need to tell pass something to
SMG$CREATE_PASTEBOARD that will let it know that you still want it to create
a pasteboard associated with your terminal. You might try passing a string
descriptor that defines "SYS$COMMAND" instead.

>I am just getting back to solving this problem.

If you're running this interactively, you could ask SYS$GETJPI to return the
name of the default terminal and pass it to the SMG$CREATE_PASTEBOARD. Not
knowing how you use this particular application, you may want to explore how
this would affect your application if it can be run as a BATCH or NETWORK
process.

[VAXman-]

In article <n46vkr$2am$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>On 2015-12-08 15:45:04 +0000, tadamsmar said:
>
>> Not sure exactly what you are suggesting I do. The output device
>> argument is not specified on the call to SMG$CREATE_PASTEBOARD. Some
>> else suggested setting it to SYS$COMMAND, go you agree?
>
>What's to agree to? Try it.
>
>> What should I set it to?
>
>Well, you could set it to "HOFF DISLIKES HIDING CONFIGURATION SETTINGS
>IN LOGICAL NAMES" if you wanted, but I'd try a valid local filename
>there first.
>
>> This particular SMG$CREATE_PASTEBOARD call is just used to get a
>> pasteboard id for the other call that sets out of band asts. It is not
>> used for output.
>
>Mr Schenkenberger appears to be suggesting modifying the source code to
>write to the desired output to a file by specifying the target output
>file in the SMG call, or by redirecting via logical name. Not
>performing the I/O redirection through DCL's already very hackish and
>rather poor "support" for I/O redirection.

Not even close. SMG$CREATE_PASTEBOARD assigns its pasteboard identifier (a
data structure with the channel assigned to the device which was defined as
the output when the SMG$CREATE_PASTEBOARD was invoked). When the OP didn't
specify an [output-device] parameter in the SMG$CREATE_PASTEBOARD call, the
default is to translate the current SYS$OUTPUT for the device. /OUTPUT the
way the OP used it, associates SYS$OUTPUT to the file specified. Ergo, the
modification of the code part of your reply is correct but I was hoping the
OP would realize that something defining the terminal being used instead of
the file would need to be passed to SMG$CREATE_PASTEBOARD output-device arg-
ument. A descriptor containing SYS$COMMAND may do the trick. I've already
replied with this info. Basically, this is a failure of the OP to RTFM.

[tadamsmar]

On Tuesday, December 8, 2015 at 11:16:49 AM UTC-5, Stephen Hoffman wrote:
> On 2015-12-08 15:45:04 +0000, tadamsmar said:
>
> > Not sure exactly what you are suggesting I do. The output device
> > argument is not specified on the call to SMG$CREATE_PASTEBOARD. Some
> > else suggested setting it to SYS$COMMAND, go you agree?
>
> What's to agree to? Try it.

I tried it today, it works fine for our purposes, it seems to be the best approach.

Just needed some hand-holding, recognizing that I am also going to get slapped around by the cranky experts here, it's worth it. Nice to get some confirmation, not good for one's confidence to find a bug that can halt your 20-year old production system with a mere ctrl-y to a user interface.

One other question. The code ends up having 3 pasteboard IDs, one used to disable ctrly (running a noop ast instead), one used to enable ctrly aborts of the user interface program (running a op ast), one that is, lo and behold, actually used a the id of a pasteboard that the code pastes upon. This all seems to work and I really don't want to rewrite it. But I wonder if there are any hidden issues.

[tadamsmar]

On Wednesday, November 11, 2015 at 5:35:36 PM UTC-5, JF Mezei wrote:
> A couple of generic questions:
>
> If one runs executable under a command procedure with a ON CONTROLY
> statement, is it possible that the executable's handler AST not get
> called and it is purely the DCL ON CONTROL Y that does the job ?

If SMG$SET_OUT_OF_BAND_ASTS used to run an AST on CONTROL Y, then I find that the DCL ON CONTROL Y is ignored even if the AST calls SYS$EXIT. DCL processing never seems to see the CONTROL Y. The command procedure just executes the next command after the RUN command.

This is OK for our purposes, but it does beg the question of what to do if you want CONTROL Y run the handler AST and also perform the processing specified
in the ON CONTROL Y command.

[Stephen Hoffman]

On 2015-12-09 13:43:07 +0000, tadamsmar said:

> Just needed some hand-holding, recognizing that I am also going to get
> slapped around by the cranky experts here, it's worth it. Nice to get
> some confirmation, not good for one's confidence to find a bug that can
> halt your 20-year old production system with a mere ctrl-y to a user
> interface.

What's been shown so far of this production system is poorly-written
and unstable application code. From experience with these cases,
there are likely also latent security problems, issues of data
integrity and potential data loss, and other issues are a distinct
possibility. Some old code is reliable and maintainable and stable.
This code is not. Most any OpenVMS C code that's still dependent on
the old VAXC standards is not going to be stable code, as I've
previously commented.

> One other question. The code ends up having 3 pasteboard IDs, one used
> to disable ctrly (running a noop ast instead), one used to enable ctrly
> aborts of the user interface program (running a op ast), one that is,
> lo and behold, actually used a the id of a pasteboard that the code
> pastes upon. This all seems to work and I really don't want to rewrite
> it. But I wonder if there are any hidden issues.

If what you have shown for other code is representative of this code,
yes, there are latent issues. As for multiple pasteboards, quoth the
doc:

"A pasteboard is a logical structure for performing output operations
to a terminal screen. You can think of a pasteboard as a
two-dimensional area on which you place and manipulate screen displays.
A pasteboard is always associated with a physical device or an OpenVMS
RMS file, but a pasteboard may be larger or smaller than the physical
screen. Each output device has only one pasteboard."

http://h30266.www3.hp.com/odl/vax/opsys/vmsos73/vmsos73/5935/5935pro_001.html#6_pasteboards


ps: my cranky is in my drafts folder.

[VAXman-]

In article <df1c075d-f1ad-422d...@googlegroups.com>, tadamsmar <tada...@yahoo.com> writes:
>On Tuesday, December 8, 2015 at 11:16:49 AM UTC-5, Stephen Hoffman wrote:
>> On 2015-12-08 15:45:04 +0000, tadamsmar said:

>>=20
>> > Not sure exactly what you are suggesting I do. The output device=20
>> > argument is not specified on the call to SMG$CREATE_PASTEBOARD. Some=
>=20

>> > else suggested setting it to SYS$COMMAND, go you agree?

>>=20

>> What's to agree to? Try it.
>

>I tried it today, it works fine for our purposes, it seems to be the best a=
>pproach.
>
>Just needed some hand-holding, recognizing that I am also going to get slap=
>ped around by the cranky experts here, it's worth it. Nice to get some con=
>firmation, not good for one's confidence to find a bug that can halt your 2=

>0-year old production system with a mere ctrl-y to a user interface.
>

>One other question. The code ends up having 3 pasteboard IDs, one used to =
>disable ctrly (running a noop ast instead), one used to enable ctrly aborts=
> of the user interface program (running a op ast), one that is, lo and beho=
>ld, actually used a the id of a pasteboard that the code pastes upon. This =
>all seems to work and I really don't want to rewrite it. But I wonder if t=
>here are any hidden issues.

You have three devices? You can *ONLY* create ONE pasteboard PER DEVICE!

I'd imagine that the other SMG$CREATE_PASTEBOARD calls fail and your paste-
board ID is zero. Zero is the ID of the first pasteboard. Pasteboard IDs
are ordinal numbers unlike other SMG virtual IDs which are addresses of the
internal structures created to track the virtual device (display, keyboard).

[Stephen Hoffman]

On 2015-12-09 17:12:26 +0000, tadamsmar said:

> On Wednesday, December 9, 2015 at 10:10:13 AM UTC-5, Stephen Hoffman wrote:
> As for multiple pasteboards, quoth the
>> doc:
>>
>> "A pasteboard is a logical structure for performing output operations>
>> to a terminal screen. You can think of a pasteboard as a>
>> two-dimensional area on which you place and manipulate screen
>> displays.> A pasteboard is always associated with a physical device or
>> an OpenVMS> RMS file, but a pasteboard may be larger or smaller than
>> the physical> screen. Each output device has only one pasteboard."
>>
>

> Actually the doc is confusing. It is confusing to *you*. Think about
> it. I am using SMG$CREATE_PASTEBOARD to get a thing called a
> "pasteboard id". But I and using this so-called "pasteboard id" to
> catch control y. It's more than an id of a two-dimensional area, it's
> also an id that may be used to configure communications on an
> input-only channel that has no associated two-dimensional area.

"Each output device has only one pasteboard" is the confusing part.

But then SMG was never very popular locally — its features were
seemingly always constrained by the DEC layered product offerings, and
it was — like X11 of that era — way too much work for what you got.
Though I do occasionally still use it for a command-line recall, but
not for much else.

[tadamsmar]

I did a little testing, and I see what is going on.

If there is already a pasteboard for the device, then it returns the existing
pasteboard id (not necessarily zero) and it returns the success code SMG-S-PASALREXI.

You are right about there being only one pasteboard id per device.

Thanks for the input.

In this app have either one or two devices depending on if I am directing output to a file via a command procedure.

[tadamsmar]

On Wednesday, December 9, 2015 at 1:14:53 PM UTC-5, Stephen Hoffman wrote:
> On 2015-12-09 17:12:26 +0000, tadamsmar said:
>
> > On Wednesday, December 9, 2015 at 10:10:13 AM UTC-5, Stephen Hoffman wrote:
> > As for multiple pasteboards, quoth the
> >> doc:
> >>
> >> "A pasteboard is a logical structure for performing output operations>
> >> to a terminal screen. You can think of a pasteboard as a>
> >> two-dimensional area on which you place and manipulate screen
> >> displays.> A pasteboard is always associated with a physical device or
> >> an OpenVMS> RMS file, but a pasteboard may be larger or smaller than
> >> the physical> screen. Each output device has only one pasteboard."
> >>
> >
> > Actually the doc is confusing. It is confusing to *you*. Think about
> > it. I am using SMG$CREATE_PASTEBOARD to get a thing called a
> > "pasteboard id". But I and using this so-called "pasteboard id" to
> > catch control y. It's more than an id of a two-dimensional area, it's
> > also an id that may be used to configure communications on an
> > input-only channel that has no associated two-dimensional area.
>
> "Each output device has only one pasteboard" is the confusing part.
>

> But then SMG was never very popular locally -- its features were

> seemingly always constrained by the DEC layered product offerings, and

> it was -- like X11 of that era -- way too much work for what you got.

> Though I do occasionally still use it for a command-line recall, but
> not for much else.
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

You responded to a message that I had deleted. (you get them in your email?)

Actually I was wrong, there is only one pasteboard per device. If you call
SGM$CREATE_PASTEBOARD twice with the same device, then it gives you back the existing pasteboard id and returns one of those -S- type success messages. The help/message says:

PASALREXI, pasteboard already exists for this device

Facility: SMG, Screen Management Facility

Explanation: You tried to create a pasteboard for a device, when one is
already created. This is normal in a modular environment.
The existing pasteboard ID is returned. Make sure you do not
delete pasteboards that you did not create.

User Action: None.

[Stephen Hoffman]

On 2015-12-09 18:31:27 +0000, tadamsmar said:

> You responded to a message that I had deleted. (you get them in your email?)

More than a few news servers do not honor article deletion requests.
Article deletion is accordingly unreliable, at best.

The headers from my postings will indicate a usenet connection via
Eternal September. Not via mail.

FWIW, the Google Groups front-end includes the IP address that you're
posting from.

[VAXman-]

In article <38b5e888-3fd3-4cfd...@googlegroups.com>, tadamsmar <tada...@yahoo.com> writes:
>On Wednesday, December 9, 2015 at 10:10:13 AM UTC-5, Stephen Hoffman wrote:
>As for multiple pasteboards, quoth the=20
>
>> doc:
>>=20
>> "A pasteboard is a logical structure for performing output operations=20
>> to a terminal screen. You can think of a pasteboard as a=20
>> two-dimensional area on which you place and manipulate screen displays.=
>=20
>> A pasteboard is always associated with a physical device or an OpenVMS=20
>> RMS file, but a pasteboard may be larger or smaller than the physical=20

>> screen. Each output device has only one pasteboard."

>>=20
>
>Actually the doc is confusing. It is confusing to *you*. Think about it. =
> I am using SMG$CREATE_PASTEBOARD to get a thing called a "pasteboard id". =
> But I and using this so-called "pasteboard id" to catch control y. It's m=
>ore than an id of a two-dimensional area, it's also an id that may be used =
>to configure communications on an input-only channel that has no associated=
> two-dimensional area.
>

On an output, not input, device.

[tadamsmar]

On Wednesday, December 9, 2015 at 3:21:38 PM UTC-5, VAXman- wrote:
> In article <38b5e888-3fd3-4cfd...@googlegroups.com>, tadamsmar <tada...@yahoo.com> writes:
> >On Wednesday, December 9, 2015 at 10:10:13 AM UTC-5, Stephen Hoffman wrote:
> >As for multiple pasteboards, quoth the=20
> >
> >> doc:
> >>=20
> >> "A pasteboard is a logical structure for performing output operations=20
> >> to a terminal screen. You can think of a pasteboard as a=20
> >> two-dimensional area on which you place and manipulate screen displays.=
> >=20
> >> A pasteboard is always associated with a physical device or an OpenVMS=20
> >> RMS file, but a pasteboard may be larger or smaller than the physical=20
> >> screen. Each output device has only one pasteboard."
> >>=20
> >
> >Actually the doc is confusing. It is confusing to *you*. Think about it. =
> > I am using SMG$CREATE_PASTEBOARD to get a thing called a "pasteboard id". =
> > But I and using this so-called "pasteboard id" to catch control y. It's m=
> >ore than an id of a two-dimensional area, it's also an id that may be used =
> >to configure communications on an input-only channel that has no associated=
> > two-dimensional area.
> >
>
> On an output, not input, device.

Yes, it's an output device and an input device, and I am using it only for input.

Anyway, thanks to all for your help. I only had to change two line of code to
put 'sys$command" as the device name on two SMG$CREATE_PASTEBOARD calls. But, I wanted to better understand the consequences of that change rather than rely only on testing to make sure it works.

[VAXman-]

In article <ff015d0e-bc6a-4085...@googlegroups.com>, tadamsmar <tada...@yahoo.com> writes:
>On Wednesday, December 9, 2015 at 3:21:38 PM UTC-5, VAXman- wrote:

>> In article <38b5e888-3fd3-4cfd...@googlegroups.com>, tadamsmar <tada...@yahoo.com> writes:
>> >On Wednesday, December 9, 2015 at 10:10:13 AM UTC-5, Stephen Hoffman wrote:
>> >As for multiple pasteboards, quoth the=20
>> >
>> >> doc:
>> >>=20
>> >> "A pasteboard is a logical structure for performing output operations=20
>> >> to a terminal screen. You can think of a pasteboard as a=20
>> >> two-dimensional area on which you place and manipulate screen displays.=
>> >=20
>> >> A pasteboard is always associated with a physical device or an OpenVMS=20
>> >> RMS file, but a pasteboard may be larger or smaller than the physical=20
>> >> screen. Each output device has only one pasteboard."
>> >>=20
>> >
>> >Actually the doc is confusing. It is confusing to *you*. Think about it. =
>> > I am using SMG$CREATE_PASTEBOARD to get a thing called a "pasteboard id". =
>> > But I and using this so-called "pasteboard id" to catch control y. It's m=
>> >ore than an id of a two-dimensional area, it's also an id that may be used =
>> >to configure communications on an input-only channel that has no associated=
>> > two-dimensional area.
>> >
>>
>> On an output, not input, device.
>

>Yes, it's an output device and an input device, and I am using it only for input.

Just how are you using the pasteboard id for input?

[tadamsmar]

On Wednesday, November 11, 2015 at 5:35:36 PM UTC-5, JF Mezei wrote:

> A couple of generic questions:

> (snip)

> Secondly, when running an interactive executable from a command
> procedure, isn't it best practice to DEFINE SYS$INPUT TT: (or
> F$TRNLNM("TT") to ensure that the program sees the terminal as input ?

I have used this:

define/user sys$input sys$command

I think it may be better practice than what you suggest.

[tadamsmar]

I get a pasteboard ID and all that I use it for is to call SMG$SET_OUT_OF_BAND_ASTS and all that does is to trap control characters "typed at the terminal" (as the user manual says). But it really does not need to be a terminal, could be a read only device or an input pipe, right?

[VAXman-]

In article <05f47c87-fb95-47b3...@googlegroups.com>, tadamsmar <tada...@yahoo.com> writes:
>On Wednesday, December 9, 2015 at 4:27:48 PM UTC-5, VAXman- wrote:
>> In article <ff015d0e-bc6a-4085...@googlegroups.com>, tadam=

>smar <tada...@yahoo.com> writes:
>> >On Wednesday, December 9, 2015 at 3:21:38 PM UTC-5, VAXman- wrote:

>> >> In article <38b5e888-3fd3-4cfd...@googlegroups.com>, ta=
>damsmar <tada...@yahoo.com> writes:
>> >> >On Wednesday, December 9, 2015 at 10:10:13 AM UTC-5, Stephen Hoffman =
>wrote:
>> >> >As for multiple pasteboards, quoth the=3D20
>> >> >
>> >> >> doc:
>> >> >>=3D20
>> >> >> "A pasteboard is a logical structure for performing output operatio=
>ns=3D20
>> >> >> to a terminal screen. You can think of a pasteboard as a=3D20
>> >> >> two-dimensional area on which you place and manipulate screen displ=
>ays.=3D
>> >> >=3D20
>> >> >> A pasteboard is always associated with a physical device or an Open=
>VMS=3D20
>> >> >> RMS file, but a pasteboard may be larger or smaller than the physic=
>al=3D20

>> >> >> screen. Each output device has only one pasteboard."

>> >> >>=3D20
>> >> >
>> >> >Actually the doc is confusing. It is confusing to *you*. Think abou=
>t it. =3D
>> >> > I am using SMG$CREATE_PASTEBOARD to get a thing called a "pasteboard=
> id". =3D
>> >> > But I and using this so-called "pasteboard id" to catch control y. =
>It's m=3D
>> >> >ore than an id of a two-dimensional area, it's also an id that may be=
> used =3D
>> >> >to configure communications on an input-only channel that has no asso=
>ciated=3D
>> >> > two-dimensional area.
>> >> >
>> >>=20

>> >> On an output, not input, device.
>> >

>> >Yes, it's an output device and an input device, and I am using it only f=
>or input.
>>=20

>> Just how are you using the pasteboard id for input?
>

>I get a pasteboard ID and all that I use it for is to call SMG$SET_OUT_OF_B=
>AND_ASTS and all that does is to trap control characters "typed at the term=
>inal" (as the user manual says). But it really does not need to be a termi=

>nal, could be a read only device or an input pipe, right?

How does your application get its input?

[tadamsmar]

I have a modification of the app in the works.

Before modification it got all it's input from SYS$INPUT

After modification, it traps CONTROL Y form SYS$COMMAND

[VAXman-]

In article <813d6501-cf72-491a...@googlegroups.com>, tadamsmar <tada...@gmail.com> writes:

>I have a modification of the app in the works.
>
>Before modification it got all it's input from SYS$INPUT
>
>After modification, it traps CONTROL Y form SYS$COMMAND

:roll:

SMG$READ_COMPOSED_LINE, SMG$READ_VERIFY, SMG$READ_KEYSTROKE, etc?

[tadamsmar]

The code uses those. They read from SYS$INPUT which is the default input device.

Before modification CONTROL Y was read from SYS$OUTPUT with is the same device as SYS$INPUT by default (unless you are executing from a command procedure).

[Tom Adams]

Seems odd that SMG$READ* routines read from SYS$INPUT by default, but SMG$SET_OUT_OF_BAND_ASTS processes input from SYS$OUTPUT by default.

Seems like a design error. Violates the principle of least astonishment.

[VAXman-]

In article <3e9511c8-46af-461f...@googlegroups.com>, Tom Adams <tada...@gmail.com> writes:
>Seems odd that SMG$READ* routines read from SYS$INPUT by default, but SMG$SET_OUT_OF_BAND_ASTS processes input from SYS$OUTPUT by default.
>
>Seems like a design error. Violates the principle of least astonishment.

SMG$READ* read from a virtual keyboard and depend upon how SMG$CREATE_VIRTUAL_KEYBOARD
has been invoked. Design error? No, the SMG$ routine, at least the loin's share, are
for use in the virtual environment of pasteboard, displays and keyboards.

[Tom Adams]

So what is the point of having SMG$SET_OUT_OF_BAND_ASTS (a function that only processes input) operate a pasteboard id instead of a keyboard id? What, pray tell, is the logic in that?

[VAXman-]

In article <acdda1b3-5ba8-426a...@googlegroups.com>, Tom Adams <tada...@gmail.com> writes:
>On Friday, December 11, 2015 at 2:51:57 PM UTC-5, VAXman- wrote:

>So what is the point of having SMG$SET_OUT_OF_BAND_ASTS (a function that only processes input) operate a pasteboard id instead of a keyboard id? What, pray tell, is the logic in that?

You need to understand the SMG$ virtual model to answer that question. ;)

[Tom Adams]

On Friday, December 11, 2015 at 5:35:59 PM UTC-5, VAXman- wrote:
> In article <acdda1b3-5ba8-426a...@googlegroups.com>, Tom Adams <tada...@gmail.com> writes:
> >On Friday, December 11, 2015 at 2:51:57 PM UTC-5, VAXman- wrote:
> >> In article <3e9511c8-46af-461f...@googlegroups.com>, Tom Adams <tada...@gmail.com> writes:
> >> >Seems odd that SMG$READ* routines read from SYS$INPUT by default, but SMG$SET_OUT_OF_BAND_ASTS processes input from SYS$OUTPUT by default.
> >> >
> >> >Seems like a design error. Violates the principle of least astonishment.
> >>
> >> SMG$READ* read from a virtual keyboard and depend upon how SMG$CREATE_VIRTUAL_KEYBOARD
> >> has been invoked. Design error? No, the SMG$ routine, at least the loin's share, are
> >> for use in the virtual environment of pasteboard, displays and keyboards.
> >> --
> >> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
> >>
> >> I speak to machines with the voice of humanity.
> >
> >So what is the point of having SMG$SET_OUT_OF_BAND_ASTS (a function that only processes input) operate a pasteboard id instead of a keyboard id? What, pray tell, is the logic in that?
>
> You need to understand the SMG$ virtual model to answer that question. ;)

You appear to be trying to obscure the fact that you can't answer my question by hiding behind rhetoric.

Since a so-called pasteboard id is already used for processing input, why bother to have a separate keyboard id? Why not one id for both?

[Stephen Hoffman]

FWIW, SYS$INPUT is the DCL command procedure file, when in a command
procedure. Just to get the third thread on this topic back into the
mix again, too.