Bob Polmanter wrote:
I looked at the code in CCKDDU64 and just prior to every branch
to the user abend 99 code, there is a #MSG message macro that will
print a single line explaining why the program is abending. This
message should be written to the SYSPRINT DD dataset.
Unfortunately, whomever decided to write this code
That would be the late great Greg Smith. One of the original Hercules developers from long ago. A truly brilliant man. I really miss him. :(
chose to use PUT-Locate for the writes to SYSPRINT.
I have no idea what that means. :(
This is a problem in the abend case because the line won't be
written until either (a) another PUT is issued (which there is
not), or (B), a CLOSE macro is issued against the SYSPRINT DCB
before the ABEND macro.
Would it be possible to issue a "dummy" PUT after each message (#MSG?) that didn't actually print anything? (Or perhaps one that only printed, say, a single blank character?)
If the program did not force an abend, then the message would
be written properly. This message could provide a clue on why
it is failing for a 3390-54.
The easiest solution is to add a CLOSE (prdcb) statement just
prior to the ABEND 99,DUMP macro, so it would go from this:
abend ABEND 99,DUMP
to this:
abend EQU *
CLOSE (prdcb)
ABEND 99,DUMP
The CLOSE macro will alter registers 14-1 before the dump is taken,
which isn't ideal in most cases, but right now the priority is to
get the error message text.
Couldn't registers 14-1 simply be saved beforehand and restored afterwards?
abend EQU * (something went very wrong somewhere!)
STM 14,1,saveregs (save registers before CLOSE)
CLOSE (prdcb) (close SYSPRINT to see our ABEND message)
LM 14,1,saveregs (restore registers after CLOSE)
ABEND 99,DUMP (ABEND with DUMP)
saveregs DC 4F'0' (registers 14-1 save area)
After that, one could examine the older U0099 dump without the CLOSE.
Eh? Wouldn't simply trying CCKDDU64 again (with the above modified code) produce a valid dump that could be examined? (AND also provide a good SYSPRINT output with the needed #MSG explaining why the abend was occurring too?) What am I missing?
Alternately, the message buffer should be in the dumps you already
have. But finding it means following a trail of control blocks and
it won't be easy.
Why can't we just make the proposed "fix" to CCKDDU64 as suggested and re-assemble and re-link it and use THAT new version of CCKDDU64 instead of the old broken one? Yes, it obviously won't magically fix whatever is ultimately causing the abend with 3390-54's, but at least we'll be able to see our abend message! Again, what am I missing here?
Longer term, the PUT-Locate method and logic for handling SYSPRINT
should probably changed to use PUT-Move (MACRF=PM) and this lack-of-
message-on-abend issue will go away.
Well then let's do THAT then! Yes?!
I'm not a z/OS programmer. I programmed on DOS/VS(E) and VM/SP. I never wrote a single program on z/OS in my life. So someone else (Brian himself maybe?) is going to need to make and test these proposed changes (fixes) to CCKDDU64 for us. Once they're made and we can see why it's failing, we would then need to basically repeat the same procedure: update the CCKDDU64 source code with the modified (fixed) code, rebuild and retest, until it eventually works correctly.
Then we can commit the newly updated/fixed CCKDDU64 program to Hercules so others won't be having the same problem that Brian is having.
Come on guys! Help me with this! Please?
Even better, just use a WTO macro to display it on the console and
job log.
Then let's do THAT instead! Sheesh! Let's FIX this thing! (Please?)
When I last used CCKDDUMP in approximately 2014, I used it against
a 3390-54 volume, but that volume was not full and the resulting cckd
dasd image was a little over 3 GB in size. CCKDDU64 did not exist
at the time. However, in order to get CCKDDUMP to work at all, I
had to modify the SYSUT2 DCB in the code to add a DCBE macro, and the
DCBE needed to specify BLOCKTOKENSIZE=LARGE. However, I see now
that in the current version of CCKDDUMP and CCKDDU64, this DCBE
parameter is now coded in the source.
Well that's good to know! :)
So.... Who is going to volunteer to make these changes to CCKDDU64 and test them?
Brian? Are you up to the challenge?
I certainly can't make or test them! I know *nothing* about software development on z/OS!
Help!
(Please?)
p.s. THANK YOU for looking into this issue for us, Bob!! MUCH appreciated!!
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
