INFO-VAX Thu, 08 Feb 2007 Volume 2007 : Issue 78 Contents: Re: Ask the wizard errors in topic 2945 (temperature etc) Re: Building OpenSSL 0.9.8d on a VAX, is it possible? Re: Building OpenSSL 0.9.8d on a VAX, is it possible? Re: Building OpenSSL 0.9.8d on a VAX, is it possible? Re: Help configuring VMS mail with Dynaccess.com Re: MSA1500 on VMS? Re: Program looping Re: SPANNING BACKUP TAPES Re: SPANNING BACKUP TAPES Re: SPANNING BACKUP TAPES Re: SPANNING BACKUP TAPES Re: SPANNING BACKUP TAPES Re: SPANNING BACKUP TAPES Re: TCPIP: BIND: zone transfer questions TCPIP: Neat dig trick (trace) Re: TCPIP: Neat dig trick (trace) Re: TCPIP: Neat dig trick (trace) Re: TCPIP: Neat dig trick (trace) Re: TCPIP: Neat dig trick (trace) ---------------------------------------------------------------------- Date: Thu, 08 Feb 2007 15:46:27 GMT From: "FredK" Subject: Re: Ask the wizard errors in topic 2945 (temperature etc) Message-ID: "JF Mezei" wrote in message news:77ffe$45c58c44$cef8887a$7587@TEKSAVVY.COM... > Since the status of the "ask the wizard" seemd to be in a state of limbo > in terms of where it should be maintained, I am posting this here. > > Topis 2945 at: > http://h71000.www7.hp.com/wizard/wiz_2945.html?jumpid=reg_R1002_USEN > > Has a sample C program to extract temperature, fan, power etc status from > a machine. > snip > > Obviously, the (F) temperature should be deprecated since all civilised > nations have evolved to Celcius :-) Since you have the source, simply convert it to whatever you want - Kelvin works for me. ------------------------------ Date: Thu, 08 Feb 2007 17:18:00 +1030 From: Mark Daniel Subject: Re: Building OpenSSL 0.9.8d on a VAX, is it possible? Message-ID: <12sli1lacgjdsff@corp.supernews.com> Marty Kuhrt wrote: > I'm trying to build OpenSSL 0.9.8D on a VAX running V7.3. > Even though I did the config on the VAX, the build runs > into problems with some routines wanting 64 bit numbers. > > Can this version be built on a VAX? It builds, tests and functions OK for me Marty with Compaq C V6.4-005 on OpenVMS VAX V7.2 (though YMMV on compiler and VMS version). The WASD OpenSSL sources are built using macros _VMS_V6_SOURCE=1, __VMS_VER=60000000, __CRTL_VER=6000000 to allowing linking down to VMS V6.0, though that whould be of no consequence. There are configuration files used to build the WASD SSL kit (OpenSSL stripped of source code but with include files, object code and some WASD-specifics) on all VMS platforms available at http://wasd.vsm.com.au/ht_root/src/openssl-0_9_8c/wasd/ These were used against 0.9.8C but should be fine for your purposes. The IA64 and Alpha are identical but the OpenSSL kit has not been maintained suitably for IA64 actually to be built without some manual fiddles (by yours truly). You can grab the Alpha and VAX versions of the configuration files and then DIFF to get a feel for how they vary. The WASD SSL kits themselves are available at http://wasd.vsm.com.au/wasd/ ------------------------------ Date: Thu, 08 Feb 2007 19:20:38 +1030 From: Mark Daniel Subject: Re: Building OpenSSL 0.9.8d on a VAX, is it possible? Message-ID: <12slp7lciv1hdd8@corp.supernews.com> George Cook wrote: > In article <12sli1lacgjdsff@corp.supernews.com>, Mark Daniel writes: > >>Marty Kuhrt wrote: >> >>>I'm trying to build OpenSSL 0.9.8D on a VAX running V7.3. >>>Even though I did the config on the VAX, the build runs >>>into problems with some routines wanting 64 bit numbers. >>> >>>Can this version be built on a VAX? >> >>It builds, tests and functions OK for me Marty with Compaq C V6.4-005 on >>OpenVMS VAX V7.2 (though YMMV on compiler and VMS version). The WASD >>OpenSSL sources are built using macros _VMS_V6_SOURCE=1, >>__VMS_VER=60000000, __CRTL_VER=6000000 to allowing linking down to VMS >>V6.0, though that whould be of no consequence. >> >>There are configuration files used to build the WASD SSL kit (OpenSSL >>stripped of source code but with include files, object code and some >>WASD-specifics) on all VMS platforms available at >> >> http://wasd.vsm.com.au/ht_root/src/openssl-0_9_8c/wasd/ >> >>These were used against 0.9.8C but should be fine for your purposes. >>The IA64 and Alpha are identical but the OpenSSL kit has not been >>maintained suitably for IA64 actually to be built without some manual >>fiddles (by yours truly). You can grab the Alpha and VAX versions of >>the configuration files and then DIFF to get a feel for how they vary. >> >>The WASD SSL kits themselves are available at >> >> http://wasd.vsm.com.au/wasd/ > > > Correct me if I am wrong, but you got it to compile on VAX by disabling > support for SHA-512. Your VAX config file contains the added lines: > > /** 21-SEP-2006 MGD **/ > #define OPENSSL_NO_SHA512 > > A good solution as long as SHA-512 support isn't needed. > > > George Cook > WVNET If memory serves (and I didn't note it anywhere) it was the obvious short-cut to compilation considering ... [.OPENSSL]SHA.H /* * Unlike 32-bit digest algorithms, SHA-512 *relies* on SHA_LONG64 * being exactly 64-bit wide. See Implementation Notes in sha512.c * for further details. */ #define SHA512_CBLOCK (SHA_LBLOCK*8) /* SHA-512 treats input data as a * contiguous array of 64 bit * wide big-endian values. */ [.CRYPTO.SHA]SHA512.C * Implementation relies on the fact that "long long" is 64-bit on * both 32- and 64-bit platforms. If some compiler vendor comes up * with 128-bit long long, adjustment to sha.h would be required. * As this implementation relies on 64-bit integer type, it's totally * inappropriate for platforms which don't support it, most notably * 16-bit platforms. and under Compaq C V6.4-005 on OpenVMS VAX V7.2 long long example; ...^ %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not supported on this platform. At line number 5 in DISK$USER_1:[DANIEL]TEST.C;1. ------------------------------ Date: 8 Feb 2007 12:23:05 -0600 From: kuhrt.nospammy@encompasserve.org (Marty Kuhrt) Subject: Re: Building OpenSSL 0.9.8d on a VAX, is it possible? Message-ID: <9miWe5JK039L@eisner.encompasserve.org> In article <12slp7lciv1hdd8@corp.supernews.com>, Mark Daniel writes: > George Cook wrote: >> In article <12sli1lacgjdsff@corp.supernews.com>, Mark Daniel writes: >> >>>Marty Kuhrt wrote: >>> >>>>I'm trying to build OpenSSL 0.9.8D on a VAX running V7.3. >>>>Even though I did the config on the VAX, the build runs >>>>into problems with some routines wanting 64 bit numbers. >>>> >>>>Can this version be built on a VAX? >>> >>>It builds, tests and functions OK for me Marty with Compaq C V6.4-005 on >>>OpenVMS VAX V7.2 (though YMMV on compiler and VMS version). The WASD >>>OpenSSL sources are built using macros _VMS_V6_SOURCE=1, >>>__VMS_VER=60000000, __CRTL_VER=6000000 to allowing linking down to VMS >>>V6.0, though that whould be of no consequence. >>> >>>There are configuration files used to build the WASD SSL kit (OpenSSL >>>stripped of source code but with include files, object code and some >>>WASD-specifics) on all VMS platforms available at >>> >>> http://wasd.vsm.com.au/ht_root/src/openssl-0_9_8c/wasd/ >>> >>>These were used against 0.9.8C but should be fine for your purposes. >>>The IA64 and Alpha are identical but the OpenSSL kit has not been >>>maintained suitably for IA64 actually to be built without some manual >>>fiddles (by yours truly). You can grab the Alpha and VAX versions of >>>the configuration files and then DIFF to get a feel for how they vary. >>> >>>The WASD SSL kits themselves are available at >>> >>> http://wasd.vsm.com.au/wasd/ >> >> >> Correct me if I am wrong, but you got it to compile on VAX by disabling >> support for SHA-512. Your VAX config file contains the added lines: >> >> /** 21-SEP-2006 MGD **/ >> #define OPENSSL_NO_SHA512 >> >> A good solution as long as SHA-512 support isn't needed. >> >> >> George Cook >> WVNET > > If memory serves (and I didn't note it anywhere) it was the obvious > short-cut to compilation considering ... > > [.OPENSSL]SHA.H > > /* > * Unlike 32-bit digest algorithms, SHA-512 *relies* on SHA_LONG64 > * being exactly 64-bit wide. See Implementation Notes in sha512.c > * for further details. > */ > #define SHA512_CBLOCK (SHA_LBLOCK*8) /* SHA-512 treats input data as a > * contiguous array of 64 bit > * wide big-endian values. */ > > [.CRYPTO.SHA]SHA512.C > > * Implementation relies on the fact that "long long" is 64-bit on > * both 32- and 64-bit platforms. If some compiler vendor comes up > * with 128-bit long long, adjustment to sha.h would be required. > * As this implementation relies on 64-bit integer type, it's totally > * inappropriate for platforms which don't support it, most notably > * 16-bit platforms. > > and under Compaq C V6.4-005 on OpenVMS VAX V7.2 > > long long example; > ...^ > %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not > supported > on this platform. > At line number 5 in DISK$USER_1:[DANIEL]TEST.C;1. > Thanks, everyone. That's essentially what I was looking to find out. I figured it would be something like this, and I didn't want to reinvent the wheel if someone was already rolling. Thanks, Marty ------------------------------ Date: Thu, 8 Feb 2007 08:44:30 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Help configuring VMS mail with Dynaccess.com Message-ID: In article <1170901887.300673.37430@v33g2000cwv.googlegroups.com>, mcbill20@yahoo.com writes: > Alternate gateway: DYNACCESS.COM That's the problem. I have Alternate gateway: SMTP-RELAY.DYNACCESS.DE TCPIP> sh host DYNACCESS.COM BIND database Server: 194.25.2.129 DNS03.BTX.DTAG.DE Host address Host name 217.114.73.101 DYNACCESS.COM TCPIP> sh host SMTP-RELAY.DYNACCESS.DE BIND database Server: 194.25.2.129 DNS03.BTX.DTAG.DE Host address Host name 62.112.159.161 SMTP-RELAY.DYNACCESS.DE 80.86.187.163 SMTP-RELAY.DYNACCESS.DE In order to make use of SMTP-RELAY.DYNACCESS.DE, you need to have at least the Heartbeat-A tarif. (You don't have to use the heartbeat feature, though.) ------------------------------ Date: Thu, 8 Feb 2007 09:26:36 -0800 From: "Malcolm Dunnett" Subject: Re: MSA1500 on VMS? Message-ID: <45cb5d3b$1@flight> "Syltrem" wrote in message news:12sk6hfk29mdrb2@corp.supernews.com... >> The biggest gotcha is that the >> 1000s only do active-standby, not active-active if you have two >> controllers. There is a (long awaited) firmware release I believe to >> fix this, but I've no news of it yet. >> >> Steve >> > > For all I know, if you have VMS 8.3 then you can upgrade the controller > firmware and enable active-active. > I thought the active/active firmware was only available for the MSA1500 (though since they're the same controllers I'm not sure why they couldn't release an MSA1000 version also). I understand VMS doesn't support the current MSA1500 firmware and the one it will support is coming "real soon now". If you find active/active firmware that works on VMS for the MSA1000 I'd love to hear about it. I ended up purchasing a used MSA1000 and a new MSA1500. I can put the MSA1000 on VMS right away and will phase in the MSA1500 when the firmware is ready. I wanted two controllers anyway so that I could do HBVS across them to two different buildings. At some point I will upgrade the MSA1000 to an MSA1500. At least that's the plan, we'll see how it all works out once the gear arrives. ------------------------------ Date: 8 Feb 2007 08:09:12 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Program looping Message-ID: <1HIsqAIu56rR@eisner.encompasserve.org> In article , Paul Sture writes: > > With V8.3, there's SET PROCESS/DUMP=NOW > I don't know about the OP,but I've got exactly one system running 8.3. I doappreciate the reminder, I'm trying to learn what I've got (those Release Notes don't always sink in to the old grey matter). ------------------------------ Date: 8 Feb 2007 04:52:36 -0800 From: "Ian Miller" Subject: Re: SPANNING BACKUP TAPES Message-ID: <1170939155.953577.112270@a34g2000cwb.googlegroups.com> Roy, you are not the only one. The /Tape_Expiration qualifier is a handy thing that has prevented badness on occasion. ------------------------------ Date: 8 Feb 2007 06:07:49 -0800 From: "AEF" Subject: Re: SPANNING BACKUP TAPES Message-ID: <1170943668.985050.225160@v33g2000cwv.googlegroups.com> On Feb 7, 8:14 pm, JF Mezei wrote: > Bob Koehler wrote: > > If that was the purpose, you'ld be using shadowing. Or at least > > you'ld turn off CRCs and groups. > > Shadowing is good for actual disk failure or multi node access to data even > if one node goes down. But it does not prevent a user from recovering from > a DELETE disk:[000000...]*.*;* You need to have a snapshot taken of your > disk from time to time. Exactly. Shadowing also doesn't protect you from data loss or corruption due to software problems. Shadowing is not a substitute for periodic backups. Shadowing is for higher data availability. AEF ------------------------------ Date: Thu, 08 Feb 2007 11:06:40 +0000 From: "R.A.Omond" Subject: Re: SPANNING BACKUP TAPES Message-ID: Wayne Sewell wrote: > >>From: Paul Sture > >>Yes, if you have the resources. But I'd rather let a backup continue to >>another tape than find the backup is incomplete. One nasty here is that >>if BACKUP requires a continuation tape, and that tape isn't available, >>it can happily overwrite the next tape physically mounted, irrespective >>of its label. >> > It can't if you use TAPESYS, which validates all labels, including those on > continuation tapes. You don't need TAPESYS to guard against the inadvertant overwriting of backup tapes. Sometimes I get the feeling that I'm the only one on the planet who makes use of the very useful feature of Backup's /Tape_Expiration qualifier. Heck, in my experience, most system managers are not even aware of that qualifier. Roy Omond Blue Bubble Ltd. ------------------------------ Date: 8 Feb 2007 08:29:05 -0800 From: "AEF" Subject: Re: SPANNING BACKUP TAPES Message-ID: <1170952145.398042.78540@h3g2000cwc.googlegroups.com> On Feb 8, 9:24 am, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <2ab6c$45ca7986$cef8887a$28...@TEKSAVVY.COM>, JF Mezei writes: > > > Bob Koehler wrote: > >> If that was the purpose, you'ld be using shadowing. Or at least > >> you'ld turn off CRCs and groups. > > > Shadowing is good for actual disk failure or multi node access to data even > > if one node goes down. But it does not prevent a user from recovering from > > a DELETE disk:[000000...]*.*;* You need to have a snapshot taken of your > > disk from time to time. > > I'd count that the same as a disk failure without shadowing. It's > going to take time. It's going to have CRCs and groups. But in this > case the user's provileges are going to be reviewed. > > Generally nobody but I can make that mistake on my systems. One could also lose just a (proper) subset of the files on a disk due to user or program error. Shadowing wouldn't help there but a backup would. AEF ------------------------------ Date: 8 Feb 2007 11:31:13 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: SPANNING BACKUP TAPES Message-ID: <1oEPWcJkBvfe@eisner.encompasserve.org> In article <1170946079.566598.16310@v33g2000cwv.googlegroups.com>, "AEF" writes: > > Have you tried BACKUP journal files? These take up less space than > regular BACKUP listings. With BACKUP journal files you can run this: > > $ BACKUP/LIST/JOURNAL=jounral-file/SELECT=missing-file > I'm just curious. Would you findp utting the listing or journal on the end of the last tape to be equivalent to the PKZIP aproach? You can mount and access the last tape of a multi-volume set when you know it's got what you want. ------------------------------ Date: Thu, 8 Feb 2007 12:18:23 -0500 From: Wayne Sewell Subject: Re: SPANNING BACKUP TAPES Message-ID: <00A62F03.B0CCE9C4.15@tachysoft.com> >From: "AEF" >X-Newsgroups: comp.os.vms >Subject: Re: SPANNING BACKUP TAPES >Date: 7 Feb 2007 17:13:02 -0800 >Organization: http://groups.google.com > >On Feb 7, 5:06 pm, koeh...@eisner.nospam.encompasserve.org (Bob >Koehler) wrote: >> In article <1170854235.530479.292...@l53g2000cwa.googlegroups.com>, "AEF" writes: >> >> >> >> > Well, there is an advantage to the pkzip method. If you want to >> > restore one file from your multi-floppy zip file, insertion of the >> > last floppy to read the "directory" allows pkzip to tell you which >> > floppy to put in next to recover that one file. (IIRC). With VMS >> > BACKUP you can only do this is you already have a journal or listing >> > file. >> >> With VMS BACKUP you can use meaningfull save set names in a >> controlled fashion so that you know which save set the one file >> is in. >> >> And if you have to, you can mount the tape as a labled tape and >> use DIRECTORY to find out which of a multi-reel set contains that >> save set. I find just keeping a batch log of the backup session >> around makes that unecessary. > >Hi Bob, > >I was talking about the case in which a single save set spans multiple >tapes. This is analagous to a zip file that spans multiple floppies, >which is what I was discussing above. If your save set spans tapes, >clever save set names aren't going to tell you which tape of the set >your file is on. Your advice would work when there are multiple save >sets on each tape, and then (in general) only if you know which save >set you're looking for. > >I was talking about the opposite case in which there are multiple >tapes in a single save set. For that you need listings or a journal >file, especially if you don't know which save set your file is in! > It's trivially easy to keep track of where files are with TAPESYS. It includes a history system that keeps track of every file in every saveset of every tape. The history is organized by file, so it will give you a list of the most recent n backups (where n is user defined) of a particular version of a particular file, returning label, saveset names and position on the tape (so that fast skip can be used). And you can simply select from a list and cause the restore of the file to be done automatically. Wayne =============================================================================== Wayne Sewell, Tachyon Software Consulting (281)812-0738 wayne@tachysoft.com http://www.tachysoft.com/www/tachyon.html and wayne.html =============================================================================== Curly:"Hey, I'm no mule." Moe:"No, your ears are too short!" ------------------------------ Date: 8 Feb 2007 09:40:23 +0100 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: TCPIP: BIND: zone transfer questions Message-ID: <45caf007@news.langstoeger.at> In article , JF Mezei writes: >I am behind a NAT router. My LAN-side DNS server serves LAN-side requests >for my domain and provides LAN side IP addresses. > >My ISP has my "internet" zone file that has host names pointing to my >internet IP address. > >I'd like to be able to update my remote "internet" zone file. Would the >VMS zone transfer utilities allow me to have a totally separate zone file >(unused by my local DNS server) and send it off to my ISP's DNS server ? >These would be manually initiated zone transfer for whenever I make >changes. (not often). > >If the answer is YES, what is the utility I should be looking for ? > >(I am on alpha at TCPIP 5.6) The normal BIND9 server (of TCPIP, TCPware still doesn't have one) is able to do this (at least it does it for me ;-). It is called "view"... acl internal { 127/8; 192.168.0/24; 192.168.1/24; andsoon }; options { allow-recursion { internal; }; allow-transfer { internal; }; directory "DNS:"; // transfer-format one-answer; recursion no; }; view "Intranet" { allow-transfer { any; }; match-clients { internal; }; recursion yes; zone "0.0.127.in-addr.arpa" IN {type master; file "NAMED.LOCAL"; }; ... zone "." IN {type hint; file "NAMED.CA"; }; }; view "Internet" { allow-transfer { none; }; !if it is primary, allow secondary match-clients { any; }; recursion no; zone ... }; -- 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: Thu, 08 Feb 2007 03:48:24 -0500 From: JF Mezei Subject: TCPIP: Neat dig trick (trace) Message-ID: <36bf4$45cae3ed$cef8887a$561@TEKSAVVY.COM> With TCPIP Services 5.6 on alpha, the "dig" utility has acquired a whole lot of new options. One of them is the "trace" option and allows to trace delegation from the root servers. For instance: $dig h71000.www7.hp.com +trace goes through the root servers, then the gtld servers (for .com), then list the various hp dns servers, and then the various CNAME translations from the above hostname to openvms.compaq.com ! And for ip addresses: $dig -x 161.114.65.60 +trace Will go from the root servers to the arin servers (since this IP is a north american one) to the hp servers. The -x automatically transforms the ip address into a .in-addr.arpa query for you. This is VERY useful when debugging DNS problems on some host to understand where the fault lies. ------------------------------ Date: Thu, 8 Feb 2007 09:56:12 -0000 From: "chris" Subject: Re: TCPIP: Neat dig trick (trace) Message-ID: <45caf091$1_1@glkas0286.greenlnk.net> how can i check what version of tcpip we have on our cluster, as it would com in handy for tracing routes Cheers "JF Mezei" wrote in message news:36bf4$45cae3ed$cef8887a$561@TEKSAVVY.COM... > With TCPIP Services 5.6 on alpha, the "dig" utility has acquired a whole > lot of new options. > > One of them is the "trace" option and allows to trace delegation from the > root servers. > > For instance: > > $dig h71000.www7.hp.com +trace > > goes through the root servers, then the gtld servers (for .com), then list > the various hp dns servers, and then the various CNAME translations from > the above hostname to openvms.compaq.com ! > > And for ip addresses: > > $dig -x 161.114.65.60 +trace > > Will go from the root servers to the arin servers (since this IP is a > north american one) to the hp servers. > > The -x automatically transforms the ip address into a > .in-addr.arpa query for you. > > This is VERY useful when debugging DNS problems on some host to understand > where the fault lies. ------------------------------ Date: Thu, 08 Feb 2007 05:12:30 -0500 From: JF Mezei Subject: Re: TCPIP: Neat dig trick (trace) Message-ID: <5e75b$45caf7a2$cef8887a$11844@TEKSAVVY.COM> chris wrote: > how can i check what version of tcpip we have on our cluster, as it would > com in handy for tracing routes $TCPIP SHOW VERSION Also,, if you do $dig -h you will see if you have about 20 lines worth of help, or about 50 lines worth (the newer version). to get dig to work: @SYS$MANAGER:TCPIP$DEFINE_COMMANDS (or $MC TCPIP$DIG arguments ) ------------------------------ Date: Thu, 8 Feb 2007 11:02:42 -0000 From: "chris" Subject: Re: TCPIP: Neat dig trick (trace) Message-ID: <45cb0027$1_1@glkas0286.greenlnk.net> cheers that seems to work , i have version 5.0A dig 8.1 thanks "JF Mezei" wrote in message news:5e75b$45caf7a2$cef8887a$11844@TEKSAVVY.COM... > chris wrote: >> how can i check what version of tcpip we have on our cluster, as it would >> com in handy for tracing routes > > $TCPIP SHOW VERSION > > Also,, if you do $dig -h you will see if you have about 20 lines worth of > help, or about 50 lines worth (the newer version). > > to get dig to work: @SYS$MANAGER:TCPIP$DEFINE_COMMANDS > > (or $MC TCPIP$DIG arguments ) > ------------------------------ Date: Thu, 8 Feb 2007 11:07:14 -0000 From: "chris" Subject: Re: TCPIP: Neat dig trick (trace) Message-ID: <45cb0137_1@glkas0286.greenlnk.net> Ive got the older version , the + trace is not recognised. "chris" wrote in message news:45cb0027$1_1@glkas0286.greenlnk.net... > cheers that seems to work , i have version 5.0A > dig 8.1 > > > thanks > > > "JF Mezei" wrote in message > news:5e75b$45caf7a2$cef8887a$11844@TEKSAVVY.COM... >> chris wrote: >>> how can i check what version of tcpip we have on our cluster, as it >>> would com in handy for tracing routes >> >> $TCPIP SHOW VERSION >> >> Also,, if you do $dig -h you will see if you have about 20 lines worth >> of help, or about 50 lines worth (the newer version). >> >> to get dig to work: @SYS$MANAGER:TCPIP$DEFINE_COMMANDS >> >> (or $MC TCPIP$DIG arguments ) >> > > ------------------------------ End of INFO-VAX 2007.078 ************************