hamm@waks.DECnet ("WAKS::HAMM") (11/15/86)
Mailer-note: Most of the above ("Reply-to:", "Date:", etc.) is wrong
Real-date: Fri, 14 Nov 86 19:24:27
Really-from: Greg H. Hamm <hamm@waks.rutgers.edu>
Organisation: Rutgers Molecular Biology Computing Laboratory
Postal-address: Waksman Insitute/CABM, P.O. Box 759, Piscataway, NJ 08854
Phone: (201)932-3060 [switchboard] (201)932-4864 [direct]
In <12254695042.66.OC.HANLEY@CU20B.COLUMBIA.EDU>, John Hanley writes:
> This leads naturally into a flame on
> VAX/VMS image activations. Rather than coping with exceptional cases by
> activating an installed image to do the above kludgery, then run the
> program of interest, then use a third image activation (SET) to restore
> things, it would be nice if suitably privileged users could grant WS
> parameters (DEFAULT, QUOTA, and EXTENT) to frequently used programs whose
> paging behaviour was well understood. The image activator would then
> stuff these values into the PCB and restore on image exit, at almost no
> cost of extra overhead. The benefit would be WS parameters tailored to
> particular images rather than the "one size fits all and if you page a lot
> you'll eventually get more memory" approach used now. Any V5.x implementors
> listening?
I remember a related discussion about image activation with Larry Kenah of VMS
development about two years ago at the DECUS Symposium in Amsterdam. A number
of neat things which would be "dirt easy" (Kenah) to do at activation time were
discussed. (The one I was concerned about at the time was being able to give
an image installed priority.) He wasn't making any promises, but seemed to
think some additional tailoring at activation time was a good idea.
That was late in VMS V3, so either they decided not to do it, or it has turned
out to be more difficult than originally thought.
Greg
------