[Info-vax] VMS - what is the current thinking amongst the user community

[Sector7]

On Mar 26, 10:52 am, prag <tadams... at yahoo.com> wrote:
> On Mar 24, 4:02 pm, Jon.Po... at sector7.com wrote:
>
>
>
> > It been a long time since I posted anything - Sector7 has been working
> > away at migrating various applications - not much change there - We
> > are releasing 3.3 of the migration libraries - which provide full
> > duplex asynchronous I/O, AST's (supervisor, kernel, user etc) - and
> > has tested at doing over 50,000 lock conversion per second on some old
> > Intel equipment.
>
> > So much for the bits and bytes - Obviously, the projects we see these
> > days are no longer the 'low hanging fruit' - we are - as always -
> > focused on complex code migrations - I would be very interested in
> > understanding what the VMS users "feel about" VMS. We seem to be
> > seeing large corporations with UNIX as the focus - that have a VMS
> > server / cluster that is working perfectly - but - represents a very
> > small percentage of the organizations skill set - and yet is as
> > mission critial as any other server.
>
> > We wont be soliciting / calling or even emailing - but - If anyone
> > feel so inclined I'd especially like to hear:
>
> > (a) Is your VMS system running mainly home grown application or
> > packaged
> > (b) If homegrown - are there any specific VMS API/ Subsystems - that
> > make VMS irreplaceable (lock manager, clustering etc)
> > (c) Is there any 'software' that would make life easier - I hate to
> > use the DEC I14Y "Interoperability" - only because - I still miss
> > DECUS / New Orleans and the TGV guys paying a for several great nights
> > out.
> > (d) Is there still the religious fervor associated with VMS? (after
> > having to duplicate the AST/QIO/Lock Manager mechanisms - I have even
> > a greater appreciation of VMS internals)
> > (e) What programming languages are popular ? (no one has asked for
> > BASIC or DIBOL for 2 or 3 years)
> > (f) If VMS was going to be replaced - as VMS guys - what target would
> > you lean toward (AIX/HPUX/LINUX/Solaris x86)
>
> > I appreciate anyone taking the time to read this.
>
> > Sincerely
>
> We looked a migration for our inhouse app about a decade ago.  One
> issue was real-time support.  But, I not sure our real-time
> requirements are all that extreme.  Unix might be good enough.
>
> And, there seemed to be a lack of support for forcing global sections
> out to disk.   We checkpoint our system so it will come up in a
> consistent state.   Seemed that UNIX did not give any control over
> what was only in memory and what was pushed out to disk.  I figured I
> would have to rewrite some stuff to put checkpointed data in a file
> and close the file to get it out to disk.
>
> That's what I recall as problems for us.

You are right - and it certainly depends on the version of UNIX as to
how it handles - flushing the equivalent of "global sections" to disk.
Interesting enough - about 6 years ago - we migrated the NY City Fire
and Ambulance system - from a PDP11 (in Central) - Small PDP11's in
the 5 boroughs - the central PDP11 - ran its own real time operating
system - manipulated its own 512 byte block memory - managed to do
over 11000 page swaps/relocation per second - after huge research - we
replaced it with a VAX - wrote a special QIO driver to allow us to
relocate memory without going through "accounting" - and finally
managed - to reproduce the performance of a aging PDP11 - on a VAX VMS
system - (which was top end - but the ALPHA had been out for some time
- but unfortunately had an 8196 page size).

The real time aspect of the original PDP11 - was of course - real time
- withing the limits of the original processor and memory - when moved
to VAX VMS and the enhanced QIO for page handling - the "response"
time was well within the "specifications" of the old "real time"
requirements.

More and more the new UNIX based system are incorporating functions
that allow the kind of control that you expected on VMS - trouble is -
like out thread model for the new AST delivery mechanism - not all
UNIX's have "caught up" - so - portability - can still be an issue.