Xref: utzoo comp.os.vms:31327 comp.databases:7530
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!uniwa!fennel.cc.uwa.oz.au!a_dent
From: a_dent@fennel.cc.uwa.oz.au
Newsgroups: comp.os.vms,comp.databases
Subject: Re: Experiences with ACMS needed
Message-ID: <1990Oct4.201344.2372@fennel.cc.uwa.oz.au>
Date: 4 Oct 90 12:13:44 GMT
References: <34287@cup.portal.com>
Organization: University of Western Australia
Lines: 30

In article <34287@cup.portal.com>, das@cup.portal.com (Dale A Scott) writes:
> We are looking into using DEC's ACMS on our VAX.  DEC seems to
> be pushing ACMS very heavily.  I am interested in both positive
> and negative experiences.
> 
We are running commercial software written by "Mincom", of Brisbane, Queensland,
Australia.  They have used ACMS as their transaction processing platform on
VMS (they also implement on CICS, Primes etc.)

Early experiences weren't favourable (we were the first people in Australia to
find out that ACMS couldn't handle 10 users!!) but the product has matured
somewhat.  I know they export a lot to the US so you may be able to chase
up some info locally or I could get some opinions from their developers
and post (if there's a lot of interest...)

When it comes to tuning, it doesn't live well on mixed machines.  The nature of
ACMS requires you to tune a machine to suit a few, large processes.  If you hav
users of a financial modelling language (like EPS) they also enjoy some of these
benefits, to the detriment of the ACMS system.

In general, it certainly lets you support fewer users for a given amount of
memory but it pays to experiment with  "overfeeding" the server processes
lots of Working Set.

> Dale Scott

Andy Dent                     A.D. Software phone 09 249 2719
Mac & VAX programmer          94 Bermuda Dve, Ballajura
a_dent@fennel.cc.uwa.oz       Western Australia  6066
a_dent@fennel.cc.uwa.oz.AU (international)