From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15807 invoked from network); 7 Jan 2021 22:56:59 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 7 Jan 2021 22:56:59 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id B56A99C8AE; Fri, 8 Jan 2021 08:56:53 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 4FC729C87F; Fri, 8 Jan 2021 08:56:33 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id C13909C87F; Fri, 8 Jan 2021 08:56:30 +1000 (AEST) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by minnie.tuhs.org (Postfix) with ESMTPS id 5B75B9C87E for ; Fri, 8 Jan 2021 08:56:30 +1000 (AEST) Received: by mail-pf1-f177.google.com with SMTP id q20so1708508pfu.8 for ; Thu, 07 Jan 2021 14:56:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2GlMtwvxVBAPBsklwA2aXMFLkZlTUqfJ9yCMbv01lRU=; b=N9teG/Xq1F1cqgPWHHf9dYrzf7CcYAdwEYZ0pv6aDQad/Ctbo2aYizcePAW4NBNwAM 6V6ilBvwL9J6V1Jrt117FEcpqpxhaRx+x0Mx4xv0HuIeplQXXzpIxTS0KcUOKHQMSOis C2BnoD66zREPcuTaPiHXHeeVTfGBBQRuCN08ugXnOgrHjvN5eUSXWLufN+Hw6xcilJil iY3ig9y0+G5qLOHcWUit8vXD0f7INwO3UfvP27U40Wqy0MQXXC1j/i8F3MNA/feKqEr1 s1ZgGcSOd8GrGimwwp+QWAaxDiQUmWfyl41G548YKPbd+UhdaGxQrzaDt+b0/1rMpJt0 C2CA== X-Gm-Message-State: AOAM533p3Pmx8f71lxi4BtulhVUOV6bLtFkWGAIuh5mSOVGamus9hcU5 Q54Xvuudjw2N2i/jnZHKY2rIydlB1AhKyphJcfGmp7As X-Google-Smtp-Source: ABdhPJxwiirXmP4iIZuafC4whVUtOyyL8WB1msrWLnDK2vqEtHtopoIFZLKhOlricAnRUzTrHzvBAZQV8St1Ntg43Bc= X-Received: by 2002:a63:5f12:: with SMTP id t18mr4039704pgb.308.1610060189708; Thu, 07 Jan 2021 14:56:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stuart Remphrey Date: Fri, 8 Jan 2021 06:56:15 +0800 Message-ID: To: Dave Horsfall Content-Type: multipart/alternative; boundary="000000000000acb51905b85759c4" Subject: Re: [TUHS] The 2038 bug... X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000acb51905b85759c4 Content-Type: text/plain; charset="UTF-8" > Dave, who's kept his COBOL knowledge a secret in every job Indeed! Also FORTRAN/RATFOR and BASIC, in my case; but especially COBOL: apart from everything else, too much like writing a novel to get anything done. On Tue, 5 Jan 2021, 05:50 Dave Horsfall, wrote: > On Mon, 4 Jan 2021, Peter Jeremy wrote: > > > Alternatively, my understanding is that the Unix epoch changed on > > several occasions in the early days. Presumably the knowledge of how to > > achieve this hasn't been lost. (Though actually performing an epoch > > rollover may be more difficult today). > > My understanding is that it's been 1st Jan 1970 since at least Ed5, if not > Ed6. > > > I suspect that 2038 may actually wind up being more serious than Y2K > > because there are now far more embedded systems than there were then but > > it's not clear that the designers of those systems learnt the lesson > > from Y2K. A few weeks ago I tried to count the number of CPUs in my > > bedroom, bathroom and study - my best guess is around 2 dozen. > > Admittedly, I think relatively few of those will be concerned about > > epoch rollover. > > The only systems I have that would care would be the various computers, > and they are all NTP-synced (except the NBN modem/router takes its time > from T$). > > > Plus 2038 is merely one epoch. Someone mentioned the Microsoft epoch > > rolling over in 2048. Between those two, the IBM S/360 epoch rolls over > > in 2042 - the Z-series appears to have glued another 8 bits onto the MSB > > end of the TOD clock but that won't help all those S/360 and S/370 > > binaries that are still being run. And they are just the well- known > > ones. I expect that there are lots of embedded systems running custom > > epochs with weird rollover dates. > > Well, I don't care about the M$ epoch, and at 86 I might even get to see > the world come to a grinding halt :-) Of course, I may be reliant upon M$ > systems in hospitals etc... > > Interesting story about the S/360 though. As a side-issue I wonder how > many COBOL programmers will still be around to maintain all that payroll > software etc? > > -- Dave, who's kept his COBOL knowledge a secret in every job > --000000000000acb51905b85759c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Dave, who's kept his COBOL kno= wledge a secret in every job

Indeed! Also FORTRAN/RATFOR and BASIC, in my case; but especially= COBOL: apart from everything else, too much like writing a novel to get an= ything done.


On Tue, 5 Jan 2021, 05:50 Dav= e Horsfall, <dave@horsfall.org&= gt; wrote:
On Mon, 4 Jan 2021, Pete= r Jeremy wrote:

> Alternatively, my understanding is that the Unix epoch changed on
> several occasions in the early days.=C2=A0 Presumably the knowledge of= how to
> achieve this hasn't been lost.=C2=A0 (Though actually performing a= n epoch
> rollover may be more difficult today).

My understanding is that it's been 1st Jan 1970 since at least Ed5, if = not
Ed6.

> I suspect that 2038 may actually wind up being more serious than Y2K <= br> > because there are now far more embedded systems than there were then b= ut
> it's not clear that the designers of those systems learnt the less= on
> from Y2K.=C2=A0 A few weeks ago I tried to count the number of CPUs in= my
> bedroom, bathroom and study - my best guess is around 2 dozen.
> Admittedly, I think relatively few of those will be concerned about > epoch rollover.

The only systems I have that would care would be the various computers, and they are all NTP-synced (except the NBN modem/router takes its time from T$).

> Plus 2038 is merely one epoch.=C2=A0 Someone mentioned the Microsoft e= poch
> rolling over in 2048.=C2=A0 Between those two, the IBM S/360 epoch rol= ls over
> in 2042 - the Z-series appears to have glued another 8 bits onto the M= SB
> end of the TOD clock but that won't help all those S/360 and S/370=
> binaries that are still being run.=C2=A0 And they are just the well- k= nown
> ones.=C2=A0 I expect that there are lots of embedded systems running c= ustom
> epochs with weird rollover dates.

Well, I don't care about the M$ epoch, and at 86 I might even get to se= e
the world come to a grinding halt :-)=C2=A0 Of course, I may be reliant upo= n M$
systems in hospitals etc...

Interesting story about the S/360 though.=C2=A0 As a side-issue I wonder ho= w
many COBOL programmers will still be around to maintain all that payroll software etc?

-- Dave, who's kept his COBOL knowledge a secret in every job
--000000000000acb51905b85759c4--