INFO-VAX Mon, 12 Mar 2007 Volume 2007 : Issue 141 Contents: Re: AMD's well may be running dry Re: AMD's well may be running dry Re: AMD's well may be running dry Re: AMD's well may be running dry Re: AMD's well may be running dry Re: AMD's well may be running dry Broken Internet connectivity Re: Broken Internet connectivity Re: Broken Internet connectivity Re: Building I64 bootable OpenVMS media on Alpha Re: Time zone/DST change question. RE: Time zone/DST change question. ---------------------------------------------------------------------- Date: Sun, 11 Mar 2007 20:28:20 -0000 From: "John Wallace" Subject: Re: AMD's well may be running dry Message-ID: <45f469af$0$8728$ed2619ec@ptn-nntp-reader02.plus.net> "JF Mezei" wrote in message news:5aa01$45f45e78$cef8887a$8522@TEKSAVVY.COM... > ... IA64 loses its reason for existance, especially since it is not a profitable product for Intel. How can Itanium lose its reason for existence, when Itanium has business-critical RAS features which (some parts of) HP tell us are not offered on any other volume processor on the market today ? Y'know, the "cosmic ray" stuff? Incidentally, readers may wish to be reminded that 2007 is the year that Intel say goodbye to the Palmer-era ten year legal agreement settling the patent troubles between Digital and Intel in 1996/7 (as reported at e.g. http://news.com.com/2100-1023-204668.html). Not that I expect anything much to change as a result of it ending, given the changes in ownership in the intervening years, but Happy Anniversary to it anyway, while I remember... regards John ------------------------------ Date: Sun, 11 Mar 2007 17:09:17 -0400 From: JF Mezei Subject: Re: AMD's well may be running dry Message-ID: John Wallace wrote: > patent troubles between Digital and Intel in 1996/7 (as reported at e.g. > http://news.com.com/2100-1023-204668.html). There was a very interesting tidbit in there. When Palmer gave Intel all those gifts to thank Intel for stealing Alpha designs, one of those gifts was a Jerusalem chip design office. It turns out that Intel's current success with its 8086 "Core" designs came from its Jerusalem office. It also means that some ALpha designers would have been transfered to Intel at that time instead of on June 25 2001. In hindsight, Digital agreeing to start developing systems based on that still very virtual IA64 thing is interesting. Had DEC already been poo-pooing that IA64 thing before, or did those presentation showing how Alpha would maintain a clear lead over that ugly kludge IA64 thing result from DEC engineers gaining access to IA64 designs as a result of Palmer's deal ? ------------------------------ Date: 11 Mar 2007 14:14:51 -0700 From: "n.rieck@sympatico.ca" Subject: Re: AMD's well may be running dry Message-ID: <1173647690.934192.292140@p10g2000cwp.googlegroups.com> On Mar 11, 10:51 am, Kilgal...@SpamCop.net (Larry Kilgallen) wrote: > From: http://news.yahoo.com/s/ap/20070311/ap_on_bi_ge/amd_intel_shifting_fo... > > SAN JOSE, Calif. - The high-flying Advanced Micro Devices Inc. of 2006 > has given way to a company in financial peril, saddled with debt and > bleeding from a brutal price battle with its larger and suddenly resurgent > Silicon Valley archrival, Intel Corp. The previous 10 years of the internet has brought me to the conclusion that the phrase "information age" does not the same thing as "accurate data age". Before the internet, "watergate scandal" meant just that, but today you've got all kinds of mis-information data flows popping up (like "scooter isn't really guilty of anything even though a jury of 12 said he was"). You never know if a news piece like this is real or stock-price manipulation. Are all things rosy at AMD? Probably not. Last year Intel ditched ~ 40,000 marketing (not sales) people and this should have been a signal to all of us that "the gloves are off". If AMD can't realize similar savings then they might lose some market share if a price war ensures. And prices are already dropping. A friend of mine just bought a 3.6 GHz dual core system and he paid less for the complete system than I did just for my hyper-threaded 3.2 GHz CPU 18 months ago. (same quality ASUS motherboard etc.) Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: 11 Mar 2007 18:21:03 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: AMD's well may be running dry Message-ID: In article <1173647690.934192.292140@p10g2000cwp.googlegroups.com>, "n.rieck@sympatico.ca" writes: > data age". Before the internet, "watergate scandal" meant just that, > but today you've got all kinds of mis-information data flows popping > up (like "scooter isn't really guilty of anything even though a jury > of 12 said he was"). I heard people offer that theory of non-guilt on TV today, without any Internet required. ------------------------------ Date: Mon, 12 Mar 2007 00:51:30 -0000 From: "John Wallace" Subject: Re: AMD's well may be running dry Message-ID: <45f4a415$0$8719$ed2619ec@ptn-nntp-reader02.plus.net> "JF Mezei" wrote in message news:ea306$45f4701c$cef8887a$14367@TEKSAVVY.COM... > Had DEC already been poo-pooing that > IA64 thing before, or did those presentation showing how Alpha would maintain a > clear lead over that ugly kludge IA64 thing result from DEC engineers gaining > access to IA64 designs as a result of Palmer's deal ? What (part of) DEC were saying about IA64 in 1999 can be found at http://www.cs.trinity.edu/~mlewis/CSCI3294-F01/Papers/alpha_ia64.pdf [1] - an Alpha vs IA64 white paper focusing on parallelism (in particular, out of order and SMT). It's a paper I like a lot, because although it's got a reasonable amount of techy stuff in it, it's still quite readable. It's 32 not all that dense pages, it makes no sense for me to try to offer summary or highlights. Given that IA64 was largely based on pre-existing VLIW stuff, and there was lots of public "how it's going to be sooooo fast" stuff, I don't think one need assume any "special" access to inside Intel to produce such a paper. That paper has been mentioned previously in this newsgroup, eg most recently in the thread titled "There goes the volume market. Remind me again...." started by John Smith (?) on 2 Feb 2005 (you were there, JF, but others may not have seen it); searching for alpha_ia64.pdf in comp.os.vms finds various other threads where it's been discussed, at least as far back as 2001. Obviously it's only of historic interest now, because Alpha is dead whereas IA64 systems are alive and affordable, and the official word is that OpenVMS on x86-64 is a non-starter. The future is kind of difficult to predict though, and many sensible folk may think a risk reduction strategy is a good thing to have, just in case the unthinkable happens. hth John [1] Originally from the Alphapowered website, actually still available at http://web.archive.org/web/20010602154126/www.alphapowered.com/presentations /alpha_ia64.pdf ------------------------------ Date: Sun, 11 Mar 2007 22:15:22 -0400 From: JF Mezei Subject: Re: AMD's well may be running dry Message-ID: John Wallace wrote: > IA64 systems are alive and affordable, and the official word is that OpenVMS > on x86-64 is a non-starter. The future is kind of difficult to predict The problem is that the statements that VMS on industry standard chips being a "non=starter" come from the very people who have no credibility because their employer has a hard record of lying to customers about platform futures. And I prefer to hope that HP is lying about VMS not going to the 8086 as opposed to interpreting the message as "HP has already decided that VMS will not be ported beyond IA64". ------------------------------ Date: 11 Mar 2007 21:21:45 -0700 From: TFTAJLLYMXZP@spammotel.com Subject: Broken Internet connectivity Message-ID: <1173673305.173827.145390@8g2000cwh.googlegroups.com> My hobbyist Alpha system running VMS 7.3-2 and TCPIP 5.4 ECO 6 has recently developed an inability to reach the Internet, at least with TCP/IP protocols. When I ping a remote host using a hostname its IP address is returned, but all packets end up lost. I believe this problem coincided with my upgrade from ECO 5 to ECO 6 of TCPIP, but wouldn't swear to it. The timing may be coincidental. The other non-VMS hosts in my LAN can get out, but the VMS box appears blocked. Within the LAN, everything works just fine and all hosts can connect to all other hosts in several ways. The LAN sits behind a D- Link router/gateway having an IP address of 192.168.0.1, but it is definitely not configured to block the VMS host from accessing the Internet. All hosts on the LAN are configured to use this gateway address as primary DNS server. I've looked through the configuration parameters several times, but simply cannot see anything amiss. Would someone have suggestions on how to troubleshoot this a bit more? Here's some of the configuration parameters I'm looking at: $ tcpip show version HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6 on a AlphaServer 1000A 4/266 running OpenVMS V7.3-2 $ tcpip show host/local LOCAL database Host address Host name 192.168.0.1 DI524, di524, di524.erebus.ca, DI524.EREBUS.CA 192.168.0.4 GONDOR, gondor, gondor.erebus.ca, GONDOR.EREBUS.CA 192.168.0.5 ISZKAZ, iszkaz, iszkaz.erebus.ca, ISZKAZ.EREBUS.CA 192.168.0.6 KIRALY, kiraly, kiraly.erebus.ca, KIRALY.EREBUS.CA 127.0.0.1 LOCALHOST, localhost 192.168.0.3 SZEGED, szeged, szeged.erebus.ca, SZEGED.EREBUS.CA $ tcpip show name_service BIND Resolver Parameters Local domain: EREBUS.CA System State: Started, Enabled Transport: UDP Domain: EREBUS.CA Retry: 4 Timeout: 4 Servers: DI524 Path: No values defined Process State: Enabled Transport: Domain: Retry: Timeout: Servers: Path: $ tcpip show interface/full we0 Interface: WE0 IP_Addr: 192.168.0.3 NETWRK: 255.255.255.0 BRDCST: 192.168.0.255 Ethernet_Addr: 00-00-F8-21-DA-F8 MTU: 1500 Flags: UP BRDCST RUN MCAST SMPX RECEIVE SEND Packets 15077 9391 Errors 0 0 Collisions: 0 $ tcpip show communication Communication Parameters Local host: szeged Domain: EREBUS.CA Maximum Current Peak Proxies 20 Remote Terminal Large buffers: 0 UCBs: 0 Virtual term: disabled $ tcpip show communication/security Communication Security Parameters Allow Log: Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimO Addr Force Log: None Security device: disabled Access lists Accept host: LOCALHOST, 142.32.2.125, 142.36.84.205 Accept netw: 192.168.0.0:255.255.255.0 $ tcpip show route DYNAMIC Type Destination Gateway AN 0.0.0.0 192.168.0.1 AH 127.0.0.1 127.0.0.1 AN 192.168.0.0/24 192.168.0.3 AH 192.168.0.3 192.168.0.3 $ ------------------------------ Date: 11 Mar 2007 22:19:46 -0700 From: "David B Sneddon" Subject: Re: Broken Internet connectivity Message-ID: <1173676786.034561.144450@30g2000cwc.googlegroups.com> Have you tried doing a trace from the VMS box to somewhere out in the wide wild world? That may give you an indication of how far it is getting and maybe where the problems lies. Dave ------------------------------ Date: Mon, 12 Mar 2007 01:23:27 -0400 From: JF Mezei Subject: Re: Broken Internet connectivity Message-ID: <17a82$45f4e3f0$cef8887a$22627@TEKSAVVY.COM> TFTAJLLYMXZP@spammotel.com wrote: > My hobbyist Alpha system running VMS 7.3-2 and TCPIP 5.4 ECO 6 has > recently developed an inability to reach the Internet, at least with > TCP/IP protocols. It is a common problem with VMS systems of a certain age. There are some magic blue pills that can help solve this issue. Look on your mailbox, you probably have a lot of advertsisements for such pills ;-) If you use "traceroute www.ibm.com" , how far does it go ? Does it reach your router ? (if the traceroute command is not defined @sys$manager:tcpip$define_commands ) Your TCPIP show route seems OK. AN 0.0.0.0 192.168.0.1 AH 127.0.0.1 127.0.0.1 AN 192.168.0.0/24 192.168.0.3 AH 192.168.0.3 192.168.0.3 First line is your default route that points to your router. 3rd line says to route anything to 192.168.0.* via the 192.168.0.3 interface. HOWEVER, it appears that: >$ tcpip show communication/security >Access lists > Accept host: LOCALHOST, 142.32.2.125, 142.36.84.205 > Accept netw: 192.168.0.0:255.255.255.0 The documentation for SET COMM/ACCEPT isn't quite explicit. But if the presence of a list implies that anything not on that list is rejected, then it would explain your behaviour. It is possible that this is something which could have changed with the ECO (eg: a bug fixed etc). try TCPIP SET COMM/ACCEPT=NONETWORK=192.168.0.0:255.255.255.0 and the corresponding hosts with NOHOST Does pinging 142.32.2.125 work ? if it, it may support the theory that hosts outside of the accept list would be blocked. ------------------------------ Date: 11 Mar 2007 20:20:02 -0700 From: "johnhreinhardt@yahoo.com" Subject: Re: Building I64 bootable OpenVMS media on Alpha Message-ID: <1173669602.807140.136550@s48g2000cws.googlegroups.com> On Mar 8, 4:48 pm, Stephen Hoffman wrote: > johnhreinha...@yahoo.com wrote: > > My Alpha system that I'm trying to build this on is a V8.2. Should I > > upgrade to V8.3? Would that help with the tools at all? > > If you are restricted to what is supported by HP OpenVMS, then the El > Torito structures are likely what can be officially expected and > required, and what Mr. Kleinsorge indicates is undoubtedly correct. > > El Torito is a disk partitioning scheme built on ISO-9660 structures, > and it's one of the ways to boot EFI off various media. Basically, the > ISO-9660 and El Torito partitioning structures are overlaid onto an > ODS-style disk, and the two are merged together. (There's a technique > around for initializing an ODS-2 or ODS-5 disk with the region of the > disk that is required for the ISO-9660 and El Torito structures > reserved, but that's fodder for another discussion.) > > There are other and unsupported paths that are available toward > bootable media that are present in the EFI specifications, and that have > been empirically found to work correctly with optical media devices. > And that can boot OpenVMS I64. > > Details on the alternative CD and DVD media bootstraps? Wander over > to the oldwww.HoffmanLabs.comweb site, find the link over to the new > HoffmanLabs website at the top of the main page of the old site, and go > looking for the document "LabsNotes: Recording CD and DVD Media on > OpenVMS" at the new site. It's at /node/28, too. Hopefully everything > you want to know about recording disks, including how to master and > generate recordable media, as well as generating bootable media for > OpenVMS I64 and for OpenVMS Alpha, is included in that document. > > The mastering description does not use and does not require the El > Torito and the ISO-9660 structures. I would certainly expect that Mr. > Kleinsorge would indicate the approach is unsupported. But it can and > does boot on EFI, so it may well address your requirements pending the > availability of supported El Torito and ISO-9660 mastering tools for > OpenVMS. > > Hoff > > --www.HoffmanLabs.com > Services for OpenVMS Okay. Actually, I'm way ahead of you there because I had already created an account on your new site (looks great BTW) and scoured the whole thing (all the blogs back to early January and the other miscellaneous postings) for any information on DVD mastering. I have the LabNote you mentioned and also the OpenVMS tip on EFI and ODS-2 and ODS-5 (which is how I got the sys$setboot info posted previously). My problem in the procedure comes at this step: $ @SYS$SYSTEM:I64VMS$PCSI_INSTALL_MIN.COM LDA4700: My Alpha V8.2 system doesn't have that command procedure anywhere. It does, however, have AXPVMS$PCSI_INSTALL_MIN.COM. But I've looked at the code and I can't see how it would create an I64 bootable piece of media. Moving on, my second attempt was also a failure. This is what I did - if you spot any problems, please point them out. 1) LD CREATE DSA2:[LDD]I64083.IMG/SIZE=5668992 2) LD CONNECT DSA2:[LDD]I64083.IMG LDA2: 3) INIT/ERASE/GPT/CLUSTER=16 LDA2: I64083 4) MOUNT /OVER=ID LDA2: 5) BACKUP LDA1:[VMS$COMMON...]*.*;* LDA2:[*...]/LOG <-- Copy the common OpenVMS system files 6) BACKUP LDA1:[SYS0...]*.*;*/EXCLUDE=([SYS0.SYSCOMMON...]*.*;*) LDA2: [*...]/LOG <--- Copy one set of system root specific files 7) SET FILE /ENTER=LDA2:[SYS0]SYSCOMMON.DIR LDA2:[000000]VMS $COMMON.DIR <-- Create the alias for the common files in the root. 8) SET FILE /ENTER=[000000]SYS1.DIR [000000]SYS0.DIR <--- Repeated for system roots sys2 - sys10 9) $ BACKUP LDA1:[ALPHA_TOOLS...]*.*;* LDA2:[*...]/LOG \ $ BACKUP LDA1:[AVAILMAN_I64026...]*.*;* LDA2:[*...]/LOG \ $ BACKUP LDA1:[AVAIL_MAN_BASE...]*.*;* LDA2:[*...]/LOG / Repeated for all install kits on the DVD $ BACKUP LDA1:[CDSA_I64022...]*.*;* LDA2:[*...]/LOG / 10) SET BOOTBLOCK/BLOCK_SIZE=2048/IA64 LDA2: 11) LD CONNECT DSA2:[LDD]I64083.IMG LDA2: 12) DSA2:[LDD]i64083.IMG is FTPed in binary mode to my Mac OS X system and written to a DVD. Here is the dump of the boot structure from sys$setboot.exe $ sb -s -f lda2: OpenVMS SETBOOT version V5.0-4 Boot Architecture : IA-64 Boot Address : 0x00004824 : 000000018468 Boot Size : 0x00001f40 : 000000008000 Boot Identifier GUID : C12A7328F81F11D2BA4B00A0C93EC93B Boot Signature GUID : 4065000400AA488311DBCDE817180ED0 Master Boot Record : Protective MBR When I put the DVD in the ZX2000 is a difference in the device mapping table in the EFI shell. I have two additional block devices, however I have no additional file structured devices: blkA: Acpi(HWP0002,500)/Pci(2|0)/Ata(Secondary,Master) blkB: Acpi(HWP0002,500)/Pci(2|0)/Ata(Secondary,Master)/ HD(Part1,SigC9B73EB7) If I dump the first 2048 bytes of the blkA device I get: Logical block number 0 (00000000), 512 (0200) bytes 74737973 20343649 20534D56 6E65704F 206E6120 73692073 69685420 34303030 0004 This is an OpenVMS I64 syst 000000 68742072 65746C61 20746F6E 206F6420 65736165 6C502020 2E6B7369 64206D65 em disk. Please do not alter th 000020 69687420 6E6F6974 69747261 702D6572 20726F6E 202C5450 47202C52 424D2065 e MBR, GPT, nor re-partition thi 000040 6F442020 2E746920 74707572 726F6320 756F7920 7473656C 202C6B73 69642073 s disk, lest you corrupt it. Do 000060 296E4B4C 4220726F 206E5346 28205450 47206E6F 20646E65 70656420 746F6E20 not depend on GPT (FSn or BLKn) 000080 00000000 00000000 00000000 00000000 00000000 00002167 6E697265 64726F20 ordering!...................... 0000A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000E0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000100 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000120 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000180 00000000 C9B73EB7 00000000 00000000 00000000 00000000 00000000 00000000 ........................?>??.... 0001A0 00000000 00000000 00000000 00000000 00000015 A01F0000 00010000 00EE0000 ..?............................. 0001C0 AA550000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ..............................U? 0001E0 Logical block number 1 (00000001), 512 (0200) bytes 00000000 00000001 00000000 C54F24BF 0000005C 00010000 54524150 20494645 EFI PART....\...?$O?............ 000000 11DBCDE8 17180ED0 00000000 00159FFE 00000000 00000022 00000000 0015A01F ........".......?.......?...???. 000020 00000000 C177FD3D 00000080 00000080 00000000 00000002 40650004 00AA4983 .I?...e@................=?w?.... 000040 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000060 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0000E0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000100 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000120 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000140 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001E0 Logical block number 2 (00000002), 512 (0200) bytes 40650004 00AA4883 11DBCDE8 17180ED0 C12A7328 F81F11D2 BA4B00A0 C93EC93B ;?>?..K??..?(s*??...???..H?...e@ 000000 006E0065 0070004F 00000000 00000000 00000000 00006763 00000000 00004824 $H......cg..............O.p.e.n. 000020 002E0049 00460045 00240053 00590053 00200034 00360049 00200053 004D0056 V.M.S. .I.6.4. .S.Y.S.$.E.F.I... 000040 00000000 00000000 00000000 00000000 00000000 00000000 00000053 00590053 S.Y.S........................... 000060 40650004 00AA4783 11DBCDE8 17180ECF 04010004 00AA448B 11D7DE65 0000000B ....e??..D?.....?...???..G?...e@ 000080 006E0065 0070004F 00000000 00000000 00000000 00004823 00000000 00000000 ........#H..............O.p.e.n. 0000A0 0020006B 00730069 00440073 00790053 00200034 00360049 00200053 004D0056 V.M.S. .I.6.4. .S.y.s.D.i.s.k. . 0000C0 00000000 00000000 00000000 006F004C 00200079 0061006C 00720065 0076004F O.v.e.r.l.a.y. .L.o............. 0000E0 40650004 00AA4783 11DBCDE8 17180ED0 04010004 00AA448B 11D7DE65 0000000C ....e??..D?.....?...???..G?...e@ 000100 006E0065 0070004F 00000000 00000000 00000000 00000000 00000000 00006764 dg......................O.p.e.n. 000120 0020006B 00730069 00440073 00790053 00200034 00360049 00200053 004D0056 V.M.S. .I.6.4. .S.y.s.D.i.s.k. . 000140 00000000 00000000 00000000 00690048 00200079 0061006C 00720065 0076004F O.v.e.r.l.a.y. .H.i............. 000160 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000180 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001A0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001C0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001E0 and all nulls for the rest of the block. At the end it prints out the following: Valid MBR --------- Partition 0 OS EE Start 0x00000001 Size 0x0015A01F Partition 1 OS EE Start 0x00000000 Size 0x00000000 Partition 2 OS EE Start 0x00000000 Size 0x00000000 Partition 3 OS EE Start 0x00000000 Size 0x00000000 If I dump the first 2048 bytes of blkB I get all nulls (zeros). The system still won't boot and I assume it is because EFI cannot find the filesystem. All it sees is the block device. Any thoughts? John H. Reinhardt ------------------------------ Date: 11 Mar 2007 11:41:08 -0700 From: "n.rieck@sympatico.ca" Subject: Re: Time zone/DST change question. Message-ID: <1173638468.287587.44810@v33g2000cwv.googlegroups.com> On Mar 10, 6:01 pm, "Main, Kerry" wrote: [snip...] > > Are you saying that there are problems with the posted Tru64 DST Patches > at:http://h30097.www3.hp.com/unix/erp/c00849060.html > [...snip...] > > Kerry Main > Nope. But the external contractors managing these Tru64 systems are staffed with kids who see the DIGITAL logo every time they log on. Now I'm assuming that some of these kids were aware of the fact that DEC was bought by Compaq. But I wonder how many are aware of the fact that HP bought (err, merged with) Compaq. Also, this contractor is notorious for not doing OS upgrades because it is not in spec (how to fix this? when the customer changes the spec, the contractor will negotiate more money, then the OS upgrade is installed). During the build up to Y2K, this contractor refused to do VMS upgrades so it was left up to me to upgrade systems as old as 5.1 to 5.5-2 just so we could load the Y2K patches; It doesn't make much sense having contractors when employees need to step in to save the day. Those uVAX systems are still running 5.5-2 by the way. On a related note, you'd be suprised how many times I run into "big system" people who are unaware of the fact that firmware and OS patches are available on the net. This problem isn't caused by HP, it is caused by companies who hire the wrong people into IT jobs. (I could go on further about the dominance of non-technical people into PM (Project Management) positions in IT but I'm sure I'd be preaching to the choir. :-) Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html ------------------------------ Date: Sun, 11 Mar 2007 23:04:20 -0400 From: "Main, Kerry" Subject: RE: Time zone/DST change question. Message-ID: > -----Original Message----- > From: n.rieck@sympatico.ca [mailto:n.rieck@sympatico.ca]=20 > Sent: March 11, 2007 2:41 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Time zone/DST change question. >=20 > On Mar 10, 6:01 pm, "Main, Kerry" wrote: >=20 > [snip...] >=20 > > > > Are you saying that there are problems with the posted=20 > Tru64 DST Patches > > at:http://h30097.www3.hp.com/unix/erp/c00849060.html > > > [...snip...] > > > > Kerry Main > > > Nope. But the external contractors managing these Tru64 systems are > staffed with kids who see the DIGITAL logo every time they log on. Now > I'm assuming that some of these kids were aware of the fact that DEC > was bought by Compaq. But I wonder how many are aware of the fact that > HP bought (err, merged with) Compaq. >=20 > Also, this contractor is notorious for not doing OS upgrades because > it is not in spec (how to fix this? when the customer changes the > spec, the contractor will negotiate more money, then the OS upgrade is > installed). During the build up to Y2K, this contractor refused to do > VMS upgrades so it was left up to me to upgrade systems as old as 5.1 > to 5.5-2 just so we could load the Y2K patches; It doesn't make much > sense having contractors when employees need to step in to save the > day. Those uVAX systems are still running 5.5-2 by the way. >=20 > On a related note, you'd be suprised how many times I run into "big > system" people who are unaware of the fact that firmware and OS > patches are available on the net. This problem isn't caused by HP, it > is caused by companies who hire the wrong people into IT jobs. (I > could go on further about the dominance of non-technical people into > PM (Project Management) positions in IT but I'm sure I'd be preaching > to the choir. :-) >=20 >=20 Oops .. My apologies - I missed your point - you were talking about local contractors.=20 Thought you were referring to issues with Tru64 posted patches. Regards ------------------------------ End of INFO-VAX 2007.141 ************************