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 cheaper than the 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). The commercialized version is likely to be designed for the Rainbow (and able to run on other cruddier 8088 based machines like IBM's, though in 80 column mode only), but a not-quite-free version may appear for PDP11 or VAX someday. I doubt the thing will ever cost over about $75 however (depending on the number of tapes or disks needed to hold it and on mailing/packaging costs). If folks respond with donations to support the effort, it's unlikely the PDP11/VAX versions will ever be charged for. 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. If you want RIM available through DECUS, you'll have to write to the Library; the legal folks are afraid of it. Let your LUG leadership know and maybe some informal distribution of RIM can be arranged for VAX and PDP11 (IAS, but should be not too hard to move to RSX11M).