 |
Description  |
|
|
TECHNICAL FIELD
This invention relates to a method of editing text formed by lines of
characters received by a processor from a remote source. More
particularly, it relates to a method for minimizing communication between
a processor and a remote source from which a text is obtained for editing
at the processor.
BACKGROUND
In the prior art, it has been recognized that the bandwidth of serial
channels is substantially less than that of information sources and sinks.
It has further been recognized that communicating only the changes to
files or text strings of characters would require far less bandwidth than
returning an amended text over the same communication links.
A file, which is no more than a formatted character string when in storage,
appears as a two-dimensional series of lines of characters. Such a
multiple line body may have lines or characters added, deleted, or
modified.
It should be recalled that characters are internally represented within
both a text processor and a source as coded numbers. It is only for output
indication, such as display or printing, that the alphabetic
representation itself must be made. Typically, coded number standards such
as ASCII and EBCDIC have long been used in the art.
It is also observed that if one sums the coded numbers for each line
respectively, the likelihood of any two sums being the same is very small.
However, a checking number formed from the mere summation or
multiplication of its coded number constituents is commutative. That is,
the same checking number will arise even though the permutative order
varies. Thus, "the rde ball bounces" has the same value as "the red ball
bounces". By recursively combining and ringshifting the coded numbers in a
line n a predetermined order (say left to right), a different order of
characters will yield a different checking number.
Bakula et al, U.S. Pat. No. 4,204,206, "Video Display System", issued May
20, 1980, describes a host and remote text processor where the text in
different areas of the display screen at the text processor may be
scrolled and edited independently. Data from the display is transmitted
one line at a time during the scrolling to the host.
THE INVENTION
It is accordingly an object of this invention to devise a method of editing
text formed by lines of characters received by a processor from a remote
source whereby communication between the remote source and the processor
is minimized, the processor being of the type capable of receiving,
modifying, and transmitting text.
The foregoing object is satisfied by the method steps at the text processor
of (a) generating a respective checking number corresponding to each line
of characters received from the source; (b) modifying the received text to
form a body of lines by selective addition, modification, or deletion of
lines and characters; (c) generating a checking number for each line of
modified text in the manner of step (a); and (d) associatively comparing
the checking numbers of consecutive counterpart lines of the modified text
with those of the received text and transmitting back to the remote source
the entire text of only those lines which have been modified as denoted by
said lines having checking numbers mismatching those of the received text.
Yet another observation is that changes either in terms of additions,
deletions, or modifications to lines or characters are reflected in
changes to the checking numbers as evidenced by a comparison match of the
checking numbers of the lines of the modified text with those of the text
as received from the remote source. Where consecutive lines of text match,
then a mere coded indication of that fact can be remitted to the source.
Several problems arise, however. Some lines may be deleted and other new
lines inserted. While a linear comparison of checking numbers between the
received and modified text will isolate the first point of difference, an
associative compare is required to identify other runs of consecutive
lines whose checking numbers comparison match the received text.
The step of associatively comparing includes (d1) comparing the checking
numbers of consecutive counterpart lines of the modified and received
texts and continuing said comparison linearly until the first mismatch is
detected on say the ith line, where i lies in the integer range
(0.ltoreq.i.ltoreq.m,n); and (d2) comparing the jth consecutive line
checking number of the modified text to the (j-1) consecutive line
checking numbers of the received text, and, comparing the jth consecutive
line checking number of the received text with the j consecutive line
checking numbers of the modified text. These steps, (d1) and (d2), are
repeated until the lines of the received and modified text become
exhausted. Lastly, coded indications of each run of two or more
consecutive lines in the modified text whose checking numbers match the
checking numbers in the received text are returned from the text processor
to the host. Otherwise, the text lines are themselves transmitted back to
the host.
As used in this specification, the terms "checking number" and "hash number
or total" are used as synonyms.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram illustrating a host processor in communication
with an intelligent computer terminal.
FIG. 2 is a diagram illustrating a typical file.
FIG. 3 is a diagram illustrating the format for communication of a file
from the host processor to the intelligent terminal.
FIG. 4 is a diagram illustrating the format of a clear text file on a
diskette at the terminal.
FIG. 5 is a diagram illustrating the format of a hash file on a diskette at
the terminal.
FIG. 6 is a diagram illustrating the format for communication of an updated
file from the intelligent terminal to the host processor.
FIG. 7 is a diagram illustrating a typical updated file.
FIG. 8 is a diagram of the hash file (32) stored in the diskette (36) of
the terminal.
FIG. 9 is a generalized description in flow-chart fashion of the basic
method of my invention.
DESCRIPTION OF THE PREFERRED EMBODIMENT
Referring to FIG. 1, a host central processing unit or processor 20 is in
communication with an intelligent terminal, such as the IBM Personal
Computer 30 with keyboard/display 35, main storage 34 and diskette storage
device 36. Host processor 20 includes main storage 24 and a non-volatile
storage device, such as direct access storage device (DASD) 26 in which a
base text file 40 (FIG. 2) may be stored. A communication link, including
communication adapter 28 at the host and communication adapter 38 at the
terminal, interconnects processor 20 and computer 30.
Referring also to FIG. 2 and FIG. 8, in distributed data systems, data
transfer between a terminal 30 and a host 20 is often limited by slow
teleprocessing links 28, 38, and the capacity of storage devices 34 and 36
at terminal 30 is generally significantly smaller than the capacity of
storage devices 24, 26 at host 20. This invention significantly improves
such communications by transmitting only changed lines in an updated file
from terminal 30 to host 20. As will be further described hereafter, when
editing a text file, the entire file, together with a hash value
calculated with respect to the entire file, is communicated from host 20
to terminal 30, there to be stored on diskette 36 at 33. A non-editable
hash file is then created at the terminal containing a host-computed hash
value 321 for the entire file and a terminal-generated hash value for each
line of the file 322; this file is stored at terminal 30 on diskette 36 at
32. After the terminal user at keyboard/display 35, or some other
application program, has edited the original text file 33, hash values are
calculated for each line of the edited file, and compared line by line
with hash file 32 to identify the lines which have changed (new or
modified). Only changed lines are returned to host 20, along with control
information specifying the location in the original file, stored on DASD
26 and brought into main storage 24 for updating, of lines to be deleted
or retained. To ensure integrity of this process, the original file at
host 20 is only updated after the hash value for the original entire file
has been recomputed by host 20 and it matches the entire file hash total
previously stored at terminal 30, thus ensuring that the original file at
host 20 has not been changed since the terminal hash file 32 was
generated. After the file at host 20 is updated, the terminal hash file
321 is rewritten to reflect the update. The hash values for each line are
generated at terminal 30 from the updated editable terminal text file 33;
and the hash value for the new entire file is recomputed by host 20 and
sent to terminal 30 and stored at 321.
The procedures of the invention are implemented in application programs
executed at host 20 and terminal 30. The host 20 application programs are
designated as host transmit (HXMT) and host receive (HRCV) and described
hereinafter by procedure specifications, with IBM System/370 assembly code
provided for the file check sum (or hash) procedure. The terminal 30
application program, referred to as the emulator, is similarly described
by procedure specifications, with a pseudo-code description of the
associative compare procedure set forth in Tables 6-8 and Intel 8088
assembly code provided for the line check sum procedures in Tables 3-5 and
for stack operations in Tables 10-19, as will be described more fully
hereafter.
Referring now to FIG. 2, a typical file 40 at host 20 includes a plurallity
of variable or fixed or undefined length records 41, each record 41
representing one line in file 40. As shown, the data in each record 40 is
designated by a letter A, . . . , K. A copy of this file is communicated
to terminal 30 and stored on diskette 36 in text file 33 for editing.
Referring now to FIGS. 3 and 6, the method for transfer of data to be
edited from host system 20 to PC diskette 36, and return of edited data to
host 20 from PC 30, will be described. In accordance with the preferred
embodiment herein described, the PC 30 part of this action is invoked,
such as by a user at keyboard 35, by issuing an emulator command. Emulator
commands are commands which are executed by the application program (or
emulator) in PC 30.
By way of illustration, the following description is provided of the
user/emulator interface. An emulator command is entered by keying "%%" at
keyboard/display 35. The emulator responds by displaying =], thus alerting
the user that he is now commanding the emulator rather than host 28 and
confirming that the "%%" was recognized. After =] appears, the user keys
in a two-character command verb. If the verb is recognized, the emulator
responds with a space. The user then enters a command operand and return.
No part of the emulator command is sent to host 20. The emulator commands
are set forth in Table 1, together with a summary description.
TABLE 1
______________________________________
SUMMARY OF EMULATOR COMMANDS
______________________________________
%%=]RF dev:fname.ext
Receive File
%%=]TF dev:fname.ext
Transmit Complete File
%%=]RC dev:fname.ext
Receive File for Transmit Changes
%%=]TC dev:fname.ext
Transmit File Changes
%%=]RB dev:fname.ext
Receive Binary File
%%=]TB dev:fname.ext
Transmit Binary File
______________________________________
All of the emulator commands of Table 1 are used in file transfer and will
be described hereafter. In the embodiment being described, the command
operand "dev:fname.ext" names a text file 33 on diskette 36 according to
IBM Personal Computer Disk Operating System (PC DOS) file naming
conventions.
In the embodiment being described, editable files at host 20 are stored on
DASD 26 or in main storage 24 in fixed, variable, or undefined-length
records of eight-bit EBCDIC characters. On diskette 36 at PC 30, file data
32 is stored in strings of ASCII characters separated into records by
ASCII carriage return and line feed (CRLF) characters. Thus, only data
which can be translated uniquely into ASCII characters can be sent or
received from host 20. Host 20 may, in this preferred embodiment, comprise
an IBM System/370 in which most source modules do not contain TAB
characters, but fields within statements are aligned into columns by
padding with blanks. The host 20 file transmit application HXMT of this
embodiment of the invention has the ability to substitute TABs for strings
of blanks. Conversely, the data receive application HRCV at host 20 can
substitute blanks for tabs. Some host files, e.g., SCRIPT source, may
contain tab characters. In these cases, it is possible to prevent any
translation of blanks and tabs in both directions of data transfer. Many
host files contain eight-digit sequence numbers at the front of variable
length records or at the end of fixed length records. The data transmit
application (HXMT) eliminates these on request from the terminal.
Conversely, the data receive application (HRCV) can renumber records
received at host 20 from terminal 30. The protocol for processing tabs,
line sequence numbers, and other similar parameters, will be described
hereafter.
The purpose in not sending blanks and sequence numbers is to shorten the
time to transmit a file and to occupy less diskette 36 and main storage 34
space at PC 30 during stand-alone editing. A typical stand-alone editor
allows variable tab positions and treats sequence numbers, if present, the
same as other data. It does not, for example, generate new sequence
numbers for inserted lines.
In accordance with the invention, in order to update from PC 30 a file
residing at host 20, the complete file is first transmitted from host 20
according to the format set forth in FIG. 3. The file transmitted from the
host is stored at PC 30, as an editable ASCII file 33 on diskette 36 in
the format set forth in FIG. 4. Terminal 30 prepares therefrom an
uneditable hash file 32 (step 901 of FIG. 9) containing a hash total for
each line in editable file 33 and stores it on diskette 36 in the format
set forth in FIG. 5. ASCII file 33 may then be modified with a stand-alone
screen editor or some other means (step 902 of FIG. 9). The host file may
then be updated by sending from the terminal a data stream of changed
lines 90 and control information 100 according to the format of FIG. 6
(step 905 of FIG. 9), rather than the entire updated file 33. The data
stream from the terminal is generated by comparing e 33 with the file 32
of line hash totals, (step 904 of FIG. 9) as will be described hereafter
in connection with Tables 6-19. After the host file 24, 26 has been
updated, the file of line hash totals 32 is regenerated to match the
updated ASCII file 33, which now matches the host base file 24, 26. These
various file and communication message formats will be more specifically
described hereafter.
The compare done in PC 30 is an associative compare which does not use
sequence numbering of either the base or updated file 33. The data stream
sent to the host to update the base file is based on line counts, rather
than sequence numbers. To ensure the integrity of the host file and of its
update process, a file checksum 84 is computed at host 20, sent to PC 30,
and stored with the line hash totals. Whenever a user requests to update
the base file at host 20, the file checksum for the original base file is
recomputed by host 20 and compared to the total previously sent to the
terminal. Only if the two checksums match is the update allowed to proceed
at the host. This procedure also prevents an inadvertent update at host 20
of the wrong file caused by a mismatch of host and terminal file names.
Referring now to FIG. 3 in connection with FIG. 1, a description will be
given of the procedure for transmitting a file to the terminal from host
20 for update. In this embodiment of the invention, the following steps
may be followed by the user at PC (or terminal) 30 to initiate and control
this process:
1. Establish a normal terminal session with host 20 (which may be
operating, for example, under control of an IMB MVS/TSO or VM/CMS
operating systems), and enter a CLIST/EXEC:
______________________________________
XMITH dsname (TSO), or
XMITH file type (CMS)
______________________________________
Where "dsname" is a host data set for MVS, and "file type" is an existing
file on the default CMS mini-disk. This invokes the host transmit
application HXMT.
2. Determining on how the CLIST/EXEC is set up, formatting commands for
assumed tab positions and other formatting parameters may be read from the
terminal or from another file. In update mode, for the embodiment being
described, these parameters are stored on the terminal diskette 36 for use
when the host file is updated.
3. When the host 20 program HXMT signals the user at keyboard/display 35
that it is ready to send, the user enters the emulator command:
%%=9RC dev:fname.ext
where "dev:fname.ext" is the name of a terminal 30 file 33 to be created or
replaced on a diskette 36. The RC command will also cause the emulator to
create or replace a file "dev:fname.HSH" 32 which contains the file 33
contents in a compressed hash form, as will be explained hereafter in
connection with Tables 3-5.
4. When the emulator command is accepted, the host application HXMT sends
the data from the host file 24, 26, line by line, to terminal 30 according
to the format of FIG. 3. After the terminal 30 has received each line and
completed any necessary disk I/O, it sends an acknowledgement to host 20.
When the host receives the acknowledgement, it sends the next line of
data, and so on.
Thus, in host 20 to terminal 30 file transfers, the terminal initiates the
transfer by sending a command word, such as "%A", to host 20. Each data
line 50 from host 20 in response thereto includes a recognition character
")" 51, a sequence letter 52, a line of data 53, a check sum 54, and a
trailer character "(" 55. Herein, sequence letter 52 is an even modulo ten
data sequence letter selected for each data line in sequence from the set
A,C,E,G,I,A,C, . . . . Check sum 54 is a modulo ten checksum digit
generated by the host transmit application HXMT by adding the EBCDIC
characters in a line modulo 256 and taking the result modulo ten,
translating it to an EBCDIC digit. The terminal verifies the checksum 54
by translating each incoming ASCII character back to EBCDIC and performing
the same calculations. Following transmission of data lines 50, two
command lines 60 are transmitted from the host: an end-of-file command and
a file checksum/formatting command. A control line 60 includes recognition
character ")" 61, command verb 62, sequence number 63 (an even modulo ten
data sequence number selected in sequence from the set 2,4,6,8,0,2,4, . .
. ), command operand 64, checksum 65, and trailer "(" 66. In the file
checksum/formatting command word 60, the command operands, or parameters,
are the same as for the "F" command described hereafter. These parameters
64 are written (overlayed) at the beginning of the "fname.HSH" terminal
diskette 36 file 32 into an area (84, 85) reserved for them before the
line hash totals (86 . . . 89). Thus, referring to FIG. 5, a hash file 32
is identified in diskette 36 directory 70 by file name 81 and length 82,
the hash file 32 itself including file check sum 84, format parameters 85,
and a hash value 86 . . . 89 for each of n lines in file 33. And,
referring to FIG. 4, the clear text file 33 on diskette 36 is identified
in directory 70 by file name 71 and file length 72, and includes a
plurality of ASCII data lines 74, 78, . . . separated by line delimiter
fields 75 and 76, with an end-of-file (EOF) field 79 at the end.
To update a host file 24, 26 from a terminal 30 file 33, the user/terminal
performs the following procedure:
1. The user establishes a normal terminal session with host 20 (MVS/TSO or
VM/CMS) and enters a CLIST/EXEC:
______________________________________
RDH dsname (TSO), or
RDH file type (CMS)
______________________________________
where "dsname" or "file type" is an existing file previously transferred to
terminal 30 with the RC command. The RDH command invokes the host 20 file
receive application HRCV.
2. During update all format commands to HRCV are overriden by parameters
used when the file was originally transmitted from the host.
3. When HRCV indicates that it is ready to receive, the user enters at
keyboard/display 35 the emulator command:
%%=]TC dev:fname.ext
where "dev:fname.ext" is the name of a terminal file 33 on a diskette 36
which has been updated with a stand-alone editor or other means. The same
diskette 36 must also contain a "dev:fname.HSH" file 32 which reflects the
unchanged host file (dsname or file type) to be updated.
4. After the emulator command is accepted and if the files "dev:fname.ext"
and "dev:fname.HSH" are found, transmission to the host begins.
5. First the file checksum, tabs and options are sent to host 20 in a
command line 100. The file checksum must match that generated for the
current base file on the host or the TC command is abended by HRCV.
6. The terminal will send the change data from the terminal file 33, line
by line 90, to the host application. The host 20 application HRCV sends an
acknowledgement when it is ready to accept another line 90. When all
changes have been sent to the host 20 and accepted by HRCV, the
"dev:fname.HSH" file 32 is rewritten to match the current file, including
a new file checksum computed at the host 20 and sent by HRCV. The session
then returns to interactive terminal mode.
Referring to FIG. 6, each data line 90 from terminal 30 is prefixed by a
one-character header 92. The header base is an even modulo ten record
sequence number (0,2,4,6,8,0, . . .), which the host application (HRCV)
checks to ensure no missing records. If a data line 90 is preceded by a
form feed on the terminal file 33, a one is added to header sequence
number 92. This will cause a page skip to be recorded on file 24, 26 if it
contains printer control characters.
Terminal to host control, or command, lines 100 are distinguished by a
header field 102 comprising a sequence letter (A,C,E, . . . , I) in place
of the digit used for the data line record sequence number 92. The letter
used corresponds to the digit which would have been used for a data line
sequence number, so the sequence checking is maintained for control lines
interspersed with data lines. Control line 100 includes, also, command
verb character 104 (described hereinafter), operand 106, and line check
sum 108 fields. The trailer, or line check sum field 96 or 108, is a
modulo ten checksum digit. Herein, this is generated by translating each
character to EBCDIC, adding it modulo 256, and taking the result modulo
ten, translating it to an ASCII digit. HRCV does the inverse at host 20,
for verification, except that data comes in already translated to EBCDIC
by the host access method.
HRCV at host 20 acknowledges receipt of each line by sending a
two-character string "%n" where "n" is the record sequence number 92 or
character 102 (less one if the number of character was odd) of the last
record 90, 100 successfully received with a good checksum 96, 108.
Terminal 30 resends any record 90, 100 if it receives an acknowledgement
other than expected.
The various command verbs 104, together with their associated operands 106,
will next be described.
(1) F file checksum/formatting parameters
This is the first line 100 sent by terminal 30 to host 20 in update mode.
It tells host 20 application HRCV that an update mode transmission is in
process, and requests HRCV to compute a file checksum for the base file in
storage 24, 26 and to verify that the file checksum sent in operand field
106 matches it. Field 106 includes: (1) the file checksum; (2) the tab
settings; (3) a no-sequence-numbers or renumber-with-sequence-numbers
(NONUM/RENUM) switch having a value "Y" if NONUM was specified when the
file was originally sent from the host, and "N" otherwise (on file update,
"Y" forces RENUM mode); and (4) a NXTAB switch, which is "Y" if NXTAB was
specified when the file was sent from the host, "N" otherwise.
When HRCV receives this command "F" at the beginning of transmission, it
first makes a copy of the host base file 40 (FIG. 2) from DASD 26 in a
DATASAV file in DASD 26. This will be the base against which updates are
applied back to the original host file to create at host 20 its copy of
modified file 42 (FIG. 7). At the same time it computes the file checksum.
If the file checksums match, an acknowledgment of the "F" command is sent
to the terminal 30 and file transfer proceeds. If the file checksums do
not match, HRCV sends an abend command and terminates; the terminal issues
an error message at display 35 and returns to interactive mode.
The "F" command is used again at the end of transmission in conjunction
with the "S" command, described hereafter.
(2) Cnnnnn
The Cnnnnn command causes HRCV to copy "nnnnn" records from the original
host copy of base file 40 into the host copy of new file 42 being prepared
at the host. These represent lines in base file 40 which are unchanged in
the updated file 42.
(3) Dnnnnn
The Dnnnnn command causes HRCV to skip "nnnnn" records in the original base
file 40 copy at the host. These represent lines which are deleted in the
updated file 42.
(4) Data line
Any data lines received at the host are written to the output file 42 in
storage 24, 26. These represent either insertions to or replacements of
lines in base file 40.
(5) S
The S command is sent after all data and update control lines have been
sent from PC 30 to host 20. It requests HRCV to compute a new file
checksum which it returns to terminal 30 in a specially formatted
acknowledgment:
%nnnnnnnnnns
where "nnnnnnnnnn" is the new file checksum and "s" is the line sequence
number of the "S" command. Since this format does not contain a checksum
digit, the new file checksum is verified by sending a second "F" command
to host 20. If the checksums do not match, HRCV acknowledges with the
previous line sequence and the terminal resends the "S" command.
(6) E
The E command is the end-of-transmission command from terminal 30 to host
20. Host 20 application HRCV responds by closing its files and
terminating. The terminal session to interactive mode.
Referring to FIG. 7 in connection with FIG. 2, the manner in which the
above commands are used will be explained. As shown in FIG. 7, a terminal
text file 40 has been modified to form a new terminal text file 42 which
includes lines having text A, B, C, D, E, H, I, and J from original file
40, has a modified line C', and inserted lines L and M. Lines F, G, and K
have been deleted from file 40 during the preparation therefrom of
modified file 42. By this invention, the modified, inserted, and deleted
lines are identified (by a procedure to be described hereafter) and the
sequence of commands set forth in Table 20 sent to the host for updating
the host copy of the text file.
In the following description of Tables 2-19, the numbers in parentheses
generally refer to source code line numbers which perform the steps being
described.
Two hash totals are used in the file update procedure of the invention.
These are set forth in Tables 2-5. The line hash total of Table 3-5, set
forth in 8088 assembly language notation, is computed and stored at the PC
30 terminal for each ASCII line received from the host for update mode. By
the procedure of Table 2, a line hash total for the entire file is
computed at host 20. This is sent to terminal 30, and stored in field 84
of hash file 32. Each hash total algorithm has the following common
elements:
(1) The hash total starts at zero (157; 253).
(2) Before each input character is added, the previous total is ring
shifted left three bits, with bits shifted off the high-order end of the
total reentered on the low-order end (186-188; 278-386). Thus, all bits of
the hash total participate more evenly in the total, and simple
transposition of characters or lines will produce a different total.
(3) The seven or eight-bit input character is added to the low-order end of
the shifted previous total. If there is a carry (overflow), a one is added
(190-194; 387-389).
(4) The above process is repeated until end-of-line or end-of-file
(167-168; 396-397).
The hash totals have the following unique attributes:
(1) The terminal line hash total is a 32-bit (4 byte) value computed from
the 7-bit ASCII charcters in a line including the terminating LF character
(154-170).
(2) The host file hash total is a 31-bit value (the sign bit is not
included) computed from all the eight-bit EBCDIC characters,
left-to-right, of all lines, front-to-back, of the host base file. All
characters of each host line record participate, including (a) record
descriptors for variable records, (b) trailing blanks in fixed records,
and (c) sequence numbers (390).
TABLE 2
__________________________________________________________________________
HOST FILE CHECKSUM PROCEDURE
__________________________________________________________________________
250
;
251
; SYSTEM/370 CODE TO READ FILE AND
252
; COMPUTE FILE CHECKSUM
253 XC FILEHSH,FILEHSH SET CHECKSUM TO ZERO
254
SNDLOOP1
GET DATAIN,DATAINB
GENERATE LINES 255-258
255
+SNDLOOP1
LA 1,DATAIN LOAD PARAMETER REG 1
256
+ LA 0,DATAINB LOAD PARAMETER REG 0
257
+ L 15,48(0,1) LOAD GET ROUTINE ADDR
258
+ BALR
14,15 LINK TO GET ROUTINE
259 IC R3,SEQNO LAST SEQNO SENT
260 N R3,=X'0000000E'
261 A R3,=F'2'
262 C R3,=F'10'
263 BL *+6
264 SR R3,R3
265 O R3,=X'000000F0'
266 STC R3,SEQNO NEXT SEQNO TO SEND
267 STC R3,TERMOUTB+9
268 CLI CHGSW,0 CHANGES MODE?
269 BE FCKS100 NO
270 LA R1,DATAINB INPUT POINTER
271 LH R3,DCBLRECL
LENGTH OF INPUT BUFF
272 LTR R3,R3 LENGTH OF DATA TO SCAN
273 BNP FCKS100 EXIT IF ZERO
274 LA R0,1
275 L R15,FILEHSH
276 SR R10,R10
277
FCKS050 IC R10,0(R1) INPUT CHAR
278 SLA R15,1 RING SHIFT LEFT 31
BITS 3 TIMES
379 BNO *+8
380 A R15,=F'1'
381 SLA R15,1
382 BNO *+8
383 A R15,=F'1'
384 SLA R15,1
385 BNO *+8
386 A R15,=F'1'
387 AR R15,R10 ADD IN CHAR
388 BNO *+12
389 A R15,=F'1'
390 N R15,=X'7FFFFFFF'
391 AR R1,R0
392 BCT R3,FCKS050
393 ST R15,FILEHSH
394
FCKS100 EQU *
395 LA R2,DATAINB SAVE INPUT BUFFER ADDR
.
.
396 B SNDLOOP1 TO GET NEXT LINE FROM FILE
.
.
.
397
INEOF EQU * DATA IN END-OF-FILE EXIT
__________________________________________________________________________
TABLE 3
__________________________________________________________________________
TERMINAL LINE HASH PROCEDURES
__________________________________________________________________________
150
;
151
; HASH LINE FROM D1 TO EOL INTO 4-BYTE FIELD
152
; POINTED AT BY RCPTR
153
;
154
HSHLIN
LABEL NEAR
155 PUSH DI
156 MOV DI,RCPTR
157 CALL CLR4B :TABLE 4
:CLEAR 4 BYTES POINTED TO BY DI
158 POP DI
159
HSHL10:
MOV AL,[DI]
:MOVE NEXT CHAR OF INPUT TO AL
160 PUSH AX
161 PUSH DI
162 MOV DI,RCPTR
163 CALL CKS4B :TABLE 4
164 POP DI
165 POP AX
166 INC DI
167 CMP AL,LF :END OF LINE (LF = X'0A')
168 JNZ HSHL10
169 RET
170 PAGE
__________________________________________________________________________
TABLE 4
__________________________________________________________________________
CHECKSUM PROCEDURES
__________________________________________________________________________
180
;
181
; ADD ACCUMULATOR AL TO 4-BYTE FIELD AT (DI)
182
; AS A CHECKSUM.
183
;
184
CKS4B
LAB | | |
