	PortaCalc
This file is VAX build notes:
	To build PortaCalc from supplied object libraries, you need
just to extract all objects from a library and link:

$LIBR/EXTRACT=*/OUT=PCCAVO.OBJ PCCAVO.OLB
$LINK/NOMAP PCCAVO
 or replace PCCAVO (VT100 version with advanced video) by
PCC100 (for VT100 without advanced video) or PCGRAF (for the
graphics utility). These should run even if you don't have Fortran.
	For those with Fortran, the COMPIL.COM or COMPILVMX.COM files build
these files from source. You can edit the VVKLUGPRM.FTN file
first (compil.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.

	Apology:
	To those who have come to know and love the name ViziKluge
which used to appear as this program's alternate title:
	I have withdrawn the name ViziKluge from the title page since
it can be interpreted to mean the program is not really a useful
tool. In fact, you will find PortaCalc a spreadsheet equal or greater
in power to most any commercial product on the market, of speeds
comparable with any of them, and more easily tailored to particular
needs than most. I am also mindful of the difficulty of convincing
people to use a tool named "vizikluge", since its' command set is
not closely related to anyone else's and learning it is another
educational chore people may have. This is the reason for the
alternate keypad commands (which I may expand and which you will
see can be expanded yourself by editing cmdmun.for or perhaps
xqtcmd.for) and the alternate keypad diagram.
	I expect eventually to offer a supported and enhanced version
of this program commercially (for a price similar to those of
Z80-based sheets, however; I am opposed to super high priced
software just because it runs on VAXen or PDP11's and encourage
users to revolt against it as I have done). For the present,
however, enhancements to this version of PortaCalc are expected
at most to include spawning subprocesses and perhaps a Datatrieve
interface for the VAX versions only. 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).
	I recommend all who use this product for office automation
look into the DTC program from DECUS also (#11-597, code MC $70).
It's a highly useful desktop calendar program for doing time based
scheduling, meetings, etc.
		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.The RIM DBMS has been submitted to DECUS now,
both for PDP11 (which is said to be slow) and for VAX (which is not).
Watch for it in DECUSCOPE; it won't be available outside the US
until 1/1/86. A RIM interface is not yet done though.
