Xref: utzoo comp.os.vms:31457 comp.databases:7579
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ub!canisius!vaughan
From: vaughan@canisius.UUCP (Tom Vaughan)
Newsgroups: comp.os.vms,comp.databases
Subject: Re: Experiences with ACMS needed
Summary: ACMS Experience
Message-ID: <2944@canisius.UUCP>
Date: 19 Oct 90 05:21:15 GMT
References: <34287@cup.portal.com> <1990Oct4.201344.2372@fennel.cc.uwa.oz.au>
Organization: Canisius College, Buffalo N.Y. 14208
Lines: 37


 Having worked with ACMS for a few months I had the following experience:

  o ACMS server configuration forces a *different* style of programming, 
    since all uses share the same code and its variables.  ie. File 
    pointers may or may not be in the same place as they were when *you*
    left a code segment, hence you have to save where you were so you
    can resume from where you left off...day during a display of multiple
    records in screen fulls.

  o We supported 70 plus users on a VAX 8530, with all having a worst
    case response time of 5 seconds.

  o Integrates well with RMS journaling and TDMS screen management

  o makes a mess out of system accounting since users never *logout*,
    ACMS takes over the user terminal and terminates the process they
    created when they logged in...hence no acconting records.

  o ACMS can be tempermental make no mistake, but when working correctly
    alot of work  can be done by many users on a small platform.

  o Performance was maintained by the unusual process priority setup
    devised by DEC to meet _promised_ performance.  Servers ran at
    a base priority of 6, while all others ran at the customary 4.
    this scheme kept the programmers and the WPS (yuch) users at bay.

  o memory wise it was very economical, without WPS 32 mb would have been
    fine.


personal Opinion:

  ACMS has its place in the market.  It takes getting used to, and surely
  requires an active imagination to do unusual things.

  I would still rather be doomed to working in Datatrieve.