INFO-VAX Tue, 23 Jan 2007 Volume 2007 : Issue 45 Contents: Re: File rename fault tolerance?? Re: Going from Pathworks 7.3 to Samba Re: Going from Pathworks 7.3 to Samba Re: How long to really setup a VMS system ? Re: How to get the codec from a file ? Re: How to get the codec from a file ? Re: How to get the codec from a file ? Re: INTRINSICDECL informational on snprintf with 64-bit pointers Re: INTRINSICDECL informational on snprintf with 64-bit pointers Re: Nonstop UNIX takes another loss Re: ODD SYSMAN IO CONNECT on Alpha PerlMagick link issue, IA64 8.3 / CC 7.2 Re: PerlMagick link issue, IA64 8.3 / CC 7.2 Re: Quorum disk removal Re: SHOW TERMINAL glitch (PPP) Re: strange LINK error Re: Suggestion: Failover logical names Re: Suggestion: Failover logical names Re: VMS Related: Off-the-wall Reflection scripting question ---------------------------------------------------------------------- Date: Mon, 22 Jan 2007 22:17:37 -0500 From: Bill Todd Subject: Re: File rename fault tolerance?? Message-ID: Bob Koehler wrote: > In article <1169151429.398844.106240@q2g2000cwa.googlegroups.com>, "Don" writes: >> If the system is powered off (or similar failure) in the middle of this >> operation, and assuming the disk still functions after reboot, will one >> of the files exist? > > Yes, the file will exist. Nothing you are doing will remove the > file, it's header, or its INDEX.SYS entry. At least one of the > names will be entered in the directory. If the directory entries > are located in two different physical blocks in the directory file > there is a small possibility that both entries will exist, in which > case one of them will look like an alias (the header has to get > updated, it can only back link to one of them). IIRC that's indeed what we used to do on RSX (which of course had no version-limit issues to worry about), but I wouldn't bet against Hein on what VMS does in this area. I'm not sure what kind of 'fault tolerance' the original poster was talking about, but if it had any concept of tracking progress such that an operation could be picked up where it left off then one not-too-complex approach would be to create an alias for the file before renaming it and delete the alias afterward: on restart/recovery, the presence of the alias would be an indication that the status of the operation should be checked and if necessary corrected. - bill ------------------------------ Date: Mon, 22 Jan 2007 22:55:54 -0600 From: John Subject: Re: Going from Pathworks 7.3 to Samba Message-ID: <45B5955A.4030508@comcast.net> tomarsin2015@comcast.net wrote: >Hello >We are using Pathworks 7.3 on the Alpha and Pathworks 6.1 and even 5.0E >on the VAX. Since Pathworks is dead has anybody switch to Samba with >little pain? The reason I'm asking is we are thinking of upgrading to >8.3 (IA64) and retiring the VAX. Right now we use Windows 2000 server >with Win2k PRO. We will be going to Windows 2003 server and XP PRO and >what ever since billy gates demands. >thanks >phillip > > This brings me to 3 questions: 1) News to me that A/S (PWRK) is dead - when did this happen (I sleep often by the way...) 2) SAMBA vs. A/S - what are the advantages? 3) Can SAMBA and A/S coexist on the same server? ------------------------------ Date: 22 Jan 2007 22:02:16 -0800 From: davidc@montagar.com Subject: Re: Going from Pathworks 7.3 to Samba Message-ID: <1169532136.532953.100970@l53g2000cwa.googlegroups.com> John wrote: > This brings me to 3 questions: > > 1) News to me that A/S (PWRK) is dead - when did this happen (I sleep > often by the way...) Not that long ago. From what I understand, Microsoft isn't providing source licenses to people such that continued ports can be done, especially to more recent CIFS protocols. Besides, HP has to pay a portion of every Pathworks license sold to MS, so that's probably a pain. > 2) SAMBA vs. A/S - what are the advantages? The price is right, and since HP (and many others) are working on the source code, it's probably going to be better supported. Many people used it instead of Pathworks, anyway. > 3) Can SAMBA and A/S coexist on the same server? No, due to TCP port conflicts. ------------------------------ Date: Mon, 22 Jan 2007 21:24:12 +0100 From: Wilm Boerhout Subject: Re: How long to really setup a VMS system ? Message-ID: <45b51d6c$0$8319$ba620dc5@nova.planet.nl> on 22-1-2007 9:06 Jan-Erik Söderholm wrote... [snip] > Now, *those* "tools/facilities" are hardly installed on a very large > number of the OpenVMS systems in *PROFESSIONAL* use. Hear, hear! Please keep MMS and compilers as far away from production systems as possible. On a development system, sure. On a test system, maybe. On a production system, shoo, shoo! /Wilm ------------------------------ Date: Mon, 22 Jan 2007 13:02:17 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: How to get the codec from a file ? Message-ID: <07012213021760_2020028F@antinode.org> From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > In article <45b4c743$0$4618$9b622d9e@news.freenet.de>, "Klaus-D. Bohn" writes: > > Hello all together, > > > > how i get the codec from a file? > > codec? What dictionary is that word listed in? Same one as has "modem", I'd reckon. Coder-decoder. http://en.wikipedia.org/wiki/Codec You should get out more. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Mon, 22 Jan 2007 18:27:28 -0500 From: Stephen Hoffman Subject: Re: How to get the codec from a file ? Message-ID: Klaus-D. Bohn wrote: > how i get the codec from a file? > > In Unix you could only use "file -i filename". > > file -i test1.txt > text/plain; charset=utf-8 > > file -i test2.txt > text/plain; charset=iso-8859-1 > > To get theses information in a higher language ( C oder C++ ) will be nice. The OpenVMS file system is massively different than that of Unix. Carrying over assumptions here -- in either direction -- can get you into a degree of difficulty ranging from annoyance to forget-about-it. file -i returns the MIME type for the file, and applications on OpenVMS will generally deals with this by guesswork and assumption. OpenVMS has very large structures dealing with the file contents and record structures, accessible through language keywords, through the direct RMS interface and its FAB, RAB and other blocks, and through the XQP file system level and the ACP QIO IO$_ACPCONTROL I/O interface. There's an included heirarchical database system that most applications explicitly or implicitly use, too. None of which really maps easily into Unix. OpenVMS applications will only typically use ASCII or maybe MCS or ISO 8859-1 in files, and generally manages constructs like language-specific sorts with the NCS mechanisms. ISO 8859-1 Latin 1 is a very direct descendant of MCS, FWIW. In Unix terms, most sequential text files on OpenVMS would be assumed to be: text/plain; charset=us-ascii That written, the record structures can differ and stuff going after raw bytes can get into trouble. Characters stored within files might well use Unicode or any of the ISO encodings, but that's managed strictly by the application -- OpenVMS itself and utilities such as TYPE doesn't really know from Unicode, MIME encoding or other such, save in specific contexts. If an application presents this sort of detail, it's generally inferred. Applications do generally know where the records within a file will start and end, through the use of RMS and its record structures. There are tools around that have tagged files with attributes, such as the PATHWORKS Server environment. These use access control list entries (ACEs) to store this sort of detail. But these tools tend to not look at the file contents. And there's no central MIME type repository. The closest to what you are looking for here would probably involve the MIME file type lists lurking over in the Mozilla/CSWB/SWB web browser. It might also be interesting to see what GNV does here, too. I'd almost have to assume that GNV it contains a list and some guesswork-related logic. Full source code to GNV is available -- haven't looked to see if GNV contains the file -i command, however. GNV: http://gnv.sourceforge.net/index.html https://sourceforge.net/projects/gnv/ I'd have to assume that the Apache/CSWS/SWS web server simply assumes text/plain ASCII. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Mon, 22 Jan 2007 21:31:58 -0600 From: David J Dachtera Subject: Re: How to get the codec from a file ? Message-ID: <45B581AE.565418FA@spam.comcast.net> "Klaus-D. Bohn" wrote: > > Hello all together, > > how i get the codec from a file? > > In Unix you could only use "file -i filename". > > file -i test1.txt > text/plain; charset=utf-8 > > file -i test2.txt > text/plain; charset=iso-8859-1 > > To get theses information in a higher language ( C oder C++ ) will be nice. > > If there experience around the world, please help. As other have pointed out, there is only one way to determine the "codec": read a bit of the file and make a brash assumption based on what was read. There's no "magic" here. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Mon, 22 Jan 2007 18:03:51 -0500 From: Stephen Hoffman Subject: Re: INTRINSICDECL informational on snprintf with 64-bit pointers Message-ID: Joe Sewell wrote: > I just discovered something rather curious with DEC C V6.0-001 on > OpenVMS Alpha V7.3-2. ... > Yes, it's an informational, but it still bugs me. > > Any known workarounds, short of a compiler and/or OS upgrade? Suppress the informational itself? There's compiler syntax for that in recent versions. Look at the /WARNING qualifier's DISABLE stuff. There's probably a pragma for this, too. (Haven't tried this C code on the current V7.1 C compiler.) I'd not expect an OpenVMS upgrade would be beneficial here, and would assume that any change(s) or correction(s) here would likely involve the installation of a newer version of the C compiler. If it's been fixed. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Mon, 22 Jan 2007 19:35:59 -0500 From: "Ed Vogel" Subject: Re: INTRINSICDECL informational on snprintf with 64-bit pointers Message-ID: <45b55874$1@usenet01.boi.hp.com> "Joe Sewell" wrote in message news:1169478863.500759.70850@l53g2000cwa.googlegroups.com... >I just discovered something rather curious with DEC C V6.0-001 on > OpenVMS Alpha V7.3-2. > > Consider the following test program: > > #include stdio > > void main(void) > { > char buf[80]; > > snprintf (buf, 80, "This is a test.\n"); > } > > compiled with > > $ CC/POINTER_SIZE=64 TEST_SNPRINTF_64 > > I get a INTRINSICDECL error within stdio, complaining about the second > parameter being expected to be "long" but is a mere "unsigned int." > > Yes, it's an informational, but it still bugs me. > > Any known workarounds, short of a compiler and/or OS upgrade? > Not what I see: $ cc/ver DEC C V6.0-001 (GEM 4089L) on OpenVMS Alpha V7.3-2 $ typ t1.c #include stdio void main(void) { char buf[80]; snprintf (buf, 80, "This is a test.\n"); } $ cc t1/point=64 snprintf (buf, 80, "This is a test.\n"); ..^ %CC-I-IMPLICITFUNC, In this statement, the identifier "snprintf" is implicitly d eclared as a function. at line number 7 in file C3$:[VOGEL]T1.C;590 In any case, I would certainly suggest a compiler upgrade. V6.0 is over eight years old. Ed Vogel HP/Compaq/DEC C/C++ Engineering ------------------------------ Date: Mon, 22 Jan 2007 22:00:23 -0500 From: Bill Todd Subject: Re: Nonstop UNIX takes another loss Message-ID: Teijo Forsell wrote: > "Robert Deininger" wrote in message > news:rdeininger-1701072017170001@dialup-4.233.173.68.dial1.manchester1.level3.net... >> In article <1169065892.501523.148290@a75g2000cwd.googlegroups.com>, >> "n.rieck@sympatico.ca" wrote: >> >>> Robert Deininger wrote: >>>> In article <1169042285.377185.315540@51g2000cwl.googlegroups.com>, >>>> "n.rieck@sympatico.ca" wrote: >>>> >>>>> Nonstop UNIX takes another loss as the Toronto stock exchange moves to >>>>> LINUX on AMD Opteron or Intel Xeon >>>>> >>>>> http://www.itbusiness.ca/it/client/en/home/News.asp?id=41862 >>>> I wonder what they mean by "HP NonStop Unix". That name isn't familiar >> to me. > ... > > Tandem has two different hardware lines: PUMA and Himalaya. Himalayas run > the NonStop Kernel aka NSK, but the PUMA series runs the NonStop-UX, which > indeed is another variation of some common UNIX breed (which could the > System V that someones mentioned, but I don't know that). The PUMA series > definitely is much more unknown. Indeed. IIRC that server line used triple-module redundancy and was previously called 'Integrity', before HP decided that they needed that name to polish up the image of their Itanic offerings. - bill ------------------------------ Date: 22 Jan 2007 22:00:04 +0100 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: ODD SYSMAN IO CONNECT on Alpha Message-ID: <45b533e4@news.langstoeger.at> In article <45b4bb3a$0$22632$c3e8da3@news.astraweb.com>, JF Mezei writes: >Alpha VMS 8.3 > >I had: > >MC SYSMAN IO CONNECT SYS$VTA0 /NOADAPT/DRIVER=SYS$TTDRIVER Make this $ MC SYSMAN IO CONNECT VTA0 /NOADAPT/DRIVER=SYS$TTDRIVER -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Mon, 22 Jan 2007 16:45:48 -0800 From: DeanW Subject: PerlMagick link issue, IA64 8.3 / CC 7.2 Message-ID: <3f119ada0701221645g289b4a6axe25c0b02ffd6d83f@mail.gmail.com> Forgive me, I'm not normally dense, but the front of my head is a bloody pulp against this, and I can't seem to google up an answer, and yes, I'm a bit over my head here. The Makefile.PL script puts together C and Linker switches that a) just don't work, and b) mostly aren't necessary (3/4 of what I identify/recognize translates to default behavior w/o that option). I've gotten the source to compile, but the linker continues to barf with "too many parameter" errors. What I started out with (this is what the PerlMagick makefile build tool thinks would work): LDFLAGS = -L../magick/.libs -lMagick /NoTrace/Map/Full/Cross What I've gotten it down to: $ LINK Magick.opt/Option [-.Magick]libMagick.olb/LIB /NoTrace/Map/Full/Cross - $_ /Shareable=[.BLIB.ARCH.AUTO.IMAGE.MAGICK]PL_IMAGE__MAGICK.EXE magick.opt: SYMBOL_VECTOR=(boot_Image__Magick=PROCEDURE) [.blib.arch.auto.Image.Magick]Magick.olb/Include=Magick [.blib.arch.auto.Image.Magick]Magick.olb/Library sys$share:freetype/Library sys$share:tiff/Library sys$share:freetype/Library sys$share:libjpeg/Library sys$share:libbz2/Library sys$share:libz/Library sys$share:DECW$XLIBSHR/Share sys$share:DECW$XTSHR/Share PerlShr/Share Given that all the files referenced exist, here's what I get when I try to do that: %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters %MMK-F-ERRUPD, error status %X00038098 occurred when updating target [.BLIB.ARCH.AUTO.IMAGE.MAGICK]PL_IMAGE__MAGICK.EXE ------------------------------ Date: Tue, 23 Jan 2007 07:33:59 +0100 From: Jur van der Burg <"vdburg at hotmail dot com"> Subject: Re: PerlMagick link issue, IA64 8.3 / CC 7.2 Message-ID: <45b5ac5b$0$333$e4fe514c@news.xs4all.nl> >$ LINK Magick.opt/Option [-.Magick]libMagick.olb/LIB /NoTrace/Map/Full/Cross - >$_ /Shareable=[.BLIB.ARCH.AUTO.IMAGE.MAGICK]PL_IMAGE__MAGICK.EXE You need a comma between '/Option' and '[-.Magick]. Jur. DeanW wrote: > Forgive me, I'm not normally dense, but the front of my head is a > bloody pulp against this, and I can't seem to google up an answer, and > yes, I'm a bit over my head here. > > The Makefile.PL script puts together C and Linker switches that a) > just don't work, and b) mostly aren't necessary (3/4 of what I > identify/recognize translates to default behavior w/o that option). > I've gotten the source to compile, but the linker continues to barf > with "too many parameter" errors. > > What I started out with (this is what the PerlMagick makefile build > tool thinks would work): > LDFLAGS = -L../magick/.libs -lMagick /NoTrace/Map/Full/Cross > > What I've gotten it down to: > $ LINK Magick.opt/Option [-.Magick]libMagick.olb/LIB > /NoTrace/Map/Full/Cross - > $_ /Shareable=[.BLIB.ARCH.AUTO.IMAGE.MAGICK]PL_IMAGE__MAGICK.EXE > > magick.opt: > SYMBOL_VECTOR=(boot_Image__Magick=PROCEDURE) > [.blib.arch.auto.Image.Magick]Magick.olb/Include=Magick > [.blib.arch.auto.Image.Magick]Magick.olb/Library > sys$share:freetype/Library > sys$share:tiff/Library > sys$share:freetype/Library > sys$share:libjpeg/Library > sys$share:libbz2/Library > sys$share:libz/Library > sys$share:DECW$XLIBSHR/Share > sys$share:DECW$XTSHR/Share > PerlShr/Share > > Given that all the files referenced exist, here's what I get when I > try to do that: > %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters > %MMK-F-ERRUPD, error status %X00038098 occurred when updating target > [.BLIB.ARCH.AUTO.IMAGE.MAGICK]PL_IMAGE__MAGICK.EXE ------------------------------ Date: Mon, 22 Jan 2007 22:39:47 -0500 From: "Jeff Goodwin" Subject: Re: Quorum disk removal Message-ID: <45b5838f$0$27059$4c368faf@roadrunner.com> "Jeff Goodwin" wrote in message news:45a2d508$0$4926$4c368faf@roadrunner.com... > > "Jilly" wrote in message > news:459bca86$1@usenet01.boi.hp.com... >> >> "Jeff Goodwin" wrote in message >> news:459aecce$0$2264$4c368faf@roadrunner.com... > ...snip... >>> >>> Has anyone removed a quorum disk via a rolling reboot method? >>> >>> -Jeff >>> >> >> Yes it will be forgotten after all nodes that once had DISK_QUORUM set >> are rebooted. The rolling reboot to remove the quorum disk worked fine. For future reference, after the final quorum disk watcher was removed: %%%%%%%%%%% OPCOM 22-JAN-2007 10:56:31.24 %%%%%%%%%%% 10:56:31.24 Node XXXX05 (csid 0001000F) is unable to verify quorum disk status with a watcher %%%%%%%%%%% OPCOM 22-JAN-2007 10:56:31.24 %%%%%%%%%%% 10:56:31.24 Node XXXX05 (csid 0001000F) lost "connection" to quorum disk %CNXMAN, Proposing modification of quorum or quorum disk membership %CNXMAN, Completing VMScluster state transition ------------------------------ Date: Mon, 22 Jan 2007 16:32:01 -0500 From: "FredK" Subject: Re: SHOW TERMINAL glitch (PPP) Message-ID: <45b52d52$1@usenet01.boi.hp.com> My guess is show term is trying to read a terminal characteristic that the driver for ASN doesn't know about. "JF Mezei" wrote in message news:45b4f3da$0$9487$c3e8da3@news.astraweb.com... >$ show term tta0 > Terminal: _ASN10: Device_Type: Unknown Owner: No Owner > Physical terminal: _TTA0: > > Terminal Characteristics: > Interactive Echo Type_ahead No Escape > Hostsync TTsync Lowercase No Tab > Wrap Scope No Remote No Eightbit > Broadcast No Readsync No Form Fulldup > No Modem No Local_echo Autobaud No Hangup > No Brdcstmbx DMA No Altypeahd Set_speed > No Commsync Line Editing Overstrike editing No Fallback > No Dialup No Secure server No Disconnect No Pasthru > No Syspassword No SIXEL Graphics No Soft Characters No Printer > Port > Numeric Keypad No ANSI_CRT No Regis No Block_mode > No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2 > No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color > VMS Style Input Backspace > %SYSTEM-F-BADPARAM, bad parameter value > > Why the error message at the bottom ? > > > This is a terminal that had been switched to a PPP link. > > > $ show term tta0/perm > %SYSTEM-F-BADPARAM, bad parameter value > > Shouldn't this one give me the permanent settings, notwidthstanding the > fact that the terminal is currently a network device ? ------------------------------ Date: Mon, 22 Jan 2007 18:54:03 -0500 From: Stephen Hoffman Subject: Re: strange LINK error Message-ID: Pierre wrote: > John E. Malmberg wrote: >> JF Mezei wrote: >>> John E. Malmberg wrote: >>> >>>> I strongly recommend that you never use the name of a standard C >>>> library routine for a replacement function, even if the original >>>> function is not present in the host system library. >>> There are 2 sides to this story though. If you are importing code, it is >>> often easier to just write jacket routines that fill the gaps of >>> routines missing in the CRTL. >> No problems with writing jacket routines. Just do not give them the >> exact same public names as the official routines. >> >> Then use macros to redirect the routines for the replacements. > > yes. but when the routine appears in the "regular" library, you still > have to remove the macro. no ? Um, no. If you use a different name, the code all works, and the code all continues to work. It's that the code using a reserved name that is nailing the code here. It's that the code is performing the same function locally as the reserved name that's often seemingly confusing to folks. If the code used it's own routine and its own name for it, then the code would be portable and transportable. If you want to go USE the system library and the function over there, then yes, you have to change the code somewhere. What's happening here is that the OpenVMS C compiler is making the assumption that the rules will be followed -- that user code will not included reserved symbols -- and the code you are working with here (xmlstarlet) apparently includes its own version under the reserved name. That's the central error here. I'll pull down the xmlstarlet code and have a look. (I should haul down and re-port the most current libxml2 baselevel, too.) This sort of code-level problem is usually pretty easy to fix. That written, I've also seen some pretty hideous open source over the years. This is usually easily fixed in the original, too, particularly if the keepers are amenable to accepting code changes that bring them into better compliance with C standards. Fixes usually include OpenVMS-specific header file -- whether that's built into the code or included with /FIRST_INCLUDE or built into the main code conditionally, other such -- can detect the RTL version on the fly. I've been doing that for some time in code I've been maintaining. I wish there were a better way, but... Well, there is a way that involves maintaining a cross-version porting kit and a version-sensitive header file that redirects the references, where all of these little home-grown hacks are fixed and maintained as a porting library. There are many operating systems that need some combination of local assists with missing or buggy functions; this isn't specific to OpenVMS. But I'm not looking to maintain a galactic porting library right now. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Mon, 22 Jan 2007 23:07:35 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Suggestion: Failover logical names Message-ID: In article <45b45f26$0$3814$c3e8da3@news.astraweb.com>, JF Mezei writes: > Version 7.x brought cluster-wide logicals which are REALLY neat. Agreed. Note that if the new name is the same as the old name, it is not redefined, whereas it is with other logicals. Presumably, the overhead of redefining it on all nodes is greater than the overhead of checking whether the old and new definitions are the same. > However, when node1 defines a cluster-wide logical, this logical survives > the demise of node1. > > It would be really neat if one could have something such as : > > > on node1: > DEFINE/TABLE=cluster_failover WWW_DIR1 $DISK1:[WWW_MAIN] > > on node2 > DEFINE/TABLE=cluster_failover WWW_DIR2 $DISK2:[WWW_SITE] > > one node 3 > DEFINE/TABLE=cluster_failover WWW_DIR3 $DISK3:[WWW_BACKUP] > > Then: > DEFINE/TABLE=special_cluster_failover WWW_DIR - > WWW_DIR1, WWW_DIR2, WWW_DIR3 > > > When all 3 nodes are up, WWW_DIR would point to $DISK1:[WWW_MAIN] > > But if NODE1 goes down, the WWW_DIR1 would be flagged as unavailable, and > translating WWW_DIR would point to the next one in line WWW_DIR2 and thus > translate as $DISK2:[WWW_SITE] and so on. > > When a node reconnects to the cluster, its node-specific logicals are are > marked as available again and translating WWW_DIR would again point to > $DISK1:[WWW_MAIN] > The above is less needed with those who have volume shadowing, or have all > their disks accessible by all the nodes. (so that when a node goes down, no > resources become inaccessible). But for those who do not have this, when a > node goes down, shifting of applications to point to new directories/disks > isn't so obvious. I don't understand why you don't have volume shadowing. It solves SO many problems. Disks are cheap. Machines are cheap, at least things likie VAXstations. Just think: if that disk crashes, all the work which went into it is gone (at least since the last backup---what backup?). Keep in mind that not all applications continuously evaluate the logicals (implicitly or not). For example, it might check logical names at startup and put them into a variable, rather than fetching the definition each time they are used. This is usually done to make the code more efficient, but in your case it would mean the applications would have to be restarted. If the applications DON'T have to be restarted, then just execute your DEFINE_JF_LOGICAL_NAMES.COM in a loop every few minutes. Of course, you need to have this running in a batch queue which will failover automatically (THAT is easy to set up and works like a charm) or do SUBMIT/RESTART to a generic queue with execution queues on all nodes. ------------------------------ Date: Mon, 22 Jan 2007 21:30:08 -0600 From: David J Dachtera Subject: Re: Suggestion: Failover logical names Message-ID: <45B58140.27791F6C@spam.comcast.net> JF Mezei wrote: > > Version 7.x brought cluster-wide logicals which are REALLY neat. > > However, when node1 defines a cluster-wide logical, this logical survives > the demise of node1. > > It would be really neat if one could have something such as : > > on node1: > DEFINE/TABLE=cluster_failover WWW_DIR1 $DISK1:[WWW_MAIN] > > on node2 > DEFINE/TABLE=cluster_failover WWW_DIR2 $DISK2:[WWW_SITE] > > one node 3 > DEFINE/TABLE=cluster_failover WWW_DIR3 $DISK3:[WWW_BACKUP] > > Then: > DEFINE/TABLE=special_cluster_failover WWW_DIR - > WWW_DIR1, WWW_DIR2, WWW_DIR3 Cluster-wide LNMs don't seem appropriate in that application. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Mon, 22 Jan 2007 21:24:18 -0600 From: David J Dachtera Subject: Re: VMS Related: Off-the-wall Reflection scripting question Message-ID: <45B57FE2.766EFBFD@spam.comcast.net> Joe Silagi wrote: > > David, > > Is Reflection acting as the console and you want an automatic way to log > console data? Well, we're already "logging" console data - huge scroll-back buffer. What we need is to have the display data logged to a disk file that gets "refreshed" every day, and the previous file transferred to someplace safe, whatever that might mean. > If this is the case then I think this is possible using a > combination of Reflection's build-in logging, and a user defined event > configured to fire once a day that switches your log file, and then ftp's or > vaxlink2's the file to another VMS machine. Where would the "user defined event" be set up? > What version of Reflection are you using? Anything V8 and later (mostly R2W, but some R4W). -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ End of INFO-VAX 2007.045 ************************