INFO-VAX Fri, 21 Mar 2008 Volume 2008 : Issue 161 Contents: Re: Can't get into SRM on PWS 433au Re: Can't get into SRM on PWS 433au Re: Decserver 200 - Not getting its image loaded Re: Decserver 200 - Not getting its image loaded Re: Divining the full pathname of a file, all logicals translated Re: Divining the full pathname of a file, all logicals translated Re: MediaWiki on VMS Re: OT: RIP Arthur C. Clarke Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Please critique my backup practices Re: Proof that macintosh is better than VMS Re: Proof that macintosh is better than VMS Re: So you think God and the devil are not real? Too many files in one directory (again) Re: Too many files in one directory (again) Re: VMS Mail translates incoming tilde character into a dollar sign. Re: VMS Mail translates incoming tilde character into a dollar sign. Re: VMS Mail translates incoming tilde character into a dollar sign. ---------------------------------------------------------------------- Date: Fri, 21 Mar 2008 01:33:18 GMT From: John Santos Subject: Re: Can't get into SRM on PWS 433au Message-ID: Bob Koehler wrote: > In article , John Santos writes: > >>Label from 0, count from 1, no matter what base you are using. >> >>Type 0 - Don't understand binary, 01 types >>Type 1 - Do understand binary, 10 types. >> > > > We're not all !@#$%^&*() C programmers here. Counting starts at 1, > if you actually have any. > Hey, watch it bud! I'm no stinking C programmer. Macro-11. Real programmers program in octal. (OK, Macro-32 kind of forces you to use hex, And counting starts a 0, so you don't have to special-case when there aren't any. Do FORTRAN arrays start at 1? It's been about 33 years, brain cells have died :-( -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Thu, 20 Mar 2008 22:31:31 -0400 From: "Richard B. Gilbert" Subject: Re: Can't get into SRM on PWS 433au Message-ID: <47E31E03.6010708@comcast.net> John Santos wrote: > Bob Koehler wrote: > >> In article , John Santos >> writes: >> >>> Label from 0, count from 1, no matter what base you are using. >>> >>> Type 0 - Don't understand binary, 01 types >>> Type 1 - Do understand binary, 10 types. >>> >> >> >> We're not all !@#$%^&*() C programmers here. Counting starts at 1, >> if you actually have any. >> > Hey, watch it bud! I'm no stinking C programmer. Macro-11. Real > programmers program in octal. (OK, Macro-32 kind of forces you to > use hex, And counting starts a 0, so you don't have to special-case > when there aren't any. Do FORTRAN arrays start at 1? It's been about > 33 years, brain cells have died :-( > Many years ago, Fortran II and Fortran IV arrays did start at 1. I think that Fortran acquired the ability to use 0 or negative subscripts somewhere along the way. I don't recall using them very much; old habits die hard and mine go back to Fortran II! And real programmers program in absolute binary! Remember when you could, and sometimes had to, load a bootstrap program through the front panel switches? I think some models of the PDP-8 made you do that. Remember that ROM and PROM came much later! ------------------------------ Date: Thu, 20 Mar 2008 18:41:36 -0700 (PDT) From: Verne Subject: Re: Decserver 200 - Not getting its image loaded Message-ID: <1c3e1722-ab2e-4bdb-907a-1aa3614d5dcd@n75g2000hsh.googlegroups.com> On Mar 20, 8:55=A0am, Jan-Erik S=F6derholm wrote: > > In article , geoffrey....@eskom.co.za writes: > >> It's defnantly a Decserver 200, I have 3 VAX machines running decnet 4 > >> and all 3 are configured to download to the Decservers. > >> Thanks > >> Geoff > > Maybe. But here on c.o.v it's not enought to just *say* so. > *Show us* that it's actualy the case. Hard proof (output) > from NCP commands is what counts. > > Jan-Erik. I am out of town and cannot check this myself, but if memory serves, some terminal servers can have a load image filename saved in the NVRAM, and when it boots, it asks for that specific image. If any VMS machine set up to respond (MCR NCP SET/DEFINE CIR ENABLE, etc) to MOP boot requests has that image in MOM$LOAD (or whatever the other logical is for storing load images, MOM$SYSTEM ??), the VMS machine will serve up the file. All this occurs *I THINK* without ever defining the specific DECserver in NCP :-) Obviously NCP has to know about it if you want to do MCR NCP CONNECT NODE xxxx Verne ------------------------------ Date: Thu, 20 Mar 2008 23:38:24 -0400 From: JF Mezei Subject: Re: Decserver 200 - Not getting its image loaded Message-ID: <47e32ddf$0$3849$c3e8da3@news.astraweb.com> Verne wrote: > I am out of town and cannot check this myself, but if memory serves, > some terminal > servers can have a load image filename saved in the NVRAM, and when it > boots, The DECserver 200 predates the invention of NVRAM :-). The load file is configured in the NCP database. look for a file DSVCONFIG.COM on your system disk. You should also have a file such as PR0801ENG.SYS on your system (this is the load file). I have the DS2033 kit if you are missing those files. (circa 1995, not sure if there have been updates since then). ------------------------------ Date: Thu, 20 Mar 2008 11:18:46 -0700 (PDT) From: Rich Jordan Subject: Re: Divining the full pathname of a file, all logicals translated Message-ID: On Mar 20, 11:26 am, "Peter Weaver" wrote: > >... > > One other alternative seems to be to use one of the FID to > > NAME programs; since I can locate the file in question I have > > its FID and can run it through a program (seen online here in > > COV, also perhaps on > > freeware) and get the full raw pathname back. That would be > > acceptable too but if anyone's done it and has > > recommendations I'd appreciate hearing back. It would mean > > many thousands of image activations running the FID to Name > program. > >... > > If you are running a newer version of VMS then there is the > F$FID_TO_NAME lexical; > > Lexicals > > F$FID_TO_NAME > > Valid for Alpha and I64 systems only. > > Translates a file identification to a file specification. > > Format > > F$FID_TO_NAME(device-name,file-id) > > Additional information available: > > Return_Value Arguments Example > > Lexicals F$FID_TO_NAME Subtopic? exa > > LEXICALS > > F$FID_TO_NAME > > Example > > $ WRITE SYS$OUTPUT > F$FID_TO_NAME("SYS$SYSDEVICE","(2901,33,0)") > DISK$NODE1:[VMS$COMMON.SYSEXE]SHOW.EXE;1 > > This example demonstrates that the file with > identifier > "2901,33,0" on the system disk is file SHOW.EXE. Note: > You > can omit the parentheses around the file identifier, > provided > it is enclosed by double quotation marks. > > Lexicals F$FID_TO_NAME Subtopic? Peter, unfortunately the system in question is not current and the VMS versions installed does not support that lexical. ------------------------------ Date: Thu, 20 Mar 2008 16:16:27 -0700 (PDT) From: AEF Subject: Re: Divining the full pathname of a file, all logicals translated Message-ID: <68a1d01a-bb04-4879-b2b4-91ae07a64e6f@m36g2000hse.googlegroups.com> On Mar 19, 5:41 pm, Rich Jordan wrote: > I'm looking at ways to generate the full "low level" pathname to a > file with no logicals, concealed, terminal, or otherwise involved, and > in standard format. > > So far the way that seems to work closest to what I need using only > VMS provided tools follows. THis is (currently) a DCL command > procedure searching multiple directories (using F$SEARCH with a > wildcard, and generally with a logical in the search term): > > - F$SEARCH returns the filename. > - The return from F$SEARCH will already have translated non- > terminal logicals; for example in the SYSTEM account searching for SYS > $LOGIN:LOGIN.COM returns SYS$COMMON:[SYSMGR]LOGIN.COM;12 > > - Take the output of F$SEARCH and feed it to F$PARSE with > argument "NO_CONCEAL" as the parse type. > > This returns: > > NODE$DKA0:[SYS0.SYSCOMMON.][SYSMGR]LOGIN.COM;12 > > Thats workable but I really need it to be normalized as > > NODE$DKA0:[SYS0.SYSCOMMON.SYSMGR]LOGIN.COM;12 Why, pray tell? If you *really* need it this way, just subtract all possible combinations of square and angle brackets. (I think that's pretty safe, but unanticipated situations and upgrades can break manual parsing in general.) I assume you're writing about files on an ODS-2 volume, right? You might get into trouble doing this on an ODS-5 volume, but I'm not sure. > > I can put in conditional code to clean up the f$parse output but I'd > rather find a way to have the clean pathname returned. Is there a way > to do this using normal lexical functions? > > ===== > > One other alternative seems to be to use one of the FID to NAME > programs; since I can locate the file in question I have its FID and > can run it through a program (seen online here in COV, also perhaps on > freeware) and get the full raw pathname back. That would be > acceptable too but if anyone's done it and has recommendations I'd > appreciate hearing back. It would mean many thousands of image > activations running the FID to Name program. Peter Weaver answered this. But why is it so important to remove the "] ["? AEF > > Thanks for any thoughts. Yes I checked the FAQ first but didn't see > anything that appeared relevant. > > Rich > CCS ------------------------------ Date: Thu, 20 Mar 2008 18:48:01 +0100 From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne?= Subject: Re: MediaWiki on VMS Message-ID: <47e2a359$0$9597$426a74cc@news.free.fr> healyzh@aracnet.com wrote: > issinoho wrote: >> I managed to get MediaWiki running on OpenVMS but it wasn't without >> problems. I know there was at least one enquiry about this in the past >> so I have documented the process here, >> http://vamp.issinoho.com/viewforum.php?f=19 > >> Hope this helps a few people. > > Very cool, I'll try to find time to take another look at this. I got > stalled on this about a year ago. As you note, we really need PHP5. At the > time I opted for PmWiki, which works pretty good on VMS. > Just to mention that MoinMoin also work on OpenVMS (for 1 or 2 years) and is include in the Python LD image. It doesn't need any database and can run as a standalone server or with WASD. Latest port include the XAPIAN search engine which allow fast search in the wiki. Some OpenVMS sites running it: http://vmspython.dyndns.org/ http://vmsmysql.dyndns.org/ http://www.kednos.com/ ... JFP ------------------------------ Date: Thu, 20 Mar 2008 16:33:31 -0700 (PDT) From: Neil Rieck Subject: Re: OT: RIP Arthur C. Clarke Message-ID: On Mar 18, 8:28=A0pm, JF Mezei wrote: > Mr VAXman said: > > > Subject says it all. > > He was 90 and died in Sri Lanka. > > http://news.bbc.co.uk/2/hi/uk_news/7304004.stm Clarke who died at the age of 90 on Wednesday had left written instructions that no religious rites of any faith should be associated with his funeral. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: Thu, 20 Mar 2008 18:36:56 +0000 (UTC) From: Dale Dellutri Subject: Re: Please critique my backup practices Message-ID: On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar wrote: > To do a backup, I pop a drive out of a shadowset, back it up and put > it back. I assume you're talking about VMS Volume Shadowing. As far as I know, taking a drive out of a shadowset causes the drive to look the same as if there'd been a power failure. In other words, it does not properly close open files. I assume that you take image backups. If so, there's no benefit to taking the drive out of the shadowset to take the image backup. According to service techs that I talked to when I first set up volume shadowing, there's no advantage over taking an image backup of the volume set (the DSA device). I assume that this is still true. > The problem is, I don't record the backup dates. You could record backup dates if you simply took an image backup of the volume set. > I have a incremental that runs every night that does record backup > dates. > If I had to restore, I would apply the last image and all the > incrementals after it. But I guess I would get some extra files. > This is easy, I never have to shutdown, but what are the gotchas? > Note that if I am *planning* to do a restore I don't use incrementals, > I just use a fresh image backup. > I have never had to do an emergency image restore using incrementals. I'm not an expert, so what I've said above may be wrong. You should check this backup scheme with the service techs (I assume you have a support contract). -- Dale Dellutri (lose the Q's) ------------------------------ Date: Thu, 20 Mar 2008 12:36:19 -0700 (PDT) From: tadamsmar Subject: Re: Please critique my backup practices Message-ID: On Mar 20, 2:36=A0pm, Dale Dellutri wrote: > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar = wrote: > > To do a backup, I pop a drive out of a shadowset, back it up and put > > it back. > > I assume you're talking about VMS Volume Shadowing. =A0As far as I know, > taking a drive out of a shadowset causes the drive to look the same as > if there'd been a power failure. =A0In other words, it does not properly > close open files. > > I assume that you take image backups. =A0If so, there's no benefit to > taking the drive out of the shadowset to take the image backup. > According to service techs that I talked to when I first set up > volume shadowing, there's no advantage over taking an image backup > of the volume set (the DSA device). > > I assume that this is still true. > > > The problem is, I don't record the backup dates. > > You could record backup dates if you simply took an image backup > of the volume set. Don't I have to shutdown my system to do that? > > > I have a incremental that runs every night that does record backup > > dates. > > If I had to restore, I would apply the last image and all the > > incrementals after it. =A0But I guess I would get some extra files. > > This is easy, I never have to shutdown, but what are the gotchas? > > Note that if I am *planning* to do a restore I don't use incrementals, > > I just use a fresh image backup. > > I have never had to do an emergency image restore using incrementals. > > I'm not an expert, so what I've said above may be wrong. =A0You should > check this backup scheme with the service techs (I assume you have > a support contract). > > -- > Dale Dellutri (lose the Q's) ------------------------------ Date: Thu, 20 Mar 2008 20:06:30 -0000 From: "John Wallace" Subject: Re: Please critique my backup practices Message-ID: <13u5gub59gtbmca@corp.supernews.com> "tadamsmar" wrote in message news:26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com... > To do a backup, I pop a drive out of a shadowset, back it up and put > it back. > > The problem is, I don't record the backup dates. > > I have a incremental that runs every night that does record backup > dates. > > If I had to restore, I would apply the last image and all the > incrementals after it. But I guess I would get some extra files. > > This is easy, I never have to shutdown, but what are the gotchas? > > Note that if I am *planning* to do a restore I don't use incrementals, > I just use a fresh image backup. > > I have never had to do an emergency image restore using incrementals. Give the community some more background and you may get better answers. Relevant practices may vary depending on what you're backing up (a system disk, a generic data disk with various files on it, a "pure database" disk with nothing on it except the database itself in which case it may have its own backup tools...). E.g. when I cared about backups, in a software development environment, it was always a goal to have files on at least two sets of media (even files which may only have existed for a couple of days), so that if there was a problem and one set of media wasn't usable for whatever reason, the relevant files would still be recoverable from another set. This was done by abandoning the usual "incremental" or "differential" schemes and doing a weekly full backup and a daily backup with files created in the previous two (or do I mean three) days, so each new file would go on the following day's daily backup, AND the daily one after that. Others might have a "version management" tool in place to achieve the same end result, which might have changed the backup requirement. One backup strategy does not necessarily fit all, not comfortably anyway. Usually the only time you need completely shut down VMS for doing a backup is if you want a clean image backup of your system disk - always assuming that any applications you may have active can be persuaded to close any files they may have opened, without shutting VMS down. For example, BASEstar (which you have previously mentioned) sometimes has lots of global section files, which should disappear (or at least close cleanly) when you shut down BASEstar. Then again, some BASEstar installations I have known have needed BASEstar running 24x7x365. Keeping the system up and running was more important than the small risk of global sections being inconsistent on the backup (generally the global sections could be recreated correctly and simply from other data within BASEstar). Other applications may not all be so well behaved. You need to understand your needs and relevant application behaviours. Regards John ------------------------------ Date: Thu, 20 Mar 2008 20:28:09 +0000 (UTC) From: Dale Dellutri Subject: Re: Please critique my backup practices Message-ID: On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar wrote: > On Mar 20, 2:36?pm, Dale Dellutri wrote: > > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar wrote: > > > To do a backup, I pop a drive out of a shadowset, back it up and put > > > it back. > > > > I assume you're talking about VMS Volume Shadowing. ?As far as I know, > > taking a drive out of a shadowset causes the drive to look the same as > > if there'd been a power failure. ?In other words, it does not properly > > close open files. > > > > I assume that you take image backups. ?If so, there's no benefit to > > taking the drive out of the shadowset to take the image backup. > > According to service techs that I talked to when I first set up > > volume shadowing, there's no advantage over taking an image backup > > of the volume set (the DSA device). > > > > I assume that this is still true. > > > > > The problem is, I don't record the backup dates. > > > > You could record backup dates if you simply took an image backup > > of the volume set. > Don't I have to shutdown my system to do that? I don't know. It depends on what you're running. I just said that when I checked into this, taking a disk out of a shadow set to take an image backup gives you no advantage over simply making an image backup of the volume set on the running system. Also, as I said below, I could be wrong. Please check with your service techs. > > > > > I have a incremental that runs every night that does record backup > > > dates. > > > If I had to restore, I would apply the last image and all the > > > incrementals after it. ?But I guess I would get some extra files. > > > This is easy, I never have to shutdown, but what are the gotchas? > > > Note that if I am *planning* to do a restore I don't use incrementals, > > > I just use a fresh image backup. > > > I have never had to do an emergency image restore using incrementals. > > > > I'm not an expert, so what I've said above may be wrong. ?You should > > check this backup scheme with the service techs (I assume you have > > a support contract). -- Dale Dellutri (lose the Q's) ------------------------------ Date: Thu, 20 Mar 2008 20:44:38 +0000 (UTC) From: Dale Dellutri Subject: Re: Please critique my backup practices Message-ID: On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar wrote: > On Mar 20, 2:36?pm, Dale Dellutri wrote: > > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar wrote: > > > To do a backup, I pop a drive out of a shadowset, back it up and put > > > it back. > > > > I assume you're talking about VMS Volume Shadowing. ?As far as I know, > > taking a drive out of a shadowset causes the drive to look the same as > > if there'd been a power failure. ?In other words, it does not properly > > close open files. > > > > I assume that you take image backups. ?If so, there's no benefit to > > taking the drive out of the shadowset to take the image backup. > > According to service techs that I talked to when I first set up > > volume shadowing, there's no advantage over taking an image backup > > of the volume set (the DSA device). > > > > I assume that this is still true. > > > > > The problem is, I don't record the backup dates. > > > > You could record backup dates if you simply took an image backup > > of the volume set. > Don't I have to shutdown my system to do that? I finally found the relevant item in "HP Volume Shadowing for OpenVMS", v7.3-2. Chapter 7, Section titled "Data Consistency Requirements": "Removal of a shadow set member results in what is called a crash-consistent copy. That is, the copy of the data on the removed member is of the same level of consistency as what would result if the system had failed at that instant." (pg 124 in my copy). Actually, reading the entire section titled "Guidelines for for Using a Shadow Member for Backup" would be very useful. > > > > > I have a incremental that runs every night that does record backup > > > dates. > > > If I had to restore, I would apply the last image and all the > > > incrementals after it. ?But I guess I would get some extra files. > > > This is easy, I never have to shutdown, but what are the gotchas? > > > Note that if I am *planning* to do a restore I don't use incrementals, > > > I just use a fresh image backup. > > > I have never had to do an emergency image restore using incrementals. > > > > I'm not an expert, so what I've said above may be wrong. ?You should > > check this backup scheme with the service techs (I assume you have > > a support contract). -- Dale Dellutri (lose the Q's) ------------------------------ Date: Thu, 20 Mar 2008 14:41:32 -0700 (PDT) From: tadamsmar Subject: Re: Please critique my backup practices Message-ID: <9ea00241-d6a8-4003-b477-902f8dde2ea7@d62g2000hsf.googlegroups.com> On Mar 20, 4:06=A0pm, "John Wallace" wrote: > "tadamsmar" wrote in message > > news:26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com... > > > > > > > To do a backup, I pop a drive out of a shadowset, back it up and put > > it back. > > > The problem is, I don't record the backup dates. > > > I have a incremental that runs every night that does record backup > > dates. > > > If I had to restore, I would apply the last image and all the > > incrementals after it. =A0But I guess I would get some extra files. > > > This is easy, I never have to shutdown, but what are the gotchas? > > > Note that if I am *planning* to do a restore I don't use incrementals, > > I just use a fresh image backup. > > > I have never had to do an emergency image restore using incrementals. > > Give the community some more background and you may get better answers. > Relevant practices may vary depending on what you're backing up (a system > disk, a generic data disk with various files on it, a "pure database" disk= > with nothing on it except the database itself in which case it may have it= s > own backup tools...). > > E.g. when I cared about backups, in a software development environment, it= > was always a goal to have files on at least two sets of media (even files > which may only have existed for a couple of days), so that if there was a > problem and one set of media wasn't usable for whatever reason, the releva= nt > files would still be recoverable from another set. This was done by > abandoning the usual "incremental" or "differential" schemes and doing a > weekly full backup and a daily backup with files created in the previous t= wo > (or do I mean three) days, so each new file would go on the following day'= s > daily backup, AND the daily one after that. Others might have a "version > management" tool in place to achieve the same end result, which might have= > changed the backup requirement. One backup strategy does not necessarily f= it > all, not comfortably anyway. > > Usually the only time you need completely shut down VMS for doing a backup= > is if you want a clean image backup of your system disk - always assuming > that any applications you may have active can be persuaded to close any > files they may have opened, without shutting VMS down. For example, BASEst= ar > (which you have previously mentioned) sometimes has lots of global section= > files, which should disappear (or at least close cleanly) when you shut do= wn > BASEstar. Then again, some BASEstar installations I have known have needed= > BASEstar running 24x7x365. Keeping the system up and running was more > important than the small risk of global sections being inconsistent on the= > backup (generally the global sections could be recreated correctly and > simply from other data within BASEstar). Other applications may not all be= > so well behaved. You need to understand your needs and relevant applicatio= n > behaviours. > > Regards > John- Hide quoted text - > > - Show quoted text - I am running VMS 7.3.2 on a DS10. I have shadowed system disks (2). This is about backing up a system disk. The app that runs on it is designed to come up clean after a crash. ------------------------------ Date: Thu, 20 Mar 2008 22:24:21 GMT From: John Santos Subject: Re: Please critique my backup practices Message-ID: In article <13u5gub59gtbmca@corp.supernews.com>, johnwallace4 @yahoo.spam.co.uk says... > > "tadamsmar" wrote in message > news:26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com... > > To do a backup, I pop a drive out of a shadowset, back it up and put > > it back. > > > > The problem is, I don't record the backup dates. > > > > I have a incremental that runs every night that does record backup > > dates. > > > > If I had to restore, I would apply the last image and all the > > incrementals after it. But I guess I would get some extra files. > > > > This is easy, I never have to shutdown, but what are the gotchas? > > > > Note that if I am *planning* to do a restore I don't use incrementals, > > I just use a fresh image backup. > > > > I have never had to do an emergency image restore using incrementals. > > Give the community some more background and you may get better answers. > Relevant practices may vary depending on what you're backing up (a system > disk, a generic data disk with various files on it, a "pure database" disk > with nothing on it except the database itself in which case it may have its > own backup tools...). > > E.g. when I cared about backups, in a software development environment, it > was always a goal to have files on at least two sets of media (even files > which may only have existed for a couple of days), so that if there was a > problem and one set of media wasn't usable for whatever reason, the relevant > files would still be recoverable from another set. This was done by > abandoning the usual "incremental" or "differential" schemes and doing a > weekly full backup and a daily backup with files created in the previous two > (or do I mean three) days, so each new file would go on the following day's > daily backup, AND the daily one after that. Others might have a "version > management" tool in place to achieve the same end result, which might have > changed the backup requirement. One backup strategy does not necessarily fit > all, not comfortably anyway. > > Usually the only time you need completely shut down VMS for doing a backup > is if you want a clean image backup of your system disk - always assuming > that any applications you may have active can be persuaded to close any > files they may have opened, without shutting VMS down. For example, BASEstar > (which you have previously mentioned) sometimes has lots of global section > files, which should disappear (or at least close cleanly) when you shut down > BASEstar. Then again, some BASEstar installations I have known have needed > BASEstar running 24x7x365. Keeping the system up and running was more > important than the small risk of global sections being inconsistent on the > backup (generally the global sections could be recreated correctly and > simply from other data within BASEstar). Other applications may not all be > so well behaved. You need to understand your needs and relevant application > behaviours. > > Regards > John > > > I want to second everything John said... The split-the-shadow-set, backup, rejoin the shadow-set method can be useful and reasonably safe, but you have to understand your applications. It's like hot-splicing an electrical circuit or mid-air refueling, if you have to ask, you probably shouldn't be doing it! If you can quiesce your application (close all files or at least flush all I/o buffers and hold it there, or activate a recovery journal or any of a dozen other techniques, and hold it there for a little while (10 seconds to a minute or so, depending on how automated everything is), you can dismount one member of the shadow set and be guaranteed it is complete and consistent as of that time. If you can't do this (like for a system disk), if you can make sure this is done at a quiet time, you can at least be reasonably sure that you've got a good snapshot, but you really need to understand what might be inconsistent and how to recognize and recover from any problems that occur when you try to restore. Often times, it will be just like trying to recover from a crash. For a system disk, the issues might be people logging in and changing info in the UAF, people changing passwords, creating, modifying or deleting user accounts, batch or print jobs (queue manager issues), etc. Don't be editing systartup_vms.com while starting up the backup! If you can be sure these things aren't happening (middle of the night, nothing in the batch or print queues currently printing or scheduled to execute in the next several minutes, etc.), then your odds of getting a usable backup are pretty good, but never 100%. Once you've split off the shadow set member, you can resume normal operations, unquiescing the application or restarting it as the case may be. Your time tag for the backup date is any time during the interval while everything is quiet. You'll need to write this down. Mount the split-out member privately with /nowrite, and back it up any way you wish (image, incremental, differential, random bunch of specific files, or whatever, depending on what's on the disk and your restore strategy.) *DON'T* use /RECORD! (You can't on a disk mounted /nowrite, and even if you did, the date stamps would all get erased when you add it back to the shadow set.) When the backup completes, dismount the disk, remount back into the shadow set (minicopy is a HUGE win here, reducing the copy time from hours to seconds.) There is no need to quiesce anything while adding the disk back into the set. The advantages of this over just doing a live backup of the shadow set are several-fold. Since the snapshot is done instantly and while there is no (or very little) activity, the chances of getting an inconsistent backup are greatly reduced (to zero if you can quiesce or shut down the application.) Even if the best you can do is do this during a relatively quiet time this is much better than doing a live backup of the active shadow set. The advantage of this method over an offline backup is speed. You don't have to shut the system down first and reboot it afterward. The application only has to be offline for a few seconds (or not at all if you have the hooks in it to record your own journal files to another disk while the disk being backed up is being split.) It doesn't matter how long the backup itself takes (well, if it takes too long, minicopy will approach normal copy times, and if it's a 2-member shadow set, you'll be working without a net until the member rejoins.) An advantage to doing the backup online, vs. booting the VMS CD and backing up from there (the only truly safe method of backing up a system disk) is you can script everything in DCL, so there are no typos (or at least no random, non-repeating operator typos), no mounting and backing up the wrong disk, the time critical bits (quiescing, dismounting, resuming) happen as fast as possible, which minimizes downtime, and you can keep a log of everything. BTW, since the time required by the backup doesn't matter much, I almost always do full image backups when using this method. To repeat all the warnings though, this method only gives reliable backups if the application can be quiesced or completely shutdown while the shadow set is being split. Otherwise some operation will write some data to both disks before the dismount and only to the remaining disk after the dismount, and your backup disk will be inconsistent, possibly in a way you won't notice till months later. (Data dry rot!) -- John ------------------------------ Date: Thu, 20 Mar 2008 15:43:02 -0700 (PDT) From: AEF Subject: Re: Please critique my backup practices Message-ID: <9838b597-4575-4e85-a503-442d0b778599@m3g2000hsc.googlegroups.com> On Mar 20, 9:02 am, tadamsmar wrote: > To do a backup, I pop a drive out of a shadowset, back it up and put > it back. > > The problem is, I don't record the backup dates. Yes, that is a problem with this method. > > I have a incremental that runs every night that does record backup > dates. > > If I had to restore, I would apply the last image and all the > incrementals after it. But I guess I would get some extra files. No. You will get the disk restored to the state it was in as seen by your last incremental pass. The penalty is that your first incremental save set after the last image save was done will contain more files than necessary (and WAY more if there are no backup dates at all on the volume). But it all gets straightened out automatically during the restore. Incremental disk backups save all .DIR files so that BACKUP has all the information necessary to accomplish this. BACKUP/INCREMENTAL does this by comparing the backup date of each .DIR file in the save set with the matching .DIR file on the disk. Then BACKUP/INCREMENTAL uses the data in the more recent of the two and attempts to bring the matching directory to agree. If the save set .DIR file is more recent, BACKUP/INCREMENTAL deletes files in the matching directory on the disk that are not in the .DIR file in the save set, restores files from the save set for that directory, and creates empty file entries for files that are listed in its .DIR file, but are not found in the save set or already on disk. If the .DIR file on the disk is the more recent of the two, BACKUP/ INCREMENTAL then simply restores every missing file it has a copy of. This is why you can restore the incremental save sets in any order, but the most efficient is to run them in reverse chronological order. With pre-V6.2 BACKUP, if you renamed any directories, then, TTBOMK, the disk can fill up even using reverse chronological order. The cure is to reapply the incrementals. [Well, I never tried using any old order with .GE.V6.2 BACKUP, but I don't see why it wouldn't work. It would just take longer than with reverse chronological order.] > This is easy, I never have to shutdown, but what are the gotchas? You need to close all files on the volume before removing the member by shutting down anything that is using it. (You can't do that if this is the SYSTEM disk, of course.) Otherwise, any files open for write might not be copied in a consistent manner (and won't be copied at all if you don't use /IGNORE=INTERLOCK). The proper way to do this is to shut down all apps accessing the volume. DISMOUNT the volume. Re-MOUNT the volume with one less member. Back up that member. Then put that member back into the shadow set. This way you avoid any problems with open files, incomplete I/O operations, etc. > > Note that if I am *planning* to do a restore I don't use incrementals, > I just use a fresh image backup. Good. > > I have never had to do an emergency image restore using incrementals. Also good! ;-) AEF ------------------------------ Date: Thu, 20 Mar 2008 15:48:36 -0700 (PDT) From: AEF Subject: Re: Please critique my backup practices Message-ID: <517638b4-cbf0-4f9d-ad2d-da3f00d683dc@d62g2000hsf.googlegroups.com> On Mar 20, 9:28 am, "Richard B. Gilbert" wrote: > tadamsmar wrote: > > To do a backup, I pop a drive out of a shadowset, back it up and put > > it back. > > > The problem is, I don't record the backup dates. > > > I have a incremental that runs every night that does record backup > > dates. > > > If I had to restore, I would apply the last image and all the > > incrementals after it. But I guess I would get some extra files. > > > This is easy, I never have to shutdown, but what are the gotchas? > > > Note that if I am *planning* to do a restore I don't use incrementals, > > I just use a fresh image backup. > > > I have never had to do an emergency image restore using incrementals. > > I'd avoid doing emergency restores using incrementals if at all > possible! Somebody has to load all those incrementals and do it in the > proper order! A slightly better choice would be to use differential > backups. Do your image once weekly and each succeeding day, do a BACKUP > /SINCE=. That way there are only two backups > to restore with only one right way and one wrong way to restore. > > Remember that emergency restores are "panic time" when it's easiest to > screw up! When your boss is hovering over your desk saying "how much > longer" every two or three minutes, is NOT a good time to try to do > anything in any way more complicated than it absolutely has to be. > > If you do your full backups with /RECORD you can do your differential > with /SINCE=BACKUP. This is better because you let the machine do your > bookeeping! It's less likely to screw up than you are! I'm reasonably sure you can restore in any order, but reverse chronological is the most efficient. Differential backups are appropriate when your backup windows are large enough. You spend more time and resources saving, but restores are quicker as you only need to apply the latest image followed by the latest differential. But since BACKUP/INCREMENTAL deletes files from the volume that were not present at the time of the most recent save set that you've already restored, it shouldn't usually take a lot longer with the regular incremental method unless you've got a lot of tapes or have to skip over a lot of large files. It depends on your situation. AEF ------------------------------ Date: Thu, 20 Mar 2008 15:59:04 -0700 (PDT) From: AEF Subject: Re: Please critique my backup practices Message-ID: <34a4b77f-3395-4e22-8244-afa597b4e756@n58g2000hsf.googlegroups.com> On Mar 20, 5:24 pm, John Santos wrote: > In article <13u5gub59gtb...@corp.supernews.com>, johnwallace4 > @yahoo.spam.co.uk says... > > > > > > > "tadamsmar" wrote in message > >news:26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com... > > > To do a backup, I pop a drive out of a shadowset, back it up and put > > > it back. > > > > The problem is, I don't record the backup dates. > > > > I have a incremental that runs every night that does record backup > > > dates. > > > > If I had to restore, I would apply the last image and all the > > > incrementals after it. But I guess I would get some extra files. > > > > This is easy, I never have to shutdown, but what are the gotchas? > > > > Note that if I am *planning* to do a restore I don't use incrementals, > > > I just use a fresh image backup. > > > > I have never had to do an emergency image restore using incrementals. > > > Give the community some more background and you may get better answers. > > Relevant practices may vary depending on what you're backing up (a system > > disk, a generic data disk with various files on it, a "pure database" disk > > with nothing on it except the database itself in which case it may have its > > own backup tools...). > > > E.g. when I cared about backups, in a software development environment, it > > was always a goal to have files on at least two sets of media (even files > > which may only have existed for a couple of days), so that if there was a > > problem and one set of media wasn't usable for whatever reason, the relevant > > files would still be recoverable from another set. This was done by > > abandoning the usual "incremental" or "differential" schemes and doing a > > weekly full backup and a daily backup with files created in the previous two > > (or do I mean three) days, so each new file would go on the following day's > > daily backup, AND the daily one after that. Others might have a "version > > management" tool in place to achieve the same end result, which might have > > changed the backup requirement. One backup strategy does not necessarily fit > > all, not comfortably anyway. > > > Usually the only time you need completely shut down VMS for doing a backup > > is if you want a clean image backup of your system disk - always assuming > > that any applications you may have active can be persuaded to close any > > files they may have opened, without shutting VMS down. For example, BASEstar > > (which you have previously mentioned) sometimes has lots of global section > > files, which should disappear (or at least close cleanly) when you shut down > > BASEstar. Then again, some BASEstar installations I have known have needed > > BASEstar running 24x7x365. Keeping the system up and running was more > > important than the small risk of global sections being inconsistent on the > > backup (generally the global sections could be recreated correctly and > > simply from other data within BASEstar). Other applications may not all be > > so well behaved. You need to understand your needs and relevant application > > behaviours. > > > Regards > > John > > I want to second everything John said... > > The split-the-shadow-set, backup, rejoin the shadow-set method > can be useful and reasonably safe, but you have to understand your > applications. > > It's like hot-splicing an electrical circuit or mid-air refueling, > if you have to ask, you probably shouldn't be doing it! > > If you can quiesce your application (close all files or at least > flush all I/o buffers and hold it there, or activate a recovery > journal or any of a dozen other techniques, and hold it there for > a little while (10 seconds to a minute or so, depending on how > automated everything is), you can dismount one member of the shadow > set and be guaranteed it is complete and consistent as of that > time. If you can't do this (like for a system disk), if you can > make sure this is done at a quiet time, you can at least be > reasonably sure that you've got a good snapshot, but you really > need to understand what might be inconsistent and how to recognize > and recover from any problems that occur when you try to restore. > Often times, it will be just like trying to recover from a crash. > [...] > > To repeat all the warnings though, this method only gives > reliable backups if the application can be quiesced or > completely shutdown while the shadow set is being split. > Otherwise some operation will write some data to both disks > before the dismount and only to the remaining disk after the > dismount, and your backup disk will be inconsistent, possibly > in a way you won't notice till months later. (Data dry rot!) > > -- > John I believe the recommended and cleanest method is the following: Shut down everything accessing the volume, thereby closing all files (except system access to INDEXF.SYS, of course.) DISMOUNT the shadow set. (This avoids the dismounted improperly syndrome.) Re-MOUNT the shadow set minus one member. MOUNT the removed member separately and back it up. DISMOUNT the removed, backed-up member (now it's own volume). Add the backed-up member back to the original shadow set. AEF ------------------------------ Date: Thu, 20 Mar 2008 23:03:30 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Please critique my backup practices Message-ID: In article <26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com>, tadamsmar writes: > To do a backup, I pop a drive out of a shadowset, back it up and put > it back. Are there any open files on the shadow set? ------------------------------ Date: Thu, 20 Mar 2008 12:37:04 -0700 (PDT) From: AEF Subject: Re: Proof that macintosh is better than VMS Message-ID: <71aea72e-90c0-4545-8ad6-64c69d775297@b64g2000hsa.googlegroups.com> On Mar 17, 8:45 am, davi...@alpha2.mdx.ac.uk wrote: > In article <4e7e482c-d37b-4084-8cec-1ce8dcc42...@p73g2000hsd.googlegroups.com>, AEF writes: > > >Hello, > > >Comments interspersed below. Sorry for the delay, but it took me a > >long time to write this. I have tried to be as clear as possible while > >still not spending too much time on it. The better thing to read is > >Feynman's The Character of Physical Law and his Lectures on Physics > >book. > > >Abstract: I'm showing how I'm basing my convictions on not just QM, > >but on the wave-particle duality, the de Broglie relation, the results > >of a vast array of experiments, one of which is described here in > >detail. Nevertheless, QM is so amazingly successful for such a huge > >range of phenomena, that there must be something very right about it. > >All this leads me to conclude that Nature, at the level of atoms and > >below, is intrinsically probabilistic, even if QM is eventually > >superseded by a better theory. > > >It's a little long. Please be patient as it takes a little while to > >explain it properly. > > >Enjoy. > > >AEF > > >On Mar 13, 11:01 am, davi...@alpha2.mdx.ac.uk wrote: > >> In article <42e3bcd3-a7d0-4fd6-badf-bc7623f68...@u72g2000hsf.googlegroups.com>, AEF writes: > > >> >On Mar 12, 8:11 am, davi...@alpha2.mdx.ac.uk wrote: > >> >> In article , AEF writes: > > >> >> >On Mar 11, 1:19 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > >> >> >> In article , > >> >> >> koeh...@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > >> >> >> > In article <960d254f-6ae7-4334-ab8e-e58e2b1ed...@8g2000hse.googlegroups.com>, Doug Phillips writes: > > >> >> >> >> You are confusing quantum mechanics math with reality. If you mean > >> >> >> >> that the mathematics of quantum mechanics is not concerned with > >> >> >> >> resolving apparent randomness, then you are correct. You might want to > >> >> >> >> look into the de Broglie-Bohm theory, more recently called Bohmian > >> >> >> >> Mechanics. > > >> >> >> > Quantum mechanics math vs. reality? You think reality differs? > > >> >> >> I'll bet a lot of people do. When science requires faith than religion > >> >> >> in order to accept that which can neither be observed nor satisfactorily > >> >> >> proven I think more and more people will see the difference. > > >> >> >I assume you meant "When science requires *more* faith..." > > >> >> >Scientists have faith in the scientific method which requires > >> >> >evidence. Religious people have what James Randi calls "blind > >> >> >faith"[1]. That makes all the difference in the world. > > >> >> >[1] Seehttp://www.randi.org/jr/072503.html(Mostlyagood article, > >> >> >but I disagree with his opinion of the Wizard of Oz.) > > >> >> >As far as using local hidden variables to restore determinism that > >> >> >only "appears" probabilistic, the experimental evidence ruling these > >> >> >out is more compelling than ever. Many, many experiments have been > >> >> >done and QM always, always wins. > > >> >> This is a strawman since there are non-local hidden variable theories. > > >> >> >We're not talking about the > >> >> >possibility of experimental error clouding the results. The skeptics > >> >> >who complained that the early experiments could still allow local > >> >> >hidden variables because of events missed by detectors because said > >> >> >detectors were not 100% efficient. OK. But the efficiencies have been > >> >> >greatly improved and the room for determinism has been all but wiped > >> >> >out. Then there is the GHZ paradox which largely sidesteps the issue. > >> >> >There is simply no way to explain the results of GHZ experiments using > >> >> >local hidden variables. > > >> >> These experiments rule out local realistic theories. > >> >> This just leaves two choices > > >> >> 1) non-locality > > >> >> or > > >> >> 2) non-realism > > >> >But what about Feynman's argument? > > >> >All these things combined (which includes stuff I don't have time to > >> >document here) leads me to believe that there is almost certainly no > >> >way out. > > >> >> To my mind the latter doesn't actually make much sense. If the wave function > > >> >What makes sense is not as important as experimental results. See, you > >> >know the drill (Beginning of Chapter 6 and parts of Chapter 7). > > >> >> doesn't actually have a physical existence and a particle doesn't have any > >> >> properties until you measure them then how are entangled particles actually > >> >> linked. (If the wave function does physically exist then it's collapse will be > >> >> a non-local effect so such versions of the Copenhagen interpretation are > >> >> non-local). > > >> >I think the realism quandary is a red herring. QM tells you what you > >> >will observe and that is what you observe. > > >> The problem I have is that such an interpretation is just > > >> "thats the way it is" > > >> which to me isn't a scientific statement. With non-local interpretations there > >> is at least some possibility that in the future it might be possible to explain > >> the non-locality. If you just take it thats "thats the way it is" then you are > >> in effect giving up on trying to find an explanation. I think more than non-locality is involved. There's still intrinsic probability to consider. There's also the issue of the subtle difference between locality and separability, but I have to review the Don Howard paper Einstein on Locality and Separability first. I have a barely legible .pdf of a .tif of a fax (or other scan) of it. > > >As to what's "scientific", please read Chapter 6 of The Character of > >Physical Law and get back to me. (Parts of Chapters 1 and 7 are also > >relevant.) You will find the answer to that in this book. Obviously > >I'm not going to quote entire chapters of the book. But I'll say this > >here: How does gravity work? Think about it. Any two masses, no matter > >how far apart, attract each other. Isn't that kind of amazing? You say > >there is a field that permeates all of space. Just what is this field > >made of and how is it generated by mass? How can it be like that? But > >we grow up with gravity from day 1 and it becomes so familiar we think > >of it as being totally normal. So what mechanism could be behind this? > >At the classical level, physics has indeed given up. > > I wasn't going to respond to this but felt I had to respond to the above. I have no problem with you responding. If you want to continue via email, drop me a note at the spamsink2001 address. If you don't, then stop. It's up to you. > If by the classical level you mean excluding relativity then you are correct in > the sense that noone is looking for a mechanism - but that is because Newtonian > theory has been superseded. > > If however by classical level you just mean excluding QM then that is rubbish. > The mechanism for Gravity is well understood - the curvature of space-time. > How mass/energy causes space-time to curve is well described by GR. > Why mass/energy has that effect on space-time isn't explained but undoubtedly > requires a better understanding of the structure of space-time. Well, if you insist on disagreeing to agree, that's okay. What is the mechanism by which mass curves space-time? I meant that there will always be a level at which you will say, "Well what is that? What mechanism generates that?" Either there are an infinite number of layers, or there exists a bottom layer. Either you think it's infinite or that we simply haven't reached bottom yet. Either way, you will always be left with a mystery as to the nature of the lowest known level. [Note that there are two possible meanings of "how" here: (1) In what manner is it curved? That's akin to asking: "What is the magnitude and direction of the force produced at this point in space by a given distribution of mass?" or, in GR terms: "What curvature is produced at this point by a given distribution of mass?" Then there's (2) "How does mass achieve this result? These are different questions. GR answers question (1), but not question (2). The "force as a result of virtual particle exchange" paradigm answers question (2), except you are then left with question (2) for that!] > > >In QM, it is > >thought that it is the exchange of virtual gravitons that causes the > >attraction, just like it is the exchange of virtual photons that > >carries the electromagnetic force. > > Quantum Gravity theorems are still extremely speculative eg Loop quantum > gravity, String theory. The existence/non-existence of the graviton and > it's properties would help either support these speculations or refute them. > > The graviton does not fit into the QM standard model. Irrelevant. It is thought by most physicists that all fundamental forces arise from the exchange of virtual particles. I don't know of any reason that the virtual-particle mechanism is restricted to the Standard Model. Physicists are looking for real gravitons in, e.g., the LIGO expriment. If one is found, it will likely be big news (well, for physicists at least). I don't think you need a Quantum Gravity theory first. In fact, QM and GR are incompatible as is. The resolution of this, of course, is one of the greatest mysteries in physics today. The answer should prove exciting indeed! Anyway, AFAIK, no one knows any mechanisms behind the spooky correlations we see in QM experiments, or the generation of virtual particles out of nothing (but it is known how they generate forces!). We may never know, and if you ever do, it will probably just be another layer to ask the same question about. I brought up gravity to show that it seems normal only because we grow up with it from day 1 and we'd likely thing the same of intrinsic probability if we grew up from day 1 experiencing that. > > >But these virtual photons -- or > >gravitons -- materialize out of nowhere, travel between particles to > >carry the force, and then disappear (thanks to a variation of the > >uncertainty principle, a violation of conservation of energy is > >allowed if it occurs over a short enough interval of time, and this > >allows virtual particles to have their fleeting existences). And > >you're still stuck with trying to find a mechanism for the virtual > >particles. Good luck. We don't grow up experiencing QM at all, so it > >seems really strange. But we are not to tell Nature how She's got to > >be. [Until we detect actual gravitons, the existence of virtual > >gravitons remains speculation. However, most physicists, AFAIK, > >believe they must exist.] > > >So you're always going to reach a point at which you say, "But what is > >that? What is the mechanism behind that?" I think with QM we've hit > >rock bottom. > > Here we disagree. Since QM is undoubtedly incomplete it is much much too early > to say we have reached rock-bottom. If you give up looking for mechanisms and > just accept that "that is the way it is" then you might as well join Boob and > put it all down to God's mysterious actions. Well, no need for insults! Just my opinion. You'd have to say the same about Feynman. Please. I just think it is very unlikely that a "reasonable" way will ever be found to "explain" what today appears to almost certainly be "intrinsic probability in nature". "Boob" says his stuff is 100% certain without giving any reasonable logic behind it. I give valid logic and solid scientific evidence in support of my ideas whereas "Boob" claims to do that, but as you well know, doesn't. Some things are pretty certain: There are eight "major planets" orbiting our Sun. Ordinary matter is made of atoms. Do you think these things will be superseded some day? The evidence in favor of these two things is overwhelming! I think Feynman's argument (combined with all the experimental evidence) is very compelling. I don't accept it on faith. I studied his argument and it seems quite valid to me. Sometimes you can rule things out. A theory can be proved to be wrong, but you can't prove a theory to be right. Feynman's argument falls into the former case. He rules out hidden variable theories. No, it's not at the level of a mathematics proof such as proving that the square roots of non- perfect squares are irrational numbers, or that pi is transcendental, or that a real number squared cannot be negative, etc., but I think it's pretty damn good. Don't compare me to "Boob"! That "theory" or conjecture is without doubt easily proved false! Did you see part 1 of the video at www.feynman.com? It's free! Let me know if you ever do. And wake me when someone gets deeper. I meant that we most likely can't go deeper to see what happens between observations. If you can know where the particle is after passing the double-slit, or beam splitter A, or what have you, it cannot contribute to an interference pattern. If you get an interference pattern, you cannot know which way the particle went because if it went only one way it couldn't contribute to an interference pattern. Even Einstein admitted that arguments like this are logically self- consistent. From Cropper's "The Quantum Physicists" when discussing the EPR paradox: "Einstein did not hesitate to say that he accepted the logical force of [Bohr's] argument and its possible validity; yet he still had reservations". Look, this is just my opinion after years of pondering the problem and considering various experiments and reading various books and seeing how things have developed over time. We disagree. That's okay. There's no need to get all worked up about it! > > >> Note. All the interpretations agree on what you will observe so in that sense > >> it doesn't matter. However interpretations can give insight into how to produce > >> a more complete theory and as I have pointed out QM is not the final theory of > >> everything. > > >[I'm not basing my claims solely on QM. I still think a more accurate > >theory will still not be able to get rid of the intrinsic > >probabilistic nature of things. See below.] > > >And how will you test it? As for QM being "final", I think certain > >aspects will survive. Note that Ehrenfest's theorem shows how quantum > >mechanics goes over into classical mechanics at the macroscopic level. > > Any future theory of everything will have to incorporate all the results of > QM experiments at least as approximate results just as GR incorporates > Newtonian theory. > That doesn't mean that the mechanisms of the theory will necessarily be > identical. We can see this by looking at the case of Gravity. > In Newtonian theory gravity is a mysterious force acting at a distance. > In GR it is the result of matter/energy curving spacetime. But you will still have the wave-particle duality which is what causes all these problems in the first place, just like you'll still have the idea that oridnary matter is made of atoms, or are you expecting that to be superseded one day, too? And I forgot in all these discussions to mention tunneling! I think the Bohmian theory will not be able to handle that to a satisfactory degree because the particle cannot be observed within the pentrated barrier. There will be a gap in the Bohmian "path" of the particle. Einstein wrestled with tunneling, too, in the form of alpha decay. The wave function for the alpha particle grows outside the nucleus and shrinks inside until the alpha particle is observed which implies that there is no definite moment of decay independent of the measurement! (See "Albert Einstein: Philosopher- Scientist" edited by Arthur Schilpp, pp. 667ff, for Einstein's description of the problem and his views, but I wonder what Einstein would think if he were alive today to see all the knew experimental results and entanglement and such.) If you can, in prinicple, determine the path of a particle through an interference appartus, it cannot contribute to an interference pattern and vice versa. This means you cannot predict ahead of time which path the particle will be found in when you check which path it's in. I cannot see how you can ever get around this. If you watch part 1 of the video or read The Character of Physical Law (at least chapter 6 thereof) and let me know what you think (via email). > Respond to this if you want but I won't be responding any further. OK. [...remainder of quoted post omitted as it contains nothing new...] AEF ------------------------------ Date: Thu, 20 Mar 2008 14:10:10 -0700 (PDT) From: AEF Subject: Re: Proof that macintosh is better than VMS Message-ID: On Mar 17, 3:12 am, JF Mezei wrote: > Lets say a photon isn't a round sphere, but rather a flat disk. And it > rotates in 3d while travelling. > > When it hits the glass, the decision on whether it bounces off or > penetrates the glass might depend on whether the disk is falling flat > against the glass (to big to fit between the cracks), or if it is in an > orientation that makes it thin and allow it to slip through between 2 > atoms easily. > > To you and me, it may be totally random because we can't see this, but > it doesn't mean that the photon doesn't react in a very logical way when > it hits glass (or water, chrome etc etc). This, too, is addressed by Feynman in the video. If this were the case, the photons that make it through the glass would all be lined up, but when these lined-up photons strike another layer of glass, you still get 4% of them reflected. And so on with more layers of glass. This, combined with other evidence, shows that this theory is wrong. PLEASE watch the video so I don't have to keep quoting from it. If you have a question about something in the video, fine. But please watch it. It's FREE! AEF ------------------------------ Date: Thu, 20 Mar 2008 16:36:18 -0700 (PDT) From: Neil Rieck Subject: Re: So you think God and the devil are not real? Message-ID: <22bc3f16-d0e3-4770-822a-8dd33f464f1e@t54g2000hsg.googlegroups.com> On Mar 14, 10:01=A0am, ultra...@gmail.com wrote: > http://www.worldnetdaily.com/index.php?fa=3DPAGE.view&pageId=3D58835 The devil is real and his name is Dick Cheney. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: Thu, 20 Mar 2008 21:19:03 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Too many files in one directory (again) Message-ID: <08032021190335_2020CE0B@antinode.org> I've heard the lecture(s) before, so please spare us all a repeat, but I recently had occasion to (try to) unpack a "tar" archive which wants to create about 190000 files in one directory. On an HP PA-RISC workstation c3700 running HP-UX 11.11 it took about 35 minutes. On an HP IA64 workstation zx2000 running VMS V8.3-1H1, it's about eight hours into the VMSTAR job, it hasn't created half the files yet, and it does not seem to be getting faster as it goes. The file names all look like "020989f4d6c2f32768d0535c1815344d.zip", "11509dd158a696797eca5700f902ce03.zip", and so on. I just pass this along as a reminder that there's still some room for improvement in dealing with cases like this which, bad design or not, don't cause nearly so much trouble on other operating systems. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Thu, 20 Mar 2008 23:16:22 -0400 From: "Richard B. Gilbert" Subject: Re: Too many files in one directory (again) Message-ID: <47E32886.6060406@comcast.net> Steven M. Schweda wrote: > I've heard the lecture(s) before, so please spare us all a repeat, > but I recently had occasion to (try to) unpack a "tar" archive which > wants to create about 190000 files in one directory. On an HP PA-RISC > workstation c3700 running HP-UX 11.11 it took about 35 minutes. On an > HP IA64 workstation zx2000 running VMS V8.3-1H1, it's about eight hours > into the VMSTAR job, it hasn't created half the files yet, and it does > not seem to be getting faster as it goes. > Cheer up, it will get slower as it goes! 190,000 files in a directory seems rather bizarre no matter what O/S you are talking about. ------------------------------ Date: Thu, 20 Mar 2008 22:44:34 GMT From: John Santos Subject: Re: VMS Mail translates incoming tilde character into a dollar sign. Message-ID: In article <47e21b55$0$3870$c3e8da3@news.astraweb.com>, jfmezei.spamnot@vaxination.ca says... > Robert Deininger wrote: > > > Paul Anderson keeps walking past my cube and muttering about tildes > > scattered around on the floor... > > If every tilde filtered by MAIL around the world ends up on the floor in > your offices, then this is a far more serious security and privacy issue > than previously thought. The thought of customer data ending up in your > offices (and on the floor nontheless) is very scary. > > I want HP to return every one of *MY* tildes that HP stole from my > machine, and will will not accept anyone else's tildes. And HP better > make sure the tildes are clean and undamaged from Paul Anderson walking > over them. > > (We should launch a class action suit on this, April 1 is coming very > soon :-) :-) :-) :-) > JF, if you've been keeping up with the "Mac OS/X is better than VMS" thread (which I think you should since you started it!), I think Alan and David must at some point mentioned the concept of degeneracy (all fundamental particles of a given type and state are the same, I.e. they can be interchanged without changing the state of the system.) Tilde's are tilde's, you can't claim that certain ones are your and others are not. Curly brackets, on the other hand... -- John ------------------------------ Date: Thu, 20 Mar 2008 22:58:56 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: VMS Mail translates incoming tilde character into a dollar sign. Message-ID: In article , Verne writes: > On Mar 20, 11:00=A0am, koeh...@eisner.nospam.encompasserve.org (Bob > Koehler) wrote: > > In article , John Santos= > writes: > > [...snip...] > > I just received yesterday new MAIL.EXE files from Support for > > Alpha v8.3 > IA64 v8.2-1 > IA64 v8.3 So with 8.X will there ever be a PROPER fix (i.e. restoring the old behaviour), or will we have to keep this logical name around? Will it at least get completely fixed in 8.4? This really shows how quality control has gone down the drain. The problem was a red herring, the security issue was a red herring, the fix is silly, and was feisted upon everyone rather than as a special image on the people who wrongly complained in the first place! ------------------------------ Date: Thu, 20 Mar 2008 22:44:21 -0400 From: JF Mezei Subject: Re: VMS Mail translates incoming tilde character into a dollar sign. Message-ID: <47e32132$1$23906$c3e8da3@news.astraweb.com> Phillip Helbig---remove CLOTHES to reply wrote: > This really shows how quality control has gone down the drain. The only thing of value VMS still has is the clustering software. The rest is all "legacy". When HP retires VMS, if the clustering is still state of the art, they may get a few pennies giving it to Microsoft (again). The rest doesn't need to have much quality control or development. ------------------------------ End of INFO-VAX 2008.161 ************************