Checksums to detect if members must be transferred

To improve performance, the DLA calculates a checksum for each book it generates, ignoring the IdML timestamp that is within the book. When a new discovery is performed the checksum is compared and if it is identical to the previous discovery, the book is not replaced, and FTP statements are not placed into the @FTPCHGP statement deck.

The ZOSBASE and subsystem books may contain a high volume of data and in many cases rarely change. So this checksum processing works well for these books.

The ZOSTASK book is more volatile since the address spaces may be active or inactive at the time of discovery. It is up to the CCMDB to handle what has changed, but at least this book is not as large as ZOSBASE and subsystem books.

The ZOSALL book has volatile and possible high volume content. Checksum processing is not effective for this book. The use of this book is recommended only when the book is to be consumed locally on the z/OS® and not transferred to the DLFS.