INFO-VAX Fri, 26 Oct 2007 Volume 2007 : Issue 586 Contents: free space on disk is not correct Re: free space on disk is not correct Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young Re: Happy Anniversary VMS - 30 years young inCorrect free space on disks inCorrect free space on disks inCorrect free space on disks inCorrect free space on disks Re: inCorrect free space on disks Re: lexical for terminal attributes? Re: lexical for terminal attributes? Re: Pathworks vs CIFS performance Re: Pathworks vs NFS Re: Some success with VMS-NFS serving OS-X Re: Some success with VMS-NFS serving OS-X Re: Standalone backup on Alpha? Re: Standalone backup on Alpha? Re: Standalone backup on Alpha? Re: Standalone backup on Alpha? Re: Standalone backup on Alpha? Re: Standalone backup on Alpha? Re: Standalone backup on Alpha? Re: Standalone backup on Alpha? Re: Standalone backup on Alpha? ---------------------------------------------------------------------- Date: Fri, 26 Oct 2007 07:23:36 -0700 From: magalettac@hotmail.com Subject: free space on disk is not correct Message-ID: <1193408616.008639.149880@o80g2000hse.googlegroups.com> Hi, I have recently built a 2 node itanium cluster, the disks are controlled by dual eva's, I have notice over the past few weeks that free disk space is not being calculated correctly on the drives from time to time. A set vol/rebuild and an anal/disk/repair does not fix the counters the only way to get the disk back to seeing correct amount of free space is to dismount drive and then remount it. The operating system is VMS 8.3, anyone seen this before is there a known fix out there somewhere..... Thanks, Carmine ------------------------------ Date: Fri, 26 Oct 2007 11:57:00 -0400 From: norm.raphael@metso.com Subject: Re: free space on disk is not correct Message-ID: This is a multipart message in MIME format. --=_alternative 00579C8385257380_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable "Syltrem" wrote on 10/26/2007 11:31:11 AM: > $ set volume=E9rebuild=3Dforce ddcu: >=20 > Is this what you need to know ? Well, no it's not as the op said below that "A set vol/rebuild=20 and an anal/disk/repair does not fix the counters...."=20 >=20 > SET >=20 > VOLUME >=20 > /REBUILD >=20 > /REBUILD[=3DFORCE] >=20 > Recovers caching limits for a volume that was dismounted > improperly. If a disk volume was dismounted improperly (such > as during a system failure), and was then remounted with the > MOUNT/NOREBUILD command, you can use SET VOLUME/REBUILD to > recover the caching that was in effect at the time of the > dismount. The FORCE option forces the disk to be rebuilt > unconditionally, thus updating the free block count in the disk > volume's lock value block. >=20 >=20 > HTH >=20 > Syltrem >=20 > wrote in message=20 > news:1193408353.875312.311250@d55g2000hsg.googlegroups.com... > > Hi, > >=20 >=20 >=20 magalettac@hotmail.com wrote on 10/26/2007 10:23:36 AM: > Hi, > I have recently built a 2 node itanium cluster, the disks are > controlled by dual eva's, I have notice over the past few weeks that > free disk space is not being calculated correctly on the drives from > time to time. A set vol/rebuild and an anal/disk/repair does not fix > the counters the only way to get the disk back to seeing correct > amount of free space is to dismount drive and then remount it. The > operating system is VMS 8.3, anyone seen this before is there a known > fix out there somewhere..... >=20 >=20 > Thanks, > Carmine >=20 --=_alternative 00579C8385257380_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

"Syltrem" <syltremzulu@videotron.ca> wrote on 10/26/2007 11:31:11 AM:

> $ set volume=E9rebuild=3Dforce ddcu:
>
> Is this what you need to know ?

Well, no it's not as the op said below that "A set vol/rebuild
and an anal/disk/repair does not fix the counters...= "

>
> SET
>
>   VOLUME
>
>     /REBUILD
>
>           /REBUILD[=3DFORCE]
>
>        Recovers caching limits for a volume that was dismounted
>        improperly. If a disk volume was dismounted improperly (such
>        as during a system failure), and was then remounted with the
>        MOUNT/NOREBUILD command, you can use SET VOLUME/REBUILD to
>        recover the caching that was in effect at the time of the
>        dismount. The FORCE option forces the disk to be rebuilt
>        unconditionally, thus updating the free block count in the disk
>        volume's lock value block.
>
>
> HTH
>
> Syltrem
>
> <magalettac@hotmail.com> wrote in message
> news:1193408353.875312.311250@d55g2000hsg.googlegroups.com...
> > Hi,
> >
>
>


magalettac@hotmail.com wrote on 10/26/2007 10:23:36 AM:

> Hi,
>       I have recently built a 2 node itanium cluster, the disks are
> controlled by dual eva's, I have notice over the past few weeks that > free disk space is not being calculated correctly on the drives from > time to time. A set vol/rebuild and an anal/disk/repair does not fix > the counters the only way to get the disk back to seeing correct
> amount of free space is to dismount drive and then remount it. The
> operating system is VMS 8.3, anyone seen this before is there a known<= br> > fix out there somewhere.....
>
>
> Thanks,
> Carmine
>
--=_alternative 00579C8385257380_=-- ------------------------------ Date: Fri, 26 Oct 2007 18:54:55 +0800 From: "Richard Maher" Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: Hi, I was around for 25 of those (for the most part) glorious years. What a crazy ride! I look forward to the next 25 (hopefully slightly less eventful) years with still the best server OS on the planet. Well done to all past and present who produced a product of such quality that it has survived, and continued to flourish, through such difficult times. The core OS engineers and the compiler guys are owed a debt of gratitude from all (me anyway) of us - Well done! (If only the layered product, middleware *and middle management* wankers could see what's starring them in the face, then the bottom line would be so much healthier! "Middleware for Dummies"? Dummies all right! Not one bloody chapter in there is still being actively supported to customers :-( Anyway, I tried not to whinge; go off and have a well deserved beer. I imagine that they'd be a gathering of many old faces at various DEC sites at the moment - The drinks are on you :-) Cheers Richard Maher "IanMiller" wrote in message news:1193307403.906042.299730@o38g2000hse.googlegroups.com... > Visit > http://h71000.www7.hp.com/openvms/30th/index.html > and see Mark Hurd talk about VMS!!! > > Post your own message at http://h71000.www7.hp.com/fb_30years.html > ------------------------------ Date: 26 Oct 2007 07:27:36 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: In article , Dirk Munk writes: > OpenVMS customers have been paranoid about HP's intend with their OS, > and with good reason. > > With that in mind, I wonder if anyone noticed that Mr. Hurd said that HP > would support OpenVMS , not support and continue to develop OpenVMS or > something similar. > > I don't know if this is significant, maybe we should ask for a > clarification? Maybe you're splitting hairs on a bald man. ------------------------------ Date: Fri, 26 Oct 2007 08:09:20 -0700 From: DaveG Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <1193411360.720813.301570@o3g2000hsb.googlegroups.com> Just an observation on what I've noticed in this thread. Rather than celebrate 30 years and all the efforts it probably took to get the Mark Hurd video and web site put together, it turned into yet another gripe session. I did like the splitting hairs on the bald guy comment. My thanks and appreciation to Sue and all the others that I probably don't know who put together the 30th anniversary stuff. Happy Anniversary VMS !!! Dave... ------------------------------ Date: Fri, 26 Oct 2007 07:25:27 -0700 From: DaveG Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <1193408727.391603.79760@19g2000hsx.googlegroups.com> On Oct 25, 9:31 am, "Syltrem" wrote: > > HP doesn't care about all the people who have bet their careers on VMS and > > whose skills are now worthless and unmarketable, we're going down with the > > ship and it won't affect any of their real customers on Wintel and HP-UX. > > HP will give us a bit of music to appease us, and keep telling us that the > > ship is unsinkable and to not worry about the rising water. At one point, > > HP will make an announcement that the ship cannot be recovered and will > > sink momentarily. > > I won't be able to attend the webcast tomorrow. > > Can someone ask Martin Fink (at the webcast) why there's not a link on thewww.hp.compage to that 30 years celebration ? > That's not expensive to do at all, and would add some visibility. > After all, HP is celebrating, or is it not.? > > Please do not answer ! Let Mr. Fink do. > > Thanks > Syltrem I sent a note to Martin Fink and Scott Stallard on this and got a reply from Stallard. There is a link from the Enterprise home page for servers, with an interesting title "The amazing OS you've never heard of". http://welcome.hp.com/country/us/en/prodserv/servers.html He also mentioned that he asked the corp HP team for a link at the top page. Dave... ------------------------------ Date: Fri, 26 Oct 2007 15:38:37 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <1SnUi.12283$ZA.8010@newsb.telia.net> DaveG wrote: > Just an observation on what I've noticed in this thread. > > Rather than celebrate 30 years and all the efforts it probably took to > get the Mark Hurd video and web site put together, it turned into yet > another gripe session... I totaly agree !! Someone complainted on that HP aren't helping those who make their living on VMS. Well, *I* have no problem with *HP*. The largest threat against me making my living on VMS seems to come from cov itself... I just couldn't care less if this and that doesn't run on a VAX (or a uV-II in particular). > My thanks and appreciation to Sue and all the others that I probably > don't know who put together the 30th anniversary stuff. It's a mistery to me how Sue can stand all the neg feedback on just about every post she does ! Amazing... Best Regards, Jan-Erik. ------------------------------ Date: Fri, 26 Oct 2007 11:44:54 -0400 From: "Syltrem" Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <13i42rn8r2jss7a@corp.supernews.com> "DaveG" wrote in message news:1193411360.720813.301570@o3g2000hsb.googlegroups.com... > Just an observation on what I've noticed in this thread. > > Rather than celebrate 30 years and all the efforts it probably took to > get the Mark Hurd video and web site put together, it turned into yet > another gripe session. > > I did like the splitting hairs on the bald guy comment. > > My thanks and appreciation to Sue and all the others that I probably > don't know who put together the 30th anniversary stuff. > > Happy Anniversary VMS !!! > > Dave... > I second that. Indeed that is all good work and it`s important that it doesn`t stay just between us. I`m glad to see the Servers page has a link to it. Thanks for following up on this. There should also be something to catch the eye, on this page: http://welcome.hp.com/country/us/en/prodserv/software_os.html Long live VMS ! Syltrem ------------------------------ Date: Fri, 26 Oct 2007 12:03:06 -0400 From: "Peter Weaver" Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <18a401c817e9$b2a20300$2802a8c0@CHARONLAP> > Visit > http://h71000.www7.hp.com/openvms/30th/index.html > and see Mark Hurd talk about VMS!!! > > Post your own message at http://h71000.www7.hp.com/fb_30years.html > Happy anniversary VMS. I have been using VMS to put food on my table since 9-JUL-1984. The late Chris Moore used to kid that I was a newbie since he had his first VMS system delivered on 3-JUL-1984, I never had the heart to tell him that I spent three years in college learning about computers on a VAX :) Congratulations to everyone involved in the greatest operating system in the world. Here's to the next 30. Peter Weaver www.weaverconsulting.ca CHARON-VAX CHARON-AXP DataStream Reflection PreciseMail HP Commercial Hardware ------------------------------ Date: Fri, 26 Oct 2007 13:29:04 -0400 From: JF Mezei Subject: Re: Happy Anniversary VMS - 30 years young Message-ID: <68a8$472223e3$cef8887a$19021@TEKSAVVY.COM> Bob Koehler wrote: > In article , Dirk Munk writes: >> With that in mind, I wonder if anyone noticed that Mr. Hurd said that HP >> would support OpenVMS , not support and continue to develop OpenVMS > Maybe you're splitting hairs on a bald man. The fact that a customer would make such a statement is indicative that there isn't much trust in HP truly intending to leverage the full potential of VMS. The fact that Hurd only talks to the VMS community instead of celebrating VMS' 30th anniversary with the media at large is also an indication that even on its birthday, VMS isn't good enough to HP to be mentioned in the real world. And when talking to the VMS community, if the best he can come up with is "continue to support", then that says a lot about just how far HP is willing to go with VMS. And as long as the HP staff loyal to VMS are unwilling to admit that there is a problem with VMS within HP and continue to paint a rosy picture and deny all our fears, then the VMS community will not rise up to convince HP upper management to change their strategy with regards to VMS. Nobody is asking HP to stop making expensive plastic cartridges with a few mm of coloured water in them. But that does not prevent HP from allowing VMS to be marketed and giving it back the human resources needed to continue proper development of VMS and give it a shot of energy to help fix all the problems started by Palmer, Curly and Carly. ------------------------------ Date: Fri, 26 Oct 2007 07:19:13 -0700 From: magalettac@hotmail.com Subject: inCorrect free space on disks Message-ID: <1193408353.875312.311250@d55g2000hsg.googlegroups.com> Hi, ------------------------------ Date: Fri, 26 Oct 2007 07:19:16 -0700 From: magalettac@hotmail.com Subject: inCorrect free space on disks Message-ID: <1193408356.361306.167560@22g2000hsm.googlegroups.com> Hi, ------------------------------ Date: Fri, 26 Oct 2007 07:19:15 -0700 From: magalettac@hotmail.com Subject: inCorrect free space on disks Message-ID: <1193408355.059142.90640@o3g2000hsb.googlegroups.com> Hi, ------------------------------ Date: Fri, 26 Oct 2007 07:19:18 -0700 From: magalettac@hotmail.com Subject: inCorrect free space on disks Message-ID: <1193408358.186346.220530@o38g2000hse.googlegroups.com> Hi, ------------------------------ Date: Fri, 26 Oct 2007 11:31:11 -0400 From: "Syltrem" Subject: Re: inCorrect free space on disks Message-ID: <13i4221isest0bd@corp.supernews.com> $ set volumeérebuild=force ddcu: Is this what you need to know ? SET VOLUME /REBUILD /REBUILD[=FORCE] Recovers caching limits for a volume that was dismounted improperly. If a disk volume was dismounted improperly (such as during a system failure), and was then remounted with the MOUNT/NOREBUILD command, you can use SET VOLUME/REBUILD to recover the caching that was in effect at the time of the dismount. The FORCE option forces the disk to be rebuilt unconditionally, thus updating the free block count in the disk volume's lock value block. HTH Syltrem wrote in message news:1193408353.875312.311250@d55g2000hsg.googlegroups.com... > Hi, > ------------------------------ Date: Fri, 26 Oct 2007 11:06:03 -0000 From: Thomas Dickey Subject: Re: lexical for terminal attributes? Message-ID: <13i3igro3pemf1d@corp.supernews.com> Arne Vajhøj wrote: > PS: That code require a damn good terminal emulator to work ! ...particularly since it is using a feature which is not documented: \E["v -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ------------------------------ Date: Fri, 26 Oct 2007 11:27:02 -0000 From: Hein RMS van den Heuvel Subject: Re: lexical for terminal attributes? Message-ID: <1193398022.158941.17170@k79g2000hse.googlegroups.com> On Oct 26, 7:06 am, Thomas Dickey wrote: > Arne Vajh=F8j wrote: > > PS: That code require a damn good terminal emulator to work ! > > ...particularly since it is using a feature which is not documented: > > \E["v > > -- > Thomas E. Dickeyhttp://invisible-island.netftp://invisible-island.net Yeah I seem to recall many a screen manager (FMS, DECforms?) to get the width by telling the terminal to place the cursor a far lower right corner (99,999) and then ask for a cursor report. fwiw, Hein. ------------------------------ Date: 26 Oct 2007 10:33:44 +0200 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: Pathworks vs CIFS performance Message-ID: <4721c288$1@news.langstoeger.at> In article , VMS is Virus Free writes: >The problem we face is that our main production VMS cluster is running >VMS V7.3-2. It would be most difficult to marshall the resources to >upgrade it to V8.3 which CIFS requires. Management's view: VMS is dead >and we're getting rid of it. Reality view: the VMS systems run at 70% >to 100% CPU all day long. They are minimally 4 CPU systems with 8 GB >of memory, relatively new EV levels and are well tuned. They are just >used because they can reliably put out the work, especially when >compared to other more, umm, "modern" GUI based systems. Oh I understand. I fight such management views for the last decades and lost. Because DEC, COMPAQ and now HP always proved the management right. But technically, go upgrade to VMS V8.3. VMS Performance and TCPIP features/ bugfixes/performance seems worth it. Only problem is see with V8.3 is with the new root feature (see $ SHOW ROOT $ SET ROOT) for GNV (and GNV itself). There is still A LOT missing to make this feature on par with VMS quality. >Why not try it out ourselves? Well, we are testing but that's nothing >like real-life experiences. For us to propose the upgrade and get it >approved, there needs to be strong business reasons to do so. We had problems with our application with TCPIP scalable kernel and this was mandatory since TCPIP V5.5 so we had to stay on VMS V7.3-2 (= UCX V5.4). But we would love to use our application on VMS 8.3 to gain the performance. But now that we heard that the application runs on TCPIP scalable kernel, we haven't upgraded so far. We have now other work to do (and most is not technical but administrative and boring) and upgrade is postponed. Maybe there is VMS V8.4 then (and the game starts again)... >Management's view is that (a) it's working okay, (b) don't mess with >it, and (c) it's going away. Well, it's been going away for the last 5 >years; it'll likely be running 5 years from now. We have only 1-2 years left, because then our MARVELs are too old and application is still not running on Itanic and so we are forced to switch to Solaris (which demoes some performance advantages of up to 400% already with Oracle Classic - so first mover will be our Oracle Database RSN). >So with that atmosphere, the answer is quite simply that we need to >know that the effort will be worth the reward. What I've been able to >read on the CIFS literature speaks nothing about performance, only >functionality. That's why I'm asking those that may have already been >done this path to offer their experiences. I see, but I can't help. CIFS will only run on my DS10/XP1000/zx6000 @home next year (but then again, 1-3 clients is not comparable to you ;-) Good luck (and tell us how it went) -- 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: 26 Oct 2007 07:47:07 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Pathworks vs NFS Message-ID: In article <-5udnWzGLsLB-rzanZ2dnUVZ_qqgnZ2d@giganews.com>, VMSQuest Reborn writes: > We have been using Pathworks for several years now, serving about 1 TB > of data to about 15,000 users. > > Some people here at my workplace are proposing a "Pathworks replacement" > that entails a NetApps solution which, according to some NetApps folk, > implies NFS for serving the VMS-based files. > > To me, comparing Pathworks to NFS is barely comparing fruit to fruit, > let alone apples to apples. I used PCNFS to connect PC's to Solaris systems. NFS has been known to have secutiry problems, many of which have been addressed, but NFS is still very UNIX-centric. You will have problems accessing VMS files from PCs and PC files from VMS since NFS doesn't understand anything but UNIX byte stream files. We had similar, but smaller, problems between Solaris' UNIX conventions and PCs. (PCs use simlilar byte stream files with different text line conventions). Pathworks knows about this and uses RMS extensions added primarily to support Windows to help deal with it. But you'll have little problem accessing VMS files from VMS and PC files from PCs. Windows has its own ideas of how to lock files from multiple access. NFS does not enforce such things on its own, but an application can ask it to. You need to verify that NetApps will enforce Windows' file locks (I suspect it does). And of course, choose your NFS server vendor for VMS wisely. ------------------------------ Date: Fri, 26 Oct 2007 03:15:58 -0400 From: JF Mezei Subject: Re: Some success with VMS-NFS serving OS-X Message-ID: <80195$47219431$cef8887a$19965@TEKSAVVY.COM> I have had mild success using VMS as a NFS client on a MAC: $TCPIP MOUNT DNFS1:/HOST=BRAKES/PATH="/"- /UID=501/GID=501/SERVER=UNIX/STRUCT=5 $CD DNFS1:[Users.JFMEZEI] > $ dir > > Directory DNFS1:[Users.JFMEZEI] > > .bash_history;1 .CFUserTextEncoding;1 .DS_Store;1 > ^.fonts.cache-1;1 .lpoptions;1 ^.ssh.DIR;1 ^.Trash.DIR;1 > .viminfo;1 .Xauthority;1 alpha_artwork010.zip;1 > cycle.DIR;1 Desktop.DIR;1 Digital_DEClaser_5100_v2013.ppd;1 > DMA0.DIR;1 DMA1.DIR;1 Documents.DIR;1 felix.DIR;1 > Library.DIR;1 Movies.DIR;1 Music.DIR;1 > Network^_Trash^_Folder.DIR;1 Pictures.DIR;1 Public.DIR;1 > Railroad^_Tycoon^_II^_Demo.DIR;1 various.DIR;1 VMS^_docs.DIR;1 > > Total of 26 files. The /SERVER=UNIX seems to have been the key change to make it work. The HELP mentions that "UNIX" is the default value, but I suspect that when a VMS sytstem connects to a MAC server, it probably overrides the default unless you put in it. > Disk DNFS1: (CHAIN), device type Foreign disk type 7, is online, mounted, file- > oriented device, shareable, accessed via DFS or NFS. > > Error count 0 Operations completed 1498 > Owner process "" Owner UIC [SYSTEM] > Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL > Reference count 1 Default buffer size 512 > Total blocks 38835000 Sectors per track 0 > Total cylinders 0 Tracks per cylinder 0 > Allocation class 11 > > Volume label "BRAKES$/" Relative volume number 0 > Cluster size 0 Transaction count 1 > Free blocks unknown Maximum files allowed 0 > Extend quantity 0 Mount count 1 > Mount status System ACP process name "DNFS1ACP" > > Volume Status: ODS-5, access dates enabled. However: >$ create Québec.txt >%CREATE-E-OPENOUT, error opening DNFS1:[USERS.JFMEZEI]QUÉBEC.TXT; as output >-RMS-E-CRE, ACP file create failed >-SYSTEM-F-DRVERR, fatal drive error And if I rename on the mac the "felix" folder to "félix", it comes out as: feÌ^81lix.DIR;1 in a DIR command on VMS. However, from what I have read (and this appears to change from version to version on the mac, the NFS software may not be fully "aware" of the latin1 and mac character encodings so the lack of accended character support might be understandable. ------------------------------ Date: 26 Oct 2007 07:50:41 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Some success with VMS-NFS serving OS-X Message-ID: <2lFrQqPr2hkX@eisner.encompasserve.org> In article <80195$47219431$cef8887a$19965@TEKSAVVY.COM>, JF Mezei writes: > > The /SERVER=UNIX seems to have been the key change to make it work. The > HELP mentions that "UNIX" is the default value, but I suspect that when > a VMS sytstem connects to a MAC server, it probably overrides the > default unless you put in it. On a vaguely related note, does anyone know what Filezilla (a Windows FTP/SFTP client) is looking for to determine that it's talking to a VMS server? Filezilla works well with my VMS systems, but doesn't honor its own VMS specific settings (e.g. show all versions). I'm running Multinet 4.4 and 5.2, _not_ in UNIX emulation mode. ------------------------------ Date: Fri, 26 Oct 2007 07:09:14 +0000 (UTC) From: gartmann@nonsense.immunbio.mpg.de (Christoph Gartmann) Subject: Re: Standalone backup on Alpha? Message-ID: In article , morris@osmium.mv.net (Skipper W. Morris) writes: >I know that for Alpha you're supposed to use AXPVMS$PCSI_INSTALL_MIN.COM >to build a minimum bootable system on some *other* device to boot and >run standalone backups. > >What I'd like to do is just build a minimum bootable root on my primary >system disk so I don't have to fuss with a CD just to do backups. > >Anyone ever tried this? Is it feasible? And what do you do if your system disk fails? Regards, Christoph Gartmann -- Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452 Immunbiologie Postfach 1169 Internet: gartmann@immunbio dot mpg dot de D-79011 Freiburg, Germany http://www.immunbio.mpg.de/home/menue.html ------------------------------ Date: Fri, 26 Oct 2007 09:53:50 +0100 From: "Roger Fraser" Subject: Re: Standalone backup on Alpha? Message-ID: <4721a7df$1_1@glkas0286.greenlnk.net> "Christoph Gartmann" wrote in message news:ffs3qq$shi$1@news.belwue.de... > In article , morris@osmium.mv.net (Skipper W. > Morris) writes: >>I know that for Alpha you're supposed to use AXPVMS$PCSI_INSTALL_MIN.COM >>to build a minimum bootable system on some *other* device to boot and >>run standalone backups. >> >>What I'd like to do is just build a minimum bootable root on my primary >>system disk so I don't have to fuss with a CD just to do backups. >> >>Anyone ever tried this? Is it feasible? > > And what do you do if your system disk fails? > > Regards, > Christoph Gartmann > > -- > Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452 > Immunbiologie > Postfach 1169 Internet: gartmann@immunbio dot mpg dot de > D-79011 Freiburg, Germany > http://www.immunbio.mpg.de/home/menue.html Why not just build VMS on a spare disk or, possibly, leave the approriate CD in the drive and boot off that? That covers primary system disk failure! Regards, Roger -- Roger Fraser - CSC Computer Sciences ------------------------------ Date: Fri, 26 Oct 2007 05:07:14 -0700 From: FrankS Subject: Re: Standalone backup on Alpha? Message-ID: <1193400434.727726.33890@50g2000hsm.googlegroups.com> On Oct 25, 7:22 pm, mor...@osmium.mv.net (Skipper W. Morris) wrote: > What I'd like to do is just build a minimum bootable root on my primary > system disk so I don't have to fuss with a CD just to do backups. I know you can do a $BACKUP/IMAGE of the boot CD-ROM onto a disk drive, and it becomes bootable. You might want to look at doing that and then transferring those files to an alternate root on the system disk. I haven't tried it, but there's probably a way to make it happen. The other thing is to avoid the issue altogether. Move any volatile files off the system disk completely. You could then do regular backups of that alternate disk, and just a "once-in-a-blue-moon" standalone backup of whatever's left on the system disk. ------------------------------ Date: Fri, 26 Oct 2007 05:20:14 -0700 From: AEF Subject: Re: Standalone backup on Alpha? Message-ID: <1193401214.005745.299290@o80g2000hse.googlegroups.com> On Oct 26, 8:07 am, FrankS wrote: > On Oct 25, 7:22 pm, mor...@osmium.mv.net (Skipper W. Morris) wrote: > > > What I'd like to do is just build a minimum bootable root on my primary > > system disk so I don't have to fuss with a CD just to do backups. > > I know you can do a $BACKUP/IMAGE of the boot CD-ROM onto a disk > drive, and it becomes bootable. You might want to look at doing that > and then transferring those files to an alternate root on the system > disk. I haven't tried it, but there's probably a way to make it > happen. > > The other thing is to avoid the issue altogether. Move any volatile > files off the system disk completely. You could then do regular > backups of that alternate disk, and just a "once-in-a-blue-moon" > standalone backup of whatever's left on the system disk. Doesn't that just move the open-for-write files to another disk with along with the same problem? If those volatile files are open for write -- and they will be -- you've got the same problem whether they're on the system disk or another disk. Right? AEF ------------------------------ Date: 26 Oct 2007 07:37:37 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Standalone backup on Alpha? Message-ID: In article <1193401214.005745.299290@o80g2000hse.googlegroups.com>, AEF writes: > > Doesn't that just move the open-for-write files to another disk with > along with the same problem? If those volatile files are open for > write -- and they will be -- you've got the same problem whether > they're on the system disk or another disk. Right? The idea of standalone backup, and of building a bootable system on a separate drive, and of booting the CD, is that you can idle your systems and close all the files on any other disk than the system disk and backup all those fully, but not the system disk. So you boot off something else, backup the normal system disk, and then boot the normal system. All of which means downtime for your system, but gets you a pristine image of your system disk. Depending on your needs, there a several workarounds. You may be able to have application down time. You may be able to shadow your system disk and temporarily take one copy off line. You may be able to get by with a less than perfect image of your system disk. You may have multiple system disks in a cluster and dual path them solely for backup purposes. You may have an intelligent disk subsystem that can snapshot data for you. You may be able to get the downtime for one system because your cluster keeps the application up. I'm sure there are others. ------------------------------ Date: Fri, 26 Oct 2007 13:12:13 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Standalone backup on Alpha? Message-ID: Bob Koehler wrote: > You may be > able to get by with a less than perfect image of your system disk. I've many times runed /image backups online from system disks, both for "backup" but also for building a totaly new/separate system. I can not recall a single time when an online image of the system disk was unusable. Of course, it might help if no system manager is doing UAF-type of work during the backup... Jan-Erik. ------------------------------ Date: Fri, 26 Oct 2007 07:00:59 -0700 From: AEF Subject: Re: Standalone backup on Alpha? Message-ID: <1193407259.284103.92540@22g2000hsm.googlegroups.com> On Oct 26, 8:37 am, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <1193401214.005745.299...@o80g2000hse.googlegroups.com>, AEF writes: > > > > > Doesn't that just move the open-for-write files to another disk with > > along with the same problem? If those volatile files are open for > > write -- and they will be -- you've got the same problem whether > > they're on the system disk or another disk. Right? > > The idea of standalone backup, and of building a bootable system > on a separate drive, and of booting the CD, is that you can idle > your systems and close all the files on any other disk than the > system disk and backup all those fully, but not the system disk. > > So you boot off something else, backup the normal system disk, and > then boot the normal system. > > All of which means downtime for your system, but gets you a > pristine image of your system disk. > > Depending on your needs, there a several workarounds. You may be > able to have application down time. You may be able to shadow > your system disk and temporarily take one copy off line. You may be While this is probably better than a hot backup of the system disk, a disk removed from a shadow set is considered "improperly dismounted" and may still contain -- but I'd think is much less likely to -- inconsistincies. > able to get by with a less than perfect image of your system disk. I've never had a hot system disk backup that didn't boot. But I think there is a chance that some inconsistencies may exist between SYSUAF.DAT and RIGHTSLIST.DAT, for example, or in the queue files. But I don't recall ever having that problem. I suppose you could also end up with problems with accounting, audit, and operator files. > You may have multiple system disks in a cluster and dual path them > solely for backup purposes. You may have an intelligent disk subsystem > that can snapshot data for you. You may be able to get the downtime > for one system because your cluster keeps the application up. > > I'm sure there are others. AEF ------------------------------ Date: Fri, 26 Oct 2007 13:42:59 -0400 From: JF Mezei Subject: Re: Standalone backup on Alpha? Message-ID: OK, different slant: What is truly needed to make a bootable disk ? Could the following work ? create a [SYS0] and copy to it: [SYS0.SYSEXE], and the VMS$COMMON version of: [SYSEXE] SYS$LDR SYSLIB SYSMGR (so all those would reside directly under [SYS0]) use WRITEBOOT to make that disk bootable, and then use SYSGEN to make that system minimal (no cluster, STARTUP_P1 = MIN, no page/swap files etc) ? On Microvax, there was no VMS$COMMON/SYS$COMMON hiearchy, everything was directly under SYS0. For Alpha, would there still be that capability to find everything under [SYS0] or is there some harcoding that requires those directories to reside in [SYS0.SYSCOMMON] AND [VMS$COMMON...] (aka, the aliases) ? ------------------------------ Date: Fri, 26 Oct 2007 17:46:17 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Standalone backup on Alpha? Message-ID: In article , JF Mezei writes: > On Microvax, there was no VMS$COMMON/SYS$COMMON hiearchy, everything was > directly under SYS0. Microvax is hardware; what you are referring to is a software issue. ------------------------------ End of INFO-VAX 2007.586 ************************