Couldn't the stack design be changed to provide some sort of 
communications (even SMSG) that tells the stack that "I'm busy... PLEASE 
Chuckie, don't force me"? 

If the start-up exit (or whatever) is coded to issue "I'm busy - maybe 
with a site-defined status indicator" at regular intervals, the problem is 
solved.   No need to even tell the stack "I'm all done now, start normal 
monitoring."

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.



"Alan Altmark" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" <[email protected]>
08/29/2007 04:59 PM
Please respond to
"The IBM z/VM Operating System" <[email protected]>



To
[email protected]
cc

Subject
Re: TCPIP restarting server too soon






On Wednesday, 08/29/2007 at 05:48 EDT, Aria Bamdad 
<[EMAIL PROTECTED]> wrote:
> This is a problem not just for what I need done but in general for
> any exit processing.  If an exit processing routine is provided and
> documented for use, then the stack needs to allow the server some
> known time window to do it's job.  As it is now, the time window changes
> each time.  It could be a few seconds, to tens of seconds.  I am not
> sure what it is dependent on but I know it is not consistent.
> 
> It would be helpful if the server could be aware of exit processing
> so that it can allow for the exit to finish properly.

I understand what you are saying.  The exit capability is provided so you 
can make custom configuration changes, not get tied up running some other 
program.  That stack has no idea whether the server is still coming up or 
has stalled.  If you don't want the stack to monitor the port, put 
NOAUTOLOG on the PORT statement for the server.  Then the server can take 
as long as it like to come up.  Of course, if it goes down, the stack 
won't restart it automatically.

Alan Altmark
z/VM Development
IBM Endicott



 
The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient 
is strictly prohibited.


Reply via email to