INFO-VAX Thu, 28 Feb 2008 Volume 2008 : Issue 118 Contents: Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: 6-core CPU on the horizon Re: Eunice (was: Wollogong TCP/IP stack) Re: Eunice (was: Wollogong TCP/IP stack) Headhunter brainstorming value additions Leap Year Re: Leap Year Re: Leap Year Re: Leap Year Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff Re: Long term archiving of VMS stuff OT: Universal healthcare in England failing - boy dies ! Re: OT: Universal healthcare in England failing - boy dies ! Re: Samba and text files various MAKE tools for VMS Re: various MAKE tools for VMS Re: various MAKE tools for VMS Re: various MAKE tools for VMS Re: various MAKE tools for VMS Re: various MAKE tools for VMS ---------------------------------------------------------------------- Date: Thu, 28 Feb 2008 04:53:41 -0800 (PST) From: Neil Rieck Subject: Re: 6-core CPU on the horizon Message-ID: <0f290c00-b750-40c8-a706-127667c4cbd8@o77g2000hsf.googlegroups.com> On Feb 27, 6:31 pm, Cydrome Leader wrote: > JF Mezei wrote: > > Cydrome Leader wrote: > > >> so in this case the point is to get people off VMS and then deprecate VMS. > > > No. The point is to send the message to HP that when they allow a VMS > > customer to drop VMS, that customer also drops HP alltogether. > > how many tens of dollars is the VMS market worth these days? I hope I'm not stating the obvious, but there are only two ways to get OpenVMS ported to other platforms like x86-64. 1) HP will need to pay professional programmers to do it. Since this will be expensive, it will also require a business plan with an ROI of 3-4 years. 2) HP would need to release the source code to the public domain then HOPE that "the world army of university students" and "open-source contributors" pick up the ball and run with it (this is one reason why UNIX + Linux seem to be everywhere and on everything). Since releasing OpenVMS code into the public domain would most likely hurt their current licensing revenue, and there is no real ROI to this action, this will never happen. So the only hope for OpenVMS is to convince HP to proceed with plan #1. To start this, we all need to be less dogmatic about non-Alpha hardware. Continually bashing Intel technology (32, 64, or 128 bit processors) sends strong messages to HP that we would never support OpenVMS on x86-64. You may call me fickle, but: I was in love with RSX on PDP-11 until I experienced VMS on VAX. I was resistant to OpenVMS on Alpha until those systems became faster and cheaper than equivalent VMS on VAX. BTW, Alpha got better-faster-cheaper primarily due to COTS (commodity off the shelf) system components. So now we're at another fork in the road and the only way to keep OpenVMS alive is to accept the fact that it will need to run on hardware that is 100% non-DEC. I can hardly wait until my employer agrees that a new Itanium platform makes sense. However, this is getting harder every day when my boss knows that 4, 6, and 8 core systems are on the horizon and under a few thousand dollars. Maybe targeting OpenVMS at an 8-core x86-64 platform may be more realistic. p.s. failure to stop complaining might relegate OpenVMS to the OS museum along with products like: RSX-11, RT-11, TRS-DOS, Apple-DOS, etc. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: 28 Feb 2008 07:40:45 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: 6-core CPU on the horizon Message-ID: <3a95$glaac9O@eisner.encompasserve.org> In article <0f290c00-b750-40c8-a706-127667c4cbd8@o77g2000hsf.googlegroups.com>, Neil Rieck writes: > > 2) HP would need to release the source code to the public domain then > HOPE that "the world army of university students" and "open-source > contributors" pick up the ball and run with it (this is one reason why > UNIX + Linux seem to be everywhere and on everything). Since releasing > OpenVMS code into the public domain would most likely hurt their > current licensing revenue, and there is no real ROI to this action, > this will never happen. While I like the results of having lots of free software because so many people contribute, I do not trust the average programmer to maintain upward compatability or security in code written in an open source environment. Most programmers I know are heavily influenced by thier first hand experience, which nowdays does not include upward compatability or serious security. ------------------------------ Date: 28 Feb 2008 14:36:27 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: 6-core CPU on the horizon Message-ID: <62nv7bF23m54kU1@mid.individual.net> In article <0f290c00-b750-40c8-a706-127667c4cbd8@o77g2000hsf.googlegroups.com>, Neil Rieck writes: > On Feb 27, 6:31 pm, Cydrome Leader wrote: >> JF Mezei wrote: >> > Cydrome Leader wrote: >> >> >> so in this case the point is to get people off VMS and then deprecate VMS. >> >> > No. The point is to send the message to HP that when they allow a VMS >> > customer to drop VMS, that customer also drops HP alltogether. >> >> how many tens of dollars is the VMS market worth these days? > > I hope I'm not stating the obvious, but there are only two ways to get > OpenVMS ported to other platforms like x86-64. > > 1) HP will need to pay professional programmers to do it. Since this > will be expensive, it will also require a business plan with an ROI of > 3-4 years. > > 2) HP would need to release the source code to the public domain then > HOPE that "the world army of university students" and "open-source > contributors" pick up the ball and run with it (this is one reason why > UNIX + Linux seem to be everywhere and on everything). Since releasing > OpenVMS code into the public domain would most likely hurt their > current licensing revenue, and there is no real ROI to this action, > this will never happen. That assumes this revenue is significant enough for them to care. A much more likely reason not to release it like this is just lack of interest. How much revenue do you think they get from Ultrix-32? And yet, their answer to a request for just a hobbyist license, not even open sourcing was, "Go use NetBSD." > > So the only hope for OpenVMS is to convince HP to proceed with plan > #1. To start this, we all need to be less dogmatic about non-Alpha > hardware. Continually bashing Intel technology (32, 64, or 128 bit > processors) sends strong messages to HP that we would never support > OpenVMS on x86-64. Ummmm..... There have been VMS users calling for VMS on Intel (well, other than Itanium) hardware for several years. Might even be a decade already!! I think they have had pelnty of proof that if they build it people would come. > > You may call me fickle, but: I was in love with RSX on PDP-11 until I > experienced VMS on VAX. I was resistant to OpenVMS on Alpha until > those systems became faster and cheaper than equivalent VMS on VAX. > BTW, Alpha got better-faster-cheaper primarily due to COTS (commodity > off the shelf) system components. So now we're at another fork in the > road and the only way to keep OpenVMS alive is to accept the fact that > it will need to run on hardware that is 100% non-DEC. I can hardly > wait until my employer agrees that a new Itanium platform makes sense. > However, this is getting harder every day when my boss knows that 4, > 6, and 8 core systems are on the horizon and under a few thousand > dollars. Maybe targeting OpenVMS at an 8-core x86-64 platform may be > more realistic. > > p.s. failure to stop complaining might relegate OpenVMS to the OS > museum along with products like: RSX-11, RT-11, TRS-DOS, Apple-DOS, > etc. Well, RSX-11 and RT-11 are hardly museum bait. They are still sold and maintained by Mentec and I know of a number of commercial operations using them. Oh yeah, and RSTS as well. TRS-DOS. Well, the owner of that was never a computer company and its attempt to move into that world was a dismal failure as you might expect of someone who had absolutely no understanding of the business. You do remember the origin of "Tandy", don't you? Oh, and just in case your curious, TRS-DOS (and its third-party competition, DOSPlus, NewDOS and others) are still thriving in the hobbyist world. And, like the VAX world they are doing it more and more on emulators as the hardware gets harder and harder to find. I now, I'm one of them. My first computer was a TRS80. My first home Unix system was a TRS-80. My first OS9 realtime system was, you guessed it, a TRS-80!! :-) The owner of Apple-DOS developed other hardware and software until Apple-DOS had no paractical reason for existance. hardly the same situation as VMS. As a matter of fact, that company's computer line is still thriving. If VMS falls, it will be due to tha apathyt of its owners. A fate not suffered by any of the others mentioned above. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 28 Feb 2008 07:37:15 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: In article , John Santos writes: > > Not necessarily! It depends on the implementation. Fork() could record > the current I/O state of all the open channels, pass it to the spawned > process, and during startup, replicate the i/o state. Which would fail since VMS by default opens many I/O channels for exclusive access. Yes, you could achieve the affect by emulating an entire UNIX kernel inside on process, except that then everyone who logged onto EUNICE would see themselves as having a separate virtual machine. When you logged onto EUNICE, you got a csh prompt and some UNIX-like libraries, not you own machine. ------------------------------ Date: 28 Feb 2008 14:45:39 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Eunice (was: Wollogong TCP/IP stack) Message-ID: <62nvojF23m54kU2@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , John Santos writes: >> >> Not necessarily! It depends on the implementation. Fork() could record >> the current I/O state of all the open channels, pass it to the spawned >> process, and during startup, replicate the i/o state. > > Which would fail since VMS by default opens many I/O channels for > exclusive access. > > Yes, you could achieve the affect by emulating an entire UNIX kernel > inside on process, except that then everyone who logged onto EUNICE > would see themselves as having a separate virtual machine. > > When you logged onto EUNICE, you got a csh prompt and some UNIX-like > libraries, not you own machine. That was the part I couldn't remember. I thought there was more to it than just a shell and commands because that wouldn't result in it being so slow. If it was merely a shell and commadns then doing an "ls" under "csh" should not have been any slower than doing a "dir" under "DCL". But it was. Painfully slower!! That was the reason most people I knew abandoned it in favor of getting their own small Unix systems (like CT Miniframe, Tandy-6000. Sage, etc.) But, looking back at your second paragraph. In this day of "virtualization". Is this not a possible solution to the "How do I run OpenOffice under VMS" question? Surely the systems are fast enough today that better than acceptable performance could be delivered. Of course, this comes back to my past comments on The Software Tools Virtual Operating System project. Maybe this is another of those things which wasn't practical at the time it started but technology has now caught up to it. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Thu, 28 Feb 2008 03:28:29 -0800 (PST) From: gorecroot Subject: Headhunter brainstorming value additions Message-ID: <75fa1754-f9bb-44b1-8663-fcaab63a2974@e25g2000prg.googlegroups.com> Source: http://www.gorecroot.com If you do not specialise you cannot value add. Case A: Large team of recruiters multiple cities / states coverage, decent recruiting brand. Clients are willing to share open positions easily but are very clear that the expected output is just resumes. The message is clear from most clients, do not bother value adding. Why? What can be clear value additions from recruiters? Case B: Mid sized team, focused in one or two cities. Do not take 'run of the mill' requirements. Specialises in two aspects: Niche skills, high quality of resumes leading to very good yield ratios. Core strength is clearly in headhunting. Creating a network and managing relationships. What are clear definitions of 'quality of resume'? What is your method to derive returns from your resume archive? Have any of us tried audio resumes or voice resumes, video resumes - for specific positions? ------------------------------ Date: Thu, 28 Feb 2008 12:18:07 +0100 From: "The Mip" Subject: Leap Year Message-ID: Some told me that chance of 29. feb. would be a Friday (as this year) was close to average, but that not all weekdays was on average. That did sound strange to me, so i wrote a little DCL Trying it from first leap year (after 17-nov-1857) 1860 to DCL end-of-time 9999 gives: Sunday: 264 (1337 %%) Monday: 306 (1550 %%) Tuesday: 264 (1337 %%) Wednesday: 305 (1545 %%) Thursday: 265 (1342 %%) Friday: 284 (1438 %%) Saturday: 286 (1448 %%) Expected average in this case, with 1974 leap years, was 282 I guess it's cyclic with a cycle of 2800 years (7 X 400 years) All cases with a 2800+ range gives mondays / wednesdays > average and sundays/thursdays < average So strange but true - the mip $! 29_feb.com $! $ if p1 .eqs. "" then exit $ if p2 .eqs. "" then exit $ year = 'p1' $! p1 must be a leap year $ if ('p1'/4)*4 .ne. 'p1' .or. - ('p1'/100)*100 .eq.'p1' .and. ('p1'/400)*400 .ne. 'p1' $ then $ write sys$output " ''p1' is not a leap Year " $ exit $ endif $ Sundays = 0 $ Mondays = 0 $ Tuesdays = 0 $ Wednesdays = 0 $ Thursdays = 0 $ Fridays = 0 $ Saturdays = 0 $! $ loop: $ weekday= "" $ weekday = F$CVTIME("29-feb-''year'",,"weekday") $! $ If Weekday .eqs. "Sunday" then Sundays = 'Sundays' + 1 $ If Weekday .eqs. "Monday" then Mondays = 'Mondays' + 1 $ If Weekday .eqs. "Tuesday" then Tuesdays = 'Tuesdays' + 1 $ If Weekday .eqs. "Wednesday" then Wednesdays = 'Wednesdays' + 1 $ If Weekday .eqs. "Thursday" then Thursdays = 'Thursdays' + 1 $ If Weekday .eqs. "Friday" then Fridays = 'Fridays' + 1 $ If Weekday .eqs. "Saturday" then Saturdays = 'Saturdays' + 1 $! $ year = 'year' + 4 $! On warning then continue ! gives same result but this is more clean :) $! $ if ((year/100)*100 .eq. year) .and. ((year/400)*400 .ne. year) then - year = 'year' + 4 $ if Year .lt. 'p2' then goto loop $! $ days ='Sundays'+'Mondays'+'Tuesdays' $ days='days'+'Wednesdays'+'Thursdays'+'Fridays'+'Saturdays' $! $ pct= 10000*'Sundays'/ 'days' $ write sys$output " Sunday: ''Sundays' (''pct' %%) " $ pct= 10000*'Mondays'/ 'days' $ write sys$output " Monday: ''Mondays' (''pct' %%) " $ pct= 10000*'Tuesdays'/ 'days' $ write sys$output " Tuesday: ''Tuesdays' (''pct' %%) " $ pct= 10000*'Wednesdays'/'days' $ write sys$output " Wednesday: ''Wednesdays' (''pct' %%) " $ pct= 10000*'Thursdays' / 'days' $ write sys$output " Thursday: ''Thursdays' (''pct' %%) " $ pct= 10000*'Fridays' / 'days' $ write sys$output " Friday: ''Fridays' (''pct' %%) " $ pct= 10000*'Saturdays' / 'days' $ write sys$output " Saturday: ''Saturdays' (''pct' %%) " ------------------------------ Date: Thu, 28 Feb 2008 05:23:50 -0800 (PST) From: AEF Subject: Re: Leap Year Message-ID: <34cdae74-657e-4924-b663-7a053923c4f1@k2g2000hse.googlegroups.com> On Feb 28, 7:18 am, "The Mip" wrote: > Some told me that chance of 29. feb. would be a Friday (as this year) was > close to average, but that not all weekdays was on average. > > That did sound strange to me, so i wrote a little DCL > > Trying it from first leap year (after 17-nov-1857) 1860 to DCL end-of-time > 9999 gives: > > Sunday: 264 (1337 %%) > Monday: 306 (1550 %%) > Tuesday: 264 (1337 %%) > Wednesday: 305 (1545 %%) > Thursday: 265 (1342 %%) > Friday: 284 (1438 %%) > Saturday: 286 (1448 %%) > > Expected average in this case, with 1974 leap years, was 282 > > I guess it's cyclic with a cycle of 2800 years (7 X 400 years) > > All cases with a 2800+ range gives mondays / wednesdays > average > and sundays/thursdays < average > > So strange but true > > - the mip "- the mip" Say what? More comments after the code below: > > $! 29_feb.com > $! > $ if p1 .eqs. "" then exit > $ if p2 .eqs. "" then exit > $ year = 'p1' > $! p1 must be a leap year > $ if ('p1'/4)*4 .ne. 'p1' .or. - > ('p1'/100)*100 .eq.'p1' .and. ('p1'/400)*400 .ne. 'p1' > $ then > $ write sys$output " ''p1' is not a leap Year " > $ exit > $ endif > $ Sundays = 0 > $ Mondays = 0 > $ Tuesdays = 0 > $ Wednesdays = 0 > $ Thursdays = 0 > $ Fridays = 0 > $ Saturdays = 0 > $! > $ loop: > $ weekday= "" > $ weekday = F$CVTIME("29-feb-''year'",,"weekday") > $! > $ If Weekday .eqs. "Sunday" then Sundays = 'Sundays' + 1 > $ If Weekday .eqs. "Monday" then Mondays = 'Mondays' + 1 > $ If Weekday .eqs. "Tuesday" then Tuesdays = 'Tuesdays' + 1 > $ If Weekday .eqs. "Wednesday" then Wednesdays = 'Wednesdays' + 1 > $ If Weekday .eqs. "Thursday" then Thursdays = 'Thursdays' + 1 > $ If Weekday .eqs. "Friday" then Fridays = 'Fridays' + 1 > $ If Weekday .eqs. "Saturday" then Saturdays = 'Saturdays' + 1 > $! > $ year = 'year' + 4 > $! On warning then continue ! gives same result but this is more clean :) > $! > $ if ((year/100)*100 .eq. year) .and. ((year/400)*400 .ne. year) then - > year = 'year' + 4 > $ if Year .lt. 'p2' then goto loop > $! > $ days ='Sundays'+'Mondays'+'Tuesdays' > $ days='days'+'Wednesdays'+'Thursdays'+'Fridays'+'Saturdays' > $! > $ pct= 10000*'Sundays'/ 'days' > $ write sys$output " Sunday: ''Sundays' (''pct' %%) " > $ pct= 10000*'Mondays'/ 'days' > $ write sys$output " Monday: ''Mondays' (''pct' %%) " > $ pct= 10000*'Tuesdays'/ 'days' > $ write sys$output " Tuesday: ''Tuesdays' (''pct' %%) " > $ pct= 10000*'Wednesdays'/'days' > $ write sys$output " Wednesday: ''Wednesdays' (''pct' %%) " > $ pct= 10000*'Thursdays' / 'days' > $ write sys$output " Thursday: ''Thursdays' (''pct' %%) " > $ pct= 10000*'Fridays' / 'days' > $ write sys$output " Friday: ''Fridays' (''pct' %%) " > $ pct= 10000*'Saturdays' / 'days' > $ write sys$output " Saturday: ''Saturdays' (''pct' %%) " As your code says, the rule is it's a leap year if it's divisible by 4; unless it's divisible by 100, then not; but if divisible by 400, it is. So that gives 97 leap years every 400 years which gives 400*365+97 days in 400 years = 146097 days which *is* evenly divisible by 7 so things repeat every 400 years. This can be checked by a few simple DCL commands: $ ev f$cvtime("1-JAN-2000",,"WEEKDAY") Saturday $ ev f$cvtime("1-JAN-2400",,"WEEKDAY") Saturday $ ev f$cvtime("1-JAN-2800",,"WEEKDAY") Saturday $ ev f$cvtime("1-JAN-3200",,"WEEKDAY") Saturday So it's a 400-year cycle. AEF ------------------------------ Date: Thu, 28 Feb 2008 07:58:27 -0800 (PST) From: AEF Subject: Re: Leap Year Message-ID: <6e5f4b80-9bce-46b2-81e9-65e72bb635fd@62g2000hsn.googlegroups.com> On Feb 28, 9:23 am, AEF wrote: > On Feb 28, 7:18 am, "The Mip" wrote: > > > > > Some told me that chance of 29. feb. would be a Friday (as this year) was > > close to average, but that not all weekdays was on average. > > > That did sound strange to me, so i wrote a little DCL > > > Trying it from first leap year (after 17-nov-1857) 1860 to DCL end-of-time > > 9999 gives: > > > Sunday: 264 (1337 %%) > > Monday: 306 (1550 %%) > > Tuesday: 264 (1337 %%) > > Wednesday: 305 (1545 %%) > > Thursday: 265 (1342 %%) > > Friday: 284 (1438 %%) > > Saturday: 286 (1448 %%) > > > Expected average in this case, with 1974 leap years, was 282 > > > I guess it's cyclic with a cycle of 2800 years (7 X 400 years) > > > All cases with a 2800+ range gives mondays / wednesdays > average > > and sundays/thursdays < average > > > So strange but true > [...code omitted...] > > As your code says, the rule is it's a leap year if it's divisible by > 4; unless it's divisible by 100, then not; but if divisible by 400, it > is. So that gives 97 leap years every 400 years which gives 400*365+97 > days in 400 years = 146097 days which *is* evenly divisible by 7 so > things repeat every 400 years. This can be checked by a few simple DCL > commands: > > $ ev f$cvtime("1-JAN-2000",,"WEEKDAY") > Saturday > $ ev f$cvtime("1-JAN-2400",,"WEEKDAY") > Saturday > $ ev f$cvtime("1-JAN-2800",,"WEEKDAY") > Saturday > $ ev f$cvtime("1-JAN-3200",,"WEEKDAY") > Saturday > > So it's a 400-year cycle. > > AEF Additionally, since 97 is not evenly divisible by 7, it cannot be that there is a 1/7 chance that Leap Day be any given day of the week. So this analysis shows that it has to be skewed to favor some days of the week over others, as you demonstrated with your code. As each leap day within a century is two days of the week before that of the prior one; and since there are 25 leap days in the 2000s, and 24 in each of the 2100s, 2200s, and 2300s, e.g.; and since this is the same for any 400-year interval starting with a multiple of 400; the first 21 leap days of each century (starting a century with a year ending in 00) should have an even distribution of days of the week for Feb 29, with the remaining determining the amount of skew towards each day of the week. AEF ------------------------------ Date: Thu, 28 Feb 2008 11:47:31 -0500 From: norm.raphael@metso.com Subject: Re: Leap Year Message-ID: This is a multipart message in MIME format. --=_alternative 005C3A42852573FD_= Content-Type: text/plain; charset="US-ASCII" AEF wrote on 02/28/2008 10:58:27 AM: > On Feb 28, 9:23 am, AEF wrote: > > On Feb 28, 7:18 am, "The Mip" wrote: > > > > > > > > > Some told me that chance of 29. feb. would be a Friday (as this year) was > > > close to average, but that not all weekdays was on average. > > > > > That did sound strange to me, so i wrote a little DCL > > > > > Trying it from first leap year (after 17-nov-1857) 1860 to DCL > end-of-time > > > 9999 gives: > > > > > Sunday: 264 (1337 %%) > > > Monday: 306 (1550 %%) > > > Tuesday: 264 (1337 %%) > > > Wednesday: 305 (1545 %%) > > > Thursday: 265 (1342 %%) > > > Friday: 284 (1438 %%) > > > Saturday: 286 (1448 %%) > > > > > Expected average in this case, with 1974 leap years, was 282 > > > > > I guess it's cyclic with a cycle of 2800 years (7 X 400 years) > > > > > All cases with a 2800+ range gives mondays / wednesdays > average > > > and sundays/thursdays < average > > > > > So strange but true > > > [...code omitted...] > > > > As your code says, the rule is it's a leap year if it's divisible by > > 4; unless it's divisible by 100, then not; but if divisible by 400, it > > is. So that gives 97 leap years every 400 years which gives 400*365+97 > > days in 400 years = 146097 days which *is* evenly divisible by 7 so > > things repeat every 400 years. This can be checked by a few simple DCL > > commands: > > > > $ ev f$cvtime("1-JAN-2000",,"WEEKDAY") > > Saturday > > $ ev f$cvtime("1-JAN-2400",,"WEEKDAY") > > Saturday > > $ ev f$cvtime("1-JAN-2800",,"WEEKDAY") > > Saturday > > $ ev f$cvtime("1-JAN-3200",,"WEEKDAY") > > Saturday > > > > So it's a 400-year cycle. > > > > AEF > > Additionally, since 97 is not evenly divisible by 7, it cannot be that > there is a 1/7 chance that Leap Day be any given day of the week. So > this analysis shows that it has to be skewed to favor some days of the > week over others, as you demonstrated with your code. > > As each leap day within a century is two days of the week before that > of the prior one; and since there are 25 leap days in the 2000s, and > 24 in each of the 2100s, 2200s, and 2300s, e.g.; and since this is the > same for any 400-year interval starting with a multiple of 400; the > first 21 leap days of each century (starting a century with a year > ending in 00) should have an even distribution of days of the week for > Feb 29, with the remaining determining the amount of skew towards each > day of the week. > > AEF I was born on Father's Day, so I have only 4 birthday's every 28 years. The cycle is 5,6,11,6 for me. It's a great way of staying young, but I shall miss the senior citizen discounts. Is someone trying to win a bar bet with this? --=_alternative 005C3A42852573FD_= Content-Type: text/html; charset="US-ASCII"
AEF <spamsink2001@yahoo.com> wrote on 02/28/2008 10:58:27 AM:

> On Feb 28, 9:23 am, AEF <spamsink2...@yahoo.com> wrote:
> > On Feb 28, 7:18 am, "The Mip" <Nos...@nowhere.au.dk> wrote:
> >
> >
> >
> > > Some told me that chance of 29. feb. would be a Friday (as this year) was
> > > close to average, but that not all weekdays was on average.
> >
> > > That did sound strange to me, so i wrote a little DCL
> >
> > > Trying it  from first leap year (after 17-nov-1857) 1860 to DCL
> end-of-time
> > > 9999 gives:
> >
> > >  Sunday:          264   (1337 %%)
> > >  Monday:         306   (1550 %%)
> > >  Tuesday:        264   (1337 %%)
> > >  Wednesday:  305   (1545 %%)
> > >  Thursday:      265   (1342 %%)
> > >  Friday:           284   (1438 %%)
> > >  Saturday:       286   (1448 %%)
> >
> > > Expected average in this case, with 1974 leap years, was 282
> >
> > > I guess it's cyclic with a cycle of 2800 years (7 X 400 years)
> >
> > > All cases with a 2800+ range gives mondays / wednesdays > average
> > > and sundays/thursdays < average
> >
> > > So strange but true
> >
> [...code omitted...]
> >
> > As your code says, the rule is it's a leap year if it's divisible by
> > 4; unless it's divisible by 100, then not; but if divisible by 400, it
> > is. So that gives 97 leap years every 400 years which gives 400*365+97
> > days in 400 years = 146097 days which *is* evenly divisible by 7 so
> > things repeat every 400 years. This can be checked by a few simple DCL
> > commands:
> >
> > $ ev f$cvtime("1-JAN-2000",,"WEEKDAY")
> > Saturday
> > $ ev f$cvtime("1-JAN-2400",,"WEEKDAY")
> > Saturday
> > $ ev f$cvtime("1-JAN-2800",,"WEEKDAY")
> > Saturday
> > $ ev f$cvtime("1-JAN-3200",,"WEEKDAY")
> > Saturday
> >
> > So it's a 400-year cycle.
> >
> > AEF
>
> Additionally, since 97 is not evenly divisible by 7, it cannot be that
> there is a 1/7 chance that Leap Day be any given day of the week. So
> this analysis shows that it has to be skewed to favor some days of the
> week over others, as you demonstrated with your code.
>
> As each leap day within a century is two days of the week before that
> of the prior one; and since there are 25 leap days in the 2000s, and
> 24 in each of the 2100s, 2200s, and 2300s, e.g.; and since this is the
> same for any 400-year interval starting with a multiple of 400; the
> first 21 leap days of each century (starting a century with a year
> ending in 00) should have an even distribution of days of the week for
> Feb 29, with the remaining determining the amount of skew towards each
> day of the week.
>
> AEF


I was born on Father's Day, so I have only 4 birthday's every 28 years.
The cycle is 5,6,11,6 for me.  It's a great way of staying young, but I
shall miss the senior citizen discounts.

Is someone trying to win a bar bet with this? --=_alternative 005C3A42852573FD_=-- ------------------------------ Date: 28 Feb 2008 12:20:35 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Long term archiving of VMS stuff Message-ID: <47c6a713$0$29460$607ed4bc@cv.net> In article <47c622af$0$90264$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >VAXman- @SendSpamHere.ORG wrote: >> In article , Rich Alderson writes: >>> JF Mezei writes: >>> >>> .... >>>> Since BACKUP save sets are essentially proprietary to VMS, one can't >>>> move those savesets to a platform that will outlive VMS and expect to >>>> ever be able to unpack those savesets in the future. >>> .... >>>> Any recommendation on which of those I should use, and whether there >>>> might be other formats I could choose ? >>> Let me second the recommendation of SimH virtual disk and virtual tape images. >>> If need be, package a copy of the SimH souces with them. >>> >>> Use a ZIP or StuffIt! program to compress them for space savings, if you like. >>> NB: StuffIt! provides tar, zip, and other archive formats as well as its own >>> proprietary ones. >> >> ...and 20 years from now do you believe that there will still be a Weendoze >> box that will run this? > >Neither tar or zip is windows specific. No, but 'tar'ring or 'zip'ping a SimH setup which will run on Weendoze would imply some Weendoze specificity. >(but MS would need to make a real big fuckup to ensure there will be no >Windows systems around in 20 years) Like VISTA? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: 28 Feb 2008 07:48:00 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Long term archiving of VMS stuff Message-ID: <9KbOauifVbqa@eisner.encompasserve.org> In article <47c6270f$0$90276$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: > > ASCII/ISO-8859-1/UTF-8 text with CR LF as line delimiter will also be > readable in 20 years. Actually I can remember bringing some of those over from a TOPS-20 system and finding that under VMS 3.3, COPY couldn't deal with them. Of course, I could have written a program to read them, but the fellow who brought it to me juts wanted to see if it could be done without programming. Long since, VMS COPY can read them. ------------------------------ Date: Thu, 28 Feb 2008 09:04:27 -0500 From: "Stanley F. Quayle" Subject: Re: Long term archiving of VMS stuff Message-ID: <47C6791B.10983.EECC407@infovax.stanq.com> On 27 Feb 2008 at 22:14, Arne Vajh=F8j wrote: > And would not be surprised if it was difficult to read CD's in 20 years.= A friend of mine has a theory about this. If a medium is "ubiquitous" (pr= esent everywhere), it'll be readable for a long, long, time. His examples: - 9-track tape vs. TK50 - Open reel audio tape vs. wire recording - 8-track tape vs. cassette - VHS vs. Betamax - Floppy vs. magneto-optical Millions of CD/DVD/HD DVD/Blueray drives have been sold, all of which can = read a CD. I believe that newly-developed drives will continue to read a CD for many, m= any years. --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html "OpenVMS, when downtime is not an option" ------------------------------ Date: Thu, 28 Feb 2008 15:36:33 GMT From: BobH Subject: Re: Long term archiving of VMS stuff Message-ID: JF Mezei wrote in news:47c5b592$0$25433$c3e8da3@news.astraweb.com: ... > But there is much older stuff I wish to keep as an archive and won't > get converted to the mac. But if someone needs some example on how to > do X on VMS, I would be able to pull it out of the archive and provide > it. > > Once my VMS systems are gone some time down the road, I don't wish to > have to continue to maintain some virtualised VMS instance just to > access certain files. ... If there are no VMS systems left to read the files, then there should be only minimal need for examples of how to do things on VMS. :-) The value of the text files is likely to outlast the value of .EXE and even .OBJ files since you can see how it was done in the text files, but if there are no VMS systems there is no where to run the VMS .EXEs or link the .OBJs. :-) Really, the right answer for long term preservation, particularly in this domain of digital storage which allows repeated copying without degradation, is to periodically copy the content to contemporary media. That protects against degradation of the media, as well as availability of the means to access it. If the material is sufficiently valuable then maintaining copies in this way on more than one type of media is a good additional hedge against the unknown. ------------------------------ Date: Thu, 28 Feb 2008 05:23:21 -0800 (PST) From: ultradwc@gmail.com Subject: OT: Universal healthcare in England failing - boy dies ! Message-ID: here is a glance of things to come if Hillary or Obama implement their healthcare plan ... the bbc did not report it but a teen died while waiting on an ambulance that was setting at the hospital with a patient inside because the hospitals were full and did not want to violate a government mandate of a 4 hour must treat law. Canada people coming here ... England people that have the money flying to India to have surgery ... don't worry, those rich liberal Harvard grads will be able to afford it while those they claim to want to help will be dying waiting for an ambulance ... that what socialism does, it ruins a country ... http://news.bbc.co.uk/1/hi/uk/7249514.stm ------------------------------ Date: Thu, 28 Feb 2008 05:28:29 -0800 (PST) From: ultradwc@gmail.com Subject: Re: OT: Universal healthcare in England failing - boy dies ! Message-ID: http://news.bbc.co.uk/1/hi/uk/7249514.stm http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2008/02/18/nhealth218.xml http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=515332&in_page_id=1770 http://www.hospitalhealthcare.com/default.asp?title=Claimsof%93patientstacking%94inUKambulances&page=article.display&article.id=8407 ------------------------------ Date: 28 Feb 2008 12:17:04 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Samba and text files Message-ID: <47c6a640$0$29460$607ed4bc@cv.net> In article <9cbb0b7a-474a-43aa-8318-b0ac092a1bd0@n77g2000hse.googlegroups.com>, AEF writes: >On Feb 27, 9:41 am, VAXman- @SendSpamHere.ORG wrote: >>{...snip...} >> Alan nailed this one! Can anyone say SAMBA? > >Thanks! (Working with an invisible cursor here. Maybe I should copy >this to Wordpad, but it will be short.) :) >> Now, I'll go back to corrupting files with vi by scrolling through them. > >Big laugh! Thanks. It wasn't for me! I locked users out of a site over the weekend because of this. I was looking through some web site code trying to find css classes of various items to change them for a slightly different page presentation. I opened one plugin services .php file for the site using 'view' (I believe this is equivalent to 'vi -R' {*} but Bill will correct me if I'm wrong) and started to scroll down through it. I quit and went to check the .css files after finding the class name. Shortly after I closed the file I received an email. A user put in username and password, and was told it was not valid. Not soon after that email, several more... {*} outputs the same "filename" [readonly] ###L, #####C message as vi -R I assumed that [readonly] means no write! I started looking about trying to figure out what happened. I'd even joined a forum (related to the particular web software in use) and posted a query there regarding the login issue. AFAIWC, I didn't change any files. Satur_DAY_ eroded into Saturday night and then into Sunday. Sunday, after I had a few hours sleep, I started looking more carefully. I followed the en- tire login line-by-line, scrutinizing everything. I finally happened upon a line in the file I was 'view'ing the day before. In it was a form tag with a name containing ..._login_username_... However, username was mis- spelled as usensname. I thought this weird. I didn't have a backup copy of the file (since I assumed I wasn't in a write mode when using view) and I did a quick grep... this usensname appeared nowhere else on the system. Then, I did another grep with .._login_username_... Lo and behold, this popped up in several locations. So, I made a copy of the plugin services file and then I edited ..._login_usensrname_... to read ..._login_username_... Logins were restored. I have Emacs on this box. I think I will avoid vi/vim/view and use it. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Thu, 28 Feb 2008 06:30:38 -0800 (PST) From: Pierre Subject: various MAKE tools for VMS Message-ID: <209589b0-2aa5-49b2-80bc-4f4604229c78@60g2000hsy.googlegroups.com> hi, on the freeware CD, there is 4 MAKE tools: make-aven, make-perry, make- mmk, make-gnu_3-60 does anyone knows if any of them can read/use makefile in unix syntax ? TIA Pierre ------------------------------ Date: Thu, 28 Feb 2008 08:43:51 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: various MAKE tools for VMS Message-ID: <08022808435097_206701FB@antinode.org> From: Pierre > on the freeware CD, there is 4 MAKE tools: make-aven, make-perry, make- > mmk, make-gnu_3-60 > > does anyone knows if any of them can read/use makefile in unix > syntax ? That may depend on what you mean. I don't use it on VMS, but I'd expect GNU "make" to act more like a UNIX "make" than, say, MMK. MMK, like MMS, needs more white space in some places than is typical in a UNIX "make" file, because ":" is different/special on VMS. For example, "target : source", instead of "target: source". Define "unix syntax". (I also know nothing about the other "make-xxx" programs in that collection.) Possibly relevant: http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1207552 (If you get lucky, and the ITRC forum is less messed up than usual.) ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Thu, 28 Feb 2008 10:04:08 -0500 From: "Richard B. Gilbert" Subject: Re: various MAKE tools for VMS Message-ID: <47C6CD68.1060901@comcast.net> Pierre wrote: > hi, > > on the freeware CD, there is 4 MAKE tools: make-aven, make-perry, make- > mmk, make-gnu_3-60 > > does anyone knows if any of them can read/use makefile in unix > syntax ? > How does "Unix" make syntax differ from "VMS" make syntax? And you forgot "GVG make" posted by Tony Ivanov at least fifteen years ago. I still have a copy, slightly cleaned up, enhanced, and a bug fixed, if anyone wants it. ------------------------------ Date: Thu, 28 Feb 2008 07:18:04 -0800 (PST) From: Pierre Subject: Re: various MAKE tools for VMS Message-ID: <94349469-a385-420d-a136-cf123f9382d2@64g2000hsw.googlegroups.com> > > on the freeware CD, there is 4 MAKE tools: make-aven, make-perry, make- > > mmk, make-gnu_3-60 > > > does anyone knows if any of them can read/use makefile in unix > > syntax ? > > That may depend on what you mean. [...] > Define "unix syntax". mainly, items in dependence list using space instead of comma as separator, backslash instead of dash as a continuation char. BTW, as I only need the actions to build a project from scratch, I don't want the make to perform the build but only to echo the actions without doing them (something like mms/noact) Pierre ------------------------------ Date: 28 Feb 2008 15:21:59 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: various MAKE tools for VMS Message-ID: <62o1smF2486ofU1@mid.individual.net> In article <47C6CD68.1060901@comcast.net>, "Richard B. Gilbert" writes: > Pierre wrote: >> hi, >> >> on the freeware CD, there is 4 MAKE tools: make-aven, make-perry, make- >> mmk, make-gnu_3-60 >> >> does anyone knows if any of them can read/use makefile in unix >> syntax ? >> > > How does "Unix" make syntax differ from "VMS" make syntax? Considering that I know of at least three different and incompatable "Unix" syntax for makefiles, I would imagine that is a major question. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Thu, 28 Feb 2008 11:16:48 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: various MAKE tools for VMS Message-ID: <08022811164852_206701FB@antinode.org> From: Pierre > > Define "unix syntax". > > mainly, items in dependence list using space instead of comma as > separator, backslash instead of dash as a continuation char. You mean like this? [.$(DEST)]ZIPCLOAK.EXE : [.$(DEST)]ZIPCLOAK.OBJ \ $(LIB_ZIPUTILS) \ $(OPT_ID) $(OPT_FILE) $(LINK) $(LINKFLAGS) $(MMS$SOURCE), - $(LIB_ZIPUTILS) /include = (GLOBALS) /library, - $(LFLAGS_ARCH) - $(OPT_ID) /options (I tend to use "\" in the dependencies, and "-" in the (DCL) action lines, but I may be eccentric.) You may be trying to solve problems which do not exist in MMS/MMK. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ End of INFO-VAX 2008.118 ************************