HP3000-L Archives

March 2001, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Fri, 16 Mar 2001 22:07:14 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
Manny writes:
> It has been over 11 years since I last did anything with HP3000/MPE.

Welcome back.

> 1.  Is C++ language available for MPE?  Will it work with KSAM, Message
> files and record oriented flat files?

The GNU Compiler Collection (GCC) includes C and C++ compilers and is
available free for MPE/iX.  See:

   http://jazz.external.hp.com/src/gnu/gnuframe.html

Commercial support for the product is available (from us) at:

   http://www.gccsupport.com

There is no HP C++ compiler for MPE, though there is an HP C compiler.

You can use the GCC compiler to call any MPE Intrinsic, though GCC does not
yet know about the MPE "Intrinsic" mechanism, so you need some extra
definitions to make things work conveniently.

> 2.  Is it possible to get a very efficient file system for HPUX that
> supports Index sequential files and record oriented (rather than byte
> addressed) files.  Though not ideal, I can get away with using pipes in
> place of the message files.

Yes and no.  Mostly no.  All Unix file systems that I've heard of only
support files that are simple streams of bytes.  Unix people think this is
cool.  On Unix if you want any sort of Database system you have to run some
sort of add-on which is generally not integrated into the operating/file
system, so you can't use any of the standard Unix commands against your
"structured" data files and databases.

Pipes are definitely not Message Files unless you only want really simple,
non-persistent, interprocess communication.

> My emphasis on record oriented rather than byte oriented file access is
> because, I was told that the Unix file system with its byte
> address, is not very efficient for randomly accessing records from very
> large files.

Unix's "natural" storage format is variable length text records separated by
linefeed characters.  This is the kind of data that the system was designed
to process 32 years or so ago.  You can certainly (and quite easily) write
fixed length records and efficiently read and write them by SEEKing to
recnum*reclength in the file, but you won't be easily able to take advantage
of all of Unix's text file handling tools.

G.

ATOM RSS1 RSS2