Tracy writes Tracy writes:
> > Yeah ... but do they have to be? I mean even a CM KSAM file is still
> > just a file, right? Why *couldn't* an CM KSAM file be accessed by NM
> > intrinsics?
>
> Just making sure you didn't miss the original intent, which was humor.

It's a perfectly valid question.  The "CM" in CM KSAM refers more to the
compatible file structure and API than to the code that implements it.
Only the KSAM logic itself is in CM code.  The underlying file access
obviously becomes Native Mode code at some point to get at the actual
data on disk.

The only reason CM KSAM isn't fully Native Mode is that HP decided
(optimistically) to rewrite *everything* when going form MPE/V to
MPE/iX, and so rewrote KSAM from scratch as KASM/XL.  The CM KSAM
code was left in for compatibility since NM KSAM files have a different
physical structure from CM KSAM files, and users would need to migrate
data files back and forth, and it was assumed that everyone would
switch over to NM KSAM files (I don't know why so many people still
use CM KSAM today).

They tried to do the same thing with Image, but HP IMAGE collapsed
under its own weight after it couldn't be made 100% compatible with
TurboImage.  It was a nice idea, but I think HP IMAGE (and to some degree
KSAM/XL too) suffered greatly from the "second system effect".  Also
"Compatibility Mode" worked so well that even having major parts of
the operating system running in CM was not a hindrance to the success
of the new operating system.

I think HP learned many valuable lessons from the MPE/V to MPE/XL
transition process, and this will have a dramatic impact on the way
that they handle the coming transition of HP-UX (and maybe MPE/iX
we hope someday too) from RISC to EPIC.

All of the things HP is talking about doing for Tahoe/IA-64/EPIC, like
object code compatibility, object code translation, etc., were all
pioneered by MPE/XL in the late 80's.  Most people in the industry
aren't aware that HP has *already* done all this stuff successfully
once before.

G.