reply/enable

[stan Jenereski_1]

What I want to do is to Reply/Enable for OPER10,OPER11,OPER12 to a non-physical
terminal at boot to fool the application.

can this be done and could someone post an example.

my thanks

[Bojan Nemec · Accepted solution]

Stan,

I try with a lat device (VMS 6.2) and need a more extended test.

$ mc latcp create port lta100
$ define/user sys$command lta100:
$ reply/enable=(oper10,oper11,oper12)

Now if you try:

$ request/to=oper10/reply

You dont get the "No operator coverage for request" error.
As I said before, it needs more testing. I dont know what it happens when there are many requests. Also you will never get a reply from such "operator".

Bojan

[John Gillings]

Stan,

I'm not sure I understand what you're trying to achieve. There is a danger in enabling OPCOM on a device where the I/O won't necessarily complete. OPCOM has some safeguards to prevent it blocking if I/Os are blocked, but it has been known to cause trouble.

In some (very) old versions of VMS hitting ^S on OPA0, or running out of paper on a hardcopy terminal (I did say *very* old! ;-) would cause OPCOM messages to back up inside the OPCOM process, which would expand virtual memory up to VIRTUALPAGECNT and then crash the system!

Although you can create an LTA port and (apprently) enable OPCOM on it, F$GETDVI(port,"OPR") will remain FALSE.

What does the application expect?

[Volker Halle]

Stan,

there is an example available for

Redirecting OPCOM Messages to a TCP/IP Server

http://h18000.www1.hp.com/support/asktima/communications/009C2137-35DF3200-1C0096.html

which could be easily modified to just ignore or log the OPCOM messages.

It also refers to another article:

Example-C Using Pseudoterminal Driver to Capture OPCOM Messages

which I couldn't locate.

Volker.