The plan was IA-64 which is why HP helped develop the chip. PA-RISC is dead... or would've been had they not have had to resurrect it because of delays on IA-64. Capellas is just another GQ Bob Palmer. Let's see if Carly Fiorina will do better than her partner in crime Rich McGinn at Lucent over time. Bill -- Bill Gates is a Persian cat and a monocle away from being a villain in a James Bond movie -- Dennis Miller bpechter@shell.monmouth.com|pechter@pechter.dyndns.org

At 09:04 AM 9/4/01 -0400, you wrote: Lots of the key architectural features in IA64 (if not most) are actually HP's intellectual property. IA64 is, in a sense, what HP was already developing as the sucessor of PA-RISC many years ago, with important, patented new features (such as multi-instruction set architecture and the related instruction set-switching mechanism, which is the main thing that Intel was after) coupled with Intel's advanced production processes. Oh, and some extras to accomodate Intel's demands (the main reason for the delays). HP needed better production technology than what they had in order for their new chip design to stick. The choices were DEC, Intel and IBM. Guess what happened. carlos. -------------------------------------------------------------- Carlos E. Murillo-Sanchez carlos_murillo(a)nospammers.ieee.org

DEC/Compaq/HP... If this goes through, it means I will have worked for three separate companies in five years time, and not had to move my office once... Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com | | Unix Support Engineering Group | (home): mbg!world.std.com | | Compaq Computer Corporation | addresses need '@' in place of '!' | | 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ | | Nashua, NH 03062 | "pdp-11 programmer - some assembler | | (603) 884 1055 | required." - mbg KB1FCA | +--------------------------------+-------------------------------------+

Paul Thompson wrote: As someone stated, it's dead. It's just taken longer than expected to die. OpenVMS is what's got me scared! Zane -- | Zane H. Healy | UNIX Systems Administrator | | healyzh(a)aracnet.com (primary) | OpenVMS Enthusiast | | | Classic Computer Collector | +----------------------------------+----------------------------+ | Empire of the Petal Throne and Traveller Role Playing, | | and Zane's Computer Museum. | | http://www.aracnet.com/~healyzh/ |

I have been hunting for new scrap yards to dig in, and found a couple new ones this week. Unfortunately the most interesting one I wasn't able to even look around in, (maybe Thur as the boss wasn't in, but they also gave me the wholesale only biz). Anyway I noticed half a dozen old full size tape drives in a big pile, makes me itch to poke around.

On Tue, 4 Sep 2001, Stan Sieler wrote: *Any* other modern OS? How about z/OS? Peace... Sridhar

Re: Yeah..pretty dumb. They've announced they're working on fixing this. IIRC, the problem is in the firmware, which assumes a 4 GB limit for the address of the boot software. I'd have assumed that would mean "hey, just put the boot image in the first 4 GB somewhere", but...:) Yep. Of course, software mirroring sucks anyway :) true. So, use HFS files! (POSIX hierarchical directory structure and file names) Huh? I use this all the time. cd /etc/foo ln -s myposix_named_file /SYS/PUB/MINE or :newlink mine.pub.sys, /etc/foo/myposix_named_file, mine.pub.sys QEDIT...it's been the editor of choice on the HP 3000 for 20+ years. (Also runs on HP-UX) (There's QEDIT for Windows, which works with the HP 3000 / HP 9000, but I haven't warmed up to it yet.) (The reason I like QEDIT is that I can mix line-mode style editing with visual editing, something few other editors can do well.) That's like saying "if you use a stupid utility to edit something that has a particular format (unknown to the utility), you'll have problems". vi is stupid...it doesn't understand record structures. It's an editor of bytestream ASCII files ... a barely adequate one at that. Rule 1: get QEDIT, and use it for MPE files. Rule 2: get QEDIT, and use it for HFS files. Rule 3: see rules 1 and 2 :) Don't know FDL. FCOPY is similar to an enhanced "dd" in Unix, it's a record-oriented file data manipulator. COPY is similar to "cp" in Unix, it's a file oriented copier. Not an OS feature, but a *product* feature. Yes, MPE's patching process could be better. OTOH, there are some positive aspects... It's trivially easy for the system manager to apply a one-word patch to running code on MPE/iX, should that be necessary. (Even if the code is in a critical part of the kernel.) (No, it doesn't happen often.) Not really...itrc.hp.com has them. You can grab "patchman" from HP's web site (it ought to be distributed with the OS!), and it will tell you what patches exist, and which you should install, and will download them and do some (all?) of the installtion for you. True, we've only had patchman for the last 2 years or so. Mail isn't part of the Unix *operating system*, although it's usually bundled with various Unix *products*. There are several Unix-style mailers available for MPE. I frequently use MAIL from Telamon (ftp.telamon.com), because it works well. true...but we have sendmail, too. So? BTW, if you want to trigger a reboot remotely, that ability has been available for about 15 years ... not well known, perhaps. And you want to .... why? :) Presumably, you're running licensed copies of the VMA and Windows software. HP has chosen not to allow a user to license both HP-UX and MPE for the same box. If you installed the PA-RISC version of Linux on an HP 3000 (presuming it's one of the PA-RISC hardware versions that Linux supports), you could do the same thing: bootup either OS. Now, Linux won't know about the MPE file system, and vice versa ... but there's nothing stopping anyone from writing an inferior MPE-look-alike file system for Linux (or, nothing stopping them from doing a hell of a lot of work and writing a work-alike/look-alike good MPE file system ... if they implement the Transaction Manager :). BTW, can you say "fsck". An MPE user doesn't know that that word is... a typoed version of f*ck ... which is what's said when a Unix user has to run it. I have never seen, nor heard of, file system damage caused by a reboot on MPE...not now, nor with the Classic MPE V. (Yes, some other things can sometimes damage the file system (e.g., disk drive problems), but that's pretty rare.) (My partner has spent all day trying to resurrect a client's HP-UX system that had 3 disk drives fail this weekend... after the drives were replaced, HP-UX notes that 3 volumes are missing from some volume groups, and 3 unknown problems are present ... 8 hours of fighting HP-UX and SAM later, well...they're still fighting, so there's no resolution yet.) So? That's not an *operating system* issue, that's a *product* issue! Yep. I think that's wrong, definitely not the HP Way. But, HP's 3000 group has an incredibly good relationship with the users...we talk with them daily, meet with them periodically .. a relationship that's the envy of the industry. Heck, I want that kind of relationship with the *HP-UX* people! MPE's good points: 1) it lets you get things done. This cannot be overstated... If you can think of something new to do with a computer, there will be a way to do it on MPE. Let's say I want to write a product that would let me mount a disk on a Sun system as if it were a local disk on a 3000 ... not a *file system* (e.g., NFS), but a *disk*. I could do that easily with MPE, even to the extent of handling page faults across the network. I couldn't even *begin* to do this with HP-UX. (Yes, I can (and have) written kernel-level / driver-level code for HP-UX.) Part of the reason this is possible is that I can write "user" code that runs at ring level 0 ... something not possible on HP-UX. Another part is that (with appropriate security) I have the ability to see/modify kernel code and data ... from a user process (i.e., from outside the kernel). 2) it's stable. I have some code that's run unchanged, un-recompiled, since 1979. 2.5) reliable. The Transaction Manager means that file system data structures, and IMAGE data structures are protected from corruption caused by system failures. If you want to have the same level of protection for user data in a file, you can...trivially. 3) it's scalable. Few, if any, OS's have demonstrated scalability from a single user up to thousands of users. 4) it's easier to manage. This is *NOT* open to debate. For 20+ years, I've seen site after site after site ... without a single exception ... spend far more money and far more time maintaining every other operating system than they spend for maintain their MPE systems. Yes, it's harder to find an MPE-trained person than a Unix or Linux or NT person ... but you only have to find one instead of two or three or a dozen. Plus, in their spare time they'll probably be the DBA for an IMAGE database, it's that easy. 5) addressing ... 64 bit since 1986. Even *today*, HP-UX is basically a 32-bit operating system. ...with stacks limited to tens of megabytes (roughly), and no ability to access much data beyond that. Since MPE XL 1.0, MPE users have had the ability to have global/stack data of to 1 GB, and up to a thousand blocks of up to 4 GB of data directly addressable by their code. 64 bit? Been there, done that! As of release MPE/iX 6.5, we can have disk files much bigger than 4 GB... but with the same file system interface as before! (No, *we* don't have to set special flags saying "large files" when we compile our code, unlike Unix :) 6) mapped files ... done right! Essentially every disk file is accessible either via file system intrinsics and/or mapped file access. Note that "and/or"...a *BIG* departure from HP-UX. (HP-UX file system buffers and their mapped file access do not share data, so if a user updates a file via "write()", there's a good chance that mapped file accessors won't see that data ... basically not a problem on MPE). (MPE's file system uses mapped access internally, so *all* file accesses eventually go through the same mapped access.) 7) kernel APIs are extremely powerful. Want to see if a virtual address is in memory? freeze it? post it if dirty? forget it? Trivial. (True, not well documented) 8) debugging the kernel is easy, and available to any system manager that wants to learn how to do it. HP-UX just this year announced some form of kernel debugging .. it requires 11i, and it requires a second 9000 to run the user interface on. (And I don't know if it's as powerful.) 9) IMAGE is bundled in, and is powerful and easy to use. We had one client, a commercial bank in London, switching from MPE & IMAGE to HP-UX & Oracle. We warned them that they would need three times the CPU and three times the disk space to get comparable performance. After they switched over, they called us to tell us we we wrong... they needed *five* times the CPU and *five* times the disk space. Relational databases are good for some things ... MPE had one years ago (ALLBASE). But, they aren't good for what people do most: day to day business. For that, hierarchical / network databases tend to outperform relational databases. IMAGE allows datasets ("tables") up to 80+ GB. Unlike most other databases, the users have a *say* in IMAGE. We've had a large number of user-request enhancements implemented in the last 10 years. 10) easy to reverse-engineer. Got a problem you need solved, and you think some part of the OS knows how to solve it (or something similar)? It's very easy to look and see how things get done. 11) POSIX Rated as "most open" system by Gartner group. 12) superior IPC Multiple message passing mechanisms to choose from (although we still lack some of the finer control features provided by Burroughs MCP (e.g., queue.memorylimit := xxx) If you throw away most of the features of message files, you get pipes. At a lower level, ports (dumb name) provide a fascinating and powerful message passing facility. (Some similarties can be found in the Amiga OS) MPE's bad points: 1) overhead. Because we have more protection, because we have a hell of a lot more functionality, some operations take more time: file opening file closing process creation process termination 2) marketing (including: A-Class clock slowdown, and 9000/3000 licensing issues) 3) marketing (yeah, thought I'd mention it again) 4) raw sockets ... or lack thereof 5) low-level terminal control/interaction What we have works better than HP-UX's, but we don't have as much, and some HP-UX (and other Unix) software is hard to port because of this. MPE was never designed to be an operating system that gets interrupted for every damn keystroke entered by the user ... unlike UNIX which started life as a single user operating system. The result is that we have never handled terminal I/O as directly (low-level) as Unix... OTOH, that history shows why record-oriented (a line of characters + <return>) I/O and block mode (an entire screen) are so efficient on MPE, compared to HP-UX. 6) POSIX porting ... some rough spots -- Stan Sieler sieler(a)allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com

Re: understandable. BTW, HP has a company wide license to use QEDIT! One method: :debug mr pc, _reboot_cpu c Or, we can provide you with a free "REBOOT" program if you want it. HP-UX 11i, for example? Just had to run it on Friday. yep. Yep...lot of misinformation out there :) we agree. -- Stan Sieler sieler(a)allegro.com www.allegro.com/sieler/wanted/index.html www.sieler.com

Oh, you mean the technology Intel got from DEC? (thats why Compaq (who buys Intel CPU's) killed the Alpha) Cameron Kaiser wrote:

Erm. The Alpha? At one point, not only was the Alpha faster clock for clock, but if I remember correctly, those chips were running at 533 when the P2 333 was released. On top of which, all the chip designers from DEC have now been hired by either AMD or Intel (from what I have heard) Not current indeed. Zach ----- Original Message ----- From: "Richard Erlacher" &lt;edick(a)idcomm.com&gt; To: &lt;classiccmp(a)classiccmp.org&gt; Sent: Tuesday, September 04, 2001 8:40 PM Subject: Re: HP & Compaq they the They'd the

At 06:40 PM 9/4/2001 -0600, you wrote: Um, I'm sure this is a troll, but still -- DEC was a leader in Ethernet implementation; in SCSI; in RISC (Alpha). VMS was the first to have true clustering, a technology that is still largely unequaled elsewhere. DEC's FORTRAN implementation was a leader for many years, and is still excellent. How's that? G

They most certainly did not! Itanium is the marketing name for what was called Merced for many years. It's been in development since something like the early 90's. What Intel got from DEC was a FAB, and in some manner the StrongARM processor (I never have understood this one). Zane -- | Zane H. Healy | UNIX Systems Administrator | | healyzh(a)aracnet.com (primary) | OpenVMS Enthusiast | | | Classic Computer Collector | +----------------------------------+----------------------------+ | Empire of the Petal Throne and Traveller Role Playing, | | and Zane's Computer Museum. | | http://www.aracnet.com/~healyzh/ |

At 10:59 AM 9/7/01 +0100, Hans wrote: Again, Itanium is more or less what HP already had in sight as a replacement/successor to PA-RISC even before it was called Mercer/IA64/Itanium. HP had intended the architecture to feature many parallel resources (which IA64 will have), multi-instruction set with dynamic switching (which IA64 will have) and a sophisticated instruction scheduler that would have optimized the utilization of the chip resources to achieve maximum parallelism, instead of relying on the compiler to do the optimal scheduling. HP holds patents on all of these features. When the alliance with Intel came up, they dropped the last feature from the design and went back to the schedule-optimizing compiler paradigm. I am sure that Intel then pressed to include features that they deemed "convenient". In any event, Itanium is more a brainchild of HP than of Intel. carlos. -------------------------------------------------------------- Carlos E. Murillo-Sanchez carlos_murillo(a)nospammers.ieee.org