MVS TOOLS AND TRICKS OF THE TRADE September 1996 Sam Golob MVS Systems Programmer sbgolob@cbttape.org Sam Golob is a Senior Systems Programmer TIDBITS It's good to have friends. I find that I have more friends when I try to be a friend, but in any case, we try to help each other, and we exchange tidbits of system information. This month, we'll talk about a few of these tidbits. CHECKSUMS Recently, my friend Bruce Leland called me to say that he found out how the AMASPZAP (IBM Superzap) CHECKSUM numbers work. To refresh your memory (if you ever heard of these things), the IBM superzap program gives you a way of checking that you didn't make a mistake in typing your ZAP control cards. So after you type in your VER and REP statements, you can write the word CHECKSUM on the next line afterwards. The AMASPZAP run will send you an AMA132I message that the CHECKSUM was some four-byte hex number, and it's now 0. The actual ZAP will also complete. If you now want to do another run of this identical zap on another copy of the unzapped module, and you now code the CHECKSUM keyword with this exact four-byte hex number afterwards, you still get a good ZAP run. But if the four-byte number was different, the NO-GO switch will be set and the ZAP won't work. Here is a good safeguard that all the VER and REP numbers were right. How these numbers are calculated is a mystery to most of the people who ever heard of them in the first place. Bruce found out how it's done, and I think it should be a useful fact for you to know. Figure 1 shows a typical AMASPZAP job, to change one byte in load module PROGRAMA at displacement +1C0 into csect CSECTA from its original value of hex 1D to hex 2D. As the figure shows, you VERify at displacement 01C0 in CSECTA of PROGRAMA, that its original value is hex 1D. If that is true, then you REPlace the value at that location with the value of hex 2D. For the purposes of accomplishing the ZAP, it doesn't really matter if you express the displacement into CSECTA as 01C0 or 0001C0. However, for the purposes of calculating the four-byte CHECKSUM value, we'll see that it makes a huge difference. To calculate this CHECKSUM value, we string out all of the numbers, displacement and hex value, into four-byte chunks, padded at the end with zeros. Then we add all these four-byte numbers together in hexadecimal to produce a four-byte sum, ignoring the overflow. The resulting sum is the CHECKSUM value. Figure 2 shows graphically how this is done. As you can see there, if the second byte at displacement +1C0 is hex F1, and this value will not be changed by the zap, but we code the VERify and REPlace statements a bit differently to reflect this, the CHECKSUM calculation comes out completely different. Everything depends on all the exact numbers in the VER and REP statements. Now comes the 64 dollar question: Why would it be helpful for people like us to know this information? The truth is that many systems programmers have never seen a CHECKSUM statement in an AMASPZAP job during their entire careers. I still think that the fact is useful to know. One often knows how super-critical the accuracy of a superzap has to be. One "typo", and the system can easily crash because of it. How can one guarantee that all of the many VER and REP statements in a complicated, but crucial ZAP job, have been coded correctly, without a mistake? This CHECKSUM mechanism of IBM's can create that guarantee. But it's helpful for you to know how this works, because if you want to employ this technique for ensuring the accuracy of your system zaps, you have to know that zeros make a big difference, even though the actual zapping effect might be the same. When you're the systems programmer assigned to create this safeguard in your shop, it helps to know that the algorithm which creates the CHECKSUM is not some magic mumbo-jumbo, but that you can calculate it yourself to make sure it's right. Now that all of you possess this information, I'm sure that some shop somewhere will be able to have enhanced "Reliability, Availability, and Serviceability" because of it. FIXING THE OLD LINKAGE EDITOR. Sometimes it makes you mad to see how some old "design criterion" perpetuates itself to the point of silliness. Everyone knows that when you "Compile and Linkedit" or "Assemble and Linkedit" a program, the 80-byte card-image object deck cannot be blocked bigger than 3200 bytes, otherwise the Linkage Editor can't accept it as its input. This restriction existed from time immemorial, from the infant beginnings of System/360, when central storage was at a premium, and you had to fight for every byte of it. Apparently, the IBM software engineers didn't want a Linkage Editor run to consume many central storage bytes, so they restricted the size of the chunks of data input to be fed into it. 3200 bytes was to be the biggest chunk. Nowadays, this restriction goes counter to the current IBM policy. Modern machines possess relatively huge quantities of central storage, to the point where operations that were formerly performed by doing I/O to disk, are now done in central storage. IBM is touting this change in its software very obviously and loudly. So what happened with the Linkage Editor? The answer is, absolutely nothing. The linkage editor is maintained by a different group, and they didn't, for some reason, want to mess with it. Today, we will show you the kind of change which will fix the Linkage Editor, so that the object decks can be blocked as big as 32720 bytes. The change is extremely simple, and you'll have a good laugh. IBM, to be sure, has actually addressed this problem in its software. The new Binder, which replaces the old Linkage Editor in the newest MVS and OS/390 systems, has had the "3200-byte input" restriction removed. However, IBM continues to supply a copy of the old Linkage Editor with DFSMS, under the program name of HEWLKED. Even though you get the new Binder if you execute PGM=HEWL, you can still get the old Linkage Editor if you execute PGM=HEWLKED. I recently examined this DFSMS version of HEWLKED, and lo and behold, the "3200-byte input" restriction is very much alive and well. (Perhaps this month, this column should be printed on the humor page.) Look at Figure 3 for some AMASPZAP input that will get rid of this restriction, once and for all, in the DFSMS copy of the Linkage Editor. I have placed several versions of this simple modification, adjusted to various maintenance levels of the Linkage Editor, in the CBT MVS Utilities Tape, on File 257. You can order copies of this encyclopedic and very useful tape through the NaSPA office. See Figure 3 for a copy of this modification. As you see, the 3200-byte limit is actually hard-coded, and in reality it could have been adjusted to any value which is a multiple of 80. Our zap can be easily fitted to any extant version of the Linkage Editor by finding the appropriate displacements into modules HEWLFINT and HEWLFAPT. Just look for the appropriate binary values, aligned on halfwords, at approximately the displacements listed. For help in doing this, I use the free FULLSCREEN ZAP program from File 134 of the CBT MVS Tape, which has a "find" function, and which can effortlessly spot the halfwords X'0C80' which is 3200 in decimal, and the X'0028' which is 40 in decimal (the count of 80-byte records in a 3200-byte block). Again, I don't know how useful you'll find this information. What I can tell you, is that it seems that IBM is not changing the program HEWLKED at all, so these displacements to fix your DFSMS copy of the old Linkage Editor, should probably be quite stable. If you get used to using the Binder, without the blocking restriction, and then you use the Linkage Editor and get burned, you might think of trying out this fix. In any case, it is a nice illustration of "vendor old fogeyness" that all of us will enjoy. ENJOYING OLD CODE. I'd like to conclude this month's installment with the announcement of a new public tape. The CBT MVS Utilities Tape got to a point where it filled up, so some of the software had to be deleted. It's proprietor didn't want to render the deleted code "permanently unavailable" to the public, so it was decided to create a new CBT Overflow Tape, which would be distributed by the same people who distribute the regular CBT Tape. The new CBT Overflow Tape has "slots" for 472 files, just like the regular CBT Tape, and is in the same format. It didn't seem to pay to make an entire tape with just a little bit of code, so more "unavailable code" was added, and the new tape, in its Version 406V, now contains a lot of other code. The German, Swiss, English, and Australian G.U.I.D.E. tapes are there, as well as a fine ISPF collection that was going to be distributed by the SHARE organization, but which never was. This collection was to be called the "SHARE ISPF Smoke and Mirrors Tape". In addition, in Version 406V, the contents of the entire SHARE MVS MODS TAPE, all 131 files, is included. This will allow users of the old SHARE code to have a place to submit fixes. Also, that code will continue to remain available and useful to the public. In summary, I think that although much of this information is "on the lighter side" and kind of peripheral, there is still quite a bit to be learned from it. I always feel that no matter what you learn, there will eventually be a place for it to be used and useful. Good luck. See you next month. * * * * * * * * * * * * * * * * * * * * * * * Figure 1. A Sample AMASPZAP Job including the correct CHECKSUM. In load module PROGRAMA, in CSECT CSECTA, you want to go to displacement +1C0 in CSECTA. You want to verify that one byte at this location contains the value X'1D'. If that's true, then you want to change this value to X'2D'. //JOBNAME JOB your jobcard goes here 00000104 //* 00000304 //S1 EXEC PGM=AMASPZAP 00000402 //SYSPRINT DD SYSOUT=* 00000502 //SYSLIB DD DSN=YOUR.LOADLIB,DISP=SHR <== LOAD LIBRARY PDS 00000604 //SYSIN DD * 00000702 * 00001100 * A SAMPLE ZAP TO ILLUSTRATE HOW CHECKSUMS ARE USED. 00002001 * 00003000 NAME PROGRAMA CSECTA 00010004 VER 01C0 1D 00020004 REP 01C0 2D 00030004 CHECKSUM C1ED1D01 00040005 /* // * * * * * * * * * * * * * * * * * * * * * * * Figure 2. How to calculate the CHECKSUM from your VER and REP statements. You see that zeros in the expression of the module displacements, make a big difference in the CHECKSUM calculation, because everything depends on lining up all the numbers on a four-byte boundary. Let's use, for example, the numbers from Figure 1. VER 01C0 1D 00020004 REP 01C0 2D 00030004 All of these numbers are strung onto a four-byte boundary and padded with zeros as follows: 01C01D01 C02D0000 Then the numbers are all added together in hexadecimal arithmetic, to produce the CHECKSUM number. C1ED1D01 And that's all there is to it. You see that zeros make a big difference. For example, suppose the VER and REP statements were: VER 0001C0 1DF1 REP 0001C0 2DF1 which would produce the same effect in the zapped module, however the CHECKSUM would be calculated: 0001C01D F10001C0 2DF10000 And these three hex numbers would be added together, producing a CHECKSUM of: 1EF2C1DD with the overflow being ignored. (Quite simple, really.) * * * * * * * * * * * * * * * * * * * * * * * Figure 3. This is an illustration of the modifications necessary to fix the old Linkage Editor, so that the object deck input can be blocked up to 32720 bytes instead of 3200. Note that these restrictions are hard-coded. ++ USERMOD(MDZ110A) /* ALLOW LKED TO READ OBJ BLKSIZE UP TO 32720) */. ++ VER(Z038) FMID(JDZ1110) PRE(UY93979). ++ ZAP(HEWLFINT) DISTLIB(AOS04). NAME HEWLFINT * DC H'3200' VER 000AE0 0C80 * DC H'40' ( = 3200/80 = NO OF RECDS/BLK) VER 000F42 0028 * DC H'32720' REP 000AE0 7FD0 * DC H'409' ( = 32720/80 = NO OF RECDS/BLK) REP 000F42 0199 IDRDATA MDZ110A ++ USERMOD(MDZ110B) /* ALLOW LKED TO READ OBJ BLKSIZE UP TO 32720) */. ++ VER(Z038) FMID(JDZ1110). ++ ZAP(HEWLFAPT) DISTLIB(AOS04). NAME HEWLFAPT * DC H'40' ( = 3200/80 = NO OF RECDS/BLK) VER 000216 0028 * DC H'409' ( = 32720/80 = NO OF RECDS/BLK) REP 000216 0199 IDRDATA MDZ110B