connection to VMS V 6.2 is too slow

[osama12]

I have VMS v6.2 with CERNER Medical application
the users connected to the vms throw cerner telnet reflection.
some times it will take 90-120 seconds to connect and after connecting the connection will be very slow even with typing.

Please help me.

[Volker Halle]

This problem can be inside the OpenVMS system or in the network. Run $ MONITOR SYSTEM to check, if the system may be overloaded. Log in on the console (OPA0:) to see if you experience the same bad throughput - if not, it's msot likely a network problem.

Volker.

[kumarasamy]

hai
similar problem I faced in our computer(open VMS 6.2)
then I observed that size of Qman$journal file was exponentially increased day by day.Then I deleted this file then system became fast responds.
just check your system whether any file becoming abnormal size or junk files by unknown process. try to normalise those thing then system's responds will be ok

mkumar

[Steven Schweda]

> I observed that size of Qman$journal file
> was exponentially increased day by day.
> Then I deleted this file then system
> became fast responds.

If this file being too large actually is the
problem, a Google search for QMAN$JOURNAL
will give you the approved method for working
around this bug:

RUN SYS$SYSTEM:JBC$COMMAND
DIAGNOSTIC 7

See, for example:

http://h71000.www7.hp.com/wizard/wiz_3333.html

where it says:

The SYS$QUEUE_MANAGER.QMAN$JOURNAL cannot be deleted.
Well, it could be deleted, but you would then need
to rebuild your queue database largely from scratch.


Also, "exponential" does not mean "great".

[Ian Miller.]

check also your DNS server. If your VMS system is attempting to perform a reverse DNS lookup for incoming telnet connections and eventually the DNS lookup times out then this can give symptoms like this.

Does this system use DNS ? (check name resolver config e.g UCX SHOW NAME).

[Steven Schweda]

Bad DNS data can delay the initial
connection, but I don't see how they could
make the connection "be very slow" after the
connection has been established.

MONITOR SYSTEM (and other tools) might help
to determine what the actual problem is.

[Phil.Howell]

If you decide that its the network...
I have used ttcp and ttcpw to check network throughput between client PCs and vms.
This shows up any network misconfiguration.
Phil

[kumarasamy]

Hai steven

yes, you can not delete the journal file as it is.but first we have to create a new print que manager. while doing so new journal file is created then the old file can be deleted..
bye

[kumar sanjay_1]

Check some Basic things..

1) free space in system disk.
2) memrory Staus.

[comarow]

The most simple way to see if it's a network
issue is go to the console or other hardwired session.

If it's fine, than you have a network problems.

Then is everything slow, or just an application?

Is everyone slow or just certain users?


If it's a network issue, which I suspect
it is than one very useful command is

Anal/system
show lan/count


and you'll see lots and lots of data. All we
are interested in are the failures and errors.

If you give us some indication of the bad fields that would help.



If it's slow at the console too, than it's analysis time.

The Monitor command as stated in previous notes is your friend.

Depending on it, other monitor commands will be used.

Diagnosing performance via a forum is really not a reasonable way to do this.

Bob

Have fun