Aye I suggested that approach to folks here as well. But still ...
--
bc

On Thu, Jan 13, 2011 at 12:01 PM, Bruce Hayden <bjhay...@gmail.com> wrote:

> FYI, here is my fix to wait until just about the clock rollover time,
> instead of just changing the constant to another value:
>
> /*------------------------------------------------------------------*
>  * NOTE: The 'delay' stage will end immediately if the end time of
>  * the delay causes the TOD clock to roll over.  Therefore, we
>  * delay only to that time, up to a max of +999999999.
>  * This code must be fixed before 2042 when the clock rolls over!
>  *------------------------------------------------------------------*/
> maxdelay=min((date('B','20420917','S') - date('B'))*24*60*60,999999999)
>   pip01 = ,
> '\ literal +'maxdelay,                 /* Never expiring timer        */
>
>
> On Thu, Jan 13, 2011 at 10:43 AM, Bob Cronin <bob.cro...@gmail.com> wrote:
> > FWIW ...  A plumber in Germany came up with this and it seems to have
> > bypassed the problem for us:
> >
> > It's not a pipeserv problem - it's a bug in pipeline's delay stage (TOD
> > overrun in 2042). As a bypass please change the line with literal +99999
> to
> > literal +59999
> >
> > I tried it on our z/VM 5.4 Test System and it works.
> >
> > Note:
> > The actual line in the  PIPESERV  REXX module is:
> >
> > '\ literal +999999999',                /* Never expiring timer        */
> >
> > This should be changed to:
> >
> > '\ literal +599999999',                /* Never expiring timer        */
> > --
> > bc
> >
> > On Thu, Jan 13, 2011 at 9:35 AM, Jeffrey Forte <jfo...@us.ibm.com>
> wrote:
> >
> >> We had a system running this code that is used for our software
> >> distribution within IBM.  We had a couple
> >> of 5.4 systems that were IPL'ed just last week.  The server came up with
> no
> >> problems.  After some emails were
> >> sent out about problem, I logged onto on of the server and IPL CMS.
>  Would
> >> not start at that point.  Worked fine on
> >> Monday and then it has been failing since Tuesday.  As far as I can
> tell,
> >> nothing has changed.
> >>
> >> Jeff Forte
> >> z/VM System Support
> >> jfo...@us.ibm.com
> >> 720-396-1716
> >>
> >> > Well, I am told that this pipeline has not been changed for years and
> it
> >> all
> >> > of a sudden stopped working the first time the virtual machine running
> it
> >> > was re-IPL'd this year (which just happened to be on 1/11 so I thought
> it
> >> > might be related as I have seen similar issues in other areas when
> >> "weird"
> >> > dates occur). Thoughts on where to start trying to debug it? I've
> >> literally
> >> > never seen PIPESERV until last night so am a bit out of my element.
> >> > --
> >> > bc
> >> >
> >> > On Thu, Jan 13, 2011 at 4:27 AM, Rob van der Heij <rvdh...@gmail.com>
> >> wrote:
> >>
> >> > > On Thu, Jan 13, 2011 at 10:18 AM, Shimon Lebowitz <
> shimon...@gmail.com
> >> >
> >> > > wrote:
> >> > > > And how exactly did my name get involved in this thread? :-)
> >> > > > Shimon
> >> > >
> >> > > Oh, my bad!  I confused you with Hobart.  We plumbers all look the
> >> > > same from behind :-)
> >> > >
> >> > > Sir Rob the Plumber
> >> > >
> >>
> >
>
>
>
> --
> Bruce Hayden
> z/VM and Linux on System z ATS
> IBM, Endicott, NY
>

Reply via email to