CHECKSUM edit macro

Macro name.  CHECKSUM Edit macro CHECKSUM
users. MVS == Systems Programmers, and Software Installation/Maintenance Author: David McRitchie
type. Edit Macro resides in SYS1.TSOCLIST for use with TSO
Edit Macro resides in d:\spfmacro  for use with SPF/PC
CHECKSUM Checks CHECKSUM with ZAP cards BEFORE actual use.
Related No related macros

Location ---

Verifying SPZAP cards containing CHECKSUM before use

CHECKSUM is a verification total to insure that a ZAPS have been properly transcribed.  The CHECKSUM macro allows checking of the content (VERIFY, VER, REP) cards to the CHECKSUM before actually running it on a live system.

This article was submitted for Enterprise Systems Journal in 1990 but was never published.

Pre-check of PGM=AMASPZAP cards using a REXX exec

By F. David McRitchie

Warning: ISPZAP is one of many tools used almost exclusively by Systems Programmers, misuse can cause serious damage.  System files should always be protected against unsecured access.  There hardly exists a systems programmer who has not submitted an SPZAP job with all verifies acceptable, only to discover that the zap was incorrect after seeing a bad return code and the message


CHECKSUM provides a verification that a zap was correctly transcribed.   Since the failure of a verify card is obvious, the checksum is mainly a check of the replacement cards.   Unfortunately CHECKSUM errors in SPZAP occur after replacements have taken place.  The problem is that AMASPZAP processes it's cards, one card at a time.  There is no preliminary pass to check the integrity of the deck.   verify cards and CHECKSUM totals are not prechecked.  Replacements will stop only after an error is actually encountered.   Subsequent replacements may begin again after a new NAME   (or CCHHR)   statement.

A better way

The use of the CHECKSUM macro, described later in this article, will enable a zap to be checked relative to it's CHECKSUM statements before actually submitting a job.

Normal precautions

In using AMASPZAP the usual precautions should still be taken: taking backups before applying zaps; using a trial run without the REP and CHECKSUM cards to make sure that the VER cards are going against the correct maintenance level; and finally when submitting for actual changes to place the VER cards together before the REP statements within a NAME so that a bad VER will terminate subsequent REP statements.

CHECKSUM calculation

The CHECKSUM statement contains a calculated total of all the hexadecimal portions since the last CHECKSUM statement or the beginning of the zap.   Comments on any statement are not included.   The example below shows the method of addition down the right side.   Hex digited numbers are treated as positive.   The last number is padded on the right with zeros until it too has eight bytes.   An understanding of how CHECKSUM is created can help locate some errors by counting digits from the start.

A CHECKSUM always consists of exactly eight hex digits.

VER 100A 0001,0000,0002 00000002
REP 100A 0001,FFFF 100A0001
CHECKSUM 20130004 +FFFF0000
20130004 is truncated from 120130004

The next two VER addresses have the same addresses but have different lengths; and therefore, correctly indicate two different CHECKSUM totals.   The last example using BASE is equivalent to the previous two but also results in a different CHECKSUM total.  (Subtract BASE from VER and REP for actual addresses.)

CHECKSUM         (with blank operands to clear out)

VER 000000 1BFF07FE+ FF07FE00

VER 0000 1BFF07FE+ 07FE0000

BASE 0004 00040004
VER 0004 1BFF07FE + 1BFF07FE
CHECKSUM 1C030802 = 1C030802

Summary of REXX coding used

The REXX (REstructured eXtended eXecutor) language provides convenient functions to deal with conversions including hex conversions not available in the old clist language.

The statement Numeric digits 20 allows the exec to add eight digit hex numbers together repeatedly without concerns of overflowing.

Character manipulations

REXX also has some very powerful character handling mechanisms.   To help visualize the parsing used in the exec consider breaking CARD shown below in quotes into four components.

VER 0A20 0000,08FC a comment

PARSE is used here to split the value of CARD into four component symbols.   The variable Opcode receives the first portion, Address receives the next portion, Operand the next portion, and Comment any remaining portion(s).   Leading and trailing blanks are also removed at the same time.   If there is no third component then Operand and Comment have valid null character values.

The second use of PARSE deals with removing commas from the value in the Operand symbol.

Comparisons of fields of unequal length are treated logically by padding with blanks in the case of character fields or numerically in the case of numeric fields.  SUBSTR is extended with blanks or a padding character of choice as needed.

REXX allows the not equal operator to be expressed in several different ways.  The choice here is /=

EXPOSE permits the use of variables external to a procedure.

X2D converts hex notation to decimal, and D2X converts decimal to hex.   There are no character to decimal conversions in the coding example, but it is C2D.  Each of these builtin functions is reversible by switching the characters to give three more conversions.

The default command processor for non-REXX commands is TSO.   An Address ISREDIT instruction is used here to change the default from TSO to the ISREDIT command processor.   Statements beginning in quotes are excluded from REXX and will now be processed by the ISREDIT command.   The MACRO statement identifies this exec as an edit MACRO exec.   The variables MSGBZ and MSGB1 contain all but the actual message for a message line.

A bit on REXX syntax

Continuation is indicated by a comma at the end of a line.   A continuation comma is unnecessary before or after THEN or ELSE.

Comments must be fully enclosed within comment delimiters, and can involve multiple lines.   Commas are not used to continue comments (no comments are continued in this example).

Capitalization are not important to the REXX language itself but are required for some of the comparisons and some ISREDIT usage in TSO.

REXX code installed into an existing clist library requires a comment on the first line that includes the characters REXX.    In a SYSEXEC library the REXX comment is not needed but is a recommended practice.

REXX manuals for TSO are TSO Extensions Version "2": REXX Reference SC28-1883, and TSO/E Ver "2": REXX User's Guide SC28-1882.

SPZAP is in MVS/ESA Service Aids GC28-1844.

Invoking the Exec

The CHECKSUM exec is an edit macro and is invoked using ISPF/PDF edit with the zap being examined in edit and by entering CHECKSUM on the command line.

Noteline or msgline lines will be added by CHECKSUM giving information on whether the zap would be expected to work or to fail if submitted strictly based on the cards and not on the actual data in files.

After examining the results, redisplay all lines with a RESET X to redisplay the undisplayed lines.

AMASPZAP begins a new accumulation only at initiation and after CHECKSUM statements.   Missing or added CHECKSUM statements will affect results.

Important items checked.

  1. A check is made that the number of NAME entries matches the number of IDRDATA entries.   IDRDATA should be present in AMASPZAP submissions for later identification purposes.
  2. A check is made between the CHECKSUM supplied and the calculated CHECKSUM.   If they do not match a  **** DOES NOT MATCH message will be included on the calculated CHECKSUM message line.

About the Author

David McRitchie started his career in 1965 and was subject to downsizing in 1996.   Most of his career had been in technical support as a Systems Programmer.

REXX Coding for CHECKSUM macro

If you can't handle the .SPF suffix (SPF/PC version), then use the .TXT copy (TSO version).  They are both the same.


The example below introduces an extra hex digit FFFFA instead of FFFF to show an unmatched result.


==MSG> **Warning** 1 NAME lines, and 0 IDRDATA lines, consider adding IDRDATA
000002VER 100A 0001,0000,0002
000003REP 100A 0001,FFFFA
==MSG> -------- 2013A004 is the calculated CHECKSUM **** DOES NOT MATCH
000004CHECKSUM 20130004

Related information

I pulled this from Newsgroups: on Thu, 25 Jun 1998.  It relates to creating a Checksum, and may be of interest to some people who come here.
From: Jeffrey C Barnard <bsiopti@IX.NETCOM.COM>
If you have the latest hardware you can use the CKSM instruction.

     XR    R0,R0        R0 <- Initial Checksum Value
     LA    R14,buffer   R14 <- Buffer Address
     L     R15,length   R15 <- Buffer Length
     CKSM  R0,R14       Calculate Checksum ...
If you do not have the hardware look at the Info-Zip site they have a C (and Intel ASM) checksum routine. I converted the Intel ASM routine to 390 ASM without to much trouble.

The CKSM instruction should work on 9672 G4 and higher, MP2000 and P/390 boxes. There may be micro-code upgrades for the earlier 9672 boxes too. -- Regards, Jeff


You are visitor  ctr since count started May 29, 1997.

Please send your comments concerning my pages or materials to:  David using send email comments

Disclaimer and site usage:  Material at The REXX Macros Toolbox is available without warranty of any kind.  Redistribution of source, coding and documentation other than from this site is prohibited.

Copyright © 1995 - 2006, F. David McRitchie, All Rights Reserved