INFO-VAX Tue, 18 Nov 2008 Volume 2008 : Issue 625 Contents: Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year Re: 150 year OVMS NetBeans IDE Error Re: OVMS NetBeans IDE Error Re: OVMS NetBeans IDE Error Re: SWB 1.1.10 -- New quirk? Re: SWB 1.1.10 -- New quirk? ---------------------------------------------------------------------- Date: Tue, 18 Nov 2008 01:40:07 -0800 (PST) From: Jerry Eckert Subject: Re: 150 year Message-ID: On Nov 17, 1:48=A0pm, AEF wrote: > On Nov 17, 11:40=A0am, "Richard B. Gilbert" > wrote: > > > > > AEF wrote: > > > On Nov 17, 3:13 am, "The Mip" wrote: > > >> $set ver > > >> $ crea foobar.foo > > >> $ wr f$file("foobar.foo","bdt") > > >> 17-NOV-1858 00:00:00.00 > > >> $ wr f$time() > > >> 17-NOV-2008 07:53:57.56 > > > >> 150 years since i backed up =A0that file :) > > > >> - the_mip > > > >> Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard/w= iz_2315.html > > > > So that's fine, but why did VMS adopt this (the Modified Julian Day)? > > > It doesn't say. It doesn't answer the question. > > > > AEF > > > There is an explanation of sorts; something to do with obsoleting star > > charts or something like that. =A0There is a detailed explanation at: > > >http://h71000.www7.hp.com/wizard/wiz_2315.html > > > As the representation used by VMS will not overflow for more than 3,000 > > years (it may be 30,000 (I don't recall)) there is no urgent reason to > > fix the problem! > > > If anybody still cares 3,000 or 30,000 years from now, they can adopt > > whatever solution(s) meet their needs. > > That's the same one that doesn't say why the MJD was adopted by > VMS. . . . The mystery remains. > > AEF Actually, it does explain why: "The 1858 date preceded the oldest star catalogue in use at SAO, which also avoided having to use negative time in any of the satellite tracking calculations." ------------------------------ Date: Tue, 18 Nov 2008 04:59:20 -0800 (PST) From: AEF Subject: Re: 150 year Message-ID: On Nov 18, 5:40=A0am, Jerry Eckert wrote: > On Nov 17, 1:48=A0pm, AEF wrote: > > > > > On Nov 17, 11:40=A0am, "Richard B. Gilbert" > > wrote: > > > > AEF wrote: > > > > On Nov 17, 3:13 am, "The Mip" wrote: > > > >> $set ver > > > >> $ crea foobar.foo > > > >> $ wr f$file("foobar.foo","bdt") > > > >> 17-NOV-1858 00:00:00.00 > > > >> $ wr f$time() > > > >> 17-NOV-2008 07:53:57.56 > > > > >> 150 years since i backed up =A0that file :) > > > > >> - the_mip > > > > >> Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard= /wiz_2315.html > > > > > So that's fine, but why did VMS adopt this (the Modified Julian Day= )? > > > > It doesn't say. It doesn't answer the question. > > > > > AEF > > > > There is an explanation of sorts; something to do with obsoleting sta= r > > > charts or something like that. =A0There is a detailed explanation at: > > > >http://h71000.www7.hp.com/wizard/wiz_2315.html > > > > As the representation used by VMS will not overflow for more than 3,0= 00 > > > years (it may be 30,000 (I don't recall)) there is no urgent reason t= o > > > fix the problem! > > > > If anybody still cares 3,000 or 30,000 years from now, they can adopt > > > whatever solution(s) meet their needs. > > > That's the same one that doesn't say why the MJD was adopted by > > VMS. . . . The mystery remains. > > > AEF > > Actually, it does explain why: > > "The 1858 date preceded the oldest star catalogue in use at SAO, > which also avoided having to use negative time in any of the > satellite tracking calculations." That explains why it was chosen for the satellites. There are alternatives that could have been chosen; e.g., 1 Jan 1800. These are VMS systems, not satellites. If you don't know the answer, admit it or say nothing. Thanks. AEF ------------------------------ Date: Tue, 18 Nov 2008 05:00:14 -0800 (PST) From: AEF Subject: Re: 150 year Message-ID: <265e11fb-4c51-461e-a3a7-7dbc47321c4b@z28g2000prd.googlegroups.com> On Nov 17, 9:31=A0pm, Jeff Campbell wrote: > AEF wrote: > > On Nov 17, 11:40 am, "Richard B. Gilbert" > > wrote: > >> AEF wrote: > >>> On Nov 17, 3:13 am, "The Mip" wrote: > >>>> $set ver > >>>> $ crea foobar.foo > >>>> $ wr f$file("foobar.foo","bdt") > >>>> 17-NOV-1858 00:00:00.00 > >>>> $ wr f$time() > >>>> 17-NOV-2008 07:53:57.56 > >>>> 150 years since i backed up =A0that file :) > >>>> - the_mip > >>>> Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard/w= iz_2315.html > >>> So that's fine, but why did VMS adopt this (the Modified Julian Day)? > >>> It doesn't say. It doesn't answer the question. > >>> AEF > >> There is an explanation of sorts; something to do with obsoleting star > >> charts or something like that. =A0There is a detailed explanation at: > > >>http://h71000.www7.hp.com/wizard/wiz_2315.html > > >> As the representation used by VMS will not overflow for more than 3,00= 0 > >> years (it may be 30,000 (I don't recall)) there is no urgent reason to > >> fix the problem! > > >> If anybody still cares 3,000 or 30,000 years from now, they can adopt > >> whatever solution(s) meet their needs. > > > That's the same one that doesn't say why the MJD was adopted by > > VMS. . . . The mystery remains. > > > AEF > > It's Julian day 2,400,000. > > ----=3D=3D Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet = News=3D=3D----http://www.pronews.comThe #1 Newsgroup Service in the World! = >100,000 Newsgroups > ---=3D - Total Privacy via Encryption =3D--- So shy did they pick Julian day 2,400,000? AEF ------------------------------ Date: Tue, 18 Nov 2008 05:15:35 -0800 From: "Tom Linden" Subject: Re: 150 year Message-ID: On Mon, 17 Nov 2008 12:41:13 -0800, Bob Eager wrote: > On Mon, 17 Nov 2008 16:23:29 UTC, "Tom Linden" > wrote: > >> Here is an interesting addendum, see the comments >> on the determination of Easter. >> http://www.kednos.com/calendar.html > > That was interesting! Not having PL/I, I quickly turned it into REXX and > it seems to work fine....! > Does REXX run on VMS? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 18 Nov 2008 05:27:49 -0800 (PST) From: AEF Subject: Re: 150 year Message-ID: <4284dc64-e17d-4c3f-814e-ea6f7f8f21da@k1g2000prb.googlegroups.com> On Nov 18, 5:40=A0am, Jerry Eckert wrote: > On Nov 17, 1:48=A0pm, AEF wrote: > > > > > On Nov 17, 11:40=A0am, "Richard B. Gilbert" > > wrote: > > > > AEF wrote: > > > > On Nov 17, 3:13 am, "The Mip" wrote: > > > >> $set ver > > > >> $ crea foobar.foo > > > >> $ wr f$file("foobar.foo","bdt") > > > >> 17-NOV-1858 00:00:00.00 > > > >> $ wr f$time() > > > >> 17-NOV-2008 07:53:57.56 > > > > >> 150 years since i backed up =A0that file :) > > > > >> - the_mip > > > > >> Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard= /wiz_2315.html > > > > > So that's fine, but why did VMS adopt this (the Modified Julian Day= )? > > > > It doesn't say. It doesn't answer the question. > > > > > AEF > > > > There is an explanation of sorts; something to do with obsoleting sta= r > > > charts or something like that. =A0There is a detailed explanation at: > > > >http://h71000.www7.hp.com/wizard/wiz_2315.html > > > > As the representation used by VMS will not overflow for more than 3,0= 00 > > > years (it may be 30,000 (I don't recall)) there is no urgent reason t= o > > > fix the problem! > > > > If anybody still cares 3,000 or 30,000 years from now, they can adopt > > > whatever solution(s) meet their needs. > > > That's the same one that doesn't say why the MJD was adopted by > > VMS. . . . The mystery remains. > > > AEF > > Actually, it does explain why: > > "The 1858 date preceded the oldest star catalogue in use at SAO, > which also avoided having to use negative time in any of the > satellite tracking calculations." To be even more explicit: Just what in tarnation does the oldest star catalog have to do with VMS? AEF ------------------------------ Date: Tue, 18 Nov 2008 09:16:10 -0500 From: JF Mezei Subject: Re: 150 year Message-ID: <000eab26$0$12302$c3e8da3@news.astraweb.com> AEF wrote: > To be even more explicit: Just what in tarnation does the oldest star > catalog have to do with VMS? Speculating that perhaps some customers of Digital at the time were astronomers and DEC wanted VMS to cater to them ? Speculation that one of the VMS enginers was a hobbyist astronomer and suggested that date ? ------------------------------ Date: Tue, 18 Nov 2008 09:42:53 -0500 From: "Richard B. Gilbert" Subject: Re: 150 year Message-ID: AEF wrote: > On Nov 17, 9:31 pm, Jeff Campbell wrote: >> AEF wrote: >>> On Nov 17, 11:40 am, "Richard B. Gilbert" >>> wrote: >>>> AEF wrote: >>>>> On Nov 17, 3:13 am, "The Mip" wrote: >>>>>> $set ver >>>>>> $ crea foobar.foo >>>>>> $ wr f$file("foobar.foo","bdt") >>>>>> 17-NOV-1858 00:00:00.00 >>>>>> $ wr f$time() >>>>>> 17-NOV-2008 07:53:57.56 >>>>>> 150 years since i backed up that file :) >>>>>> - the_mip >>>>>> Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard/wiz_2315.html >>>>> So that's fine, but why did VMS adopt this (the Modified Julian Day)? >>>>> It doesn't say. It doesn't answer the question. >>>>> AEF >>>> There is an explanation of sorts; something to do with obsoleting star >>>> charts or something like that. There is a detailed explanation at: >>>> http://h71000.www7.hp.com/wizard/wiz_2315.html >>>> As the representation used by VMS will not overflow for more than 3,000 >>>> years (it may be 30,000 (I don't recall)) there is no urgent reason to >>>> fix the problem! >>>> If anybody still cares 3,000 or 30,000 years from now, they can adopt >>>> whatever solution(s) meet their needs. >>> That's the same one that doesn't say why the MJD was adopted by >>> VMS. . . . The mystery remains. >>> AEF >> It's Julian day 2,400,000. >> >> ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==----http://www.pronews.comThe #1 Newsgroup Service in the World! >100,000 Newsgroups >> ---= - Total Privacy via Encryption =--- > > So shy did they pick Julian day 2,400,000? > > AEF It was an arbitrary decision and its only purpose was to annoy you! -- draco vulgaris ------------------------------ Date: 18 Nov 2008 14:41:25 GMT From: "Bob Eager" Subject: Re: 150 year Message-ID: <176uZD2KcidF-pn2-Swll892j9jEz@rikki.tavi.co.uk> On Tue, 18 Nov 2008 13:15:35 UTC, "Tom Linden" wrote: > On Mon, 17 Nov 2008 12:41:13 -0800, Bob Eager wrote: > > > On Mon, 17 Nov 2008 16:23:29 UTC, "Tom Linden" > > wrote: > > > >> Here is an interesting addendum, see the comments > >> on the determination of Easter. > >> http://www.kednos.com/calendar.html > > > > That was interesting! Not having PL/I, I quickly turned it into REXX and > > it seems to work fine....! > > > Does REXX run on VMS? I assumed it did, but I admit I didn't do it on one of my VAXes! There's a portable implementation... -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: 18 Nov 2008 08:45:41 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 150 year Message-ID: In article , AEF writes: > > That's the same one that doesn't say why the MJD was adopted by > VMS. . . . The mystery remains. MJD in this case being no more well defined than "arbitrary base date for absolute time". So how do you define a time system without one? VMS Engineering used the Smithsonian calendar base date, instead of the CEO's birthday, or the previous decade, or some other base date that would be more random or less usefull. ------------------------------ Date: 18 Nov 2008 08:46:36 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 150 year Message-ID: In article , AEF writes: > > So you're saying they picked MJD because its day 0 pre-dates the first > release of VMS? So does Jan 1, 1900. No, they looked to a more apropriate authority: the Smithsonian Institution. ------------------------------ Date: 18 Nov 2008 08:48:56 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 150 year Message-ID: In article <000db06b$0$12274$c3e8da3@news.astraweb.com>, JF Mezei writes: > > The Unix system time is just seconds in a 32 bit integer and it > simplifies arithmetic being done. But provides a clock usefull over only 68 years. Don't try to use it to support a business that plans to be in business for over 100 years. ------------------------------ Date: 18 Nov 2008 14:50:54 GMT From: "Bob Eager" Subject: Re: 150 year Message-ID: <176uZD2KcidF-pn2-0tOoJZON8BWt@rikki.tavi.co.uk> On Tue, 18 Nov 2008 13:15:35 UTC, "Tom Linden" wrote: > On Mon, 17 Nov 2008 12:41:13 -0800, Bob Eager wrote: > > > On Mon, 17 Nov 2008 16:23:29 UTC, "Tom Linden" > > wrote: > > > >> Here is an interesting addendum, see the comments > >> on the determination of Easter. > >> http://www.kednos.com/calendar.html > > > > That was interesting! Not having PL/I, I quickly turned it into REXX and > > it seems to work fine....! > > > Does REXX run on VMS? Here you are... http://sourceforge.net/project/showfiles.php?group_id=28102 -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: Tue, 18 Nov 2008 09:54:57 -0500 From: "Richard B. Gilbert" Subject: Re: 150 year Message-ID: <6r6dnX1etYx-S7_UnZ2dnUVZ_gCdnZ2d@giganews.com> AEF wrote: > On Nov 18, 5:40 am, Jerry Eckert wrote: >> On Nov 17, 1:48 pm, AEF wrote: >> >> >> >>> On Nov 17, 11:40 am, "Richard B. Gilbert" >>> wrote: >>>> AEF wrote: >>>>> On Nov 17, 3:13 am, "The Mip" wrote: >>>>>> $set ver >>>>>> $ crea foobar.foo >>>>>> $ wr f$file("foobar.foo","bdt") >>>>>> 17-NOV-1858 00:00:00.00 >>>>>> $ wr f$time() >>>>>> 17-NOV-2008 07:53:57.56 >>>>>> 150 years since i backed up that file :) >>>>>> - the_mip >>>>>> Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard/wiz_2315.html >>>>> So that's fine, but why did VMS adopt this (the Modified Julian Day)? >>>>> It doesn't say. It doesn't answer the question. >>>>> AEF >>>> There is an explanation of sorts; something to do with obsoleting star >>>> charts or something like that. There is a detailed explanation at: >>>> http://h71000.www7.hp.com/wizard/wiz_2315.html >>>> As the representation used by VMS will not overflow for more than 3,000 >>>> years (it may be 30,000 (I don't recall)) there is no urgent reason to >>>> fix the problem! >>>> If anybody still cares 3,000 or 30,000 years from now, they can adopt >>>> whatever solution(s) meet their needs. >>> That's the same one that doesn't say why the MJD was adopted by >>> VMS. . . . The mystery remains. >>> AEF >> Actually, it does explain why: >> >> "The 1858 date preceded the oldest star catalogue in use at SAO, >> which also avoided having to use negative time in any of the >> satellite tracking calculations." > > To be even more explicit: Just what in tarnation does the oldest star > catalog have to do with VMS? > > AEF For God's sake give it a rest! Thirty or more years ago, someone had to pick a date for the "beginning of time". Whoever it was chose the Smithsonian base date. I've been working with VMS for about 24 years now and you are the first person who seems to have a problem with the Smithsonian base date as "the beginning of time". What, exactly, is your objection? That YOU were not allowed to choose it? Your alternative is Unix where 1 January 1970 is "the beginning of time". That works too. Well, sort of!!! ------------------------------ Date: 18 Nov 2008 08:54:24 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 150 year Message-ID: <7T6BTl4GBDsL@eisner.encompasserve.org> In article <49222845$0$90265$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: > > The transformation between true time and calendar could have been > made locale specific. > > Or it could have been if it were implemented today. I don't think > that way of doing things were common in 1978. That way of doing things was common in the late 1960s when primitive two-mode timesharing operating systems were first written at places like DEC and Bell Labs. It's one of the few good ideas DEC knew before they wrote VMS and didn't put in. Or maybe they were just afraid of putting in an unecessary error. The TOPS-20 Fortran RTL couldn't handle midnight between December 31 and January 1 for us one year because we were running our system on GMT and the library did a divide by zero. ------------------------------ Date: Tue, 18 Nov 2008 09:56:48 -0500 From: "Richard B. Gilbert" Subject: Re: 150 year Message-ID: <6r6dnXxetYzPSr_UnZ2dnUVZ_gCdnZ2d@giganews.com> JF Mezei wrote: > AEF wrote: > >> To be even more explicit: Just what in tarnation does the oldest star >> catalog have to do with VMS? > > Speculating that perhaps some customers of Digital at the time were > astronomers and DEC wanted VMS to cater to them ? > > Speculation that one of the VMS enginers was a hobbyist astronomer and > suggested that date ? Folks, I think we are getting close to an answer. It was JF's birth date! ;-) ------------------------------ Date: Tue, 18 Nov 2008 07:01:00 -0800 From: "Tom Linden" Subject: Re: 150 year Message-ID: On Tue, 18 Nov 2008 06:41:25 -0800, Bob Eager wrote: > On Tue, 18 Nov 2008 13:15:35 UTC, "Tom Linden" > wrote: > >> On Mon, 17 Nov 2008 12:41:13 -0800, Bob Eager wrote: >> >> > On Mon, 17 Nov 2008 16:23:29 UTC, "Tom Linden" >> > wrote: >> > >> >> Here is an interesting addendum, see the comments >> >> on the determination of Easter. >> >> http://www.kednos.com/calendar.html >> > >> > That was interesting! Not having PL/I, I quickly turned it into REXX >> and >> > it seems to work fine....! >> > >> Does REXX run on VMS? > > I assumed it did, but I admit I didn't do it on one of my VAXes! There's > a portable implementation... > So what did you run it on? BTW, why not post the REXX code so others don't have to reinvent the wheel? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 18 Nov 2008 10:03:17 -0500 From: "Richard B. Gilbert" Subject: Re: 150 year Message-ID: <6r6dnX5etYxKRb_UnZ2dnUVZ_gCdnZ2d@giganews.com> Bob Koehler wrote: > In article <000db06b$0$12274$c3e8da3@news.astraweb.com>, JF Mezei writes: >> The Unix system time is just seconds in a 32 bit integer and it >> simplifies arithmetic being done. > > But provides a clock usefull over only 68 years. Don't try to use it > to support a business that plans to be in business for over 100 > years. > I've heard rumors that most Unices either plan to adopt, or have adopted, a 64 bit time. ------------------------------ Date: Tue, 18 Nov 2008 07:20:42 -0800 (PST) From: MetaEd Subject: Re: 150 year Message-ID: On Nov 18, 8:16=A0am, JF Mezei wrote: > AEF wrote: > > To be even more explicit: Just what in tarnation does the oldest star > > catalog have to do with VMS? > > Speculating that perhaps some customers of Digital at the time were > astronomers and DEC wanted VMS to cater to them ? > > Speculation that one of the VMS enginers was a hobbyist astronomer and > suggested that date ? Compatibility with TOPS-20. ------------------------------ Date: Tue, 18 Nov 2008 07:43:26 -0800 (PST) From: AEF Subject: Re: 150 year Message-ID: <524c031d-2567-45e5-a9ac-3bccf01e585a@s9g2000prg.googlegroups.com> On Nov 18, 10:42=A0am, "Richard B. Gilbert" wrote: > AEF wrote: > > On Nov 17, 9:31 pm, Jeff Campbell wrote: > >> AEF wrote: > >>> On Nov 17, 11:40 am, "Richard B. Gilbert" > >>> wrote: > >>>> AEF wrote: > >>>>> On Nov 17, 3:13 am, "The Mip" wrote: > >>>>>> $set ver > >>>>>> $ crea foobar.foo > >>>>>> $ wr f$file("foobar.foo","bdt") > >>>>>> 17-NOV-1858 00:00:00.00 > >>>>>> $ wr f$time() > >>>>>> 17-NOV-2008 07:53:57.56 > >>>>>> 150 years since i backed up =A0that file :) > >>>>>> - the_mip > >>>>>> Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard= /wiz_2315.html > >>>>> So that's fine, but why did VMS adopt this (the Modified Julian Day= )? > >>>>> It doesn't say. It doesn't answer the question. > >>>>> AEF > >>>> There is an explanation of sorts; something to do with obsoleting st= ar > >>>> charts or something like that. =A0There is a detailed explanation at= : > >>>>http://h71000.www7.hp.com/wizard/wiz_2315.html > >>>> As the representation used by VMS will not overflow for more than 3,= 000 > >>>> years (it may be 30,000 (I don't recall)) there is no urgent reason = to > >>>> fix the problem! > >>>> If anybody still cares 3,000 or 30,000 years from now, they can adop= t > >>>> whatever solution(s) meet their needs. > >>> That's the same one that doesn't say why the MJD was adopted by > >>> VMS. . . . The mystery remains. > >>> AEF > >> It's Julian day 2,400,000. > > >> ----=3D=3D Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usen= et News=3D=3D----http://www.pronews.comThe#1 Newsgroup Service in the World= ! >100,000 Newsgroups > >> ---=3D - Total Privacy via Encryption =3D--- > > > So shy did they pick Julian day 2,400,000? > > > AEF > > It was an arbitrary decision and its only purpose was to annoy you! > > -- > draco vulgaris Finally an answer. Thanks! AEF ------------------------------ Date: Tue, 18 Nov 2008 07:44:06 -0800 (PST) From: AEF Subject: Re: 150 year Message-ID: On Nov 18, 10:45=A0am, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article , AEF writes: > > > > > That's the same one that doesn't say why the MJD was adopted by > > VMS. . . . The mystery remains. > > =A0 =A0MJD in this case being no more well defined than "arbitrary base > =A0 =A0date for absolute time". =A0So how do you define a time system wit= hout > =A0 =A0one? > > =A0 =A0VMS Engineering used the Smithsonian calendar base date, instead o= f > =A0 =A0the CEO's birthday, or the previous decade, or some other base dat= e > =A0 =A0that would be more random or less usefull. But it's not the only possibility. They could have picked the Julian Date. AEF ------------------------------ Date: Tue, 18 Nov 2008 09:00:22 -0700 From: "Terry Aardema" Subject: Re: 150 year Message-ID: On Tue, 18 Nov 2008 05:59:20 -0700, AEF wrote: > That explains why it was chosen for the satellites. There are > alternatives that could have been chosen; e.g., 1 Jan 1800. > These are VMS systems, not satellites. If you don't know the answer, > admit it or say nothing. Thanks. > AEF Does nobody remember that Google exists? http://h71000.www7.hp.com/wizard/wiz_2315.html is the first hit returned for a Google search for +VMS +"base date" ... Terry -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Tue, 18 Nov 2008 18:05:45 +0200 From: Mike Rechtman Subject: Re: 150 year Message-ID: JF Mezei wrote: > Richard B. Gilbert wrote: > >> It doesn't really make any difference that I can see! If you say "SHOW >> TIME" it gives you the date and time as "17-NOV-2008 16:02:21" which I >> find entirely adequate. > > > > > The Unix system time is just seconds in a 32 bit integer and it > simplifies arithmetic being done. > Isn't there a problem in 2038? -- Mike R. http://alpha.mike-r.com/ -- ------------------------------ Date: Tue, 18 Nov 2008 11:17:25 -0500 From: "Richard B. Gilbert" Subject: Re: 150 year Message-ID: <57ydnViXJc-qd7_UnZ2dnUVZ_gednZ2d@giganews.com> Mike Rechtman wrote: > JF Mezei wrote: >> Richard B. Gilbert wrote: >> >>> It doesn't really make any difference that I can see! If you say >>> "SHOW TIME" it gives you the date and time as "17-NOV-2008 16:02:21" >>> which I find entirely adequate. >> >> >> >> >> The Unix system time is just seconds in a 32 bit integer and it >> simplifies arithmetic being done. >> > > Isn't there a problem in 2038? > > -- > Mike R. > http://alpha.mike-r.com/ > > -- Yes, there is. The end of Unix! And good riddance! Actually, Unix will be moving to 64 bits for timekeeping. This will delay the "end of time" for about 30,000 years. This fact will be rediscovered 29,998 years from now and there will be a "Year 30K" problem. We should consider ourselves fortunate that we will not have to cope with it. ------------------------------ Date: Tue, 18 Nov 2008 18:25:26 +0200 From: Mike Rechtman Subject: Re: 150 year Message-ID: Richard B. Gilbert wrote: > Michael Moroney wrote: >> JF Mezei writes: >> >>> AEF wrote: >> >>>> That's the same one that doesn't say why the MJD was adopted by >>>> VMS. . . . The mystery remains. >> >>> When it isn't clearly stated in the documentation, it means that this >>> date was decided at a bar where VMS engineers, after a few beers, did >>> some brainstorming on what sort of "base" dates they should be using, >>> and the one that had absorbed the most beer came up with that one, they >>> laughed and laughed, drank and drank, pissed and pissed, and at the end >>> of the night, couldn't come up with a better one so they decided to use >>> that one. >> >> Hah! Probably not far from the truth! >> >> If it was up to me (and I remained sober enough) I would have chosen the >> start of the Gregorian calendar. I'm not sure _which_ start, either the >> overall start in 1582 (no dates before then were in the Gregorian >> calendar) >> or perhaps the start of the use of the Gregorian calendar in Britain and >> her colonies (1752). That date may be good since many dates before then >> were on the Julian calendar and would be rendered inaccurately by VMS >> if the 1582 date were chosen. >>> The next morning, they had no clue on WHY they had chosen that one. They >>> just vaguely remembered that they had decided on that one. >> >>> This is why, my friends, we don't know why they chose 17-NOV-1858 as the >>> base date for VMS. > > In my entire VMS career, I never needed to represent a date/time that > VMS could not accommodate! In fact, I don't think I ever needed to > represent a date prior to 1984 which was the year I was VAXinated. OTOH on RSTS writing financial applications we had to manage dates up to 100 years in the future for long-range planning, loans etc. IIRC the native RSTS dates only went up to 2002 (1970 + 32767/1000) -- Mike R. http://alpha.mike-r.com/ -- ------------------------------ Date: Tue, 18 Nov 2008 16:37:44 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: 150 year Message-ID: "Martin Vorlaender" writes: >Michael Moroney wrote: >> If it was up to me (and I remained sober enough) I would have chosen the >> start of the Gregorian calendar. I'm not sure _which_ start, either the >> overall start in 1582 (no dates before then were in the Gregorian calendar) >> or perhaps the start of the use of the Gregorian calendar in Britain and >> her colonies (1752). >But it wasn't adopted in Russia until after the october revolution (1922) - >which is why the celebrations for it later took place in september. >And Greece, Turkey and China were even later (1923, 1926, and 1929, >respectively). See http://en.wikipedia.org/wiki/Gregorian_Calendar#Timeline >What a mess... Yes it was a mess. However I picked those times because the countries that switched after Great Britain did were mostly relatively minor players while still on the Julian calendar. The biggest were the Ottoman Empire and Russia during WW1. (and when VMS was created, Russia was run by the commies and we weren't supposed to help them! :-) ) However Britain generated plenty of history before 1752 and VMS running a Gregorian calendar for such dates would create hidden errors. 1582 would allow some places to use all possible (Gregorian) dates on VMS. ------------------------------ Date: Tue, 18 Nov 2008 16:38:09 +0000 From: "R.A.Omond" Subject: Re: 150 year Message-ID: <4922ef72$0$90274$14726298@news.sunsite.dk> Richard B. Gilbert wrote: > [...snip...] > > Yes, there is. The end of Unix! And good riddance! > > Actually, Unix will be moving to 64 bits for timekeeping. This will > delay the "end of time" for about 30,000 years. This fact will be > rediscovered 29,998 years from now and there will be a "Year 30K" > problem. We should consider ourselves fortunate that we will not have > to cope with it. Talk for yourself ... I have no intention of dying. I aim to live forever, else I'm gonna die trying ;-) ------------------------------ Date: Tue, 18 Nov 2008 18:39:33 +0200 From: Mike Rechtman Subject: Re: 150 year Message-ID: Richard B. Gilbert wrote: > Mike Rechtman wrote: >> JF Mezei wrote: >>> Richard B. Gilbert wrote: >>> >>>> It doesn't really make any difference that I can see! If you say >>>> "SHOW TIME" it gives you the date and time as "17-NOV-2008 16:02:21" >>>> which I find entirely adequate. >>> >>> >>> >>> >>> The Unix system time is just seconds in a 32 bit integer and it >>> simplifies arithmetic being done. >>> >> >> Isn't there a problem in 2038? >> >> -- >> Mike R. >> http://alpha.mike-r.com/ >> >> -- > > Yes, there is. The end of Unix! And good riddance! > > Actually, Unix will be moving to 64 bits for timekeeping. This will > delay the "end of time" for about 30,000 years. This fact will be > rediscovered 29,998 years from now and there will be a "Year 30K" > problem. We should consider ourselves fortunate that we will not have > to cope with it. > Why not? Are you planning on early retirement? :) -- -- Mike R. http://alpha.mike-r.com/ -- ------------------------------ Date: Tue, 18 Nov 2008 08:41:17 -0800 (PST) From: AEF Subject: Re: 150 year Message-ID: <7a7d73be-7303-4ebf-a340-8ffc179a4083@g17g2000prg.googlegroups.com> On Nov 18, 10:54=A0am, "Richard B. Gilbert" wrote: > AEF wrote: > > On Nov 18, 5:40 am, Jerry Eckert wrote: > >> On Nov 17, 1:48 pm, AEF wrote: > > >>> On Nov 17, 11:40 am, "Richard B. Gilbert" > >>> wrote: > >>>> AEF wrote: > >>>>> On Nov 17, 3:13 am, "The Mip" wrote: > >>>>>> $set ver > >>>>>> $ crea foobar.foo > >>>>>> $ wr f$file("foobar.foo","bdt") > >>>>>> 17-NOV-1858 00:00:00.00 > >>>>>> $ wr f$time() > >>>>>> 17-NOV-2008 07:53:57.56 > >>>>>> 150 years since i backed up =A0that file :) > >>>>>> - the_mip > >>>>>> Lets celebrate with a good old 1 :http://h71000.www7.hp.com/wizard= /wiz_2315.html > >>>>> So that's fine, but why did VMS adopt this (the Modified Julian Day= )? > >>>>> It doesn't say. It doesn't answer the question. > >>>>> AEF > >>>> There is an explanation of sorts; something to do with obsoleting st= ar > >>>> charts or something like that. =A0There is a detailed explanation at= : > >>>>http://h71000.www7.hp.com/wizard/wiz_2315.html > >>>> As the representation used by VMS will not overflow for more than 3,= 000 > >>>> years (it may be 30,000 (I don't recall)) there is no urgent reason = to > >>>> fix the problem! > >>>> If anybody still cares 3,000 or 30,000 years from now, they can adop= t > >>>> whatever solution(s) meet their needs. > >>> That's the same one that doesn't say why the MJD was adopted by > >>> VMS. . . . The mystery remains. > >>> AEF > >> Actually, it does explain why: > > >> "The 1858 date preceded the oldest star catalogue in use at SAO, > >> which also avoided having to use negative time in any of the > >> satellite tracking calculations." > > > To be even more explicit: Just what in tarnation does the oldest star > > catalog have to do with VMS? > > > AEF > > For God's sake give it a rest! =A0Thirty or more years ago, someone had t= o > pick a date for the "beginning of time". =A0Whoever it was chose the > Smithsonian base date. OK. > > I've been working with VMS for about 24 years now and you are the first > person who seems to have a problem with the Smithsonian base date as > "the beginning of time". I don't have a problem with it. I'm just curious what the motivation was. Example: What was the motivation for building cars? Answer: To be able to get around without leaving s*** all over the streets. What was the motivation for inventing calculus? For Newton is was to be able to do more advanced physics calculations. What is the motivation for eating? Too relieve one from the discomfort of hunger. OK, maybe it *was* an arbitrary decision. But if it wasn't, I'd just like to know what the motivation was. I have no problem with it. AEF > > What, exactly, is your objection? =A0That YOU were not allowed to choose = it? > > Your alternative is Unix where 1 January 1970 is "the beginning of > time". =A0That works too. =A0Well, sort of!!! ------------------------------ Date: Tue, 18 Nov 2008 16:47:36 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: 150 year Message-ID: "Richard B. Gilbert" writes: >In my entire VMS career, I never needed to represent a date/time that >VMS could not accommodate! In fact, I don't think I ever needed to >represent a date prior to 1984 which was the year I was VAXinated. I did at one time. I was trying to figure out when my billion-second "birthday" was (when I would be 1 billion seconds old) - and VMS failed me! That's because I wanted to add a delta time equal to 1 billion seconds to my birthdate but DCL cannot handle delta times greater than 9999 23:59:59. ------------------------------ Date: Tue, 18 Nov 2008 11:52:02 -0500 From: "Richard B. Gilbert" Subject: Re: 150 year Message-ID: <5-adnT086rbJb7_UnZ2dnUVZ_r3inZ2d@giganews.com> R.A.Omond wrote: > Richard B. Gilbert wrote: >> [...snip...] >> >> Yes, there is. The end of Unix! And good riddance! >> >> Actually, Unix will be moving to 64 bits for timekeeping. This will >> delay the "end of time" for about 30,000 years. This fact will be >> rediscovered 29,998 years from now and there will be a "Year 30K" >> problem. We should consider ourselves fortunate that we will not have >> to cope with it. > > Talk for yourself ... I have no intention of dying. > > I aim to live forever, else I'm gonna die trying ;-) I think it was Bill Cosby who said: "Some people seek immortality through their children, others seek it through their work. I plan to seek immortality by not dying!" Actually, I'm inclined to doubt that immortality is that good a deal. Did you ever notice an article in your newspaper about the "World's oldest man/woman"? There is invariably a photograph of the oldest man/woman. The photo invariably shows an attendant holding the oldest by one arm. These photos all leave me wondering if he/she can stand and walk unassisted, feed him/herself, and whether he still recognizes his relatives and friends, etc. A few, rare, individuals make it to 120 but I'm not certain that it's worth doing! ------------------------------ Date: Tue, 18 Nov 2008 11:56:13 -0500 From: "Richard B. Gilbert" Subject: Re: 150 year Message-ID: <5-adnTw86rbSbr_UnZ2dnUVZ_r3inZ2d@giganews.com> Mike Rechtman wrote: > Richard B. Gilbert wrote: >> Mike Rechtman wrote: >>> JF Mezei wrote: >>>> Richard B. Gilbert wrote: >>>> >>>>> It doesn't really make any difference that I can see! If you say >>>>> "SHOW TIME" it gives you the date and time as "17-NOV-2008 >>>>> 16:02:21" which I find entirely adequate. >>>> >>>> >>>> >>>> >>>> The Unix system time is just seconds in a 32 bit integer and it >>>> simplifies arithmetic being done. >>>> >>> >>> Isn't there a problem in 2038? >>> >>> -- >>> Mike R. >>> http://alpha.mike-r.com/ >>> >>> -- >> >> Yes, there is. The end of Unix! And good riddance! >> >> Actually, Unix will be moving to 64 bits for timekeeping. This will >> delay the "end of time" for about 30,000 years. This fact will be >> rediscovered 29,998 years from now and there will be a "Year 30K" >> problem. We should consider ourselves fortunate that we will not have >> to cope with it. >> > Why not? Are you planning on early retirement? :) > I'm already retired! I'd go back to work if anybody was hiring VMS System Managers any longer!! ------------------------------ Date: Tue, 18 Nov 2008 12:05:19 -0500 From: "Richard B. Gilbert" Subject: Re: 150 year Message-ID: Michael Moroney wrote: > "Richard B. Gilbert" writes: > >> In my entire VMS career, I never needed to represent a date/time that >> VMS could not accommodate! In fact, I don't think I ever needed to >> represent a date prior to 1984 which was the year I was VAXinated. > > I did at one time. I was trying to figure out when my billion-second > "birthday" was (when I would be 1 billion seconds old) - and VMS failed > me! That's because I wanted to add a delta time equal to 1 billion > seconds to my birthdate but DCL cannot handle delta times greater than > 9999 23:59:59. DCL can't handle it, but Macro, C, Fortran, BASIC, COBOL, etc, can. See SYS$BINTIM and SYS$ASCTIM. For a moderately outrageous fee, I'll write it for you in Fortran, C, or Macro-32 (extra charge). ------------------------------ Date: 18 Nov 2008 17:19:42 GMT From: "Bob Eager" Subject: Re: 150 year Message-ID: <176uZD2KcidF-pn2-MopGS4TrCg8m@rikki.tavi.co.uk> On Tue, 18 Nov 2008 16:25:26 UTC, Mike Rechtman wrote: > OTOH on RSTS writing financial applications we had to manage dates up to > 100 years in the future for long-range planning, loans etc. > IIRC the native RSTS dates only went up to 2002 (1970 + 32767/1000) Not as bad as DOS/BATCH on the PDP-11, which stored the date as ((year-1970)*1000)+dayinyear, in 12 bits! Ran out in Spring 1974... -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: 18 Nov 2008 17:19:43 GMT From: "Bob Eager" Subject: Re: 150 year Message-ID: <176uZD2KcidF-pn2-J56lUyddzQhH@rikki.tavi.co.uk> On Tue, 18 Nov 2008 15:01:00 UTC, "Tom Linden" wrote: > >> > That was interesting! Not having PL/I, I quickly turned it into REXX > >> and > >> > it seems to work fine....! > >> > > >> Does REXX run on VMS? > > > > I assumed it did, but I admit I didn't do it on one of my VAXes! There's > > a portable implementation... > > > So what did you run it on? Nearest system at hand...OS/2. > BTW, why not post the REXX code so others don't > have to reinvent the wheel? Well, since you ask... /* * File: easter.cmd * * Display Easter date * */ parse arg year junk if junk \= '' then do say 'Too many args' exit 1 end year = arg(1) if year = '' then do say 'Usage: easter year' exit 1 end /* The following calculation of the Date for Easter follows the algorithm given in the New Scientist magazine, issue No. 228 (Vol. 9) page 828 (30 March 1961). */ /* Find position of year in 19-year Lunar Cycle, called the Golden Number. */ a = year//19 /* b is century number, c is year number within century*/ b = year%100 c = year//100 /* These are used in leap year adjustments. */ d = b%4 e = b//4 i = c%4 k = c//4 /* The next step computes a correction factor used in the following step which computes the number of days between the spring equinox and the first full moon thereafter. The correction factor is needed to keep the approximation in line with the observed behavior of the moon. It moves the full moon date back by one day eight times in every 2500 years, in century years three apart, with four years at the end of the cycle. The constant 13 corrects the correction for the fact that this cycle was decreed to start in the year 1800. */ g = (8*b+13)%25 /* Now the number of days after the equinox (21 March, by definition) that we find the next full moon. This is a number between 0 and 29. The term 19*a advances the full moon 19 days for each year of the Lunar Cycle, for a total of 361 days in the 19 years. The other 4.24 days are made up when a returns to zero on the next cycle. Thus, the full moon dates repeat every 19 years. The term b-d advances the date by one day for three out of every four century years, the years which are not leap years although divisible by 4. The term g is the correction factor calculated above, and 15 adjusts this whole calculation to the actual conditions at that date on which the scheme began, probably in Oct of 1582. */ h = (19*a + b - d - g + 15)//30 /* Now we are interested in how many days we have to wait after the full moon until we get a Sunday (which has to be definitely after the full moon). The following step calculates a number l which is one less than the number of days. Every ordinary year ends on the same day of the week on which it started; a leap year ends on the day of the week following the one on which it started. Thus, if it is known on what day of the week a date occurred in any year it is possible to calculate its day of the week in another year by marching through the week one day for each regular year and two for each leap year. The term k is the number of ordinary years since the last leap year; each such year brings the date of the full moon one day closer to Sunday, and so reduces the number of days to be waited (unless it goes negative, but modular arithmetic theory makes -1 = 6 where the modulus is 7). The term i is the number of leap years so far in the current century. each leap year has with it three ordinary years, and each such group advances the day of the week by 5 days. But in modulo 7 arithmetic subtracting 5 days is equivalent to adding 2 days. So we add two days for each group of four years in the current century. Since a century consists of 25 groups of four years, it advances the day of the week by 124 or 125 days depending on whether the century year is an ordinary or leap year. The remainders when these numbers are divided by seven are 5 and 6 respectively. The term e is the number of ordinary century years since the last leap century year. As with the groups of four years, we add two days for each rather than subtract 5 for each. Every fourth century year is a leap year; therefore, each group of four centuries advances the day of the week by 3*5+6 = 21 days, or 0 in modulo 7 arithmetic, and no term is necessary for time before the last leap century year. The constant term 32 adjusts the calculation for the day of the week of the equinox when the scheme was put into effect. It also is larger than necessary by 28 in order to assure that the subtractions of k and h never reduce the dividend below 0. Thus, mod(2*e + 2*i - k + 32, 7) gives one less than the number of days between the equinox and its following Sunday. But we need to calculate the number of days after the full moon. The term h, calculated in the previous step, gives the number of days after the equinox that the full moon occurs. Each of those days brings the full moon closer to the actual Sunday of Easter, so it reduces the number of days after the full moon until Easter. (Again, if h > 6, modular arithmetic theory readjusts the result to another cycle of 0 to 6, and here the constant 32 keeps the dividend > 0.) */ l = (2*e + 2*i - k + 32 - h)//7 /* The calendar set up by Pope Gregory XIII and his advisor, the astronomer Clavius, provided for official full moon dates as well as matching the equinoxes and solstices with their nominal dates. But, since the period of the moon is not an exact number of days, some fudging was needed here as elsewhere in the calendar system. Some of the periods between successive full moons in the Lunar Cycle are 30 days, some 29 days. Clavius then arranged the periods carefully so that if a full moon fell on 20 March (the day before the equinox), the period following it would be of 29 days. The effect of this arrangement is that Easter can never occur later than 25 April. The above calculations assume uniform 30-day lunar periods. In rare cases (e.g., 1954 and 1981) one of these 29-day lunar periods causes the full moon to fall on a Saturday where a 30-day period would put it on a Sunday. The following step calculates the fudge factor for this situation. The result m is 0 if no fudging is necessary, or 1 if fudging is required. */ m = (a + 11*h + 19*l)%433 /* Now we have calculated the number of days which will elapse between 21 march and Easter: h + (l + 1) - 7*m. The next two steps turn this into a month and day. In the first expression, the constant 90 assures that the the quotient will be at least 3 (= March). If the elapsed days exceed 9, then the quotient will be 4 (= April). In the second expression, if month = 3 then 33*month + 19 = 118 and the remainder of that part of the expression is 22; when month = 3, l + h - 7*m < 10, so 22 < day <= 31. If month = 4, 33*month = 132, and since h + l - 7*m > 9, the whole expression satisfies 5*32 = 160 < expr. The remainder is greater than 0 and less than 26. */ month = (h + l - 7*m + 90)%25 day = (h + l - 7*m +33*month + 19)//32 say 'Easter in' year 'is on' day month_name(month) exit 0 /*--------------------------------------------------------------------*/ month_name: procedure month = arg(1) if month > 12 then month = 0 if month < 0 then month = 0 m.0 = '???' m.1 = 'Jan' m.2 = 'Feb' m.3 = 'Mar' m.4 = 'Apr' m.5 = 'May' m.6 = 'Jun' m.7 = 'Jul' m.8 = 'Aug' m.9 = 'Sep' m.10 = 'Oct' m.11 = 'Nov' m.12 = 'Dec' return m.month /* * End of file: easter.cmd * */ -- Bob Eager Use the BIG mirror service in the UK: http://www.mirrorservice.org ------------------------------ Date: 18 Nov 2008 12:00:27 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 150 year Message-ID: <7TSh6zC0LvdS@eisner.encompasserve.org> In article <6r6dnX1etYx-S7_UnZ2dnUVZ_gCdnZ2d@giganews.com>, "Richard B. Gilbert" writes: > > Your alternative is Unix where 1 January 1970 is "the beginning of > time". That works too. Well, sort of!!! It may work for my niece, but it can't handle a good many of my birthdays. At least VMS picked a date before the birth of anyone then living. ------------------------------ Date: 18 Nov 2008 12:03:06 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 150 year Message-ID: In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes: > > I did at one time. I was trying to figure out when my billion-second > "birthday" was (when I would be 1 billion seconds old) - and VMS failed > me! That's because I wanted to add a delta time equal to 1 billion > seconds to my birthdate but DCL cannot handle delta times greater than > 9999 23:59:59. DCL is not VMS's most powerfull programming language. 8-; ------------------------------ Date: Tue, 18 Nov 2008 18:13:22 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: 150 year Message-ID: In article <5-adnT086rbJb7_UnZ2dnUVZ_r3inZ2d@giganews.com>, "Richard B. Gilbert" writes: > I think it was Bill Cosby who said: "Some people seek immortality > through their children, others seek it through their work. I plan to > seek immortality by not dying!" I've heard that it was Woody Allen who said "I don't want to achieve immortality through my work; I want to achieve it through not dying". ------------------------------ Date: 18 Nov 2008 12:14:58 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 150 year Message-ID: In article <6r6dnX5etYxKRb_UnZ2dnUVZ_gCdnZ2d@giganews.com>, "Richard B. Gilbert" writes: > Bob Koehler wrote: >> In article <000db06b$0$12274$c3e8da3@news.astraweb.com>, JF Mezei writes: >>> The Unix system time is just seconds in a 32 bit integer and it >>> simplifies arithmetic being done. >> >> But provides a clock usefull over only 68 years. Don't try to use it >> to support a business that plans to be in business for over 100 >> years. >> > > I've heard rumors that most Unices either plan to adopt, or have > adopted, a 64 bit time. Internally, yes. But the API is still 32 bit. C and UNIX need to propose and adopt a new API, just as Fortran did for Y2K. Fortran defined the DATE function as returning (in part) the two-digit year since 1900. Obviously that definition couldn't be adheared to in 2000. The function was redefined to return the last two digits in the year, and a new function was added that returns the four digit year. The only code I have that uses DATE just wants to report the year and those two digits are fine. C and UNIX need to adopt a definition for what the current API will return by the end of 2038, and a new API that will last somewhat longer. 30 years ought to be plenty of time to get it done. Meanwhile, other, newer tools, such as Java, have already adopted much more usefull calendar systems. But the world ends in 2012, right? ------------------------------ Date: Tue, 18 Nov 2008 18:17:13 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: 150 year Message-ID: In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes: > Yes it was a mess. However I picked those times because the countries > that switched after Great Britain did were mostly relatively minor players > while still on the Julian calendar. The biggest were the Ottoman Empire > and Russia during WW1. (and when VMS was created, Russia was run by the > commies and we weren't supposed to help them! :-) Which is why the CVAX chip contained the microscopic statement, in Russian, "VAX - when you care enough to steal the very best ": http://micro.magnet.fsu.edu/creatures/pages/russians.html ------------------------------ Date: Tue, 18 Nov 2008 18:31:50 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: 150 year Message-ID: "Richard B. Gilbert" writes: >Michael Moroney wrote: >> I did at one time. I was trying to figure out when my billion-second >> "birthday" was (when I would be 1 billion seconds old) - and VMS failed >> me! That's because I wanted to add a delta time equal to 1 billion >> seconds to my birthdate but DCL cannot handle delta times greater than >> 9999 23:59:59. >DCL can't handle it, but Macro, C, Fortran, BASIC, COBOL, etc, can. >See SYS$BINTIM and SYS$ASCTIM. >For a moderately outrageous fee, I'll write it for you in Fortran, C, or > Macro-32 (extra charge). I did it in DCL since it was a one-time need. (I was one billion seconds old only once) I just broke the delta time addition into two, one for adding 9999 00:00:00 to my birthdate and the second to add the remainder of the days, hours, minutes & seconds. ------------------------------ Date: Tue, 18 Nov 2008 06:45:15 -0800 (PST) From: sccr13plyr@gmail.com Subject: OVMS NetBeans IDE Error Message-ID: <1162ca5f-c114-4ad0-829c-c6cb82ded0eb@k36g2000pri.googlegroups.com> Hello, Our System Admin recently installed the OpenVMS component for NetBeans. I installed NetBeans and the OVMS module on my machine. When I try to establish a connection with the remote IDE server, I get a popup with the error: error during JRMP connection establishment; nested exception is: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake The sysadmin has been too busy to look at the issue right now, so I was curious if anyone around here might have some suggestions as to what the problem might be... TIA sccr13plyr ------------------------------ Date: Tue, 18 Nov 2008 15:04:32 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: OVMS NetBeans IDE Error Message-ID: <4QAUk.4184$U5.28804@newsb.telia.net> sccr13plyr@gmail.com wrote: > Hello, > > Our System Admin recently installed the OpenVMS component for > NetBeans. I installed NetBeans and the OVMS module on my machine. > When I try to establish a connection with the remote IDE server, I get > a popup with the error: > > error during JRMP connection establishment; nested exception is: > javax.net.ssl.SSLHandshakeException: Remote host closed connection > during handshake > > The sysadmin has been too busy to look at the issue right now, so I > was curious if anyone around here might have some suggestions as to > what the problem might be... > > TIA > > sccr13plyr > You'll better wait for your admin. I have the tools installed but the error doesn't tell me anything anyway... Jan-Erik. ------------------------------ Date: 18 Nov 2008 12:06:39 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: OVMS NetBeans IDE Error Message-ID: In article <1162ca5f-c114-4ad0-829c-c6cb82ded0eb@k36g2000pri.googlegroups.com>, sccr13plyr@gmail.com writes: > Hello, > > Our System Admin recently installed the OpenVMS component for > NetBeans. I installed NetBeans and the OVMS module on my machine. > When I try to establish a connection with the remote IDE server, I get > a popup with the error: > > error during JRMP connection establishment; nested exception is: > javax.net.ssl.SSLHandshakeException: Remote host closed connection > during handshake > > The sysadmin has been too busy to look at the issue right now, so I > was curious if anyone around here might have some suggestions as to > what the problem might be... > > TIA > > sccr13plyr Since you have no data and we're just wild guessing here, I'd suspect something in your LOGIN.COM on the remote server that the connection doesn't expect. ------------------------------ Date: Tue, 18 Nov 2008 05:11:12 -0800 (PST) From: IanMiller Subject: Re: SWB 1.1.10 -- New quirk? Message-ID: On 18 Nov, 05:12, s...@antinode.info (Steven M. Schweda) wrote: > =A0 =A0Trying out the new "SWB 1.1.10 | Mozilla/5.0 (X11; U; OpenVMS > COMPAQ_Professional_Workstation; en-US; rv:1.8.1.15) Gecko/20080928 > SeaMonkey/1.1.10" on my VMS V7.3-2 system (with VMS732_UPDATE V15.0), I > noticed a couple of quirks. > > =A0 =A0At first, the "hp" logo progress indicator (upper right) was going > blank instead of rolling around as expected during a Reload, but that > problem seems to have disappeared after a browser restart. =A0(I don't > know if I was lucky before or now.) > > =A0 =A0Now, the annoyance is a different visual quirk. =A0If I move the c= ursor > onto the "Reload" button by passing over a button directly below it > (might be "Bookmarks", might be "The Mozilla Organization", depending on > whether "Home" is there on the left), instead of the normally > highlighted "Reload" button with its usual curvy blue arrow, I get a > slightly corrupted green arrow, like the "Back" arrow, but with a few > extra green pixels which look like leftovers from the proper (but blue) > "Reload" arrow. =A0It doesn't happen every time, but it's pretty common. > (Might be a coin toss.) > > =A0 =A0Anyone else see any of this stuff? =A0I didn't notice any of it wi= th > the pre-SeaMonkey SWB. > > =A0 =A0Naturally, (and this _is_ like the pre-SeaMonkey SWB) the FTP code > still can't cope with even simple (but long) ODS2 file names as > presented by a TCPIP FTP server: > > =A0 =A0 =A0ftp://antinode.info/moz_test/ > > (Each directory there contains three files, as can easily be seen using > a simple FTP client program.) > > =A0 =A0I assume that it's also still bewildered by ODS5 extended file nam= es, > or at least by the way a TCPIP FTP server deals with them. =A0(But who > wouldn't be?) > > ------------------------------------------------------------------------ > > =A0 =A0Steven M. Schweda =A0 =A0 =A0 =A0 =A0 =A0 =A0 sms@antinode-info > =A0 =A0382 South Warwick Street =A0 =A0 =A0 =A0(+1) 651-699-9818 > =A0 =A0Saint Paul =A0MN =A055105-2547 If you have an Itainium VMS system then compare it with the beta release of firefox http://www.openvms.org/stories.php?story=3D08/11/18/1050594 You have send your comments to HP haven't you? Lots of people don't read items posted here. ------------------------------ Date: Tue, 18 Nov 2008 07:19:10 -0600 (CST) From: sms@antinode.info (Steven M. Schweda) Subject: Re: SWB 1.1.10 -- New quirk? Message-ID: <08111807191064_202004DB@antinode.info> From: IanMiller > If you have an Itainium VMS system then compare it with the beta > release of firefox > http://www.openvms.org/stories.php?story=3D08/11/18/1050594 Will do. Suggestion appreciated. > You have send your comments to HP haven't you? I submitted some of them on the Web form. Got only the automated response. Thought I'd try to determine if anyone else was affected before wasting more time that way. > Lots of people don't read items posted here. Small wonder, when you look at most of the drivel posted here by the socially isolated. Speaking of off-topic, Web-browser-related, scary stuff, try this: http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1289142 (There's another one for Linux, too.) I can hardly wait to see what the all-singing, all-dancing version of SAM will look like. (Probably put the AIX SMIT dude to shame.) SMS. ------------------------------ End of INFO-VAX 2008.625 ************************