Hi,

JAISHANKAR.G.J writes:
>     We require help in mapping these intrinsics to UNIX.
...

Well...that's a large can of worms!  Certainly some of the intrinsics
are simple to port to Unix.  Others, however, require massive amounts
of coding (e.g., DBOPEN).

If you want IMAGE on HP-UX, you need to contact HP.
I don't know if the very-briefly-available IMAGE/UX
product is still available, but I believe HP owns the rights to it now.
(Note: it isn't as full featured as TurboIMAGE/SQL.)

Or, Nick Demos ([log in to unmask]) may have something to help.
I believe his company may also have something like a V-Plus for Unix.

>     HPFOPEN

Gather up all the file system intrinsics and ask yourself: what am I trying
to accomplish?

A variety of people have written, or tried to write, FOPEN/HPFOPEN
emulators.  But, what do you do when an FOPEN says "new disk file,
with 2 userlabels, fixed record ASCII, ldev=3, CIR"?  That's four separate
non-UNIX concepts!  Some users have said "implement userlabels as a separate
file (with a name like <original file name>.ul), others have simply
made them be the first n * 256 bytes of the file.

I've found it better to say:  I'm not going to emulate the MPE file system...
it's far to powerful/sophisticated/complex/hard to emulate on a Unix
system.

Note: Turing machines not withstanding, you can generally only
emulate successfully a *less* powerful system, not a *more* powerful system!
That's why the IBM PC can emulate an Apple II, and the Power PC Macintosh
a PC, and why the Commodore Amiga could emulate a PC, 68K-based Mac, Apple II,
Commodore 64) ... but you never saw successful Mac emulators on a PC,
or Amiga emulators on a PC or Mac (at least, not in the same time frame
that the Amiga was emulating PC/Mac).

So, what I've done is evaluate *how* I use the MPE file system, and
developed several cover functions, like:

   open_printer

   open_new_disk_file     (byte stream oriented)
   open_old_disk_file     (byte stream oriented)

   turn_off_echo & turn_on_echo   (instead of emulating FCONTROL (12/13))


>     TIMER

int32 TIMER (void)

   {

   struct tms buf;

   int32
      millisecs_per_tick,
      ticks_per_millisec;

   clock_t
      ticks;


   ticks = times (&buf);

                  /* on HP-UX 8.0 (9000/834), CLK_TCK = 100 */

                                             /* HP-UX 8.0 9000/834 */
   ticks_per_millisec = CLK_TCK / 1000;      /*   0 */
   millisecs_per_tick = 1000 / CLK_TCK;      /*  10 */

   if (ticks_per_millisec > 0)
      return (ticks / ticks_per_millisec);
   else
      return (ticks * millisecs_per_tick);

   } /* end TIMER proc */


>     DATELINE


>     PUTJCW

No...you can't *truly* emulate PUTJCW *unless* you only want PUTJCW,
GETJCW, SETJCW, and FINDJCW to be the *only* routines that can see
JCWs.  In that case, simply create some kind of "session temporary" file
that contains JCW-name / value pairs.  (Of course, Unix lacks the
concept of "session temporary" file, too!)

If you want the JCWs to be treated like environmental variables (e.g.,
"export CIERROR=9", you're stuck.  Unix lacks the concept/ability for
a process to set an environmental variable ABOVE itself (i.e., in the
domain of the parent process).

>     WHO

Parts are simple, parts require making a decision
on how to map certain concepts.  (E.g., the "capability" mask parameter)

>     PRINT

Surprisingly somewhat trickier than you think, particularly if you
want to have the first parameter be a 64-bit address, as it is in MPE!

My PRINT, which has a 64-bit wide first parameter, implements only
carriage control values 0 and %320.

>     COMMAND

   system () plus returning error.

but...this intrinsic, and most others, *also* sets the condition code.
This is generally pretty easy to emulate:

    #define CCG 0
    #define CCL 1
    #define CCE 2
    #define CCU 3               /* not used on MPE/iX, but on MPE V */

    int my_cc = CCE;

    int CCODE ()
       {
       return my_cc;
       }

    void HPSETCCODE (int new_cc)
       {
       if ((new_cc >= 0) & (new_cc <= CCE))
          my_cc = new_cc;
       else
          my_cc = CCL;   /* or CCU, if you want to be Classic MPE inspired */

       }

>     STACKDUMP.

Check comp.sys.hp.hpux ... there was discussion recently (2 or 3 weeks ago?)
about how to generate a stack trace programmatically.

>     GETDSEG

<plug>

We have a data segment replacement package with the various data segment
intrinsics.

</plug>

>     PRINTOPREPLY

Wow...a lot of non-Unix concepts in that one!  Including, if you're running
on a workstation, where *is* the console?  (Hint: open /dev/console)

>     CREATE

Look at execlp() and execvp()...which combine fork/exec.

>     SENDMAIL

An ugly mechanism, even on MPE.


Good luck!

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html