The problem with SET SECUSER is that it changes to who messages are delivered: If you issue SET SECUSER REXECD MAINT messages sent to REXECD are directly delivered to MAINT. REXECD runs a program that intercept messages, but when they are delivered to MAINT.... When using SET OBSERVER such message rerouting isn't taking place, so it can be safely used
If you directly log on to REXECD there is no such problem. But, you might forget to issue #CP DISC and when your 3270 session to it is terminated, REXECD might get forced off later. Or, REXECD might get stuck in MORE or HOLDING and become unresponsive until the screen is cleared... 2011/7/20 Tom Duerbusch <duerbus...@stlouiscity.com> > 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 <alan_altm...@us.ibm.com> 7/20/2011 9:35 AM >>> > On Wednesday, 07/20/2011 at 10:18 EDT, Tom Duerbusch > <duerbus...@stlouiscity.com> 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 > alan_altm...@us.ibm.com > IBM Endicott > -- Kris Buelens, IBM Belgium, VM customer support
