"GIANT" AnalytiCalc

AnalytiCalc for the VAX has heretofore used 16 bit cell IDs internally,
which limited the number of distinct cells to 32000 or less to ensure
that integer * 2 arithmetic was correct.

While this makes sense on PDP11 or micros, it is not so sensible on VAX,
where large address spaces are available. The address space has been able
to extend to 32000 by 32000 on VAX before, but this was simply a mapping
which did not extend the actual available storage beyond 16 bits; rather,
there were simply a VERY large number of cells one could not independently
fill (i.e., just like the expensive PC spreadsheets.)

The version of AnalytiCalc here has had all integer*2 internal limitations
removed, except that row number and column number of real cells must
each fit in 16 bits. By default it builds a spreadsheet with physical
dimensions of 300 columns and 1000 rows (vs the 80 columns and 400 rows
of the older versions), and this storage can be increased basically as
much as desired. The addressing hacks of the older AnalytiCalc are
all still permitted, so the address limits of 32000 by 32000 (due to
the need to fit row and column in 16 bits) are still valid. However,
applications that need a LOT of free space in distinct cells can now
get it. AnalytiCalc must be compiled over, after modifying BVKLUGPR5.FOR,
to change maximum dimensions. For most applications, you will find that
300,000 distinct cells (and zillions of cells in the address space)
is more than adequate.

Note that AnalytiCalc uses an internal array to hold actual data, and this
array can be enlarged also if more space is needed but the number of
cells is adequate. Parameters in BVKLUGPR5.FOR control this size also.

The object library PCCBIG.OLB and executable PCCBIG.EXE were produced
on VMS 5.3 with no Datatrieve support, and with no support for calling
arbitrary Fortran callable applications. To rebuild AnalytiCalc-GIANT
with Datatrieve support, do the following:

$ LIBR/REPL PCCBIG DTRIF.OBJ_DTR
$ LIBR/EXTR=*/OUT=PCCBIG PCCBIG
$ LINK/NOMAP PCCBIG+DTR.OPT/OPT

(This of course assumes you have DTR32 installed.)

To link with the callable subroutines, you need to locate SSP.OLB
elsewhere on the distribution and do the following:

$ LIBR/REPL PCCBIG SCIFCT.OBJ_LIB
$ LIBR/EXTR=*/OUT=PCCBIG PCCBIG
$ LINK/NOMAP PCCBIG+SSP/LIB

This allows the functions in SCIFCT.LIBS_PRESENT to be called. Edit and
recompile SCIFCT.LIBS_PRESENT to call other functions; comments inside
that file are intended to document what is needed. Basically you have
to edit some arrays to indicate numbers of arguments, type (real*8 or
integer*4 currently), and where output arguments are, and you have to
add function name and a call to the function. Use supplied examples as
guides.

The dimensions provided should not be increased indiscriminately. There
is a bitmap sized (#rows X # cols)/8 and a byte array sized 
(# rows X # cols), in addition to the actual formula and value storage
arrays, and increasing the maximum dimensions can VERY easily result in
insufficient virtual address space to hold the spreadsheet if you get
carried away. Remember: a spreadsheet is an INTERPRETER, and if your
problem is REALLY big enough to overflow the spreadsheet (or even
come close to filling it), you should be thinking HARD about using a
compiled program to do what you need. Neither AnalytiCalc nor any other
spreadsheet should be used to run a Fortune 1000 company! (You wouldn't
think of doing it in interpreted BASIC, now, would you??)

	Since the PCCBIG.* files require VIRTUALPAGECNT and PGFLQUOTA
bigger than the defaults, the PCCMED.OLB and .EXE are supplied in which
the sheet is somewhat smaller, but will run without having to have
extra-large address space.

	Running AnalytiCalc:

AnalytiCalc requires NO privileges and can be run from anywhere. The
command on my system to run analyticalc is @dk:spread
with PCCBIG.EXE in sys$system (which on my system is a searchlist with
local stuff second). I also have PCCX.EXE there, and DK: is assigned
(either system or at login) to a directory containing what is found
in the [.DK] subdirectory here. It is of course permissible to run
AnalytiCalc from anywhere, and an ASSIGN/USER to dk: can be done
prior to activating the image. AnalytiCalc will set your terminal
for no line edit during its run and restore things when it exits,
so those features of SPREAD.COM are not really needed any more. Operation
should be OK on VT52, H19, VT100, VT200, and VT300 series. It understands
8 bit controls also.

	Please let me know about any problems or bugs.
	And if someone comes up with a screen module that uses SMG$
or X11 please let me have a copy. The one here uses SCRFT and while it
works OK, it needs updating.

	Thanks,
	Glenn Everhart
	25 Sleigh Ride Rd
	Glen Mills PA 19342
Everhart@Arisia.dnet.GE.com
Everhart%Arisia.decnet@crd.ge.com
office: 215 354 7610