Thanks Alan
I was somewhat confused with the Planning and Customization manual, with the
section:
Starting and Stopping TCP/IP Servers
It lists many of the servers and how to stop them, usually with SMSG.
It didn't list REXECD which was part of my questioning Kris' post.
Apparently, I was in the wrong part of the manual...again..
And the OBEY command you pointed me at, does work at resetting the MaxRestart
parm:
netstat obey port 512 tcp tcpip
VM TCP/IP Netstat Level 520
OBEY command response is: OK
OBEY return code = 0
And I see REXECD and RXAGENT1 being xautologged.
And...imagine that....it works as advertised!
However, now that it all worked, I logged onto REXECD.
When I ran my same tests (from MAINT), they still worked.
When using "guest", it seemed to use the RXAGENT1 server.
When using a "userid", it xautologged on the user and executed the command.
So, I thought that the "communication" problem that being logged on to the
server may only be at startup.
#CP IPL CMS (from REXECD)
and brought the server up.
Both my tests still ran fine.
So, is the caution about not being logged on to REXECD or having the secondary
user, one of mere caution, or are there occasional things might happen, later,
perhaps much later, that fouls up things, perhaps recovery?
Anyway, for testing, it seems I can be logged on.
But now that it works, I would only be logged on to update the a-disk with some
rexx programs that I will be executing remotely.
Thanks for your help
Tom Duerbusch
THD Consulting
>>> Alan Altmark <[email protected]> 7/20/2011 9:35 AM >>>
On Wednesday, 07/20/2011 at 10:18 EDT, Tom Duerbusch
<[email protected]> wrote:
> My manuals (z/VM 5.2) do not show a method of recycling REXECD using the
> OBEYFILE command. It does show it for about a dozen other servers, but
not for
> REXECD.
>
> Searching the archives, I found very few questions about REXECD and
nothing
> concerning OBEYFILE.
>
> Is it possible that your comment about OBEYFILE to restart TCPIP
servers, a
> general comment and not explicitly for the REXECD server?
The OBEYFILE technique for resetting the restart counter applies to any
server actually monitored by the stack. That is, those with PORT
reservations that do not have NOAUTOLOG in them. You will not find any
server-specific reference; only the generic usage note on the MaxRestart
statement. (And it doesn't apply to RXAGENTx servers because they don't
even talk to TCP/IP!)
> 06:01:09 AUTO LOGON *** RXAGENT1 USERS = 62 BY REXECD
> 06:01:09 USER DSC LOGOFF AS REXECD USERS = 61
> USER DSC LOGOFF AS REXECD USERS = 61
> 06:01:12 DTCIPI030W STARTANEWLIFE: VICTIM REXECD....
> CALLED FOR REASON: CLIENT HAS ENDED TCP/IP SERVICE
REXECD's and RXAGENT1's console logs should have some information on them.
REXECD is ending *itself*. Perhaps there is a problem with RXAGENT1's
use of RXSNDIU? Perhaps some authority problem?
But whatever you do, don't logon to REXECD or RXAGENT1, or use SET SECUSER
to figure out what's happening. If you try to look at their consoles in
real time, you interfere with their communications. Rome will burn and
civilization will end. (SET OBSERVER might be ok...dunno.)
Alan Altmark
Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
[email protected]
IBM Endicott
