cancel
Showing results for 
Search instead for 
Did you mean: 

event 0.7

 
SOLVED
Go to solution
bkelly13
Advisor

event 0.7

I have been asked to consult on a project that has a VAX FT810 running VMS 5.5. They need it to stay operational until December. Its been more than 10 years since I last worked on this system or touched a VAX or VMS system.

It had dual Ethernet between the FT810 and a Xyplex terminal server. It kept getting adjacency down then up with attendant application failure. The application depends on the Ethernet connection to the Xyplex server. We disable one of the Ethernet link and that problem disappeared.

Now we are getting an occasional message about event 0.7, aborted service request from node 1.9. It is followed rather quickly by another message saying things are ok. I think that event was 4.10 but don't have my notes with me and I am not on site.

I am reasonably certain that node 1.9 is the FT810 computer node, but I cannot find anything about event 0.7. Can anyone tell me about event 0.7? (that is zero point seven )

I have the full set of manuals. Is this documented in there somewhere?

Thanks for your time,
Bryan
15 REPLIES 15
Hoff
Honored Contributor
Solution

Re: event 0.7

You'll want the old DECnet Phase IV manuals (long retired from the docs, and I found a set years back and tossed them onto the Freeware V5.0 distro), and the DECnet architecture manuals, if you're wading into this area.

DECnet event 0.7, is an aborted service request, and will usually indicate a line open error, unrecognized component or other such condition. It's typically a MOP request that has arrived. Some widget on your LAN is looking for boot files, usually.

This 0.7 is nothing to worry about; it's entirely normal for many configurations. (Now if there is no other box around that is servicing the MOP requests here or something blocking the MOP sequences, now that's more of a problem and worth a look.)

I have a collection of DECnet and DECnet MOP articles and topics posted (and links to manuals and the architecture documents and such); start with:

http://labs.hoffmanlabs.com/node/61

bkelly13
Advisor

Re: event 0.7

Hello Hoff,
RE: DECnet event 0.7, is an aborted service request, and will usually indicate a line open error, unrecognized component or other such condition. It's typically a MOP request that has arrived. Some widget on your LAN is looking for boot files, usually.

Our LAN is limited to about six feet of thin net cable between the VAX and the Xyplex terminal server. There are no other components connected. The FT810 drives a communications controller by polling it a few times a second. When we get the event, communications stops for a bit then resumes.

As noted, we simply disconnected ethernet link KFE-0 and are running on KFE-1. The computer seems to not know anything about KFE-0 but we don't know why.

I cannot see your reply while I write this, but will follow your link and see what I find.

Thanks for the reply,
Bryan
Hoff
Honored Contributor

Re: event 0.7

The 0.7 aborted service request means the box didn't or couldn't deal with an arriving network request. That's usually a MOP request from something, but could well point to some other problem with the LAN hardware or the ThinWire network or the Xyplex terminal server.

The ThinWire coax has specific configuration requirements around the cabling and the T and the termination, and the cabling can get damaged and can simply degrade. That's worth confirming.

If this isn't MOP, then what's going on here requires some more detail (there's usually a second error message associated with 0.7) and could well need a look at the hardware; at the Jetstream box and its NICs, and at the ThinWire, and at the terminal server.

JetStream needed 5.5-2HF? or some other specific releases for these boxes, as well as the FTSS pieces. Though given your comments, I doubt that stuff has been changed here, or will be changed here.

Also see http://vt100.net/manx/search?cp=1&q=vaxft


bkelly13
Advisor

Re: event 0.7

Hello Hoff,
I have recomended that we replace the thin net cable and to ohm out the terminators. As we are just trying to limp along while waiting for a replacement system, I'll let this error slide for a while.

Just in case, I will leave this open for a day or two just in case someone else has a thought, then I will close it.

Thanks for taking the time to reply.
Wim Van den Wyngaert
Honored Contributor

Re: event 0.7

I would start with a power off/power on and reseating the (network)cards and network connections.

fwiw

Wim
Wim
Volker Halle
Honored Contributor

Re: event 0.7

Bryan,

consider to post the full DECnet event 0.7 message text.

You can DEFINE/SYS MOM$LOG FF and then look at SYS$MANAGER:MOM.LOG (or is it SYS$SYSTEM:MOM.LOG ?) after the next error has happened. You may find more information about the received MOP message in that .LOG file.

Volker.
bkelly13
Advisor

Re: event 0.7

Wim Van den Wyngaert: We are down to one drive that has been running for something like ten years or more and have no one with recent VMS experience. If we power down and the driver doesnâ t spin up we are really up a creek. I must wait on that until I have checked out two other computers that are in unknown state but should be able to run the application. Both are rather old, but we will see.

Volker Halle: Thanks for the suggestions. I will implement and see what I get. I wonâ t have a response until mid next week.
bkelly13
Advisor

Re: event 0.7

This is a long post so in summary I have two questions:
How do I enable Ethernet cards KFE-0 and KFE-1 and make them functional?
What is the syntax for starting the NCP log file?

I tried this suggestion

[quote]You can DEFINE/SYS MOM$LOG FF and then look at SYS$MANAGER:MOM.LOG (or is it SYS$SYSTEM:MOM.LOG ?) after the next error has happened. You may find more information about the received MOP message in that .LOG file.[/quote]

VMS accepted the command, but no log data was produced. I found three versions of [SYS$MANAGER]:MOM.LOG, all about a month old and probably on the same day. But no recent files. I used the name MOMBK.LOG so I wouldnâ t mess up any old files.

The problem became much worse today and decayed to the point that the application would not run. The drives are all 10 to 15 years old and I was worried that if turned off they might not spin back up. After looking at the machine I realized/remembered that the CPU logic power is separated from the disk driver power. I was able to power down the CPU and leave the drives spinning. We put the Ethernet cards from the bottom half into the top half and booted it up. We are now running without error.

We do have a complete backup FT810 that was a development system. When I checked it, only half the machine will power up, but thatâ s ok. When I checked the Ethernet cards with a SHOW CIRCUITS, it showed none. If my two Ethernet cards on the operational system are KFE-0 and KFE-1, how do I turn them on and make them useful.

I still want to be able to activate logging. I started MCP and started with the SET command and let it prompt me all the way to the end. Then it gave me a syntax error that was unexpected. To make this short, the command was:
SET LOGGING FILE CIRCUIT KFE-1 EXECUTOR
After hitting the enter key for EXECUTOR it prompted with:
Sink name (filename.typ)
I entered MOMBK.LOG and when that did not work tried the whole process over again with [SYS$MANAGER]:MOMBK.LOG.
It prompted with
Sink state (ON, OFF, HOLD)
I entered ON and pressed return. The response was:
%NCP-W-NUPGP. Invalid parameter grouping, sink node.

The prompting did not seem to indicate a grouping? Does anyone know what I have wrong?
Volker Halle
Honored Contributor

Re: event 0.7

Bryan,

to configure DECnet Phase IV, run @SYS$MANAGER:NETCONFIG. It will do a new configuration - based on your input and the system configuration.

DECnet lines/circuits KFE-n are associated with OpenVMS EFcn: devices. In general, you would DEFINE them with

$ MC NCP DEF LINE KFE-0 STATE ON
$ MC NCP DEF CIRC KFE-0 COST x STATE ON

Running @STARTNET would then activate these lines/circuits given that OpenVMS autoconfiguration found and created the underlying EFcn: devices.

Please post the full 0.7 event message.

MOM$LOG is a private LOG file of the MOM process and will log additional information into SYS$MANAGER:MOM.LOG - if the MOM process would be activated to service a MOP request. This has NOTHING to do with DECnet event logging itself.

Note that if you generally mistrust your old hardware, it may be possible to emulate a FT-VAX by using the CHARON-VAX emulator based on a fault-tolerant PC (e.g. STRATUS).

Volker.
bkelly13
Advisor

Re: event 0.7

I'll be working that today. The full text of the message is:

OPCOM 27 Apr 2009 08:27:17.18
Mesage from User DECNET on OPS810
DECnet event 0.7, aborted service request
From note 1.9 (OIPS810) 27 aPR 2009 08:27:15.22
Circuit KFE-1, Receive error

There is nothing more than this.
Volker Halle
Honored Contributor

Re: event 0.7

Bryan,

did you ever look at the LINE and CIRCUIT counters of KFE-1 ?

$ MC NCP SHOW LINE KFE-1 COUNTER
$ MC NCP SHOW CIRC KFE-1 COUNTER

Is this 0.7 event eventually followed by a 4.10 circuit up ?

Volker.
Volker Halle
Honored Contributor

Re: event 0.7

Bryan,

this event is declared in module [NETACP]NETDLE when a network packet has been received by the DECnet downline load and
loopback class driver (NDDRIVER) and the IO status word indicates an error. A circuit down event (4.7) will also be declared as well.

Volker.
Volker Halle
Honored Contributor

Re: event 0.7

Bryan,

the received packet will be ignored, so no MOM process will be created. This explains, why you don't see a new MOM.LOG file together with this event.

You may actually have to monitor this LAN segment with a LAN analyzer/sniffer to find out, which packet from which node seems to be triggering this event. Finding out the actual IOSB error code is not possible, except if you patch NETACP to crash the system or loop, if such a packet has been received with a bad IOSB.

Volker.
bkelly13
Advisor

Re: event 0.7

To All,
As noted in my post yesterday, the system deteriorated to the point that the application could not function. We replaced the Ethernet card and cured the problem. It has not been running over 24 hours without a single event. We did some testing and concluded that the Ethernet card was not able to properly drive the thin wire cable. It probably could not detect that and could declare an error and conclude something else caused the problem.

Regardless, the Ethernet card was bad and was the cause of the problem.

Now I have this FT810 able to support the application. I guess that really closes this thread. I do have another FT810 that is running, but does not recognize any Ethernet connection. But that should be a new problem.

The information you, each of you, has provided has been helpful and will continue to be helpful as I work the other computer.

I will look up additional information on new machines that can run VMS and our code using the information I have found on this site.

I thank you all for your assistance.
bkelly13
Advisor

Re: event 0.7

I am closing this thread because the problem has been resolved. I thank everyone that took the time to respond.

Thank you,
Bryan