Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Errors with MV.NET

1 view
Skip to first unread message

Sean Chapman

unread,
Sep 3, 2008, 11:35:05 AM9/3/08
to
We started getting these errors from AIX last night.

Sep 3 08:24:01 00000010 7.4.2.M12 19 Open error on serial
device 900

I wrote a quick app to check the current unix PIDs to see what is on
each and got (900-950 is the range set for mv.net using the
serialrange option in the pick config):
PORT: 900 PID: 8237136
PORT: 901 PID: 8704144
PORT: 902 PID: 7733378
PORT: 903 PID: 8831054
PORT: 904 PID: 3903730
PORT: 905 PID: 7647428
PORT: 907 PID: 7610542
PORT: 909 PID: 4739110
PORT: 910 PID: 5763176
PORT: 912 PID: 7618650

Looking at the MV.NET Session monitor I'm only seeing ports 907 and
910 showing up in the list of used ports. If I check the ports in
question they're at
:where 900

Ln PCB PIB ABS Stat R1 & Return stack contents 08:28:41 03
Sep 2008
FID Stat Base

0900 000AA4 E390 000018 rdl.getchar:4F8 rdl.getchar:048
readlinx:08C
br.input:2CC

Right now if I try and tandem to them I can't get to the debugger like
normal and typing text into them creates more of that AIX error.


Any help would be greatly appreciated

Sean Chapman

unread,
Sep 3, 2008, 11:36:06 AM9/3/08
to
Just for reference we're using version 3.5.1.3 of MV.NET

Tony Gravagno

unread,
Sep 3, 2008, 12:42:02 PM9/3/08
to
Use session manager to logoff/terminate all mv.NET connections.
Restart the session/license services from session manager.
Not sure if this will work but in D3 try:
logoff 900-950
or create a proggie to do it.
Make sure all processes are wrapped up.
Try a single connection from mv.NET again, maybe using data manager.
If error occurs again, set server profile to show connection monitor
and watch what's happening.

Any help?
T

Sean Chapman

unread,
Sep 3, 2008, 12:45:36 PM9/3/08
to
That's what I've been doing right now to clear it up. It is has
repeated though since we've started using the product. We'll get ports
that just seem to go wonky. The session monitor doesn't list them, but
they keep unix pids. I have an app that checks the range and does a !
kill on the pids if I need to clear them, but we'd rather not see the
errors come up and was hoping someone could point us in the right
direction to debug them.

On Sep 3, 9:42 am, Tony Gravagno


<address.is.in.po...@removethis.com.invalid> wrote:
> Use session manager to logoff/terminate all mv.NET connections.
> Restart the session/license services from session manager.
> Not sure if this will work but in D3 try:
>   logoff 900-950
> or create a proggie to do it.
> Make sure all processes are wrapped up.
> Try a single connection from mv.NET again, maybe using data manager.
> If error occurs again, set server profile to show connection monitor
> and watch what's happening.
>
> Any help?
> T
>

Tony Gravagno

unread,
Sep 9, 2008, 10:50:59 PM9/9/08
to
The error started on 2-Sep. I'm wondering if it was running OK before
then, and if so, what changed.

The only other thing I can think of is to ensure you have the 7bit
conversion set for client-host comms from the Server Profile tab. I
don't think I've seen a *nix system that worked without that checked
because for some reason *nix sends across funky escape sequences when
Windows does not.

I think CDP and other forums are excellent for HowTo questions about
products, but when there are "wonky" errors I think the vendor should
be contacted immediately for simultaneous/direct support. In this
case, I recommend you contact your mv.NET reseller, or BlueFinity if
you bought direct.

FWIW, I have only one client with any mv.NET connectivity issues,
that's a Unidata site, and BlueFinity is working directly with the
developer (who is certainly reading this) to resolve the issue. So I
hope your issue is identified and you can share the cause/resolution
with us.

Regards,
T


Sean Chapman wrote:

>That's what I've been doing right now to clear it up. It is has
>repeated though since we've started using the product. We'll get ports
>that just seem to go wonky. The session monitor doesn't list them, but
>they keep unix pids. I have an app that checks the range and does a !
>kill on the pids if I need to clear them, but we'd rather not see the
>errors come up and was hoping someone could point us in the right
>direction to debug them.
>

0 new messages