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
------------------------------

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
------------------------------

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
------------------------------

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
------------------------------

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
------------------------------

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
------------------------------

Thanks for this Manu, and apologies for the delay, I was out for the holidays and getting back into things now. I will take a look at the attachment.

------------------------------
Steven Wingfield
Rocket Software
------------------------------

Hi Manu!

I am sure Steven will come up with the actual technical answer, but I can provide some anecdotal information that might help.

We work in a Universe on AIX environment, but we also occasionally get the "unavailable" response to some ports when we run a PORT.STATUS. Our experience has been that PORT.STATUS will return "unavailable" under the following conditions:
- The process that is running on that port is VERY busy and does not respond to the PORT.STATUS command
- The connection (uvcs or ssh) has been dropped by the user, but the back-end process is still active and has not terminated (stuck on a lock, stuck in a tight loop, etc.)
- The process on that port is stuck waiting on some kind of system input (like a response to a disk write) and is ignoring other system requests
- The process that was running on that port aborted in such a way that it did not properly clean up the workspace (very rare).

Again, though, we're in an AIX environment, so I don't know if any of these scenarios apply to the Windows world or not.

------------------------------
Brian Paige
Serta Simmons Bedding, LLC
------------------------------

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
------------------------------

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
------------------------------

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
------------------------------

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
------------------------------

Hi Jean-Christophe,
The ticket Steve mentioned related to PORT.STATUS and uvcs processes on Windows is UNV-29751. It is currently a candidate to be included in the next 11.3.x maintenance release which is 11.3.5.
The latest information you supplied seems to be related to telnet processes that might be waiting to get a lock? I wasn't sure from your example. In the code snippet if the READU was successful and the THEN clause was executed, the WRITE statement should finish immediately and move on to the next statement in the program. I did try a test where another user held the lock and the WRITE statement waited until the lock was released, but was not able to reproduce the behavior you described.
If the behavior is reproducible, you may want to open a support ticket and get the behavior logged since it is not directly related to the uvcs issue reported with UNV-29751.
Thank you.
Neil

------------------------------
Neil Morris
Universe Advanced Technical Support
Rocket Software
------------------------------

Hi Neill,

Thank you for your reply.
Good news for the port.status and the uvcs processes.

For my example with the telnet processes that wait to get the lock, I will open perhaps a support ticket.
The content of the support ticket will be different because with my example, the commande LIST.READU EVERY displays the pid wich is waiting to get the lock.
I have other cases with PORT.STATUS doesnt show the layer stack.

Regards,
Jean-Christophe

------------------------------
Jean-Christophe Dewalque
Developer
Infodata
Bereldange LU
------------------------------

Thanks Jean-Christophe. Sounds good.

------------------------------
Neil Morris
Universe Advanced Technical Support
Rocket Software
------------------------------

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
------------------------------

I am experiencing this exact issue right now with PORT.STATUS on Windows with UV11.3.x.

The primary symptom being that logging into SB/XA is incredibly slow once there are a considerable number of users logged in.
@manu fernandes you mentioned that you overloaded PORT.STATUS when requested by sbxa'login.

Can you share information on that? does it have any negative impact? Is it limited to just the login process?

Thanks in ADvance

------------------------------
Aaron Glover
AU
------------------------------

I am experiencing this exact issue right now with PORT.STATUS on Windows with UV11.3.x.

The primary symptom being that logging into SB/XA is incredibly slow once there are a considerable number of users logged in.
@manu fernandes you mentioned that you overloaded PORT.STATUS when requested by sbxa'login.

Can you share information on that? does it have any negative impact? Is it limited to just the login process?

Thanks in ADvance

------------------------------
Aaron Glover
AU
------------------------------

hello Aaron,

Yes we overload PORT.STATUS to return a 'cache' of PORT.STATUS when we are on sbxa login.

Here is the code : IN.PORT.STATUS.CACHE

to overload, we COPY VOC PORT.STATUS,:PORT.STATUS
and catalog my program IN.PORT.STATUS.CACHE as PORT.STATUS
then whn executed IF CASE @SENTENCE = 'PORT.STATUS' AND SYSTEM(9001)<3,2>[8] = 'SB.LOGIN'
return a previous/cached PORT.STATUS value else we CHAIN ':':@SENTENCE

We see no impact on sbxa runtime but quick connection .

With kind regards

------------------------------
manu fernandes
------------------------------

Thanks so much @manu fernandes.

I am also testing a patched version of SB.LOGIN given to me by Rocket. This patched version uses LISTUSER instead of PORT.STATUS for UniVerse.
Apparently this has always been done for UniData but they can now do for UniVerse since 11.3.1 when it was introduced.

Both approaches work perfectly. I'm guessing that the hotfix I have received from Rocket will be released as an official patch at some point.

thanks again!

------------------------------
Aaron Glover
AU
------------------------------

Sign up

Please log in or register:

Welcome to the Rocket Forum!

Please log in or register:

Scanning file for viruses.

This file cannot be downloaded