"Rob Young" <[log in to unmask]> wrote in message
news:wiPxg$CpTEmv@eisner.encompasserve.org...
> In article <[log in to unmask]>, David Mathog
<[log in to unmask]> writes:
> > Alan Greig wrote:
> >
>
> >
> > So, unfortunately, rather than HP MANMAN users moving to VMS MANMAN, it
> > seems a lot
> > more likely that MANMAN will be ported to Solaris, AIX, or even Linux.
> > That's what I
> > would do if MANMAN was my product.
> >
>
> Yep.  But...
>
> No more than you port DSM to Solaris or AIX.  You don't.  You
> create a new Mumps that's kinda sorta like DSM but lacks the
> goodness DSM customers come to expect.... and call it ISM.  It
> doesn't support "true" clustering, etc. but who needs that!?!!!
> Why you just stick in a failover box... yeah ... that's the ticket!
>
> So.. maybe Alan can comment.  Does MANMAN take advantage of
> VMS in a big way?  i.e. uses its DLM, After Image Journalling, etc.?
>

From what i've seen of the source code, most of it is written to use MANMAN
specific library calls for most functions. MANMAN consists of several
hundred
commands (which are a mixture of standalone executables and commands
compiled into the MANMAN command dispatcher). With a few exceptions,
commands
use only MANMAN library calls. OS-specific calls are pretty rare, apart from
the use
of callable SORT. The source language is FORTRAN.

Two problems are:
    - It uses DBMS for all its data applications. Every single command uses
DBMS READY,
FETCH, MODIFY, COMMIT, etc. Changing this to use another database would be
quite a task.
A good programmer might be able to munge READY, FETCH, &c. functions that
could replicate
_most_ of the features of DBMS; more complex statements would require extra
code to do the
things that couldn't be emulated (Don't know much about DBMS, so I can't
really cite an example).
This could speed up any porting effort, but would be unlikely to speed up
the database access ;)

    - Some commands use DECforms. Again, proprietary. No doubt there are
other portable forms
packages that could be used.

AIJ and suchlike is taken care of by DBMS. Lot of logical names - you could
use environment
variables for that.

Hmmm. Our licence allows us to modify the source code. I suppose it
therefore allows us to
port it to a different architecture. Might have a problem getting licenses
from CA for it once
it was ported ;-)

I have been told that the MPE variety is radically different in certain
ways, such as its security
setup, and its operation is quite different. Don't have any experience of
the MPE version.
Anyone care to comment on the portability of the MPE version?

> If so... no easy port at all.
Not easy. Possible, but it would take a team of programmers months.
Biggest problem is what to do about DBMS.

>
> MANMAN may be taking advantage of the strengths of MPE and VMS. . .
> i.e. their native filesystems.  The Unix answer of course is
> "we don't need no stinking filesystem features... why we have
> all the tools you need to build what you need..."  And so the
> mindset of least common denominator coding comes into play (unless
> of course you port it to Oracle as a backend and skip/substitute
> native filesystem features.  Get out your paychecks!)

I think the MPE version uses MPE's own built-in database engine, whose name
escapes me.
Same portability problem as the VMS version have with DBMS...

Crossposted to comp.sys.hp.mpe (apologies to the non-MANMAN users).

-Malcolm MacArthur
(MANMAN systems administrator)

>
> Gotta love clashing paradigms!  Doesn't get any better than
> that!
>
> Rob
>
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *