INFO-VAX Tue, 11 Mar 2008 Volume 2008 : Issue 141 Contents: Re: DHCP Server question/problem Re: DLT-4 cassetes are slower than DLT-3 on the same drive? Re: How do I get rid of LINK-W-MULTFR errors? Re: How do I get rid of LINK-W-MULTFR errors? Re: Noob File-Transfer (License to .com) Question Re: Proof that macintosh is better than VMS Re: Proof that macintosh is better than VMS Re: Proof that macintosh is better than VMS Re: Proof that macintosh is better than VMS Re: Proof that macintosh is better than VMS Re: Proof that macintosh is better than VMS Re: SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM bug on VAX Re: TCPIP$ROUTED_OUTPUT.LOG or log file maintenance! Re: TCPIP$ROUTED_OUTPUT.LOG or log file maintenance! Re: Updated GNV kits available Re: Updated GNV kits available Re: Updated GNV kits available ---------------------------------------------------------------------- Date: Mon, 10 Mar 2008 15:45:59 -0400 From: JF Mezei Subject: Re: DHCP Server question/problem Message-ID: <47d5908c$0$1443$c3e8da3@news.astraweb.com> Peter Weaver wrote: > Finally I gave up on fixing the Alpha and decided to let my router do the > DHCP serving, so I enabled the DHCP serving and rebooted the router. As the > router was rebooting the two devices both received their DHCP information > from the Alpha. So something in my router decided to block the DHCP > response. DHCP is a LAN level protocol. It was not originally designed to be routable. Extensions have later permitted routers to pass DHCP requests and responses across a router. In my case, the Mac receives the DHCP response and gets an IP, But it doesn't receive or process any additional information such as the default route (gateway router) or the list of DNS servers available. ------------------------------ Date: 10 Mar 2008 15:50:30 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DLT-4 cassetes are slower than DLT-3 on the same drive? Message-ID: In article <2008Mar10.163057@hujicc>, yehavi@vms.huji.ac.il writes: > Hello, > > We have DLT-40/80 tape drives connected to Alpha systems running VMS-8.3; > up to recently we have been using DLT-3 cassetes and now moved to DLT-4. We > noticed that backups take much more time (2 times and more) with the new tapes > compared to the old ones. This happens when we use the same density or use the > higher densities of DLT-4. > > Anyone has an idea what to look for? A different block size? Someone who understands tapes? ------------------------------ Date: 10 Mar 2008 15:48:49 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: How do I get rid of LINK-W-MULTFR errors? Message-ID: In article , "Ade" writes: > > void main() This is is main entry point of your C code, which looks like you want it to be the main entry program for your entire program; so far so good. > .entry nat_lib_crc,^m<> This is the entry point of a Macro-32 routine with the wrong register save mask. You are using R0 through R6 in your code and when it returns to the calling routine that routine will act wrongly. Use: .entry nat_lib_crc,^m > .end nat_lib_crc This is the end of a Macro-32 routine and a declaration to the linker that the routine NAT_LIB_CRC is the main entry point for the whole program, which conflicts with what you appear to want. Use: .end And thank you for learning Macro-32. (Figuring out why the register save mask was wrong and why the new mask is right is left as an important exercise to the student.) ------------------------------ Date: Mon, 10 Mar 2008 20:33:42 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: How do I get rid of LINK-W-MULTFR errors? Message-ID: <47d5d35e$0$90274$14726298@news.sunsite.dk> Ade wrote: > void main() Other has already explained the problem you have. I will just add that you should make main return int and not void. Arne ------------------------------ Date: 10 Mar 2008 19:58:33 -0600 From: BEGINcornelius@decuserve.orgEND (George Cornelius) Subject: Re: Noob File-Transfer (License to .com) Question Message-ID: In article <1qAGnPIs+L$W@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > Getting a DOS format file or a UNIX format file to read corretly from > an ISO CD may depend on the proper use of /undefined_fat on the mount > command: > > For the DOS file: > > $ mount/media_format=cdrom/undefined_fat=stream_cr device: label > > For the UNIX file: > > $ mount/media_format=cdrom/undefined_fat=stream device: label Don't you mean the following instead? Text Using Using File type /UNDEFINED_FAT $ SET FILE/ATTRIB=RFM:x DOS file (CR/LF terminator) stream stm Macintosh (CR terminator) stream_cr stmcr Unix/Linux (LF terminator) stream_lf stmlf I often mount with /UNDEF=FIXED:CR:512 and use $ SET FILE/ATTRIBUTES after moving it to VMS, given the combinations of record terminators that are possible. Assuming, of course, that file length is correct and not automatically converted to a multiple of 512 by the 'FIXED:...' specification. [Just tried it with a firmware CD, which apparently uses CR/LF terminators, and it works ok after $ SET FILE/ATTRIB=RFM:STM ] -- George Cornelius cornelius A T eisner D O T decus D O T org cornelius A T mayo D O T edu ------------------------------ Date: Mon, 10 Mar 2008 11:45:54 -0700 (PDT) From: AEF Subject: Re: Proof that macintosh is better than VMS Message-ID: <0d13393f-9e0d-4ed9-bb61-7e66e1aff485@n77g2000hse.googlegroups.com> On Mar 10, 9:41 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > In article <20e1fe5e-5c4d-480c-bab5-f679364d5...@x30g2000hsd.googlegroups.com>, > AEF writes: > > > On Mar 10, 8:18 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > > >> Unless you have studied statistics. Then you know the futility of either > >> approach. (Hint: I took a stat class last summer. The Prof actually > >> had the students look at the various lottery games in PA. A bonus was > >> offered for any student who found the one with the wrong published odds. > >> I was the only one in the class at the start who had any understanding > >> at all of how really poor your chances of winning are. Most of the > >> students actually thought it was tilteed int he players favor!!) > > > You lost me here, Bill. You're saying that most of the students are, > > well, mentally challenged. So? > > I said no such thing. What I said is that until they took a stat course > the average student believes what everyone else believes, which is that > your chance of winning is better than a snowballs chance in hell. > > I actually knew an IT professional in NY who had all the numbers ever > drawn in the NY State Lottery and each week he added the current set > and re-ran his program (on a Univac-1100 mainframe) determined to find > a pattern and thus be able to predict winning numbers. That was 28 > years ago. I amn sure he is retired by now but probably still running > his program (on a PC now) looking for that magic pattern. > > Truly a tax on the stupid. I never said, or meant, otherwise. Except that those who have win a jackpots might take exception! (Not that they won through acts of brilliance, mind you.) But yes, in general, it's a very bad deal. > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > billg...@cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include ------------------------------ Date: Mon, 10 Mar 2008 15:42:49 -0400 From: JF Mezei Subject: Re: Proof that macintosh is better than VMS Message-ID: <47d58fcf$0$1443$c3e8da3@news.astraweb.com> Bill Gunshannon wrote: > There is nothing random in a computer and some of us > seriously doubt there is any true randomness in the universe. I agree with this. However, when you bring the word "random" back to human scale, there is still plenty of stuff that appears "random" to humans because we cannot predict it. To a layman, the first signal light he will encounter after exiting a highway will be "random" between read green or yellow, even though the light operates on a predictable schedule. A lottery remain random as long as humans are unable to predict it even if in theory, it is predictable. Eisenberg states that the act of looking at something disrupts it. But if studio lights are already shining on the lottery machine with the balls in it, having an extra camera with high precision lens some distance from the machine won't affect the outcome and you might be able to follow the movement of balls and predict which one is next to come out. Whether the photons emitted by the balls and machine are absorbed by a camera or clothing of an audience menber doesn't make much of a difference to the balls in the machine. However, prior to the draw, even if you knew the full configuration of the machine, balls and aerodynamic properties of the chamber and the fan blowing in it, you cannot predict the exact position of the rotating chamber at time of start, the exact time difference between start of rotation and the moment they drop the balls into the chamber, and the exact moment when some human pushes a button to get a ball to come out. So even if physics, aerodynamics and others sciences can explain the movement of balls in the machine, no human has sufficient information to have all the variables and thus, the outcome is random at the human level. ------------------------------ Date: Mon, 10 Mar 2008 15:48:24 -0700 (PDT) From: AEF Subject: Re: Proof that macintosh is better than VMS Message-ID: <7aac9134-1712-47d8-8cf7-63fdfe11c589@e60g2000hsh.googlegroups.com> On Mar 10, 9:26 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > In article <47D542AA.5050...@comcast.net>, > "Richard B. Gilbert" writes: > > > > > JF Mezei wrote: > >> Bill Gunshannon wrote: > > >>>Random numbers are a theoretical mathematical concept and nothing can > >>>"generate" numbers that are truly random. > > >> In a situation where a human needs to press a key (or click mouse) to > >> initiate generation of numbers, then if you use VMS time as a seed, it > >> would be pretty random since the human's interpretation of time is way > >> less precise than what VMS does, and as a result, the lowest bytes in > >> the VMS time would be randomly selected since there would be no way for > >> a human to press a key at the moment he would want all those nanoseconds > >> to be a specific value. > > >> But if you have a job that automatically generates a random number at > >> 20:00:00 every friday, I would agree that there would not be much > >> randomness in any seed you would use. > > > There's damned little randomness to be found there!! Remember that the > > clock is updated every ten milliseconds by adding 10,000,000 (forgive me > > if I've lost a decimal point somewhere) nanoseconds to the counter! > > And, all of these schemes ignore the fact that if you start with the > same seed they repeat the same sequence. Hardly seems random when > the numbers are generated by a fixed and predictable mathematical > formula. There is nothing random in a computer and some of us > seriously doubt there is any true randomness in the universe. (Hint: > just because you don't see the pattern or can't determine all of the > root causes doesn't mean it's random.) > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > billg...@cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include There's random, and then there's random. :-) What I mean is this: Is the process random enough for the purposes of the application? Pseudo-random numbers are very useful for certain purposes. I used FORTRAN's random function to generate some pseudo- data to test a program I was working on in physics. It worked fine. Such functions are also useful for the lottery quick pick. Some applications require higher quality random number sequences. In fact, back in the early 90's some mathematicians (or physicists) found some surprise correlated triplets for certain cases involved in Monte Carlo simulations (that's the physics term for it -- see the Wikipedia article) and for some purposes that would be a bad thing. Shuffling a deck of cards is a good example here. Are you going to tell me that shuffling is not random enough to play cards? And if you knew the initial positions and velocities of a set of dice, you could in principle predict the outcome. But dice are random enough for board games and the like, no? As for "true randomness", yes, many have questioned the validity of QM for that. Even Einstein, so you're in good company. But it flies in the face of increasingly compelling evidence to the contrary, that quantum processes are truly random except that the probability each of the possible outcomes is given by the wave function which is calculable via the equations of QM. I venture to guess even Einstein would have been convinced had he lived long enough to see today. Please read Chapter 6 of The Character of Physical Law by Feynman (a Nobel prize winner for his work on QED) and get back to me. I find Feynman's argument very compelling. No, it's not absolute proof. You never get that in science (though would you doubt the reality of atoms?). But trust me, it looks really, really bad for causality. AEF ------------------------------ Date: Mon, 10 Mar 2008 16:58:11 -0700 (PDT) From: AEF Subject: Re: Proof that macintosh is better than VMS Message-ID: On Mar 10, 1:56 pm, JF Mezei wrote: > Bill Gunshannon wrote: > > I actually knew an IT professional in NY who had all the numbers ever > > drawn in the NY State Lottery and each week he added the current set > > and re-ran his program (on a Univac-1100 mainframe) determined to find > > a pattern and thus be able to predict winning numbers. > > A couple years ago, there was some guy in montreal who used a computer > to determine patterns at some game at the montreal casino. Turns out > there was a pattern and he was able to win big. I don't recall the > specifics though, but that game was repaired to remove that pattern. Intersting. > > > Truly a tax on the stupid. > > Winning the big jackpot require faith... (aka: odds approach zero). But > the odds of winning a free ticket or $10 are far more realistic. No, not faith. Winning the big jackpot requires picking the winning numbers! good luck. Yes, that's it: It's a matter of luck! > > When you send money as tax to the government, you have no odds of > getting it back. When you buy a lottery ticket, you have some odds of > getting it back (and some almost zero odd of winning big). > > Now, if they made lottery tickets tax deductible (since it is tax you > are paying to the government), then it would become a smart tax payment > system. YOu could end up paying all your income tax via lottery tickets > which would give you more reasonable odds of winning part or all of that > money back. I think you mean to make the lottery tickets count as a tax credit. No, this wouldn't work because you'd have to double the tax rates. Think about it. AEF ------------------------------ Date: Mon, 10 Mar 2008 20:26:00 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Proof that macintosh is better than VMS Message-ID: <47d5d18f$0$90274$14726298@news.sunsite.dk> Bob Koehler wrote: > In article <47d407a5$0$90274$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >> Certain physics stuff are considered true random. Including >> radioactivity I believe. Around 1900 the world was considered >> deterministic, but then came Einstein, Heissenberg and all those >> guys and suddenly the world was random (and impossible >> to understand). > > Plank. Max Planck ? Arne ------------------------------ Date: Mon, 10 Mar 2008 18:52:34 -0700 (PDT) From: AEF Subject: Re: Proof that macintosh is better than VMS Message-ID: <1efbdc12-6725-4fce-88f0-0846e7c0b4ff@59g2000hsb.googlegroups.com> On Mar 10, 7:26 pm, Arne Vajh=F8j wrote: > Bob Koehler wrote: > > In article <47d407a5$0$90274$14726...@news.sunsite.dk>, =3D?ISO-8859-1?Q= ?Arne_Vajh=3DF8j?=3D writes: > >> Certain physics stuff are considered true random. Including > >> radioactivity I believe. Around 1900 the world was considered > >> deterministic, but then came Einstein, Heissenberg and all those > >> guys and suddenly the world was random (and impossible > >> to understand). > > > Plank. > > Max Planck ? > > Arne Oui. It was he who started it all. He was trying to find a theory to explain the spectral distribution of black body radiation as a function of temperature. There were two theories at the time: one worked at small wavelengths and the other worked at large. He found an ingenious interpolation between the two but it depended on a parameter h (Planck's constant) that had a finite value that could be fitted to the data. Within two months Planck found that he could derive the formula by assuming that light only comes in packets of energy equal to the frequency of the light times this constant. But this implied that light comes in discrete bundles of energy. But everyone "knew" that light was a wave. This was an extremely radical idea for the time. Planck argued that for some unknown reason the light was emitted and absorbed in quanta. (I think I read somewhere that he resisted this and considered h to be only a useful trick to get the right equation and that for some reason.) Einstein boldly said that these quanta of light were real (they are known as photons) and used the idea of photons to explain the photoelectric effect which cannot be explained at all by classical physics. Later, the Compton effect became the most direct evidence for the particle nature of radiation. In the Compton effect, a photon scatters off of an electron in an atom and the energy loss of the photon is calculated assuming it is a simple billiard ball collision. When the energy loss is plugged into the E =3D h*frequency equation, you get a lower frequency since the energy is lower. This lower frequency corresponds to a longer wavelength and this is in fact observed when gamma rays are scattered by matter. There was then no doubt that radiation or light (and when a physicist says light, he means electromagnetic radiation of any frequency all the way from radio waves to gamma rays) has a particle nature. Bohr called these dual properties of light "complementarity". It turns out that matter also exhibits this duality. Enough physics for now. AEF ------------------------------ Date: Mon, 10 Mar 2008 22:06:57 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM bug on VAX Message-ID: <47d5e939$0$90264$14726298@news.sunsite.dk> Brendan Welch wrote: > I have been out of VMS for many years, but I remember that making a > radical change > ( a whole hour, especially if subtracting, in the Fall) could cause big > problems. > You first had to shut down some monitoring utilities, so as not to cause > discontinuities. Years ago (V5.x and earlier I believe) VMS used localtime internally. So it was either app down, set time and app up - or use the Macro-32 hack that either did 4 hours in 3 hours or 3 hours in 4 hours. Arne ------------------------------ Date: Mon, 10 Mar 2008 12:17:28 -0700 (PDT) From: Hein RMS van den Heuvel Subject: Re: TCPIP$ROUTED_OUTPUT.LOG or log file maintenance! Message-ID: On Mar 10, 1:02=A0pm, "pcovie...@gmail.com" wrote: > Hi, we have a similar issue with another post with the same subject > but there was no replies to his post, I thought I tacked on to that > one and emailed him instead :-) sorry! > > any ways I have an 8.2 system with a log file at about 1 GB and a > cluster running 7.3-2 that each node is around 1.5 GB so what do > others do to clean this up? =A0and reboot should not be an option :-) > > thanks > Paul %COV-W-CROSSPOSTING, non-disclosed cross posting in other forum detected. http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=3D1211= 483 Hein. ------------------------------ Date: Mon, 10 Mar 2008 13:04:40 -0700 (PDT) From: "pcoviello@gmail.com" Subject: Re: TCPIP$ROUTED_OUTPUT.LOG or log file maintenance! Message-ID: On Mar 10, 3:17=A0pm, Hein RMS van den Heuvel wrote: > On Mar 10, 1:02=A0pm, "pcovie...@gmail.com" wrote: > > > Hi, we have a similar issue with another post with the same subject > > but there was no replies to his post, I thought I tacked on to that > > one and emailed him instead :-) sorry! > > > any ways I have an 8.2 system with a log file at about 1 GB and a > > cluster running 7.3-2 that each node is around 1.5 GB so what do > > others do to clean this up? =A0and reboot should not be an option :-) > > > thanks > > Paul > > %COV-W-CROSSPOSTING, non-disclosed cross posting in other forum > detected.http://forums12.itrc.hp.com/service/forums/questionanswer.do?thre= adId... > > Hein. oops sorry thought the audience in here was a little wider than the ITRC! ------------------------------ Date: 10 Mar 2008 20:50:43 +0100 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: Updated GNV kits available Message-ID: <47d59f23$1@news.langstoeger.at> In article <47D46FD4.2020401@comcast.net>, bradhamilton writes: >I had a few hours this afternoon to fool around with the installation; I >got a successful installation only after making sure that GNV and >PSX$ROOT pointed to different disks. The PCSI instructions provided >during the install were less than clear on this particular point. I had no problems installing GNV on the system disk: A conventional location for the POSIX root is SYS$SYSDEVICE:[PSX$ROOT] but you may choose another location if you prefer. You MUST NOT choose a location which is has the PCSI Destination of GNV ( DISK$VMSSYS:[VMS$COMMON.] ) as a subdirectory, as this would cause a loop in the directory structure. Please provide a directory on an ODS-5 disk, below: Where do you want the system root ("/")? [ SYS$SYSDEVICE:[PSX$ROOT] ]: %CREATE-I-EXISTS, SYS$SYSDEVICE:[PSX$ROOT] already exists The following may be needed in a mixed architecture cluster Do you want to create an architecture specific root? [No]: y >I did notice the problem posted above by Peter; a one-line >addition/comment to GNV$STARTUP.COM fixed that problem, as well as >renaming sys$startup:psx$configAlpha.dat to sys$startup:psx$config.dat. Yup, that is easy, but what was intended by this code? >Folks, this software is not ready for any kind of serious production >environment (not yet, anyway). IMHO. It's running; (after a fashion) >now I'm going to look into mounting disks in this environment (shudder!). At least, it now makes no longer the endless loop by entering the (system) disk root dir as a subdir into PSX$ROOT:[MNT.disklabel] without a way to prevent this... -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Mon, 10 Mar 2008 19:15:01 -0400 From: John Reagan Subject: Re: Updated GNV kits available Message-ID: >>Folks, this software is not ready for any kind of serious production >>environment (not yet, anyway). IMHO. It's running; (after a fashion) >>now I'm going to look into mounting disks in this environment (shudder!). > The GNV developer told me that a pre-release version was accidently loaded to the website. He fixed this particular bug for the final kit, but it wasn't loaded to the website. He has asked for the website to be fixed. -- John Reagan OpenVMS Pascal/Macro-32/COBOL Project Leader Hewlett-Packard Company ------------------------------ Date: Mon, 10 Mar 2008 19:31:52 -0400 From: bradhamilton Subject: Re: Updated GNV kits available Message-ID: <47D5C4E8.4090502@comcast.net> Peter 'EPLAN' LANGSTOeGER wrote: > In article <47D46FD4.2020401@comcast.net>, bradhamilton writes: >> I had a few hours this afternoon to fool around with the installation; I >> got a successful installation only after making sure that GNV and >> PSX$ROOT pointed to different disks. The PCSI instructions provided >> during the install were less than clear on this particular point. > > I had no problems installing GNV on the system disk: True, but I do not wish to install on the system disk; if something bad happens, then I have to restore my system disk from backup - not a pleasant way to spend my free time. > A conventional location for the POSIX root is SYS$SYSDEVICE:[PSX$ROOT] > but you may choose another location if you prefer. > > You MUST NOT choose a location which is has the PCSI Destination of GNV > ( DISK$VMSSYS:[VMS$COMMON.] ) > as a subdirectory, as this would cause a loop in the directory structure. ..and this is the wording that I find so awkward and hard to understand - I thought at first that they were warning me away from putting POSIX root on the same device as GNV. I guess an easier way to warn off folks would have been, "Don't install POSIX root and GNV in the same directory tree!" It looks as though it's possible to put both structures on the system disk, but why? Death wish?? :-) Stay away from the system disk and its rooted-logical directory structures, and you're already ahead of the game... [...] >> I did notice the problem posted above by Peter; a one-line >> addition/comment to GNV$STARTUP.COM fixed that problem, as well as >> renaming sys$startup:psx$configAlpha.dat to sys$startup:psx$config.dat. > > Yup, that is easy, but what was intended by this code? Apparently to distinguish between Alpha and IA64 HW environments; why is beyond me. Again, more complication than needs to be present... >> Folks, this software is not ready for any kind of serious production >> environment (not yet, anyway). IMHO. It's running; (after a fashion) >> now I'm going to look into mounting disks in this environment (shudder!). I realize my comment above is somewhat ironic, given that GNV is intended as a development "tool", but this tool acts more like a hammer to the top of the head. > At least, it now makes no longer the endless loop by entering the (system) > disk root dir as a subdir into PSX$ROOT:[MNT.disklabel] without a way > to prevent this... Probably true, but I had enough "fun" for one weekend; time to relax and take up tobacco-smoking again. :-) ------------------------------ End of INFO-VAX 2008.141 ************************