Not Your Dad's Mainframe: Little Iron 3997

misc. recent dumprx references

so the obvious thing with dumprx in advanced analysis of postmortem kernel dumps was searching for various signatures in the trace table.

one of the things that cp67 had was a "DIE" condition (svc0) where it would generate (originally) a paper dump (when it encountered a bane condition). this was enhanced to copy of the contents of storage to disk and then immediately reboot. when i was playing with loader tables as part of the pageable kernel (in cp67) ... there is a story here of local customer modification resulting in cp67 kernel "DIE" and immediate restart (footnote comparing multics which might take half a day to recover from a failure situation):

i start looking at uniquely flagging each "DIE" situation. This was released in vm370 with each DIE condition having a unique identifier ... and there was a manual which gave a brief overview of the conditions for each "DIE" operation.

so the internal dumprx ... had a softcopy of the manual and could present the brief overview text for each situation. however, the advanced dumprx analysis started automated examination of lots of stuff that normally be done manually as part of problem determination.

however, another gimick on live system ... was do some operation, turn off trace table entires (since sometimes it could wrap quite quickly), capture ("snap shot") the kernel storage location of the trace table, and then turn it back on ... and then examine the trace table entries slightly more liesurely.

lots of past postings related to dumprx, problem determination, etc