Hi Steve,
Do you have any news about the engineering case created around this?
Additionnal information :
1. If I execute the command "PORT.STATUS" and the last layer stack is on the verb "SLEEP", the port.status works.
Ex :
SLEEP 30
Result :
S.INFO>PORT.STATUS PID 7556 LAYER.STACK
There are currently 0 uniVerse sessions; 1 interactive, -1 phantom
Pid.... User name. Who. Port name..... Last command processed............
7556 jcd 18 telnet WI.JCD [ WI.JCD @ 0x6 ]
Layer type....... Program name.................... Address...
BASIC run machine WI.JCD 0x00000006
Verb
2. If I execute the command "PORT.STATUS" and the last layer stack is on the verb "WRITE" and the record is locked, the port.status never works.
Ex :
READU ITEM FROM F.TMP,"JCD" THEN
WRITE "TEST" ON F.TMP,"JCD"
END
Result :
S.INFO>PORT.STATUS PID 7556 LAYER.STACK
There are currently 0 uniVerse sessions; 1 interactive, -1 phantom
Pid.... User name. Who. Port name..... Last command processed............
7556 jcd 18 Unknown Unavailable
Tested on UV 11.3.2 (Platform windows). Session Telnet (Process tl_server.exe)
Regards,
Jean-Christophe
------------------------------
Jean-Christophe Dewalque
Developer
Infodata
Bereldange LU
------------------------------
Original Message:
Sent: 02-22-2021 14:16
From: Manu Fernandes
Subject: UV PORT.STATUS on Windows and Unavailable last command
Hi steve,
Many thanks for the explain.
Yes, there is wait-time on uvcs client (SBXA) but too with process runnung as iPhantoms which are using socket waiting request result. Probable the same behavior you de scribe.
Actually to accellerate the sbxa login, I overload PORT.STATUS when requested by sbxa'login.
Regards
------------------------------
Manu Fernandes
Original Message:
Sent: 02-22-2021 12:36
From: Steven Wingfield
Subject: UV PORT.STATUS on Windows and Unavailable last command
Hi Manu,
I am so sorry for the delay. Was busy with a release, and then some crazy winter weather took our state out of commission for a bit. I'm back now though.
So, on Windows, UniVerse uses an alternative to Unix signal handling to communicate PORT.STATUS information from the queried processes over to the port.status.exe program. This mechanism uses Windows Event Objects. The delay you see (about one second per queried uvcs process), is because the uvcs processes are busy listening on their tcp/ip port, and cannot respond to port.status.exe's query. Thus, each of these queries to the respective uvcs processes times out after about one second. This is cumulative across all of the uvcs processes that port.status.exe is querying.
There was recently filed an engineering case around this. I will reach out to you with additional details.
Thanks for your patience,
Steve
------------------------------
Steven Wingfield
Rocket Software
Original Message:
Sent: 12-09-2020 10:02
From: Manu Fernandes
Subject: UV PORT.STATUS on Windows and Unavailable last command
hi,
thanks for any help
I join a xls file to detail the sessions.
I hope you can help
column pkg show what it is : sbxa, wihdl = phantom+socket
------------------------------
Manu Fernandes
Original Message:
Sent: 12-08-2020 12:20
From: Steven Wingfield
Subject: UV PORT.STATUS on Windows and Unavailable last command
Thanks for the extra info Manu. Would you be able to send us the following as well?
1. Output of port.status
2. Annotated with which processes are uvcs, which are uvsh, and which are phantoms executing the socket operation?
3. Total time the command took to finish.
Something like the following, for example:
There are currently 48 uniVerse sessions; 19 interactive, 29 phantom
Pid.... User name. Who. Port name..... Last command processed.......
5555 userA 9 Unknown Unavailable <-- phantom executing socket call
6666 userB -30 Unavailable <-- uvcs from sb/xa
7777 userB -43 Unavailable <-- uvcs from sb/xa
8888 userB -44 Unavailable <-- uvcs from sb/xa
9999 userC -46 LIST VOC <-- uvsh
...
------------------------------
Steven Wingfield
Rocket Software
Original Message:
Sent: 12-08-2020 11:30
From: Manu Fernandes
Subject: UV PORT.STATUS on Windows and Unavailable last command
Hi steve,
Thanks for your participation.
I encounter it under uv/windows 11.3.2 (but from 11.x and always under windows os)
Some session are uvsh (Telnet) , some are uvcs (sb/xa), many are phantom (with socket operation).
Actually, with 20 actives sessions, port.status takes 25 seconds... And as sb/xa start a port.status when user login it became critical... That's why I start a search...
Thanks for any advice.
------------------------------
Manu Fernandes
Original Message:
Sent: 12-08-2020 09:40
From: Steven Wingfield
Subject: UV PORT.STATUS on Windows and Unavailable last command
Hi Manu,
Quick question, are these processes uvsh processes (telnet/ssh) or uvapi processes (UO.NET/UOJ/etc.)? Also, what version of UniVerse did you see this slow down?
Thanks,
Steve
------------------------------
Steven Wingfield
Rocket Software
Original Message:
Sent: 12-07-2020 11:33
From: Manu Fernandes
Subject: UV PORT.STATUS on Windows and Unavailable last command
hello
One behavior of UV / Windows Port.Status that I have never resolved is the presence of Unavailable as the last process command.
Which greatly slows down the output of port.status.
Have you ever experienced such a situation?
sample
There are currently 48 uniVerse sessions; 19 interactive, 29 phantom
Pid.... User name. Who. Port name..... Last command processed.......
10760 efv 9 Unknown Unavailable
8104 jcd -30 Unavailable
4132 jcd -43 Unavailable
8588 jcd -44 Unavailable
10660 jcd -46 Unavailable
------------------------------
Manu Fernandes
------------------------------