PortaCalc
This file is VAX build notes:
For VAX PortaCalc use the @compilvmx procedure in this
account. For RSX, use the [312,371] account and edit
pccpdpnew.com to make a suitable compile file. Then make
needed libraries and build with PCCNAT.CMD and PCCNAT.ODL.
Inspect PCCNAT.ODL to see what object files to make libraries
out of.
For PRO 350, use PCCPRO.COM or a mod to compile, then build with
PCCNAT.* again as in RSX (do it on the PRO). The PCCMAKI.COM
file in [312,371] is to build the VAX variant of that form of
PortaCalc.
	This version may need your VIRTUALPAGECNT sysgen parameter
to be increased (perhaps to 20000) to link. Do so if you need
to.
	ALWAYS BUILD FROM SOURCE IF POSSIBLE.
	For those with Fortran, the COMPILVMX.COM file builds
these files from source. You can edit the HVKLUGPR5.FTN file
first (compilvmx.com copies it to vklugprm.ftn for inclusion in the
compiles) to set your max sheet sizes if the ones supplied are too
small. The maxima possible then are large enough you are very
unlikely to need to go into sources to edit them.
Look over the READMEs before doing your build please!!!!!!!!!
	The file PortaCalc.rno can become a VAX help library
and be integrated with your system help if desired. The graphics
utility is described separately in PCG.DOC and there is a file
called KEYPAD.DOC in the distribution which describes various files
of PortaCalc commands which implement auxiliary keypad functions.
It should be edited to reflect any system default changes if
these features are to be generally used. Note that if CMDMUN.FOR
is compiled with the /debug qualifier, these files reside on device
DK:, which may be ASSIGN/USER'd to a particular system area prior
to running the local PortaCalc version.
	The PortaCalc.rno file must be passed through Runoff (possibly
DECUS runoff as opposed to DSR) to convert it to a VAX help file
format. It is designed to fit on 2 columns (using the LISTRS program
to reformat it, available in various places in the DECUS library
including 11-SP-6), but can fit on other sizes output with a little
editing. Column size of less than 60 characters may fail in some
places.
	I now have an 8088 version of this program. It sells
for $49.95/copy on IBM PC DSDD disks, and needs 256K RAM.
There's a  $5 s/h charge also, and NJ residents must add
6% sales tax. Order by writing Glenn Everhart, 409 High St.
Mt. Holly NJ 08060 and ask for General Engineering ANALYTICALC-88
giving your name, address, and enclosing payment. I can't handle
credit cards.
I'm considering an interface
to the public domain RIM DBMS instead, since that DBMS is pretty
good and available from Boeing for a copy fee. However, the
difficulty of providing a general purpose DBMS interface is
considerable where values need to be returned. Therefore, a usable
general purpose database interface may wait on a commercialized version
which will integrate various other tools as well (including hopefully
editing, more complex graphics, and timekeeping).
		Glenn Everhart
		6/14/1983
Additional note: 8/18/83
	This version of PortaCalc has 2 VAX versions of interest. The
older one uses a random access workfile to hold formulas, and may be
used where the workfile provides insurance against crashes or other
faults. Since this is a burden on some sites with tight disk quotas,
a second version, here called PortaCalc-VM, is provided for VAX only.
It is built by running the COMPILVMX.COM procedure (possibly after edits
to HVKLUGPRM.FTN) and it uses a memory array to hold formulas. The
WRKFIL.F4 source of the routine that handles this array is pretty
crude and could easily be adapted to keep better track of which
array elements are in use, but it works reliably. In this version,
the S command allows resetting title and default format specification,
but does not modify the data. The ZA command clears data out of the
array (virtually; actually, it only zeroes the bitmap), and the
X and XD commands are identical. The VM version of PortaCalc does
not ask any questions about workfile names (since there are none).
	Since VMS will treat the big array as demand-zero pages,
it normally will hit only those you use, so a large sheet is
not a major liability. If it won't link on your system, you may need
to increase the VIRTUALPAGCNT (I think) parameter; the default
of 8192 is too small for some versions. Boost to 20,000 or so
while doing your links. We leave ours at 60,000.
	The PDP11 versions of PortaCalc still use workfiles, since
they need the storage and haven't room for it in memory. The XL
version of PortaCalc-11, which has virtual arrays available, could
conceivably be modified to use this approach, but it is costly in
memory and seems of questionable usefulness on any but the very
largest PDP11 configurations. If you need it, it only takes about
an hour to do the mods, maybe less with my model. The one complication
with virtual arrays is that their names must be in subroutine call
sequences; hence the WRKFIL subroutine cannot hide the array
representation in a modified PortaCalc-XL as it does in the-VM
version on VAX. I do not propose to make this mod for PDP11; the
workfile approach is usable there, and the FX: driver allows the
workfile to reside on a memory disk with NO program mods if this
approach is needed.
	PDP11 users will find a trial PortaCalc that uses VERY
much smaller workfiles in the [312,371] area on RSX SIG tapes.
No total build file exists for RSX at my site (though a file to
build in compat mode on VMS is supplied, with working ODL), but
it should be pretty clear what to do from the compat mode file
that IS supplied. The current version supports a 16,000 cell
array on PDP11 with NO special bells & whistles like I/D space
or virtual arrays. If you can use virtual arrays or I/D space
you should be able to reduce the complexity of the overlay structure
and substantially speed the program up.
	I will not be offering a commercial PortaCalc on VAX, but
am asking for small donations (see README.NOT) to support the
effort of maintenance. However, it appears that the RIM database
manager is submittable to DECUS (with a US use only restriction),
so once that is done, a RIM interface to PortaCalc is more
likely. In the interim, the ability to spawn DCL commands from
PortaCalc will serve.