From:	CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 21-JAN-1989 09:14
To:	MRGATE::"ARISIA::EVERHART"
Subj:	CHECKSUM problems


Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Thu,  5 JAN 89 09:27:00 PDT
Received: from uhnix2.uh.edu ([129.7.1.15]) by KL.SRI.COM with TCP; Thu, 5 Jan 89 09:20:47 PST
Received: from uhvax1.uh.edu by uhnix2.uh.edu (5.59/1.1)
	id AA05363; Thu, 5 Jan 89 10:50:43 CST
Date: Thu, 5 Jan 89 10:51 CST
From: Mike Frederick <MIKE@BASSON>
Subject: CHECKSUM problems
To: INFO-VAX@KL.SRI.COM
X-Vms-To: uhvax1::in%"INFO-VAX@KL.SRI.COM"

Lately I have noticed more and more questions concerning the undocumented 
CHECKSUM utility.  There also have been an increase in the number of 
questions being asked about some problems with the program.  I have isolated 
two problems, and here's what I have found out:
 
======================================================================
 
1) The CHECKSUM program has a logic error as follows: if the RMS $OPEN 
operation on the input file fails, the program does not exit, but attempts to 
continue executing.  This results in an loop condition returning the error 
messages:
 
 
%CLI-E-OPENIN, error opening <filespec> as input
-RMS-E-FLK, file currently locked by another user
%CLI-E-READERR, error reading <filespec>
-RMS-F-ISI, invalid internal stream identifier (ISI) value
 
The last two lines repeat forever (or at least long enough that I gave up).
 
The following PATCH commands will fix this problem:
 
$ patch sys$system:checksum.exe
PATCH> replace/inst 6E5='BRB 70A'
NEW> 'ret'
NEW> exit
PATCH> update
PATCH> exit
 
After doing this, you will need to move the new CHECKSUM.EXE (it will be in 
your default directory) to SYS$COMMON:[SYSEXE]CHECKSUM.EXE.  This patch is 
the same for VMS versions 4.6 - 5.0-2.
 
======================================================================
 
2) There is also a problem with the code that allocates the RMS "user buffer" 
area to hold each record as it is read.  The code that calculates the amount 
of memory to allocate for the buffer is based on the following algorithm:
 
max (max ( <input file's XAB$W_LRL>, <input file's XAB$W_MRZ>), 512)
 
If the input file has a "longest record length" and "maximum record size" of 
zero, this code will fail if records are larger than 512 bytes.  The file 
SYS$SYSTEM:TERMTABLE.EXE is an example of this situation.  I have not 
developed a solution for this problem.
 
Mike Frederick
University of Houston
Houston, Texas
MIKE@UHVAX1
(713)749-2761
 

