INFO-VAX Fri, 18 Feb 2005 Volume 2005 : Issue 98 Contents: Re: 7.32 patching questions Re: 7.32 patching questions Re: 7.32 patching questions Re: 7.32 patching questions Re: 7.32 patching questions Re: 7.32 patching questions Re: 7.32 patching questions Re: 7.32 patching questions Re: Does anyone know of an object compatible (non static) way of setting timeout Re: How to get a free iPod? Re: How to get a free iPod? Re: How to get a free iPod? Re: HP financials: Alpha sales down Re: HP financials: Alpha sales down RE: HP financials: Alpha sales down Re: HP financials: Alpha sales down Re: HP financials: Alpha sales down Re: HP financials: Alpha sales down Re: HP financials: Alpha sales down Re: HP financials: Alpha sales down Re: HP financials: Alpha sales down Re: HP financials: Alpha sales down Re: linux kernel has major security flaws ... Re: linux kernel has major security flaws ... Re: linux kernel has major security flaws ... looking for a new job Re: looking for a new job Re: Looking for suggestions for bootcamp sessions Re: Looking for suggestions for bootcamp sessions Micro$oft warns of undetectable spyware security risk ... Re: Mounting disks during STARTUP Re: Mounting disks during STARTUP Re: Mounting disks during STARTUP Re: Mounting disks during STARTUP RE: Need performance help Re: OpenVMS 8.2 docs and freeware Re: OpenVMS 8.2 docs and freeware Re: OpenVMS 8.2 docs and freeware Re: OpenVMS 8.2 docs and freeware Re: OpenVMS Cluster to Replace News.Individual.NET ? Re: OpenVMS Cluster to Replace News.Individual.NET ? Re: OpenVMS Small Partner Strategy Re: OpenVMS Small Partner Strategy Re: OpenVMS Small Partner Strategy Re: OT: Message to Peter "EPLAN" LANGSTOEGER Re: Port Print facility Update for I64 Re: read monitor (>>>) variables from OpenVMS ? Re: read monitor (>>>) variables from OpenVMS ? Shark Tank mentions VMS RE: Shark Tank mentions VMS RE: Shark Tank mentions VMS Re: TCPIP automatic route additions TCPIP name cache TCPIP name cache Re: TCPIP name cache Re: TCPIP name cache Terminal connection Re: VMS 8.2 Itanium Distribution Re: VMS 8.2 Itanium Distribution ---------------------------------------------------------------------- Date: Fri, 18 Feb 2005 10:28:55 +0100 From: Paul Sture Subject: Re: 7.32 patching questions Message-ID: <37lqqmF5dll75U1@individual.net> norm.raphael@metso.com wrote: >>So, you think this process would probably be OK?: >> >>1. apply PCSI-V0100 patch > > > Step 2 or step 3, although both wouldn't hurt ;) > > >>2. SET COMMAND SYS$UPDATE:PCSI.CLD >>3. Log out/in > But don't do what I once did. I faithfully did either 2 or 3, then accidentally picked another DECterm session to do the update. ------------------------------ Date: Fri, 18 Feb 2005 12:18:53 +0000 (UTC) From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: 7.32 patching questions Message-ID: In article <37lqqmF5dll75U1@individual.net>, Paul Sture writes: >But don't do what I once did. I faithfully did either 2 or 3, then >accidentally picked another DECterm session to do the update. This (I mean, getting the most current DCLTABLES) is not the only reason why I strongly recommend doing installations via a SET HOST[/LAT]/LOG= every time. And having some PCSI logicals defined helps a lot to get a meaningful installation logfile. (LNM$SYSTEM_TABLE) [kernel] [shareable,system] [Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]] "AXPVMS$PCSI_EXECUTE_VERIFY" [exec] = "YES" "AXPVMS$PCSI_LOG_TRACE" [exec] = "BOTH" "PCSI$$SAVE_RECOVERY_DATA" [exec] = "YES" "PCSI$LOG" [exec] = "TRUE" "PCSI$SOURCE" [exec] = "SYS$SYSDEVICE:[INSTALL_KITS]" "PCSI$TRACE" [exec] = "TRUE" If you consider installing new layered products (DCPS V2.4, DFG V2.9, ...) as well, and you want to eventually back out ECOs (PRODUCT UNDO) then install all the LPs before all ECOs (or at least before all the ECOs you eventually want to UNDO). Every full product install/deinstall deletes all ECO recovery data and then you can no longer UNDO any patch. And finally let me list my current recommendation for V7.3-2 ECOs VMS732_PCSI V1.0 VMS732_UPDATE V3.0 VMS732_TRACE V2.0 VMS732_SYS V6.0 VMS732_FIBRE_SCSI V4.0 VMS732_PTHREAD V2.0 VMS732_RMS V2.0 VMS732_CPU270F V1.0 VMS732_BACKUP V3.0 VMS732_MQ V1.0 VMS732_SYSINI V1.0 VMS732_DRIVER V1.0 DNVOSIECO01 V7.3-2 TCPIP_ECO V5.4-154 which means all of the current ECOs. YMMV of course (no MARVEL/MQ/APACHE/...) NOTE: So far, I don't know the VMS732_VMSUPD V1.0 that this thread mentioned. -- 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: 18 Feb 2005 05:06:53 -0800 From: tadamsmar@yahoo.com Subject: Re: 7.32 patching questions Message-ID: <1108732013.450021.325440@g14g2000cwa.googlegroups.com> norm.raphael@metso.com wrote: > see below > > tadamsmar@yahoo.com wrote on 02/17/2005 04:15:58 PM: > > > > > norm.raphael@metso.com wrote: > > > tadamsmar@yahoo.com wrote on 02/17/2005 02:44:48 PM: > > > > > > > Looking at: > > > > > > > > ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-2 > > > > > > > > What the heck is MASTER_V732_MASTER_ECOLIST? > > > > > > > > It seems to be a kit, but it is too small to contain > > > > everything mentioned in the description .TXT file of > > > > the same name. The text seems to describe VMS732_UPDATE-V0300. > > > > > > > > Anyway I just loaded 7.32 from the Oct 03 distribution. > > > > > > > > To patch it, I think that I should apply: > > > > > > > > 1. VMS732_PCSI-V0100 > > > > 2. VMS732_UPDATE-V0300 > > > > 3. VMS732_VMSUPD-V0100 (from the mandatory update CD that came > > > > with the recent 8.2 shipment. It is not on the patch site!?) > > > > 4. Any other INSTALL_1 or applicable patches that have > > > > come out since VMS732_UPDATE-V0300. > > > > > > > > Is this a good way to proceed? I am assuming that UPDATE-V0300 > > > > rolls up all the important patches that preceed it. > > > > > > > > Could they make this more confusing?? > > > > > > > That's about correct. the master list is documentation: > > > > > > CURRENT UPDATE KIT RELEASE DATE > > > ------------------ ------------ > > > VMS732_UPDATE-V0300 28-OCT-2004 > > > > > > > > > KITS INCLUDED IN UPDATE KIT: > > > =========================== > > > > > > KIT NAME RELEASE DATE SUPERSEDED > > > ----------------------------- ------------ ---------- > > > VMS732_AUDSRV-V0100 31-AUG-2004 > > > VMS732_BACKUP-V0200 4-OCT-2004 Yes > > > VMS732_DCL-V0200 4-FEB-2004 > > > VMS732_F11X-V0300 18-OCT-2004 > > > VMS732_FIBRE_SCSI-V0300 4-MAY-2004 Yes > > > VMS732_GRAPHICS-V0200 26-JAN-2004 > > > VMS732_HBMM-V0200 23-SEP-2004 > > > VMS732_IPC-V0100 7-SEP-2004 > > > VMS732_LAN-V0200 13-APR-2004 > > > VMS732_LIBRTL-V0100 15-JUL-2004 > > > VMS732_LMF-V0100 24-MAY-2004 > > > VMS732_MANAGE-V0200 10-MAR-2004 > > > VMS732_MOUNT96-V0100 11-AUG-2004 > > > VMS732_PTHREAD-V0100 18-JUL-2004 Yes > > > VMS732_RMS-V0100 11-AUG-2004 Yes > > > VMS732_RPC-V0300 20-FEB-2004 > > > VMS732_SHADOWING-V0200 15-OCT-2004 > > > VMS732_SYS-V0500 24-AUG-2004 Yes > > > VMS732_SYSLOA-V0200 21-JUL-2004 > > > VMS732_TDF-V0200 1-JUN-2004 > > > VMS732_UPDATE-V0200 1-MAR-2003 > > > VMS732_XFC-V0100 22-JUL-2004 > > > > > > > > > ECO KITS NOT INCLUDED IN UPDATE KIT: RELEASE DATE COMMENTS > > > ------------------------------------ ------------ > > -------------------- > > > VMS732_SYSINI-V0100 25-JAN-2005 > > > VMS732_MQ-V0100 12-JAN-2005 > > > VMS732_BACKUP-V0300 6-JAN-2005 > > > VMS732_CPU270F-V0100 4-JAN-2005 > > > VMS732_RMS-V0200 4-JAN-2005 > > > VMS732_PTHREAD-V0200 7-DEC-2004 > > > VMS732_FIBRE_SCSI-V0400 6-DEC-2004 Documentation > > Modified > > > VMS732_SYS-V0600 6-DEC-2004 > > > VMS732_TRACE-V0200 1-NOV-2004 > > > VMS732_PCSI-V0100 3-MAR-2004 > > > > > > > > > One patch has been published that is not on here due to > > > download issues > > > > > > VMS732_DRIVER-V0100 15-FEB-2005 > > > > > > You'll have to check for INSTALL_level and prerequisites to > > > see if you need all of the last ones. > > > > > > > > > The PCSI patch has to go in first and then > > > > > > 7.3 Special Installation Instructions: > > > > > > > > > o No reboot is necessary after installation of this kit. > > > However, after installation of the kit users will need to > > take > > > > one of the following steps to ensure that the new PCSI files > > Note: one of the following.... > > > > are used: > > > > > > - Execute the command SET COMMAND SYS$UPDATE:PCSI.CLD > > > > > > - Log out and log back in. > > > > > > So, you think this process would probably be OK?: > > > > 1. apply PCSI-V0100 patch > > Step 2 or step 3, although both wouldn't hurt ;) > > > 2. SET COMMAND SYS$UPDATE:PCSI.CLD > > 3. Log out/in > > > 4. apply UPDATE-V0300 mega-patch patch > > 5. apply mandatory security patch from the CD that came w/8.2 > > 6. review all the patches since UPDATE-V0300 and > > apply any patches that are recommended for > > my configuration of software usage. > > > That will "probably be OK." I phrased it that way because I'm not planning to sue you :). And, I have 3 stages of backups since I had to do pre-upgrade and post-upgrade patches, and you never know when a corrupt patch/upgrade file will tell you to go back to your backup and start over! If you stage it, you avoid some repetition. After I have proven all my patch/upgrade files work, I will just do one stage of backup tapes for the other machines. Thanks for your help! ------------------------------ Date: 18 Feb 2005 05:20:26 -0800 From: tadamsmar@yahoo.com Subject: Re: 7.32 patching questions Message-ID: <1108732826.693604.296180@z14g2000cwz.googlegroups.com> Peter 'EPLAN' LANGSTOEGER wrote: > In article <37lqqmF5dll75U1@individual.net>, Paul Sture writes: > >But don't do what I once did. I faithfully did either 2 or 3, then > >accidentally picked another DECterm session to do the update. > > This (I mean, getting the most current DCLTABLES) is not the only reason > why I strongly recommend doing installations via a SET HOST[/LAT]/LOG= > every time. And having some PCSI logicals defined helps a lot to get a > meaningful installation logfile. > > (LNM$SYSTEM_TABLE) [kernel] [shareable,system] > [Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]] > > "AXPVMS$PCSI_EXECUTE_VERIFY" [exec] = "YES" > "AXPVMS$PCSI_LOG_TRACE" [exec] = "BOTH" > "PCSI$$SAVE_RECOVERY_DATA" [exec] = "YES" > "PCSI$LOG" [exec] = "TRUE" > "PCSI$SOURCE" [exec] = "SYS$SYSDEVICE:[INSTALL_KITS]" > "PCSI$TRACE" [exec] = "TRUE" > > > If you consider installing new layered products (DCPS V2.4, DFG V2.9, ...) > as well, and you want to eventually back out ECOs (PRODUCT UNDO) then > install all the LPs before all ECOs (or at least before all the ECOs > you eventually want to UNDO). Every full product install/deinstall > deletes all ECO recovery data and then you can no longer UNDO any patch. > > > And finally let me list my current recommendation for V7.3-2 ECOs > > VMS732_PCSI V1.0 > VMS732_UPDATE V3.0 > VMS732_TRACE V2.0 > VMS732_SYS V6.0 > VMS732_FIBRE_SCSI V4.0 > VMS732_PTHREAD V2.0 > VMS732_RMS V2.0 > VMS732_CPU270F V1.0 > VMS732_BACKUP V3.0 > VMS732_MQ V1.0 > VMS732_SYSINI V1.0 > VMS732_DRIVER V1.0 > > DNVOSIECO01 V7.3-2 > TCPIP_ECO V5.4-154 > > which means all of the current ECOs. YMMV of course (no MARVEL/MQ/APACHE/...) > NOTE: So far, I don't know the VMS732_VMSUPD V1.0 that this thread mentioned. VMSUPD 1 is part of the VMS 8.2 media distribution. Its on a mandatory security patch CD for earlier versions of VMS that comes with the distribution. I know some of those patches (BACKUP 3, for instance) are marked as "upgrade if you are having problems" (INSTALL_3). > > -- > 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: 18 Feb 2005 05:50:11 -0800 From: tadamsmar@yahoo.com Subject: Re: 7.32 patching questions Message-ID: <1108734611.310614.132050@l41g2000cwc.googlegroups.com> Peter 'EPLAN' LANGSTOEGER wrote: > In article <37lqqmF5dll75U1@individual.net>, Paul Sture writes: > >But don't do what I once did. I faithfully did either 2 or 3, then > >accidentally picked another DECterm session to do the update. > > This (I mean, getting the most current DCLTABLES) is not the only reason > why I strongly recommend doing installations via a SET HOST[/LAT]/LOG= > every time. And having some PCSI logicals defined helps a lot to get a > meaningful installation logfile. > > (LNM$SYSTEM_TABLE) [kernel] [shareable,system] > [Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]] > > "AXPVMS$PCSI_EXECUTE_VERIFY" [exec] = "YES" > "AXPVMS$PCSI_LOG_TRACE" [exec] = "BOTH" > "PCSI$$SAVE_RECOVERY_DATA" [exec] = "YES" > "PCSI$LOG" [exec] = "TRUE" > "PCSI$SOURCE" [exec] = "SYS$SYSDEVICE:[INSTALL_KITS]" > "PCSI$TRACE" [exec] = "TRUE" > > > If you consider installing new layered products (DCPS V2.4, DFG V2.9, ...) > as well, and you want to eventually back out ECOs (PRODUCT UNDO) then > install all the LPs before all ECOs (or at least before all the ECOs > you eventually want to UNDO). Every full product install/deinstall > deletes all ECO recovery data and then you can no longer UNDO any patch. > > > And finally let me list my current recommendation for V7.3-2 ECOs > > VMS732_PCSI V1.0 > VMS732_UPDATE V3.0 > VMS732_TRACE V2.0 > VMS732_SYS V6.0 > VMS732_FIBRE_SCSI V4.0 > VMS732_PTHREAD V2.0 > VMS732_RMS V2.0 > VMS732_CPU270F V1.0 > VMS732_BACKUP V3.0 > VMS732_MQ V1.0 > VMS732_SYSINI V1.0 > VMS732_DRIVER V1.0 > > DNVOSIECO01 V7.3-2 DNVOSIECO01 is for DECNET-PLUS users only. I am running phase IV. > TCPIP_ECO V5.4-154 > > which means all of the current ECOs. YMMV of course (no MARVEL/MQ/APACHE/...) > NOTE: So far, I don't know the VMS732_VMSUPD V1.0 that this thread mentioned. > > -- > 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: 18 Feb 2005 05:59:45 -0800 From: tadamsmar@yahoo.com Subject: Re: 7.32 patching questions Message-ID: <1108735185.289975.233640@o13g2000cwo.googlegroups.com> Peter 'EPLAN' LANGSTOEGER wrote: > TCPIP_ECO V5.4-154 First, I don't see that patch here: ftp://ftp.itrc.hp.com/openvms_patches/layered_products/alpha/ Second, I am running TCPIP V5.0-10 fresh off the VMS 7.32 distribution. So, I guess I would need to upgrade from the quarterlies to get to that version of TCPIP. ------------------------------ Date: 18 Feb 2005 06:06:33 -0800 From: tadamsmar@yahoo.com Subject: Re: 7.32 patching questions Message-ID: <1108735593.268598.45490@z14g2000cwz.googlegroups.com> tadams...@yahoo.com wrote: > Peter 'EPLAN' LANGSTOEGER wrote: > > TCPIP_ECO V5.4-154 > > First, I don't see that patch here: > > ftp://ftp.itrc.hp.com/openvms_patches/layered_products/alpha/ > > Second, I am running TCPIP V5.0-10 fresh off the VMS 7.32 > distribution. > > So, I guess I would need to upgrade from the quarterlies > to get to that version of TCPIP. Opps! I was running PROD SHOW PROD on the wrong box! I'm at TCPIP V5.4-15 but the ECO is still not on the ftp site, so where do I find it? ------------------------------ Date: Fri, 18 Feb 2005 08:56:10 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: 7.32 patching questions Message-ID: <05021808561037_27800279@antinode.org> From: tadamsmar@yahoo.com > > Peter 'EPLAN' LANGSTOEGER wrote: > > > TCPIP_ECO V5.4-154 > > > > First, I don't see that patch here: > > > > ftp://ftp.itrc.hp.com/openvms_patches/layered_products/alpha/ > [...] > Opps! I was running PROD SHOW PROD on the wrong box! > > I'm at TCPIP V5.4-15 That makes more sense. > but the ECO is still not on the ftp site, so where do > I find it? I had the same problem. The key is not to be distracted by these: ALP_TCPIP_ECO-V0501-155.PCSI-DCX_AXPEXE ALP_TCPIP_ECO-V0501-155.txt ALP_TCPIP_ECO-V0503-182.PCSI-DCX_AXPEXE ALP_TCPIP_ECO-V0503-182.txt but to continue down to these: DEC-AXPVMS-TCPIP_ECO-V0504-151-4.PCSI-DCX_AXPEXE DEC-AXPVMS-TCPIP_ECO-V0504-151-4.txt DEC-AXPVMS-TCPIP_ECO-V0504-152-4.PCSI-DCX_AXPEXE DEC-AXPVMS-TCPIP_ECO-V0504-152-4.txt DEC-AXPVMS-TCPIP_ECO-V0504-154-4.PCSI-DCX_AXPEXE <--- DEC-AXPVMS-TCPIP_ECO-V0504-154-4.txt <--- It's a clever naming convention. ------------------------------------------------------------------------ Steven M. Schweda (+1) 651-699-9818 382 South Warwick Street sms@antinode-org Saint Paul MN 55105-2547 ------------------------------ Date: Fri, 18 Feb 2005 08:53:09 -0000 From: "Robin" Subject: Re: Does anyone know of an object compatible (non static) way of setting timeout Message-ID: "Bob Koehler" wrote in message news:9kg$pgK$caLa@eisner.encompasserve.org... > In article , "Robin" writes: > > Hi all, > > > > I hope someone can help. I need a way of setting object compatible > > timeouts within VMS. Both the system command 'sys$setimr()' and the X > > toolkit command 'XtAppAddTimeOut()' call static functions on completion > > rendering my object code useless. (There will be multiple instances of the > > object but only one of the timeout routine!) > > > > If anyone knows any other way of achieving this I would be grateful. > > The general way of telling things apart in the AST called by $SETIMR > is by the request id, which is basically an argument passed to the > AST that you can use as you wish. You need to map the request id > to the specific object instance. For example, in Java you could use > Object.hash() (inheritted by all objects) as a unique request id. > There should be something similar in C++, perhaps &object. There > should then be a hook to allow your static routine to access object > instance specific data and functions, but you may have to make sure > you write them in an AST reentrant manner. > Within C++ you supply the 'this' pointer from which you can access any members of the object. Ta Robin ------------------------------ Date: 18 Feb 2005 06:59:11 -0800 From: DeathbySuicide@gmail.com Subject: Re: How to get a free iPod? Message-ID: <1108738751.155524.53630@f14g2000cwb.googlegroups.com> here is a link, just in case that person got theres http://www.freeiPods.com/?r=8123756 ------------------------------ Date: 18 Feb 2005 06:59:08 -0800 From: DeathbySuicide@gmail.com Subject: Re: How to get a free iPod? Message-ID: <1108738748.413214.62670@z14g2000cwz.googlegroups.com> here is a link, just in case that person got theres http://www.freeiPods.com/?r=8123756 ------------------------------ Date: Fri, 18 Feb 2005 18:21:01 +0000 (UTC) From: DeathbySuicide@gmail.com Subject: Re: How to get a free iPod? Message-ID: illegal message cancelled ------------------------------ Date: Fri, 18 Feb 2005 05:03:00 -0800 From: "Tom Linden" Subject: Re: HP financials: Alpha sales down Message-ID: On Thu, 17 Feb 2005 22:33:35 -0500, Neil Rieck wrote: > In December-2004 my employer purchased two used AS-DS20e machines from a > used equipment vendor and we quickly realized we were in the middle of a > bidding war. The vendor told us that used Alpha sales were up 150% > (whatever > that means) since September 2004 with no end in sight coming. This > started > us to speculate: "Did this have anything to do with the announced > End-of-Life of Alpha?". Were others thinking things like "Gee, Itanium > boxes > are coming out now but I'd like to wait for the technology to mature a > bit > so I'll by myself some time by purchasing used Alphas?" If any of these > speculations are even partly true, it makes you wonder why Compaq/HP > didn't > do the IBM thing and be a little more secretive when it comes to EOL > statements etc. Which computer systems did IBM EOL? -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Fri, 18 Feb 2005 08:33:55 -0500 From: "John Smith" Subject: Re: HP financials: Alpha sales down Message-ID: Tom Linden wrote: > On Thu, 17 Feb 2005 22:33:35 -0500, Neil Rieck > wrote: > >> In December-2004 my employer purchased two used AS-DS20e machines >> from a used equipment vendor and we quickly realized we were in the >> middle of a bidding war. The vendor told us that used Alpha sales >> were up 150% (whatever >> that means) since September 2004 with no end in sight coming. This >> started >> us to speculate: "Did this have anything to do with the announced >> End-of-Life of Alpha?". Were others thinking things like "Gee, >> Itanium boxes >> are coming out now but I'd like to wait for the technology to mature >> a bit >> so I'll by myself some time by purchasing used Alphas?" If any of >> these speculations are even partly true, it makes you wonder why >> Compaq/HP didn't >> do the IBM thing and be a little more secretive when it comes to EOL >> statements etc. > > Which computer systems did IBM EOL? 709 - sometime long ago, but I bet if you called and asked IBM for help with one you still had around, they'd find a way to help you out. -- OpenVMS - The classics never go out of style. ------------------------------ Date: Fri, 18 Feb 2005 08:55:48 -0500 From: "Main, Kerry" Subject: RE: HP financials: Alpha sales down Message-ID: > -----Original Message----- > From: Bill Todd [mailto:billtodd@metrocast.net]=20 > Sent: February 17, 2005 8:41 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: HP financials: Alpha sales down >=20 > Keith Parris wrote: >=20 > ... >=20 > > Also, the majority of VMS' sizeable contributions to HP's=20 > revenues and=20 > > profits are found not in BCS, but in this area: >=20 > Indeed. And given that VMS sales aren't even close to=20 > holding up their=20 > end, the service revenues will inevitably follow them down=20 > hill - just=20 > with an obvious time-lag comparable to the installed lifetimes of the=20 > system involved. >=20 > "HP Services (HPS) > > revenue grew 20% year-over-year to a record $3.8 billion. On a=20 > > year-over-year basis, Managed Services revenue grew 44%,=20 > Consulting and=20 > > Integration grew 20% and Technology Services grew 14%.=20 > Operating profit=20 > > was $281 million, or 7.4% of revenue, compared with $261=20 > million in the=20 > > prior-year period." Based on past experience, one could=20 > estimate that=20 > > roughly 15% of the revenues and 25% of the profits here=20 > were from VMS. >=20 > The 'past experience' you are basing this on would appear to be=20 > pre-Alphacide experience (very much as that perpetual=20 > '411,000 installed=20 > systems' seems to be), unless you're asserting that the Alphacide had=20 > very little effect in this area: I could have believed that a few=20 > months or even a year or more after the event (due to the=20 > time-lag noted=20 > above), but it seems rather less believable coming up on its fourth=20 > anniversary. >=20 > - bill >=20 Bill, The services revenue is very significant and if you believe some analysts, is where the future is wrt to solutions selling.=20 As an example, pointer to OpenVMS USD $750M services win last year: http://www.hp.com/hpinfo/newsroom/press/2004/040324a.html "HP awarded $784 Million Services Contract by Department of Veteran Affairs" "...HP has been an infrastructure, consulting and services provider to the VA since 1983 through its work on the Decentralized Hospital Computer Program (DHCP) and Enhanced Decentralized Hospital Computer Program (EDHCP) contracts. Over time, HP and the VA have collaborated closely to continually evolve the VA's IT environment and have successfully deployed HP's OpenVMS clusters on AlphaServer systems to build an adaptive environment that has increased performance, utilizes 64-bit architecture and has enhanced reliability and up-time. As part of this latest agreement, HP takes responsibility for maintenance and support for all hardware and software products that comprise the VistA solution." Hey - that's what Linux is all about right? Sell cheap and get the service contract. :-) Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .." ------------------------------ Date: Fri, 18 Feb 2005 09:23:21 -0500 From: JF Mezei Subject: Re: HP financials: Alpha sales down Message-ID: <1108735844.85b4ffa0222c77cf4d82e22a759c8f8a@teranews> Tom Linden wrote: > Which computer systems did IBM EOL? System 34, System 36, System 38. (replaced by the AS400). The old AS400 was then ported to Power based systems. IBM redid all the OS names and I lost track. The lack of upgradibilkity from the incompatible 34, 36, 38 and MVS systems was one of the big reasons that VMS took off since it was able to offer from desktop to data centre on the same OS and in that time, on the same hardware architecture. The 34/36/28/MVS mess was purposefully done so that should IBM have been forced to divest, the companies buying the smaller systems would not inherit any of the valuable MVS and 370 architecture stuff. This is one of the big reasons VMS got such a boost in the 1980s. When IBM combined the midrange systems into the AS400, the AS400 then became the "VAX Killer". It was still different from MVS machines, but it greatly reduced the disparity and incompatibility within IBM by simplifying the product offering between the PC, AS400 and MVS mainframes. ------------------------------ Date: Fri, 18 Feb 2005 09:48:28 -0500 From: "John Smith" Subject: Re: HP financials: Alpha sales down Message-ID: <0ZWdneJAmrKinYvfRVn-uQ@igs.net> Main, Kerry wrote: >> -----Original Message----- >> From: Bill Todd [mailto:billtodd@metrocast.net] >> Sent: February 17, 2005 8:41 PM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: HP financials: Alpha sales down >> >> Keith Parris wrote: >> >> ... >> >>> Also, the majority of VMS' sizeable contributions to HP's >> revenues and >>> profits are found not in BCS, but in this area: >> >> Indeed. And given that VMS sales aren't even close to >> holding up their >> end, the service revenues will inevitably follow them down >> hill - just >> with an obvious time-lag comparable to the installed lifetimes of the >> system involved. >> >> "HP Services (HPS) >>> revenue grew 20% year-over-year to a record $3.8 billion. On a >>> year-over-year basis, Managed Services revenue grew 44%, >> Consulting and >>> Integration grew 20% and Technology Services grew 14%. >> Operating profit >>> was $281 million, or 7.4% of revenue, compared with $261 >> million in the >>> prior-year period." Based on past experience, one could >> estimate that >>> roughly 15% of the revenues and 25% of the profits here >> were from VMS. >> >> The 'past experience' you are basing this on would appear to be >> pre-Alphacide experience (very much as that perpetual >> '411,000 installed >> systems' seems to be), unless you're asserting that the Alphacide had >> very little effect in this area: I could have believed that a few >> months or even a year or more after the event (due to the >> time-lag noted >> above), but it seems rather less believable coming up on its fourth >> anniversary. >> >> - bill >> > > Bill, > > The services revenue is very significant and if you believe some > analysts, is where the future is wrt to solutions selling. > > As an example, pointer to OpenVMS USD $750M services win last year: > http://www.hp.com/hpinfo/newsroom/press/2004/040324a.html > "HP awarded $784 Million Services Contract by Department of Veteran > Affairs" > > "...HP has been an infrastructure, consulting and services provider to > the VA since 1983 through its work on the Decentralized Hospital > Computer Program (DHCP) and Enhanced Decentralized Hospital Computer > Program (EDHCP) contracts. Over time, HP and the VA have collaborated > closely to continually evolve the VA's IT environment and have > successfully deployed HP's OpenVMS clusters on AlphaServer systems to > build an adaptive environment that has increased performance, utilizes > 64-bit architecture and has enhanced reliability and up-time. As part > of this latest agreement, HP takes responsibility for maintenance and > support for all hardware and software products that comprise the VistA > solution." > > Hey - that's what Linux is all about right? Sell cheap and get the > service contract. Spin, spin, spin. VA was an *existing* VMS customer outsourcing. How many sales of VMS >$25 million (hardware / os / layered products) in one deal have there been in the time since the VA outsourcing deal? How many of these sales were to *new* customers? How many of these included a significant Services component? My money says Zero, Zero, Zero. How many VMS services deals with exisiting VMS customers for VMS services >$50 million have been done since that VA deal? -- OpenVMS - The classics never go out of style. ------------------------------ Date: Fri, 18 Feb 2005 07:14:57 -0800 From: "Tom Linden" Subject: Re: HP financials: Alpha sales down Message-ID: On Fri, 18 Feb 2005 09:23:21 -0500, JF Mezei wrote: > Tom Linden wrote: > >> Which computer systems did IBM EOL? > > System 34, System 36, System 38. (replaced by the AS400). The old AS400 > was then ported to Power based systems. IBM redid all the OS names and I > lost track. You need to check your facts. AS400, e.g. runs on a Power core using emulation. It is compatible. The point I was trying to make is that IBM endeavoured to not endanger its installed base by introducing non-compatible architecture. You can run an object module compiled 30 years ago on z-os contrast that with VAX->AXP->IPF In fact, you could run the old System 3 code on the 34, etc. > > The lack of upgradibilkity from the incompatible 34, 36, 38 and MVS > systems was one of the big reasons that VMS took off since it was able > to offer from desktop to data centre on the same OS and in that time, on > the same hardware architecture. > > The 34/36/28/MVS mess was purposefully done so that should IBM have been > forced to divest, the companies buying the smaller systems would not > inherit any of the valuable MVS and 370 architecture stuff. This is one > of the big reasons VMS got such a boost in the 1980s. > Pure speculation on your part. I have never heard such a story before. > When IBM combined the midrange systems into the AS400, the AS400 then > became the "VAX Killer". It was still different from MVS machines, but > it greatly reduced the disparity and incompatibility within IBM by > simplifying the product offering between the PC, AS400 and MVS > mainframes. Huh? What are you talking about? Those are different product lines and there has never been any claim of compatibility amongst them. -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Fri, 18 Feb 2005 07:16:18 -0800 From: "Tom Linden" Subject: Re: HP financials: Alpha sales down Message-ID: On Fri, 18 Feb 2005 08:33:55 -0500, John Smith wrote: > Tom Linden wrote: >> On Thu, 17 Feb 2005 22:33:35 -0500, Neil Rieck >> wrote: >> >>> In December-2004 my employer purchased two used AS-DS20e machines >>> from a used equipment vendor and we quickly realized we were in the >>> middle of a bidding war. The vendor told us that used Alpha sales >>> were up 150% (whatever >>> that means) since September 2004 with no end in sight coming. This >>> started >>> us to speculate: "Did this have anything to do with the announced >>> End-of-Life of Alpha?". Were others thinking things like "Gee, >>> Itanium boxes >>> are coming out now but I'd like to wait for the technology to mature >>> a bit >>> so I'll by myself some time by purchasing used Alphas?" If any of >>> these speculations are even partly true, it makes you wonder why >>> Compaq/HP didn't >>> do the IBM thing and be a little more secretive when it comes to EOL >>> statements etc. >> >> Which computer systems did IBM EOL? > Quite right, forgot about that one, maybe I should have said in the last 40 years:-) > > 709 - sometime long ago, but I bet if you called and asked IBM for help > with one you still had around, they'd find a way to help you out. > > -- > OpenVMS - The classics never go out of style. > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: 18 Feb 2005 15:28:35 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: HP financials: Alpha sales down Message-ID: <37mft3F5f2qc1U1@individual.net> In article , "Tom Linden" writes: > On Fri, 18 Feb 2005 09:23:21 -0500, JF Mezei > wrote: > >> it greatly reduced the disparity and incompatibility within IBM by >> simplifying the product offering between the PC, AS400 and MVS >> mainframes. > Huh? What are you talking about? Those are different product lines > and there has never been any claim of compatibility amongst them. Well, there was that PC370 thing. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Fri, 18 Feb 2005 16:44:15 GMT From: Nigel Barker Subject: Re: HP financials: Alpha sales down Message-ID: <965c111jgou80bs67jk4tu3p7ja92o89n4@4ax.com> On Thu, 17 Feb 2005 20:49:33 -0500, JF Mezei wrote: >Since VMS runs only on a small subset of IA64 boxe I wouldn't call 50% a small subset. -- Nigel Barker Live from the sunny Cote d'Azur ------------------------------ Date: Fri, 18 Feb 2005 13:44:59 -0500 From: Bill Todd Subject: Re: HP financials: Alpha sales down Message-ID: Main, Kerry wrote: >>-----Original Message----- >>From: Bill Todd [mailto:billtodd@metrocast.net] >>Sent: February 17, 2005 8:41 PM >>To: Info-VAX@Mvb.Saic.Com >>Subject: Re: HP financials: Alpha sales down >> >>Keith Parris wrote: ... >> "HP Services (HPS) >> >>>revenue grew 20% year-over-year to a record $3.8 billion. On a >>>year-over-year basis, Managed Services revenue grew 44%, >> >>Consulting and >> >>>Integration grew 20% and Technology Services grew 14%. >> >>Operating profit >> >>>was $281 million, or 7.4% of revenue, compared with $261 >> >>million in the >> >>>prior-year period." Based on past experience, one could >> >>estimate that >> >>>roughly 15% of the revenues and 25% of the profits here >> >>were from VMS. >> >>The 'past experience' you are basing this on would appear to be >>pre-Alphacide experience (very much as that perpetual >>'411,000 installed >>systems' seems to be), unless you're asserting that the Alphacide had >>very little effect in this area: I could have believed that a few >>months or even a year or more after the event (due to the >>time-lag noted >>above), but it seems rather less believable coming up on its fourth >>anniversary. >> >>- bill >> > > > Bill, > > The services revenue is very significant You are, as usual, side-stepping the specific issue raised, Kerry. VMS services revenue could qualify as 'very significant' even if were only 1/4 what it was 4 years ago. If you're not willing to go on record with actual numbers, you're just (again as usual) spewing spin. By the way, the value of that $784 million service contract you cited was not only spread out over a full decade (i.e, less than $80 million annually) but, as John noted, merely reflects the extension of *existing* VMS service revenue rather than new business. - bill ------------------------------ Date: Fri, 18 Feb 2005 00:46:00 -0800 From: Z Subject: Re: linux kernel has major security flaws ... Message-ID: John Santos wrote: > The 1st (of 4) security flaw described says you can access supposedly > secure data if you (as an unprivileged user) have read access to the > swap area or physical access to the machine. I've never heard of a > system that encrypts the swap area (maybe there are systems that > encrypt *everything* on the disk, and so encrypt the swap area), but > other than that, doesn't having read access to the swap area and/or > physical access to the system violate security on any system? Yes, it does. The only real and unfixed flaw in that list is #2, the setsid() bug. ------------------------------ Date: 18 Feb 2005 05:24:35 -0800 From: bob@instantwhip.com Subject: Re: linux kernel has major security flaws ... Message-ID: <1108733074.901509.270530@l41g2000cwc.googlegroups.com> and how many more lists will there be after that? ------------------------------ Date: 18 Feb 2005 13:51:38 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: linux kernel has major security flaws ... Message-ID: <37ma79F5c8371U1@individual.net> In article , Z writes: > John Santos wrote: >> The 1st (of 4) security flaw described says you can access supposedly >> secure data if you (as an unprivileged user) have read access to the >> swap area or physical access to the machine. I've never heard of a >> system that encrypts the swap area (maybe there are systems that >> encrypt *everything* on the disk, and so encrypt the swap area), but >> other than that, doesn't having read access to the swap area and/or >> physical access to the system violate security on any system? > > Yes, it does. The only real and unfixed flaw in that list is #2, the > setsid() bug. I would also wonder if any of this applies to the SE version of RedHat which has (finally) incorporated the work done by NSA into the kernel. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Fri, 18 Feb 2005 12:37:35 +0000 (UTC) From: Heinz Subject: looking for a new job Message-ID: Hi everybody After the company I use to work for closed the doors I was left without a job. At this time it is very hard to find a job as vax/vms system manager in the netherlands. so if there is somebody out there in the world who can use a vax/vms - NT - system manager please let me know and I be happy to send you my cv. Thankz. ------------------------------ Date: 18 Feb 2005 10:07:23 -0800 From: "Barry" Subject: Re: looking for a new job Message-ID: <1108750043.820260.318020@o13g2000cwo.googlegroups.com> If you get yourself an account at decuserve.org, there's a DECNotes conference for employment. It doesn't get a lot of activity, but at least it's another place to post your need. Good luck. ------------------------------ Date: Fri, 18 Feb 2005 11:05:47 GMT From: Nigel Barker Subject: Re: Looking for suggestions for bootcamp sessions Message-ID: On 16 Feb 2005 19:16:02 -0800, kenneth.randell@verizon.net wrote: >On an Alpha, I simply type B DKA0 and I'm all set -- this is very easy >for my users to remember. My experience on Itanium is that the boot >information has some kind of disk-partition/other-magic-code stored in >the NVRAM, so even if the disk is in the same slot and bootable, the >saved boot information is different so the system won't boot. My >remote users are not the kind to use BCFG commands in order to change >things. This part can likely be done via a script, but it seems more >hackerly to write a program. It's true that boot will fail if you swap out one system disk for another set up to autoboot from a disk with a particular Globally Unique Identifier (GUID). However it is still possible to do the equivalent of >>> b dka0 it's just that you have to type in a few more characters e.g. shell> fs0:\efi\vms\vms_loader.efi Creating a new entry in the boot menu is just a question of selecting a couple of menu items. -- Nigel Barker Live from the sunny Cote d'Azur ------------------------------ Date: Fri, 18 Feb 2005 16:51:16 GMT From: John Reagan Subject: Re: Looking for suggestions for bootcamp sessions Message-ID: <82pRd.303$ZA.292@news.cpqcorp.net> Nigel Barker wrote: > However it is still possible to do the equivalent of >>> b dka0 it's just that > you have to type in a few more characters e.g. > > shell> fs0:\efi\vms\vms_loader.efi > > Creating a new entry in the boot menu is just a question of selecting a couple > of menu items. The shell does invoke some ini/login file if present (I don't remember the name right off hand). You can put an alias in there for the above command. -- John Reagan HP Pascal/{A|I}MACRO for OpenVMS Project Leader Hewlett-Packard Company ------------------------------ Date: 18 Feb 2005 05:28:30 -0800 From: bob@instantwhip.com Subject: Micro$oft warns of undetectable spyware security risk ... Message-ID: <1108733310.343931.80970@g14g2000cwa.googlegroups.com> so you think everything can be patched in windoze land ... http://www.theinquirer.net/?article=21326 ------------------------------ Date: 18 Feb 2005 00:10:26 -0800 From: Bart.Zorn@xs4all.nl (Bart Zorn) Subject: Re: Mounting disks during STARTUP Message-ID: There is one example which demonstrates that it works: when you have a shadowed system disk with more than one member, the second (and third) member get automatically added to the shadow set at boot time. But yes, I have seen it work and we use it here in a separate MOUNT_DISKS.COM which is called frol SYLOGICALS.COM. Bart Zorn David J Dachtera wrote in message news:<4215470E.5182510E@comcast.net>... > Bart Zorn wrote: > > > > Not really. If you find a disk which appears to be a shadowset member, > > you can mount it with the /INCLUDE qualifier and it will find its > > fellow members automatically. > > Has anyone seen that actually work? > > -- > David J Dachtera > dba DJE Systems > http://www.djesys.com/ > > Unofficial OpenVMS Hobbyist Support Page: > http://www.djesys.com/vms/support/ > > Unofficial Affordable OpenVMS Home Page: > http://www.djesys.com/vms/soho/ > > Unofficial OpenVMS-IA32 Home Page: > http://www.djesys.com/vms/ia32/ > > Coming soon: > Unofficial OpenVMS Marketing Home Page ------------------------------ Date: Fri, 18 Feb 2005 03:32:17 -0500 From: JF Mezei Subject: Re: Mounting disks during STARTUP Message-ID: <1108714795.7463671c9faa315adbd1d78d697c6012@teranews> Bart Zorn wrote: > > There is one example which demonstrates that it works: when you have a > shadowed system disk with more than one member, the second (and third) > member get automatically added to the shadow set at boot time. Yes because system disks are mounted REALLY early into the booting process, way before any of your DCL gets executed. But do data shadow sets now automount any members that were there when the shadow set was dismounted ? Or must one still do a /INCLUDE to specify which actual drives are to be included ? Back when I did this ( along time ago), I had code that waited up to a few minutes for other disks in a shadow set to become available before proceeding with the mount. If you mounted the shadow set alltogether and it was properly dismounted before, the mount would be quick. If you added a member afterwards, then it could result in a copy/merge operation. (I know that this has changed since I last used it). Waiting a couple minutes during boot saved a lot of processing time. It also gave VMS a much better opportunity at deciding which drive was the most current in case there was a difference in the set. The problem is when not all nodes were being booted at the exact same time. ------------------------------ Date: 18 Feb 2005 07:57:31 -0800 From: Bart.Zorn@xs4all.nl (Bart Zorn) Subject: Re: Mounting disks during STARTUP Message-ID: JF Mezei wrote in message news:<1108714795.7463671c9faa315adbd1d78d697c6012@teranews>... > Bart Zorn wrote: > > > > There is one example which demonstrates that it works: when you have a > > shadowed system disk with more than one member, the second (and third) > > member get automatically added to the shadow set at boot time. > > Yes because system disks are mounted REALLY early into the booting > process, way before any of your DCL gets executed. > > But do data shadow sets now automount any members that were there when > the shadow set was dismounted ? Or must one still do a /INCLUDE to > specify which actual drives are to be included ? > > Back when I did this ( along time ago), I had code that waited up to a > few minutes for other disks in a shadow set to become available before > proceeding with the mount. If you mounted the shadow set alltogether and > it was properly dismounted before, the mount would be quick. If you > added a member afterwards, then it could result in a copy/merge > operation. (I know that this has changed since I last used it). > > Waiting a couple minutes during boot saved a lot of processing time. It > also gave VMS a much better opportunity at deciding which drive was the > most current in case there was a difference in the set. The problem is > when not all nodes were being booted at the exact same time. The fact that the boot process is able to find the original members of the shadowset indicates to me that the chance that MOUNT can do it later on for other disks is very good. I started using /INCLUDE just because I found it in the documentation and until now I have had no reason to distrust it. I call the MOUNT_DISKS.COM, which uses /INCLUDE, from SYLOGICALS.COM and that works OK! I do not use WAITs in MOUNT_DISKS.COM Regards, Bart Zorn ------------------------------ Date: Fri, 18 Feb 2005 17:35:32 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Mounting disks during STARTUP Message-ID: In article , Bart.Zorn@xs4all.nl (Bart Zorn) writes: > I started using /INCLUDE just because I found it in the documentation > and until now I have had no reason to distrust it. I call the > MOUNT_DISKS.COM, which uses /INCLUDE, from SYLOGICALS.COM and that > works OK! I do not use WAITs in MOUNT_DISKS.COM I haven't used it since I don't understand it. :-) What's the advantage, apart from being able to specify only one member of the shadow set? (Actually, for documentaton purposes, I would like to specify all of them.) If all aren't available when using MOUNT/INCLUDE, will the mount fail? If so, this MIGHT be what you want, but might not be. ------------------------------ Date: Fri, 18 Feb 2005 09:18:43 -0500 From: "Main, Kerry" Subject: RE: Need performance help Message-ID: > -----Original Message----- > From: David J Dachtera [mailto:djesys.nospam@comcast.net]=20 > Sent: February 17, 2005 8:48 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Need performance help >=20 > Kenneth Farmer wrote: > >=20 > > Please email this guy directly if you're able to assist. > >=20 > > Rajat.Gupta(at)gb.vodafone.co.uk > >=20 > > I've also posted in OpenVMS Tech forum on OpenVMS.org: > >=20 > > http://www.openvms.org/phorum/read.php?f=3D1&i=3D1533&t=3D1533 > >=20 > > Hello , > >=20 > > Thank you very much for the reponse. I want to know of any=20 > profiling tool > > avalaible for openVMS like gprof on unix. > >=20 > > Actually I have a process that gives a performance of 20000=20 > transactions per > > sec on linux machine but gives only 3000 transactions on an=20 > OpenVMS platform > > with maximum CPU utilization. I want to get hold of the=20 > limiting issues. >=20 > Look into using Extended File Cache, and make sure your disk units on > your storage arrays are set with writeback cache enabled. >=20 Also, have not used this myself, but check out: http://h71000.www7.hp.com/openvms/products/dcpi/ "The HP Digital Continuous Profiling Infrastructure (HP DCPI) Advanced Development Kit for AlphaServer systems permits continuous low-overhead profiling of entire systems, including the kernel, user programs, drivers, and shared libraries. The system is efficient enough that it can be left running all the time, allowing it to be used to drive online profile-based optimizations for production systems.=20 HP DCPI maintains a database of profile information that is incrementally updated for every executable image that runs. A suite of profile analysis tools analyzes the profile information at various levels. At one extreme, the tools show what fraction of CPU cycles were spent executing the kernel and each user program. At the other extreme, the tools show how long a particular instruction stalls on average, for example, because of a D-cache miss.=20 HP DCPI documentation contains an overview of DCPI for OpenVMS, along with detailed descriptions of DCPI commands.=20 To download and install DCPI, you must first agree to the terms of the license and register with HP. You will then receive an e-mail message with the location of the download kit.=20 To be notified of new releases and other developments, sign up for our HP DCPI mailing list by sending us your full name, affiliation, mailing address, and preferred e-mail address." Regards ------------------------------ Date: 18 Feb 2005 02:35:29 -0800 From: "issinoho@gmail.com" Subject: Re: OpenVMS 8.2 docs and freeware Message-ID: <1108722929.675096.60340@l41g2000cwc.googlegroups.com> Has the version of ImageMagick on here been tested and verified to work with JPEG images? My initial attempt at building it didn't work - I'd be interested in hearing from anyone with more fruitful results. ------------------------------ Date: Fri, 18 Feb 2005 12:05:14 -0500 From: "warren sander" Subject: Re: OpenVMS 8.2 docs and freeware Message-ID: <42162094$1@usenet01.boi.hp.com> fixed "Larry Kilgallen" wrote in message news:uDyJyfLtgR3Z@eisner.encompasserve.org... > In article <42152be4$1@usenet01.boi.hp.com>, "warren sander" writes: > > The OpenVMS 8.2 docs are new up and available. > > http://h71000.www7.hp.com/doc > > From here in Massachusetts, the 8.2 link gets me a page that says 8.2 > at the top but has only a column for 7.3-2. The one manual I checked > (Guide to System Security, of course) is the 7.3-2 version. ------------------------------ Date: Fri, 18 Feb 2005 12:05:59 -0500 From: "warren sander" Subject: Re: OpenVMS 8.2 docs and freeware Message-ID: <421620c1@usenet01.boi.hp.com> some of the manuals haven't been updated or they hadn't created new 8.2 versions for me. send your emails to openvmsdocs@hp.com "Larry Kilgallen" wrote in message news:uDyJyfLtgR3Z@eisner.encompasserve.org... > In article <42152be4$1@usenet01.boi.hp.com>, "warren sander" writes: > > The OpenVMS 8.2 docs are new up and available. > > http://h71000.www7.hp.com/doc > > From here in Massachusetts, the 8.2 link gets me a page that says 8.2 > at the top but has only a column for 7.3-2. The one manual I checked > (Guide to System Security, of course) is the 7.3-2 version. ------------------------------ Date: Fri, 18 Feb 2005 13:08:37 -0500 From: "warren sander" Subject: Re: OpenVMS 8.2 docs and freeware Message-ID: <42162f6f$1@usenet01.boi.hp.com> the 7.3-2 version of the guide to security is the most recent copy. it was not updated for 8.2 according to the doc group folks "Larry Kilgallen" wrote in message news:uDyJyfLtgR3Z@eisner.encompasserve.org... > In article <42152be4$1@usenet01.boi.hp.com>, "warren sander" writes: > > The OpenVMS 8.2 docs are new up and available. > > http://h71000.www7.hp.com/doc > > From here in Massachusetts, the 8.2 link gets me a page that says 8.2 > at the top but has only a column for 7.3-2. The one manual I checked > (Guide to System Security, of course) is the 7.3-2 version. ------------------------------ Date: Fri, 18 Feb 2005 09:41:14 +0100 From: Paul Sture Subject: Re: OpenVMS Cluster to Replace News.Individual.NET ? Message-ID: <37lo19F5fb8j4U1@individual.net> Bill Gunshannon wrote: > In article <1108624898.4b72846fc2fcfeae325e3f1dfb4fadf8@teranews>, > JF Mezei writes: > >>leslie wrote: >> >>>One way to give OpenVMS some much-needed publicity would be to offer >>>the internet a multi-site OpenVMS cluster as a free news server. >> >>Is there a NNTP server on VMS that supports user authentication ? >> >>Such a service would be a neat technology demonstration, especially if >>it were setup for free by hobbyists, a showcase of how simple it would >>be compared to the complex and expensive distributed solution sused by >>services such as akamai and the large commercial distributed news servers. > > > I can't imagine whatr solution they use but I ran a News Server for > a long time and it was one of the systems that required the least > of my time. > I too ran a News Server on a SuSE system. and once set up, it just ran. The documentation claimed it had been designed for reliability rather than a high number of users, but it ran fine for me on a 300 MHz el cheapo PC. On a bigger scale there were continual threats to scrap the News Server at work a few years ago, simply because noone wanted it on their budget. The sum involved was peanuts in the grand scheme of things - about half the budget for one person per year, so with maintenance, capital and floorspace costs probably didn't take much time to manage. ------------------------------ Date: Fri, 18 Feb 2005 09:12:54 -0800 From: David Mathog Subject: Re: OpenVMS Cluster to Replace News.Individual.NET ? Message-ID: George Cook wrote: > I may be misunderstanding your data, but the greatest part of the > slowness appears related to file create/open/close? In some cases that was true, but not for the examples given in the benchmark. I've occasionally seen Unix code that opens a file for append, writes to it, then closes it, then does it all over again. This causes only a very minor performance hit on Unix/linux (at least the ones I've used) but is horrifically slow on VMS. You note that DNEWS is much faster than ANUNEWS. I'm not familiar with either one. However, since you state that the latter keeps each post in a separate file by definition it must be doing a lot of open/close, and it's almost axiomatic from that point on that it must be very slow. I'm also going to guess that it started as a port from some Unix program, where all of those and opens and closes wouldn't have been as much of a problem. One can pretty much guess that DNEWS stores posts in a more efficient manner, in some sort of container or database file, so that it doesn't need to open/close zillions of files all the time. Perhaps it uses RMS indexed files, and if not, reimplements something fairly similar at the disk block level. Bypass RMS and then VMS can write data onto disk at a sustained rate as fast as the hardware will go. On the other hand, use RMS, especially through C, and typical smallish read/write programs are, or at least were, much slower on VMS than on identical hardware running linux. This was a real problem for me since roughly 100% of the software we use is written in C! prep@prep.synonet.com wrote: > David Mathog writes: > > David, if you take a broken IO design and do a brain-dead port of it, > what do you expect... If you do it RIGHT, vms will pound unix IO to > pulp. That is why unix is now getting such new ideas as MMIO and Direct > IO. ;| Well, take a look at the benchmarks and tell me in which way they are broken. Most of them do nothing more than open an input file, open an output file (or files) and copy from one to the other. They represent a pretty typical IO load for the sorts of programs I encounter. > > A News server is a notorious system killer. google for `i-node hack' > for an intro. The normal news implementation uses a simplistic file > design to store articles, and hammers file creation to a pulp. The > 50 GB/day is also problematic. > > There is already a reasonable News server for VMS, ANU News, and > it has had several updates and overhauls by I should be able to remember> in it's comercial supported form. George said that ANUNEWS "was a total I/O dog" whereas DNEWS isn't. You guys must be grabbing different parts of that elephant. Is ANUNEWS an I/O dog or not??? Regards, David Mathog mathog@caltech.edu ------------------------------ Date: 18 Feb 2005 08:26:50 -0800 From: jordan@ccs4vms.com Subject: Re: OpenVMS Small Partner Strategy Message-ID: <1108744009.975338.57300@g14g2000cwa.googlegroups.com> Compaq added requirements for certification for a certain number of employees; I got both the Alphaserver and VMS certifications, one other person got the VMS cert, and a third got just the Alphaserver certification. That was sufficient, and we were set to renew that when HP dropped its million dollar doggy bomb on us. However, we used to be a direct VAR under Digital. Under GQ Palmer we were relegated to 'tiered VAR' status, which meant we had to buy through a distributor (in our case Wyle) at lower margins. At the end we were still purchasing through Wyle/Arrow, but as a result of the HP doggy bomb, we were informed that we were no longer qualified to purchase enterprise equipment or software, even through a tier distributor. That means the officially authorized new equipment distributors are prohibited by HP from selling equipment to folks like us for resale. We do still have the ability to 'resell' Alphas and OpenVMS, but now we have to do it through an end reseller (like we used to be); margins are squeaky and order versatility is not what we used to have, In addition, credit for, paperwork for, and HP recognition for the sale goes to the end reseller we 'facilitated' through, not to us. HP support contracts have their name, not ours. So in a way we can do what you described now, though with major caveats and very little margin (and considering you're competing against other end resellers who get a better deal than you on hardware and software cost, you can't count on winning many sales... at least on price). I don't see HP even bothering to pay attention to any such suggestion. They are just flat NOT INTERESTED in selling VMS into small/medium business, and so have no interest in vendors that specialized in that area. Thats why we may well have sold our very last VMS system into a site last year, the end of a ~30 year run that started with PDP-8s and -11s and ended with Dells (because they are cheaper and better wintels and we get a better deal retail from them than we can get from HP as a reseller of their wintel products, and Dell will sell _ANYTHING_ to us without imposing a million dollar minimum requirement...) Rich ------------------------------ Date: Fri, 18 Feb 2005 12:15:07 -0500 From: "John Smith" Subject: Re: OpenVMS Small Partner Strategy Message-ID: <_JGdnXIliNoAv4vfRVn-hg@igs.net> jordan@ccs4vms.com wrote: > Compaq added requirements for certification for a certain number of > employees; I got both the Alphaserver and VMS certifications, one > other person got the VMS cert, and a third got just the Alphaserver > certification. That was sufficient, and we were set to renew that > when HP dropped its million dollar doggy bomb on us. > > However, we used to be a direct VAR under Digital. Under GQ Palmer we > were relegated to 'tiered VAR' status, which meant we had to buy > through a distributor (in our case Wyle) at lower margins. At the end > we were still purchasing through Wyle/Arrow, but as a result of the HP > doggy bomb, we were informed that we were no longer qualified to > purchase enterprise equipment or software, even through a tier > distributor. That means the officially authorized new equipment > distributors are prohibited by HP from selling equipment to folks like > us for resale. > > We do still have the ability to 'resell' Alphas and OpenVMS, but now > we have to do it through an end reseller (like we used to be); > margins are squeaky and order versatility is not what we used to > have, In addition, credit for, paperwork for, and HP recognition for > the sale goes to the end reseller we 'facilitated' through, not to > us. HP support contracts have their name, not ours. > > So in a way we can do what you described now, though with major > caveats and very little margin (and considering you're competing > against other end resellers who get a better deal than you on > hardware and software cost, you can't count on winning many sales... > at least on price). > > I don't see HP even bothering to pay attention to any such suggestion. > They are just flat NOT INTERESTED in selling VMS into small/medium > business, and so have no interest in vendors that specialized in that > area. Thats why we may well have sold our very last VMS system into a > site last year, the end of a ~30 year run that started with PDP-8s and > -11s and ended with Dells (because they are cheaper and better wintels > and we get a better deal retail from them than we can get from HP as a > reseller of their wintel products, and Dell will sell _ANYTHING_ to us > without imposing a million dollar minimum requirement...) Not that you don't have better things to do with your time, but have you written to Ann Livermore? -- OpenVMS - The classics never go out of style. ------------------------------ Date: 18 Feb 2005 10:17:08 -0800 From: bob@instantwhip.com Subject: Re: OpenVMS Small Partner Strategy Message-ID: <1108750628.738920.322920@g14g2000cwa.googlegroups.com> they are not cheaper ... there is the big lie ... total tco is higher with any other non vms solution ... ------------------------------ Date: Fri, 18 Feb 2005 12:39:55 +0000 (UTC) From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: OT: Message to Peter "EPLAN" LANGSTOEGER Message-ID: In article <1108702038.711081.70250@z14g2000cwz.googlegroups.com>, "johnhreinhardt@yahoo.com" writes: >I've tried to send this to you several times, however, I guess your ISP >has my Yahoo mail address blocked. At least that is what is seems to >be from the return message. Sorry, no. I'm the ISP in this case. I forgot to whitelist you, because I've blacklisted YAHOO (besides a bunch of others, too). >Sorry for posting here. I didn't know any other way of getting through >and I didn't want you to think I was ungrateful. A text-only message should always come through if it's not from an RBLed mailer or with an yahoo, msn, netscape and similar sender addresses. So your company mail address may have worked ;-) Normally, I check my OPERATOR.LOG for unwanted rejections, but I was/am ill... You're whitelisted now and Good Luck -- 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: Fri, 18 Feb 2005 16:52:36 GMT From: John Reagan Subject: Re: Port Print facility Update for I64 Message-ID: David J Dachtera wrote: > Thanx to the maintainers of the test-drive cluster site for the use of > the IA64 machine. > Just curious... How long did it take you to port? Any interesting problems you ran into? -- John Reagan HP Pascal/{A|I}MACRO for OpenVMS Project Leader Hewlett-Packard Company ------------------------------ Date: Fri, 18 Feb 2005 14:55:05 +0100 From: "Ferry Bolhar" Subject: Re: read monitor (>>>) variables from OpenVMS ? Message-ID: <1108734909.382005@proxy.dienste.wien.at> schrieb im Newsbeitrag news:1108571853.458156.104310@z14g2000cwz.googlegroups.com... > What version of OpenVMS allows you to use a f$setenv function? > v7.3-1 returns an -IVFAM invalid lexical function name. Perhaps you're on a VAX? F$GETENV exists on Alpha only. Greetings, Ferry -- Ing. Ferry Bolhar Municipality of Vienna, Department 14 A-1010 Vienna / AUSTRIA E-mail: bol@adv.magwien.gv.at ------------------------------ Date: 18 Feb 2005 12:08:31 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: read monitor (>>>) variables from OpenVMS ? Message-ID: In article <1108734909.382005@proxy.dienste.wien.at>, "Ferry Bolhar" writes: > > schrieb im Newsbeitrag > news:1108571853.458156.104310@z14g2000cwz.googlegroups.com... >> What version of OpenVMS allows you to use a f$setenv function? >> v7.3-1 returns an -IVFAM invalid lexical function name. > > Perhaps you're on a VAX? F$GETENV exists on Alpha only. The same is true of V7.3-1 :-) ------------------------------ Date: Fri, 18 Feb 2005 11:38:43 -0500 From: "Stanley F. Quayle" Subject: Shark Tank mentions VMS Message-ID: <4215D3C3.27182.2FD3584@localhost> http://www.computerworld.com/departments/opinions/sharktank/0,4885,998 78,00.html?source=NLT_SH&nid=99878 Beware abbreviations! --Stan Quayle Quayle Consulting Inc. ---------- Stanley F. Quayle, P.E. N8SQ +1 614-868-1363 8572 North Spring Ct., Pickerington, OH 43147 USA stan-at-stanq-dot-com http://www.stanq.com ------------------------------ Date: Fri, 18 Feb 2005 12:07:18 -0500 From: "Main, Kerry" Subject: RE: Shark Tank mentions VMS Message-ID: > -----Original Message----- > From: Stanley F. Quayle [mailto:squayle@insight.rr.com]=20 > Sent: February 18, 2005 11:39 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Shark Tank mentions VMS >=20 > http://www.computerworld.com/departments/opinions/sharktank/0,4885,998 > 78,00.html?source=3DNLT_SH&nid=3D99878 >=20 > Beware abbreviations! >=20 > --Stan Quayle > Quayle Consulting Inc. >=20 > ---------- > Stanley F. Quayle, P.E. N8SQ +1 614-868-1363 > 8572 North Spring Ct., Pickerington, OH 43147 USA > stan-at-stanq-dot-com http://www.stanq.com >=20 >=20 Stan, Reminds me of some older VAX console commands that used to interpret ">>>H" as short for "halt" the system. That is until a few incidents were reported whereby operaters would enter ^P to get to the console and then type "H" for "help" .... :-) As I recall, subsequent versions required one to enter at least HA or HE to be recognized. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .." ------------------------------ Date: Fri, 18 Feb 2005 13:33:41 -0500 From: "Bochnik, William J" Subject: RE: Shark Tank mentions VMS Message-ID: <2D75787AAF09C64481BDFD89113BE6D507CBCCB3@ac2kama0102.ac.lp.acml.com> Had a similar incident at my old job. The "esc" key on the Microvax 2 would take you to the >>> prompt. We used terminal servers there, where hitting the esc key would allow you to switch sessions. Well, one day a programmer was in the datacenter and walked over to the MII. He sees that someone's logged in, so hits the esc key, and gets the >>> prompt. Needless to say 30 seconds later we had a cluster state transition.... -----Original Message----- From: Main, Kerry [mailto:kerry.main@hp.com]=20 Sent: Friday, February 18, 2005 12:07 PM To: Info-VAX@Mvb.Saic.Com Subject: RE: Shark Tank mentions VMS > -----Original Message----- > From: Stanley F. Quayle [mailto:squayle@insight.rr.com] > Sent: February 18, 2005 11:39 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Shark Tank mentions VMS >=20 > http://www.computerworld.com/departments/opinions/sharktank/0,4885,998 > 78,00.html?source=3DNLT_SH&nid=3D99878 >=20 > Beware abbreviations! >=20 > --Stan Quayle > Quayle Consulting Inc. >=20 > ---------- > Stanley F. Quayle, P.E. N8SQ +1 614-868-1363 > 8572 North Spring Ct., Pickerington, OH 43147 USA > stan-at-stanq-dot-com http://www.stanq.com >=20 >=20 Stan, Reminds me of some older VAX console commands that used to interpret ">>>H" as short for "halt" the system. That is until a few incidents were reported whereby operaters would enter ^P to get to the console and then type "H" for "help" .... :-) As I recall, subsequent versions required one to enter at least HA or HE to be recognized. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .." ----------------------------------------- The information contained in this transmission may contain privileged and c= onfidential information and is intended only for the use of the person(s) n= amed above. If you are not the intended recipient, or an employee or agent = responsible for delivering this message to the intended recipient, any revi= ew, dissemination, distribution or duplication of this communication is str= ictly prohibited. If you are not the intended recipient, please contact the= sender immediately by reply e-mail and destroy all copies of the original = message. Please note that we do not accept account orders and/or instructio= ns by e-mail, and therefore will not be responsible for carrying out such o= rders and/or instructions. If you, as the intended recipient of this message, the purpose of which is = to inform and update our clients, prospects and consultants of developments= relating to our services and products, would not like to receive further e= -mail correspondence from the sender, please "reply" to the sender indicati= ng your wishes. In the U.S.: 1345 Avenue of the Americas, New York, NY 101= 05. ------------------------------ Date: Fri, 18 Feb 2005 10:15:18 +0000 From: Roy Omond Subject: Re: TCPIP automatic route additions Message-ID: <37ltm5F5g3l08U1@individual.net> DeanW wrote: >>I have a customer with a somewhat mis-configured network. Clients are >>connecting to the VMS box via a router that normally shouldn't be >>passing that traffic- and when they do, TCPIP (5.0a) automatically >>adds a route back to that client's subnet through the incorrect >>router, which then prevents all the rest of the clients on that subnet >>from connecting the proper way. >> >>It's a simple installation, with not dynamic routing enabled on the >>VMS side (or anywhere, if they're following my suggestion- but they >>did just bring a high-priced network consultant in, which is probably >>how we got this mess in the first place... *sigh*) >> >>Anyway, the routing table should look like: >> >>$ tcpip sho route >> >> DYNAMIC >> >>Type Destination Gateway >> >>DN 0.0.0.0 172.16.1.1 >>DH 127.0.0.1 127.0.0.1 >>AN 172.16.0.0/22 172.16.1.4 >>DN /24 172.16.1.10 >>$ tcpip sho route /perm >> >> PERMANENT >> >>Type Destination Gateway >> >>PN 0.0.0.0 172.16.1.1 >>PH 127.0.0.1 127.0.0.1 >>PN 172.16.0.0/22 172.16.1.4 >>PN /28 172.16.1.10 >>$ >> >>The trouble comes when something connects from 192.168.0.x via the >>firewall at 172.16.1.10 instead of coming in through the default >>router (172.16.1.1) Solving this issue is going to take some time, as >>it's sporradic (usually once or twice a month) but crippling when it >>happens, until the incorrect routes get removed. >> >>Is there a way to have TCPIP not automatically add routes that I don't want? >> >>If I put a permanent route in for 192.168.0/24 to go through the >>default router, will that defeat the automatic routes being added? >>(I'm dubious- note that the permenant route to the external net is >>correct, the dynamic one has an incorrect bitmask...) Sorry for the late addition, but this has been discussed before on cov. The solution is to disable ICMP redirects in the inet subsystem. I.e. $ tcpip TCPIP> sysconfig -r inet icmp_rejectcodemask=32 Roy Omond Blue Bubble Ltd. ------------------------------ Date: Fri, 18 Feb 2005 12:07:47 +0100 From: "Usenet" Subject: TCPIP name cache Message-ID: <4215cc9f$0$23944$ba620e4c@news.skynet.be> Hi, Is somebody could tell me how I can see the naming cache in TCPIP point of view and how I can flush it. Thus the same as $ mc cdi_cache_dump $ mc ncl flush session control naming cache entry "*" but for tcpip. We have a DNS based configuration. My problem is the following : A client has token a telnet session on a server. As there is no reverse dns on the ip address of the client, the logical SYS$REM_NODE is equal to the ip address. Thus SET DISPLAY/CREATE/NODE='f$trnlnm("SYS$REM_NODE")/TRANS=TCPIP works well For a management reason, the reverse resolution of the client ip address was activated but to an other name that the dns name. Thus SYS$REM_NODE was defined to a NONE_DNS_NAME , thus SET DIPLAYS no more working. The reverse resolution was disabled but the NONE_DNS_NAME seems to be associated in a cache to the ip address of the client. TTL of the reverse record : 3 hours, NONE_DNS_NAME still present after 2 days. Thanks for your help Seghers Bruno Belgium ------------------------------ Date: Fri, 18 Feb 2005 12:08:15 +0100 From: "Usenet" Subject: TCPIP name cache Message-ID: <4215cca0$0$23944$ba620e4c@news.skynet.be> Hi, Is somebody could tell me how I can see the naming cache in TCPIP point of view and how I can flush it. Thus the same as $ mc cdi_cache_dump $ mc ncl flush session control naming cache entry "*" but for tcpip. We have a DNS based configuration. My problem is the following : A client has token a telnet session on a server. As there is no reverse dns on the ip address of the client, the logical SYS$REM_NODE is equal to the ip address. Thus SET DISPLAY/CREATE/NODE='f$trnlnm("SYS$REM_NODE")/TRANS=TCPIP works well For a management reason, the reverse resolution of the client ip address was activated but to an other name that the dns name. Thus SYS$REM_NODE was defined to a NONE_DNS_NAME , thus SET DIPLAYS no more working. The reverse resolution was disabled but the NONE_DNS_NAME seems to be associated in a cache to the ip address of the client. TTL of the reverse record : 3 hours, NONE_DNS_NAME still present after 2 days. Thanks for your help Seghers Bruno Belgium ------------------------------ Date: Fri, 18 Feb 2005 06:37:36 -0500 From: JF Mezei Subject: Re: TCPIP name cache Message-ID: <1108725911.f600f61a9cb72f0e240206e3e64907ae@teranews> Usenet wrote: > Is somebody could tell me how I can see the naming cache in TCPIP point of > view and how I can flush it. @sys$manager:tcpip$define_commands or ncd :== "$sys$system:tcpip$bind_server_control.exe" then: $ndc dumpdb This creates [sys0.tcpip$bind]tcpip$bind_server_zones_dump.DB It includes all the stuff in its cache in what seems to be a random order. I *assume* that restarting the name server (there is an option in NDC, but you can also user TCPIP SET NAME_SERVICE/INITIALIZE) would zap the cache and reload your own zone files from scratch. But I haven't tested this. (only hat the set name/init does reload the local zone file, not sure about cache) ------------------------------ Date: Fri, 18 Feb 2005 07:03:05 -0500 From: JF Mezei Subject: Re: TCPIP name cache Message-ID: <1108727435.a567f99a19b860767f6a248a3d6e7adb@teranews> Usenet wrote: > Thus SET DISPLAY/CREATE/NODE='f$trnlnm("SYS$REM_NODE")/TRANS=TCPIP works > well > > For a management reason, the reverse resolution of the client ip address was > activated but to an other name that the dns name. You can try instead of f$trnlnm("SYS$REM_NODE") : 'F$GETDVI ( "TT", "TT_ACCPORNAM" ) However, this may yeield the same information (eg: translated name instead of IP address). If you have access to your own DNS server, you might be able to override what the corporate server gives you. It is VERY wrong for a coprate DNS scheme to assign a wrong name to an IP, especially if that name is shared between many IPs since this means that you can't really tell who is coming into your system. Right now, about the only way I have found is: SHOW TERM, this gives you the remote port number. then TCPIP SHOW DEV and then hnt for the line that has that remote port number, and you get the IP address instead of translated host name. Is there a better way to corrolate the TNAxxx: device to the BGxxx: device ???? ------------------------------ Date: Fri, 18 Feb 2005 08:51:07 -0800 From: "Tom Linden" Subject: Terminal connection Message-ID: I use PuTTY from W2k to connect using SSH2 to a 7.3-2 machine and then DECnet to a 7.3-1 machine where I run emacs 19.28 When I try to run emacs I get NORNS> emacs -nw FOO.TXT [Spawning a new Kept EMACS] emacs: Terminal type vt102-80 is not defined. If that is not the actual type of terminal you have, use the Bourne shell command `TERM=... export TERM' (C-shell: `setenv TERM ...') to specify the correct type. It may be necessary to do `unset TERMCAP' (C-shell: `unsetenv TERMCAP') as well. [Attached to DCL in directory $7$DKA0:[TOM]] Now in the TERM dir there is VT100.ELC;1 VT102.EL;1 VT125.EL;1 VT200.EL;1 VT200.ELC;1 VT201.EL;1 VT220.EL;1 VT240.EL;1 NORNS> type VT102.EL (load "term/vt100" nil t) Is the problem that the above lisp file is not byte compiled? Who is claiming that it is VT102-80, PuTTY? SHO TERM/FULL doesn't supply that form of designation. ------------------------------ Date: Fri, 18 Feb 2005 16:40:21 GMT From: Nigel Barker Subject: Re: VMS 8.2 Itanium Distribution Message-ID: <2v4c1158obfjco5laa6896902hqov4q5ri@4ax.com> On Thu, 17 Feb 2005 03:47:34 GMT, rdeininger@mindspringdot.com (Robert Deininger) wrote: >(Yes, the VMS installation kit for Itanium is on DVD, not CD.) It's on DVD for the very good reason that it doesn't fit on a CD. In fact AFAICR it wouldn't even fit on 2 CDs. -- Nigel Barker Live from the sunny Cote d'Azur ------------------------------ Date: Fri, 18 Feb 2005 11:35:17 -0500 From: JF Mezei Subject: Re: VMS 8.2 Itanium Distribution Message-ID: <1108743749.8025c9a5c7b2d36a5aaf6f3b13db15a0@teranews> Nigel Barker wrote: > It's on DVD for the very good reason that it doesn't fit on a CD. In fact AFAICR > it wouldn't even fit on 2 CDs. I can understand executables bloating from VAX to Alpha since all pointers/adresses double in size from 32 to 64 bits, and if you have instructions containing 2 adddresses, that makes things even worse. But from Alpha to IA64, since both are 64 bits, how come there would be so much difference in size between 600meg and over 1200 meg ? Is the bloat due to truly bigger .exe files ? Or are there extra components bundled into the OS installtion CDs ? ------------------------------ End of INFO-VAX 2005.098 ************************