"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 *