According to the description of OA19281 (a z/OS 1.8-only APAR), GRS in z/OS
1.8 is frequently overlaying 16 bytes of PSA, but only occasionally causes
noticeable problems. Hmmm.
I'm not z/OS 1.8, so I hadn't noticed the APAR. That is, until yesterday
when I tried to download service using RECEIVE ORDER. Job ended RC=8, due
to syntax error in the HOLDDATA file. I thought, "Huh?". The command ended
like this:
----------++ NULL. /* END OF ENHANCED HOLDDATA */
GIM25201E ** THE INDICATED COMMAND IS INCOMPLETE.IT MAY BE MISSING DATA OR A
DELIMITER, OR A PREVIOUS COMMAND MAY BE MISSING A PARENTHESIS.
GIM20501I RECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 08.
I poked around, and SUPERC compared file full.txt from the Enhanced
HOLDDATA FTP site ftp://service.boulder.ibm.com/s390/holddata to the
holddata file that SMP/E had downloaded in GIMZIP format in my RECEIVE
command, and discovered the problem.
The very same APAR OA19281.
The holddata file SMP/E had downloaded included the following:
++HOLD(HBB7730) FMID(HBB7730) REASON(AA19281) ERROR DATE(06355)
COMMENT(SMRTDATA(SYMP( CLASS(HIPER).
This is not valid MCS syntax.
The full.txt file from the Enhanced HOLDDATA FTP site was corrupt in a
different manner:
++HOLD(HBB7730) FMID(HBB7730) REASON(AA19281) ERROR DATE(06355)
COMMENT(SMRTDATA(SYMP(........) CHGDT(061221)))
CLASS(HIPER).
The characters "........" are actually x'00' characters in the full.txt file
- also not valid MCS syntax.
My guess (a total guess) is that the process which generates these HOLDDATA
files is being tripped up by the number of versions of APAR fixes there
apparently have been for this problem. I noticed the current APAR fix is
named GA19281. Perhaps there's never been version "G" of an APAR fix
before. Or perhaps it's the combination of dire flags. HIPER.
RESTART/BOOT/IPL. FUNCTIONLOSS. PERVASIVE. SYSPLEXDS.
As a result of this error, any IBM software packages which include z/OS
HOLDDATA (which might be all software packages these days) may RECEIVE with
RC=8 and if so, will probably not provide the customer valid or complete
HOLDDATA. I can only assume that the various processes IBM uses to generate
++HOLD MCS do NOT include a step to perform a "test" RECEIVE internally and
report an error if unsuccessful. Such a "test" RECEIVE into a dummy Global
zone might be a useful enhancement to the Enhanced HOLDDATA build process,
so that in future such errors are not published to the outside world, with
consequent software packaging problems.
Brian
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
