Oh, I should point out that EDI.aps is set as a 'Server' application startup shell, which is what started me down this experiment in the first place. 

This should work:

You always need to specify the extension .aps when specifying your own start-up shell for a UServer. If you don't do this then the server will not start. And when you start a server or UST manually then you always need to specify all the command line option. The UServer or the URouter will not check the UST definitions specified in the urouter.asn in this case. Two remarks: when you use nowait then the UServer process will start and execute the code in the start-up shell. Depending on the code you are using the Debugger will not show any code (although it should attach to the process). And the specified maxidle setting is not really long. You really need to start the Debugger in a hurry and if no additional code is executed then the UServer will be shut down again after 30 seconds. So it probably does not make much sense to use the Debugger here. Just saying. Hope this helps. Daniel

Hi Daniel,  Hmmm, it won't start with /maxidle=30s. It will start if I change to /maxidle=30 (or 60), or remove /maxidle entirely.  Whatever /maxidle is set to, the started userver shows up in the urouter as idle for 5.57.54, and with maxidle of -1. And the server never shuts itself down.  Using apexit in the application execute trigger doesn't close the server process either. So I'm not sure this is good for what I want to do, (system housekeeping on the server). As for the debugger, the secret is to start the debugger process with :create, wait 30 seconds, then start the userver, that way you can catch the first line of the application execute trigger to see what it is doing.  Iain

Thanks Iain. I've double checked this and /maxidle is actually not a valid command line switch for the UServer (when it's started manually). This switch is a management switch that can be used in a UST definition (in the [SERVERS] section of the urouter.asn) and is interpreted by the URouter. Unfortunately the UServer does not report that it does not recognize the /maxidle switch (and just fails to start). Not sure how you've managed to start a UServer using the mentioned switch. When I test this here then the userver always exits immediately (without logging an error) when I use /maxidle. You could also specify the idle timeout using the ASN setting $NET_TIMEOUT (in the ASN file of the UServer). This will work, but you want see the idle timeout in the URouter Monitor. Also, the UServer process will be shutdown regardless if it has state (this behavior differs from /maxidle). Also not sure why apexit does not close the UServer process in your case. When I test this here then the process disappears as soon as apexit is executed. But instead of starting a UServer from the command line, you also could start it using the UROUTMON operation START_SERVERS. This will allow you again to use /maxidle (in the (UST). Hope this helps. Daniel

So, what I am looking to do is to start a userver, run a single operation on a service, close the userver. This is for housekeeping tasks within our application.  I have tried putting the apexit in the execute trigger of the start up shell, and as the last line in the operation of the service. Neither appears to close the userver from within the urouter monitor. I'd ideally like to start it from the task scheduler within windows, as this gives me built in functions for scheduling, although an alternative is to build in an infinite loop to the start up shell, and put scheduling code in the loop, then start the service on urouter startup. (from the urouter ASN there's a setting).  When you say $NET_TIMEOUT exits regardless of state, does that mean it will kill the process even if the service is still running?    Regards,  Iain

Hi Iain, You should run your operation using uniface.exe and your aps rather than userver.exe. Regards, Mike

Iain Sharp said I have tried putting the apexit in the execute trigger of the start up shell, and as the last line in the operation of the service. Neither appears to close the userver from within the urouter monitor.

I've used this before in a service that was running on a UServer and it definitely shut-down the process. Not sure why you mention the URouter Monitor. Do you mean that the UST/server in question is still listed? That is possible, since the UServer process will be shutdown immediately by the apexit. I don't think it'll report anything back to the URouter. One way to check if a server is "dead" is by sending a request (i.e. activating a remote operation) to that UST. The URouter should then realize that the specific server is gone (and remove it from the administration). It would of course be nice if the URouter had another way to detect this, but I think that we've already discussed this before (and there are still some open issues regarding the /uec and /vfy switches).

Iain Sharp said I'd ideally like to start it from the task scheduler within windows, as this gives me built in functions for scheduling, although an alternative is to build in an infinite loop to the start up shell, and put scheduling code in the loop, then start the service on urouter startup. (from the urouter ASN there's a setting). 

Using an infinite loop in a server is not such a good idea, since it will use a lot of CPU cycles. I've used the UTIMER component before in a UServer to check/call a Web Service every 15 minutes. That worked quite well.

Iain Sharp said When you say $NET_TIMEOUT exits regardless of state, does that mean it will kill the process even if the service is still running? 

No, it will only shut down a process that is idle. But the /maxidle setting will only shut down a UServer if there are no open instances or database transactions. $NET_TIMEOUT will not do this and the open instances and db transactions will be (forcibly) closed (resulting in a rollback in the later case). Hope this helps. Regards, Daniel

Daniel - Ah, yes, I've checked and the process does indeed close, without de-registering from the urouter.             I've tried close and close "$DNP" and they don't help keep the urouter tidy.  Mike - We currently do run the housekeeping from a start up shell which starts mostly services from uniface.exe. Since our system is client server, that means we have two processes running (uniface.exe and userver.exe) to do one job, both on the same machine (the app server), I know the difference is going to be marginal, but I was hoping to use less system resource, since speed at runtime is one of our biggest bugbears.