Alan Altmark replied > But if RSCS doesn't do that, it won't start promptly when they > power the printer on and you will get complaints. (I am vaguely > surprised that RSCS doesn't treat this as an auto-dial connection > and use the backoff retry facility. Maybe it's under the RESTART > GCS-style of control?)
Yes, we run a GCS exec that restarts links every 10 minutes, so that printers that have lost the automatic start attribute can be kicked into life. Stops users complaining ;-) It doesn't account for RSCS restarting this link every second, all night, though > But what is the problem with it looping all night? The 1,000,000s of lines of console traffic that is being generated. > Use automation (building your own or using a product such as IBM > Automated Operations for z/VM) to monitor the RSCS console and take > action based on what you deem important. You can even filter out > restart messages if you want. And you can avoid generating large > CP console logs that contain a lot of e-debris (tm). > Automation even lets you respond to the "reset" error such that > you can deactivate the link if, say, it's after 7pm and then restart > it at 7am (or whatever). Ok. In the absence of a neat and useful RSCS configuration parameter, yes I can set something up in VM:Operator. Thank you both Regards Ian Phone: +44 (0)7790 492056 -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: 28 October 2008 16:08 To: [email protected] Subject: Re: Connection reset by peer 'loop' On Tuesday, 10/28/2008 at 11:49 EDT, "Jones, Ian H" <[EMAIL PROTECTED]> wrote: > RSCS is restarting the link every second or so, until the users switch > their printer back on again. RSCS is probably trying to restart the > link because there is a file sitting on the queue, but I would prefer > it not to loop all night. I can't find a timeout value or retry > interval that looks relevant to this problem. But if RSCS doesn't do that, it won't start promptly when they power the printer on and you will get complaints. (I am vaguely surprised that RSCS doesn't treat this as an auto-dial connection and use the backoff retry facility. Maybe it's under the RESTART GCS-style of control?) But what is the problem with it looping all night? Use automation (building your own or using a product such as IBM Automated Operations for z/VM) to monitor the RSCS console and take action based on what you deem important. You can even filter out restart messages if you want. And you can avoid generating large CP console logs that contain a lot of e-debris (tm). Automation even lets you respond to the "reset" error such that you can deactivate the link if, say, it's after 7pm and then restart it at 7am (or whatever). Alan Altmark z/VM Development IBM Endicott
