'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2018-02-24 02:06:42 UTC
1. Do we know what the garbage looks like? Do we have a hexdump of the punch file containing the garbage? (that shows where the good data ends and where the bad data begins and what the bad data looks like?)
2. Does the problem happen at random steps during the sysgen? Or does is always happen after a particular step?
3. Is the Hercules punch file being re-created fresh each time? (i.e. after each step that consumes the previous step's punch output, is the previous run's punch about being deleted so that the next run of Hercules always starts with creating the o/p punch file "anew" (i.e. fresh/empty)?
4. Has CCW tracing of the punch device been enabled in the configuration file? (or in whatever automation script is being run before the guest is IPL'ed?) Can we see the hercules log outputs from both the run PRIOR to (immediately BEFORE) the one that produces the garbage AS WELL AS the run that produces the garbage?
5. How exactly is the "garbage" being detected? Is it being detected between Hercules runs? If so, how is it being detected?
6. If the garbage (bad data) is being detected by MVS, can we introduce a step between Hercules runs that hex-dumps the Hercules punch file so we can determine whether the card reader is simply reading it wrong? Maybe the bug isn't with the punch device but rather in the card reader device?
(I'm presuming the punch output of one step is fed into the card reader of the next step, yes? Does this happen within the same run of Hercules? (via devinit of the Hercules punch and reader devices) Or is the next sysgen step run in from a new Hercules instance?)
I seem to recall a bug in Hercules's handling of printer and punch output with respect to proper handling of the "noclear" (or "notrunc") option and their corresponding default "clear" and "trunc" handling. The fix I had to commit to my repository was to do a "ftruncate" after opening the output file to ask the filesystem (Windows) to reset the file to empty. I'm not seeing that fix anywhere in Hercules 3.07 nor in hercules-390/Hyperion (4.0). Maybe that's the bug that's biting you? Has anyone (Paul) bothered to try the same test(s) using my SDL Hyperion instead of the hercules-390/hyperion?
2. Does the problem happen at random steps during the sysgen? Or does is always happen after a particular step?
3. Is the Hercules punch file being re-created fresh each time? (i.e. after each step that consumes the previous step's punch output, is the previous run's punch about being deleted so that the next run of Hercules always starts with creating the o/p punch file "anew" (i.e. fresh/empty)?
4. Has CCW tracing of the punch device been enabled in the configuration file? (or in whatever automation script is being run before the guest is IPL'ed?) Can we see the hercules log outputs from both the run PRIOR to (immediately BEFORE) the one that produces the garbage AS WELL AS the run that produces the garbage?
5. How exactly is the "garbage" being detected? Is it being detected between Hercules runs? If so, how is it being detected?
6. If the garbage (bad data) is being detected by MVS, can we introduce a step between Hercules runs that hex-dumps the Hercules punch file so we can determine whether the card reader is simply reading it wrong? Maybe the bug isn't with the punch device but rather in the card reader device?
(I'm presuming the punch output of one step is fed into the card reader of the next step, yes? Does this happen within the same run of Hercules? (via devinit of the Hercules punch and reader devices) Or is the next sysgen step run in from a new Hercules instance?)
I seem to recall a bug in Hercules's handling of printer and punch output with respect to proper handling of the "noclear" (or "notrunc") option and their corresponding default "clear" and "trunc" handling. The fix I had to commit to my repository was to do a "ftruncate" after opening the output file to ask the filesystem (Windows) to reset the file to empty. I'm not seeing that fix anywhere in Hercules 3.07 nor in hercules-390/Hyperion (4.0). Maybe that's the bug that's biting you? Has anyone (Paul) bothered to try the same test(s) using my SDL Hyperion instead of the hercules-390/hyperion?
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com