INFO-VAX Sat, 15 Dec 2007 Volume 2007 : Issue 686 Contents: Re: "snapshot" backup and HBVS Re: "snapshot" backup and HBVS Re: Compiling ANU-NEWS on Alpha? RMS v. CRTL: "ctx = stm" string Forces stream mode access. Re: RMS v. CRTL: "ctx = stm" string Forces stream mode access. ZKO to close ---------------------------------------------------------------------- Date: Sat, 15 Dec 2007 11:22:12 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: "snapshot" backup and HBVS Message-ID: In article , moroney@world.std.spaamtrap.com (Michael Moroney) writes: > helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > > >In article > >, > >norm.raphael@metso.com writes: > > >> ITSM it was suggested that the third member cosist of a 2-spindle > >> mirror-set > >> from the SAN. Then, if you need to use the third volume, you split it > >> into > >> two separate 1-spindle LUNs and mount them as a shadow-set pair. > > >Will that force a full copy? > > No. > > However, you have to be careful with the MOUNT command since the disks > will have the same label as the shadowset they came from but different > VMS device names, which will not match the names in the SCB. Precisely. In the case that I have to resort to the backup, then of course the first time I make a new backup copy, it has to be a full copy. There is no way around that. However, even if the contents are the same, if I split a mirror set and then mount it as a shadow set, as far as VMS is concerned this is a new shadow set---VMS doesn't know that the contents are identical. Surely it's not enough to just say No when asked if a full copy should be done?! ------------------------------ Date: Sat, 15 Dec 2007 15:58:08 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: "snapshot" backup and HBVS Message-ID: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > However, even if the contents are >the same, if I split a mirror set and then mount it as a shadow set, as >far as VMS is concerned this is a new shadow set---VMS doesn't know that >the contents are identical. Sure it does. When you issue a $ MOUNT, MOUNT looks at the SCB and sees the disk is a shadowset and acts appropiately. If you issue a $ MOUNT /SHADOW=(member1,member2), MOUNT sees the two members are consistent (since the SCBs are identical and that of a shadowset member, or had better be!) so it knows it can form a shadowset with no copy required, as long as they were full members when removed from the original shadowset. However the shadowset members listed in the SCB will *not* match the names of the former RAID set members so you have to be careful not to specify parameters such as /INCLUDE. > Surely it's not enough to just say No when >asked if a full copy should be done?! It'll know that no copy is necessary. ------------------------------ Date: Sat, 15 Dec 2007 12:14:08 +0000 (UTC) From: gartmann@nonsense.immunbio.mpg.de (Christoph Gartmann) Subject: Re: Compiling ANU-NEWS on Alpha? Message-ID: In article , cook@wvnvms.wvnet.edu (George Cook) writes: >If the logical NEWS_ROOT is defined and neither /NETSERVER or >/NETPROTOCOL is given on the NEWS command, it should default to >accessing the local files directly? Here it does not. NEWS_ROOT is defined. >Does the NEWSMGR account have the identifier specified by the logical >NEWS_MGR_ID? Yes, it does. >Does the NEWSMGR's NEWSRC. file have >PROFILE >NEWREGISTER=none > >at the end? This is not the case. >This will prevent the new group questions? The new group question aren't a problem. If there is no DECNET and no NEWSRC NEWS asks for the protocol (DECNET or TCP) and for the host to connect to. If DECNET is running NEWS will create NEWSRC automatically. Will NEWS/NONETSERVER allow to run NEWS without DECNET? 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: Sat, 15 Dec 2007 01:41:04 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: RMS v. CRTL: "ctx = stm" string Forces stream mode access. Message-ID: <07121501410472_202647DE@antinode.org> When I use the C RTL open() to open a file, I can specify "ctx=stm", which, according to the HELP, "Forces stream mode access". I'd be grateful if someone could tell me what, if anything, this does to the FAB, RAB, or any other RMS structure. (I'd like to be able to fiddle with this setting in an access callback function, but I don't know what it does where.) ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sat, 15 Dec 2007 05:02:29 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: RMS v. CRTL: "ctx = stm" string Forces stream mode access. Message-ID: <61cc0d5c-140b-490f-8c70-4d6f9fab74e4@y5g2000hsf.googlegroups.com> On Dec 15, 2:41 am, s...@antinode.org (Steven M. Schweda) wrote: > When I use the C RTL open() to open a file, I can specify "ctx=stm", > which, according to the HELP, "Forces stream mode access". I'd be > grateful if someone could tell me what, if anything, this does to the > FAB, RAB, or any other RMS structure. It tells the CRTL to go ahead and use NON RMS byte access. The CRTL then uses RMS SYS$READ and SYS$WRITE calls to do BLOCKIO to the file and interprets the record structure itself. What it does to the RAB and FAB is best observed using ANALYZE/ SYSTEM ... SET PROC ... SHOW PROC/RMS=(RAB,FAB,FSB) The FSB is the statistics block which of course will only be there if you have done a SET FILE/STATS before the open. hth, Hein. (I'd like to be able to fiddle > with this setting in an access callback function, but I don't know what > it does where.) > > ------------------------------------------------------------------------ > > Steven M. Schweda sms@antinode-org > 382 South Warwick Street (+1) 651-699-9818 > Saint Paul MN 55105-2547 ------------------------------ Date: Wed, 12 Dec 2007 09:28:32 -0500 From: Charles Coldwell Subject: ZKO to close Message-ID: I have it on good authority that HP are closing the ZKO facility on Spit Brook Road in Nashua, New Hampshire. The jobs are moving to the Marlborough, Massachusetts facility. Chip -- Charles M. Coldwell "Turn on, log in, tune out" Somerville, Massachusetts, New England GPG ID: 852E052F GPG FPR: 77E5 2B51 4907 F08A 7E92 DE80 AFA9 9A8F 852E 052F ------------------------------ End of INFO-VAX 2007.686 ************************