If you find that you must make any changes to VICAR in order for it to run on your system (especially if it is a supported machine type), please let us know so we can fix the problem.
Use the Electronic Failure Report Form to report any VICAR problems. If you prefer Email, below is a copy of the form, and a filled-out example you should use when reporting VICAR problems to the correct person from the contact list.
Electronic Failure Report ------------------------------ 1. Initiated By: 2. Phone Number: 3. E-Mail Address: 4. Reporting Date (mo/day/yr): 5. Suspected problem area (H/W, S/W, Procedural, Other): 6. Projects affected: 7. Hardware Name (if applicable): Property Number: Location (bldg-rm): 8. Software Name (if applicable) VICAR Version: Operating system (ops, cert, dev): 9. Description of Problem (Describe in as much detail as possible so problem can be corrected without delay. Attach all supporting/explanatory evidence.):
Actual Electronic Failure Report submitted by Brian Carcich ------------------------------------------------------------ GLL colleagues, I have recoded the VICAR program SARGON to remove some limitations and some potential problems. The following is an FR for that work. The upshot is that the new version should be available as CUSPIF::SARGON.COM on DECnet and as SARGON.COM via anonymous ftp on moe.tn.cornell.edu (128.84.242.72). Hopefully this corrected version will be part of the next VICAR release. If you don't want to rebuild SARGON.EXE from SARGON.COM, you may just copy SARGON.EXE (and optionally .PDF) from either of the above sources (don't forget binary for .EXE ftp). Please note that if you want to build this SARGON, you must also have my updated INSIDE.COM, which I submitted as an FR last May. INSIDE.COM is available from the same places as SARGON. See notes on installing SARGON at the end of this note. -btc Electronic Failure Report ------------------------- 1. Initiated By: Brian T. Carcich 2. Phone Number: +01(607)255-5908 3. Mail Address (U.S.postal): SEE END OF THIS FR 4. Reporting Date (mo/day/yr): 10/14/1991 5. Time of Failure: (Doy/hr/min in local time): N/A 6. Suspected problem area (H/W, S/W, Procedural, Other): S/W 7. Projects affected: GLL SSI 8. Hardware Name (if applicable): ALL Property Number: Location (bldg-rm): 9. Software Name (if applicable): SARGON Vicar Version: ALL Operating system (ops, cert, dev): ALL 10. Description of Problem (Describe in as much detail as possible so problem can be corrected without delay. Attach all supporting/explanatory Evidence.): (1) The graphics Image Memory Plane for VRDI is incorrectly hardcoded as 4. This should be obtained via XDDINFO (or whatever) so it can work with the X-Window VRDI Device Driver. (2) There is a limit of 24 vertices to a polygon, in part caused by a limited INSIDE.COM. I have previously submitted an FR for INSIDE which removes this restriction, and my updated version of SARGON ups the limit to 298 vertices. (4) The subroutine OPRATE can easily have an arithmetic overflow, and can also ABEND without cleaning up its VRDI display. (3) Once you turn debug on, (DBUG), you can't turn it off. (5) The data-type of the INSIDE SUBLIB function is incorrectly defined as LOGICAL*1 when it should be LOGICAL*4 or just LOGICAL. 11. System Encountering error: ALL 12. Real time action to restore capability: I have rewritten SARGON.COM to eliminate the above restrictions as well as updating the help file, &c. It is available via NSI/DECnet (formerly SPAN) with the command $ COPY CUSPIF::SARGON.COM *.*; It should be accessible via NSI/DECnet to LAW320, GMY059 and TCG059 accounts from MIPL1:: or MIPL3:: as well as selected HIIPS accounts. It is also available for anonymous ftp on the Internet at moe.tn.cornell.edu (128.84.242.72). Installation Note: Since you need INSIDE.COM to build this version, you may need to take additional steps in the build. Here are several possible paths you may take: (1) Just copy the already-built version of SARGON.EXE (and optionally SARGON.PDF). This version should be compatible with VRDI's from "gsmatch=lequal,1,7" forward. (2) Ignore INSIDE & assume your users will not use more than 24 ver- tices per polygon. Copy SARGON.COM and @SARGON. CAVEAT EMPTOR! (3) Ignore INSIDE improvements and physically limit SARGON to 24 vertices per polygon. To do this, edit all occurences in SARGON.COM of the line PARAMETER MNVERT = 300 to read PARAMETER MNVERT = 26 and then DO "$ @SARGON". (4) Get and build INSIDE and put it in your regular SUBLIB: $ @INSIDE SORC $ FORTRAN INSIDE $ LIBR/LOG/REPL R2LIB:SUBLIB INSIDE $ @SARGON This, however, gives a non-official VICAR R2LIB:SUBLIB.OLB. (5) Build and use SARGON.OLB: $ @SARGON SORC $ FORTRAN SARGON $ @SARGON OLB $ @INSIDE SORC $ FORTRAN INSIDE $ LIBR/LOG/REPL SARGON INSIDE $ @SARGON LINK (6) Put the INSIDE subroutine into a local object library: $ DEFINE CU_SUBLIB disk:[culib]CU_SUBLIB !* ** see below $ CREATE CU_SUBLIB CU_SUBLIB/LIB R2LIB:SUBLIB/LIB ^Z $ RENAME/LOG CU_SUBLIB .OPT $ @INSIDE SORC $ FORTRAN INSIDE $ LIBR/CREAT/LOG CU_SUBLIB INSIDE $ @SARGON * "disk:[culib]" is a location you pick for this local object library. ** If you can make this a DEFINE/SYSTEM and make it permanent (i.e. put it somewhere in the system startup files), so much the better. Brian Carcich - Galileo Project - Centre for Radiophysics & Space Research Cornell University | +01(607)255-5908 422 Space Sciences Building | carcich@cuspif.tn.cornell.edu Ithaca, NY 14853-6801 | CUSPIF::CARCICH (SPAN 6287::) FAX +01(607)255-9002 | btcx@crnlvax5.BITnet The only things I don't like about C and Eunuchs(tm) are their proponents