[H390-MVS] FW: Some questions (re: dodgy punch)

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

Oops! I posted this to the wrong group.
Am now forwarding it to the correct group.
Sorry!


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?

[[e-mail] [H390-MVS]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
Oops! I posted this to the wrong group.
Am now forwarding it to the correct group.
Sorry!
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?)

No hexdump has been supplied.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
2. Does the problem happen at random steps during the sysgen?
Or does is always happen after a particular step?

Supposedly random but line numbers weren't given so could
be clustered or scattered? Garbage was implied at the end
so not crashing Hercules with the punch still opered was
investigated. Now data is said to also be missing in the
middle but with no line numbers, that could be near the
beginning, literally in the middle, or near the end.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
3. Is the Hercules punch file being re-created fresh each time?

Yes. MVS system generation STAGE1 source is being assembled.
Output is pointed to SPOOL.
The punch file is the STAGE2 input JCL stream output from
STAGE1. It is large. Have fun trying to trace.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
(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)?

System is almost fresh but SPOOL is cold started to clear
pointers instead of data. Clearing SPOOL for each run was
requested but changing cold to format may take some time.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
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?

Neither a MVS GTF SIO trace nor Hercules I/O trace have
been done. Either would be huge files but if transferred
from linux to Windows, WORDPAD could handle.
The file could be uploaded in binary to MVS if MVS tools
are needed.

The JES2 was before it had standard exits so it was
common at the time to just update the source.
We have the MVS and JES2 source from the switch
from MVS 3.7 to MVS 3.8 but the MVS starter system
could be back-level in maintenance?

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
5. How exactly is the "garbage" being detected? Is it being
detected between Hercules runs? If so, how is it being detected?

diff was mentioned as one of the utilities finding the issue.
awk was to be used later to process the data.
My poor memory remembers seeing one display from tail?

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
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?

No card reader involved.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
(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?)

No card reader.

One step assembler with output in card format.
Output to JES2 for complication or old instructions.
Output card image file changed to ASCII on punch
by Hercules with no answer as to whether LF or
CRLF was requested.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
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 http://www.softdevlabs.com

Hyperion 4.0 was mentioned as tried but no fish
were mentioned as to yes or no.

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

Post by ***@yahoo.com [H390-MVS]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
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?

No card reader involved.

Then I'm confused. What is the purpose of the punch output? How is it being used?

Post by ***@yahoo.com [H390-MVS]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
(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?)

No card reader.
One step assembler with output in card format.
Output to JES2 for complication or old instructions.
Output card image file changed to ASCII on punch
by Hercules with no answer as to whether LF or
CRLF was requested.

Then again, I am very confused! If the assembler output is going to JES2, then of what purpose is Hercules's punch output? It sounds to me that Hercules's punch output is not even being used at all. So of what concern is the garbage? (Except as an indication of a possible Hercules bug, which in this case, sounds like it doesn't seem to impact anything? The sysgen is using JES2, not the Hercules punch output!)

Help! :(

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]

Post by ***@yahoo.com [H390-MVS]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
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?

No card reader involved.

Then I'm confused. What is the purpose of the punch output? How is it being used?

Post by ***@yahoo.com [H390-MVS]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
(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?)

No card reader.
One step assembler with output in card format.
Output to JES2 for complication or old instructions.
Output card image file changed to ASCII on punch
by Hercules with no answer as to whether LF or
CRLF was requested.

Then again, I am very confused! If the assembler output is going to
JES2, then of what purpose is Hercules's punch output? It sounds to me
that Hercules's punch output is not even being used at all. So of what
concern is the garbage? (Except as an indication of a possible Hercules
bug, which in this case, sounds like it doesn't seem to impact anything?
The sysgen is using JES2, not the Hercules punch output!)
Help! :(

In the Jay Moseley SYSGEN, the stage1 "sysgen01.jcl" job
punch the stage2 JCL deck on a file which is then given to an awk/perl
script to change some bit of the output and this new JCL
deck is pushed down into the reader as "stage2.jcl" to complete
STAGE2 in multiple single steps.

Have a look to the Jay Moseley documentation:

http://www.jaymoseley.com/hercules/installMVS/iSYSGEN.htm

at the section "Stage 1 SYSGEN01" for the details.

Jay Moseley point out the reason why he choosed that road
in these periods (quoting from the web pages):

"However, there are some changes that need to be made to the jobstreams
before they are submitted.

I am aware that other folks who have done this process have taken the
approach to modify the System Generation macros, which results in these
changes already being made when the card images are produced. My approach
is to leave the macros as they are distributed and make the changes at
this point, when the card images have been transferred to a text file on
the host operating system (LINUX, Windows, etc.).

You may make the changes manually with your favorite text editor - joe,
vi, notepad, etc. - but I have also provided a couple of scripts that will
make the changes for you. To make the changes manually, copy pch013.txt
to stage2.jcl; then edit the stage2.jcl file to make the changes. If you
utilize my scripts (which are described in the highlighted section below),
execution of the script will copy the contents of pch013.txt as it makes
the changes."

Peppe.

[Joe Monk [e-mail] [H390-MVS]]

"In the Jay Moseley SYSGEN, the stage1 "sysgen01.jcl" job
punch the stage2 JCL deck on a file which is then given to an awk/perl
script to change some bit of the output and this new JCL
deck is pushed down into the reader as "stage2.jcl" to complete
STAGE2 in multiple single steps."

Correction. This is the IBM way, not the Jay Moseley way. :)

Joe

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]

Post by ***@yahoo.com [H390-MVS]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
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?

No card reader involved.

Then I'm confused. What is the purpose of the punch output? How is it

being used?

Post by ***@yahoo.com [H390-MVS]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
(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?)

No card reader.
One step assembler with output in card format.
Output to JES2 for complication or old instructions.
Output card image file changed to ASCII on punch
by Hercules with no answer as to whether LF or
CRLF was requested.

Then again, I am very confused! If the assembler output is going to
JES2, then of what purpose is Hercules's punch output? It sounds to me
that Hercules's punch output is not even being used at all. So of what
concern is the garbage? (Except as an indication of a possible Hercules
bug, which in this case, sounds like it doesn't seem to impact anything?
The sysgen is using JES2, not the Hercules punch output!)
Help! :(

In the Jay Moseley SYSGEN, the stage1 "sysgen01.jcl" job
punch the stage2 JCL deck on a file which is then given to an awk/perl
script to change some bit of the output and this new JCL
deck is pushed down into the reader as "stage2.jcl" to complete
STAGE2 in multiple single steps.
http://www.jaymoseley.com/hercules/installMVS/iSYSGEN.htm
at the section "Stage 1 SYSGEN01" for the details.
Jay Moseley point out the reason why he choosed that road
"However, there are some changes that need to be made to the jobstreams
before they are submitted.
I am aware that other folks who have done this process have taken the
approach to modify the System Generation macros, which results in these
changes already being made when the card images are produced. My approach
is to leave the macros as they are distributed and make the changes at
this point, when the card images have been transferred to a text file on
the host operating system (LINUX, Windows, etc.).
You may make the changes manually with your favorite text editor - joe,
vi, notepad, etc. - but I have also provided a couple of scripts that will
make the changes for you. To make the changes manually, copy pch013.txt
to stage2.jcl; then edit the stage2.jcl file to make the changes. If you
utilize my scripts (which are described in the highlighted section below),
execution of the script will copy the contents of pch013.txt as it makes
the changes."
Peppe.

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
No card reader involved.

Then I'm confused. What is the purpose of the punch output?
How is it being used?

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
No card reader.

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]

Then again, I am very confused! If the assembler output
is going to JES2, then of what purpose is Hercules's punch
output? It sounds to me that Hercules's punch output is not
even being used at all. So of what concern is the garbage?

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
In the Jay Moseley SYSGEN, the stage1 "sysgen01.jcl" job
punch the stage2 JCL deck on a file which is then given to
an awk/perl script to change some bit of the output and this
new JCL deck is pushed down into the reader as "stage2.jcl"
to complete STAGE2 in multiple single steps.

<snip>

That's what I thought!

But then somitcw kept saying "No card reader", causing confusion.

He either lied to me or misunderstood my question (or was referring to something else and *I* didn't understand his response).

But thank you for confirming for me that what I originally thought was indeed correct, Peppe. I really appreciate it. My sanity has been restored. :)

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
- - - beginning snipped - - -

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
But then somitcw kept saying "No card reader", causing confusion.

- - - ending snipped - - -

No cause for confusion.

While MVS has thousands of components,
data being corrupted when writing from SPOOL to a
card punch file does not in anyway involve a card reader.

The fact that the procedure being followed may at a future
point involve a tape, card reader, printer, or disk data set
does not change that.

Many steps later should involve the linkage editor but
debugging dozens of steps before or after the corruption
does no good. Get Jay's instruction and debug all the
many and sundry steps except SPOOL to the card
punch may not be helpful.

There is no card reader involved.
There is no tape drive involved.
There is no IPL of VM, DOS/VS or Music/SP involved.
At this time, it appears that the issue is JES2 SPOOL
to a card punch being corrupted.

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
No card reader involved.

Then I'm confused. What is the purpose of the punch output?
How is it being used?

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
No card reader.

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]

Then again, I am very confused! If the assembler output
is going to JES2, then of what purpose is Hercules's punch
output? It sounds to me that Hercules's punch output is not
even being used at all. So of what concern is the garbage?

[...]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
In the Jay Moseley SYSGEN, the stage1 "sysgen01.jcl" job
punch the stage2 JCL deck on a file which is then given to
an awk/perl script to change some bit of the output and this
new JCL deck is pushed down into the reader as "stage2.jcl"
to complete STAGE2 in multiple single steps.

<snip>
That's what I thought!
But then somitcw kept saying "No card reader", causing confusion.
He either lied to me or misunderstood my question (or was referring to something else and *I* didn't understand his response).
But thank you for confirming for me that what I originally thought was indeed correct, Peppe. I really appreciate it. My sanity has been restored. :)

Well, the Moseley sysgen involve submitting down
to a reader the "stage2.jcl" stream, but the reader
doesn't seem involved at all, David.

Paul get garbage BEFORE anything is done with
the reader, I guess that is the point somitcw
was trying to make clear and it seems Paul
is getting garbage even in simpler tests,
from what I'm reading so far.

I may do some test on myself, of course, but I'm
beginning to suspect it is something that happens
on the Paul environment, as I've never seen
anything weird out of my punch, which by
the way I used for many purpouses in my MVS
plays, with different versions of the hercules
emulator.

Mmm ... I'm in a "pure" Linux environment
and I don't use hercules scripting at all,
all my steps has been done manually.

Paul, if I got the picture, works in a
Windows environemnt and is trying to
automate the SYSGEN using hercules HAO
scripts, a game I've never embraced.

I see many people are proposing simpler tests
that an actual sysgen. Let see the results.

Maybe we will end up with a simple test which
may point out where the problem come.

Peppe.

[Joe Monk [e-mail] [H390-MVS]]

"Then again, I am very confused! If the assembler output is going to JES2,
then of what purpose is Hercules's punch output? It sounds to me that
Hercules's punch output is not even being used at all. So of what concern
is the garbage? (Except as an indication of a possible Hercules bug, which
in this case, sounds like it doesn't seem to impact anything? The sysgen is
using JES2, not the Hercules punch output!)"

Fish,

The sysgen process generates a card deck out of stage1, which is fed back
in as stage 2.

Before it can be put back in as stage2, the card deck must be manipulated
just as it would in real life. There are some edits that have to be done on
the JOB cards, etc.

So, the stage 1 job spools the output to the punch via JES2, which Hercules
sends to the PC as a file to be edited and then devinit back in via the
reader.

Make sense?

Joe

On Sat, Feb 24, 2018 at 6:17 AM, ''Fish' (David B. Trout)'

Post by ***@yahoo.com [H390-MVS]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
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?

No card reader involved.

Then I'm confused. What is the purpose of the punch output? How is it
being used?

Post by ***@yahoo.com [H390-MVS]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
(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?)

No card reader.
One step assembler with output in card format.
Output to JES2 for complication or old instructions.
Output card image file changed to ASCII on punch
by Hercules with no answer as to whether LF or
CRLF was requested.

Then again, I am very confused! If the assembler output is going to JES2,
then of what purpose is Hercules's punch output? It sounds to me that
Hercules's punch output is not even being used at all. So of what concern
is the garbage? (Except as an indication of a possible Hercules bug, which
in this case, sounds like it doesn't seem to impact anything? The sysgen is
using JES2, not the Hercules punch output!)
Help! :(
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

Post by Joe Monk ***@gmail.com [H390-MVS]
The sysgen process generates a card deck out of stage1,
which is fed back in as stage 2.
Before it can be put back in as stage2, the card deck
must be manipulated just as it would in real life. There are
some edits that have to be done on the JOB cards, etc.
So, the stage 1 job spools the output to the punch via JES2,
which Hercules sends to the PC as a file to be edited
and then devinit back in via the reader.
Make sense?

Perfectly! And what you just described is precisely how I thought things worked.

But then somitcw kept saying "No card reader involved", which confused the hell out of me! :)

I'm glad I was correct in my original understanding.

Thanks Joe.

[[e-mail] [H390-MVS]]

- - -In H390-***@yahoogroups.com, <***@...> wrote:
- - - beginning snipped - - -

Perfectly! And what you just described is precisely how I thought things worked.
But then somitcw kept saying "No card reader involved", which confused the hell out of me! :)
I'm glad I was correct in my original understanding.
Thanks Joe.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com http://www.softdevlabs.com

The procedure died long before any clean but massaged
data was read back to MVS with IND$FILE, a card reader,
an OMA/TDF tape, FTP, dasdload or other method.

No card reader has been used.

We have corruption long before the thought of a card
reader.

If you are working on finding a bug for a card reader
when none has been involved, you might miss the
fact that SPOOL to punch creates corrupted data.

There is no card reader involved.
With corrupted punch data, it is too early to introduce
a card reader that has not been involved in any
debugging efforts.

P.S. Jay's procedure using a card punch is not what
most people would do but it is what we are using to
debug a possible Hercules issue that does not in
anyway involve a card reader.

There is no card reader involved.
Data set SYS1.AOSU0 wasn't involved either.

['Dave Wade' [e-mail] [H390-MVS]]

Hi Fish, (and Paul)

I am out today. I planned to try and see if VM would produce garbage. Will
contact you off-list about Hv4. Not had a HEX dump from Paul. Would be
usefull.
Paul has reproduced on un-patched Hercules but not sure if V3.13 was latest
or if he has used 4.
I not think he should try with latest V4 as you say channel architecture is
different.
Busy today so may be Sunday before I have time to try things myself.

Dave

-----Original Message-----
Sent: 24 February 2018 02:07
Subject: [hercules-390] Some questions (re: dodgy punch)
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?
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Paul, I've never seen any garbage from my Moseley stage1 SYSGEN, done
under MVS3.7 or MVS3.8j, but, reading back from my notes, I realized
I always issue these commands from the hercules console
(I use channel 00d from MVS3.8j instead of channel 013
Jay Moseley use from MVS3.7, but for the same goal, in the same step):

sh > pch00d.txt
devinit 00d pch00d.txt ascii

BEFORE actually running "sysgen01.jcl" to get the stage2
JCL deck out of the punch, the step where, I guess, you met the
problem.

The hercules commands are issued just to be sure "pch00d.txt" is an empty,
new created UNIX file and the hercules emulated punch point
to the beginning of this empty new file (that for my own bad
habit to forget I had already something in the punch file ;-) )

Maybe it has nothing to do with your problem, perhaps
I had just been lucky and I haven't met the problem,
but it looks quite a weird coincidence to my eyes.

Peppe.

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

(slight editing for clarity)

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
Paul, I've never seen any garbage from my Moseley stage1
SYSGEN, done under MVS3.7 or MVS3.8j, but, reading back
from my notes, I realized I always issue the following
commands from the hercules console [...] BEFORE actually
running "sysgen01.jcl" to get the stage2 JCL deck out of
sh > pch00d.txt
devinit 00d pch00d.txt ascii

Interesting!

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
The hercules commands are issued just to be sure "pch00d.txt"
is an empty, new created UNIX file and the hercules emulated
punch point to the beginning of this empty new file (that for
my own bad habit to forget I had already something in the punch
file ;-) )

How much trouble would it be, Peppe, for you to try the SYSGEN again (possibly several time since, from the sounds of it, the problem doesn't always occur) but WITHOUT issuing those commands? I'm rather curious as to whether your manual clearing/emptying of the emulated punch file (pch00d.txt) is what is preventing Paul's problem from occurring.

Paul? How much trouble would it be to insert the above commands that Peppe is using into your automation scripts and then trying to reproduce the problem again?

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
Maybe it has nothing to do with your problem, perhaps
I had just been lucky and I haven't met the problem,
but it looks quite a weird coincidence to my eyes.

It looks that way to my eyes as well, Peppe!

This is looking more and more like it actually *IS* a Hercules bug. A Hercules bug that was reported last year and fixed in my SDL version of Hyperion, but which was unfortunately (for reasons unknown) never fixed in the hercules-390 version of Hyperion (and one which still exists in 3.07 too, obviously!).

So it isn't so much that Hercules is producing garbage (which it's not), but rather that it's simply not cleaning out old data when it opens its emulated punch output file (i.e. it's not "ftruncate"ing its output file).

I seem to recall we had this same problem with emulated TAPE output too, a long time ago. And I believe it was somitcw that reported it too. When an existing (non-empty) emulated .AWS or .HET, etc, tape file was specified as the emulated media to be mounted on a tape drive (e.g. "attach 580 3420 mytape.aws" or "devinit 580 mytape.aws", and "mytape.aws" had a non-trivial amount of data on it) and the guest wrote to that tape drive, but only wrote a small/tiny amount of data to it, then after the file was closed by Hercules, there would be trailing garbage past what SHOULD have been the end of the tape (because Hercules was failing to "ftruncate" the file at close).

This "dodgy punch" issue is beginning to sound like the very same thing.

[[e-mail] [H390-MVS]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
sh > pch00d.txt
devinit 00d pch00d.txt ascii

Paul? How much trouble would it be to insert the
above commands that Peppe is using into your
automation scripts and then trying to reproduce
the problem again?

Can I use a "del" to delete the existing punch
file instead? And if I start doing a devinit for
the same file, what do you want me to change
this config file definition to:

0013 3525 pch013.txt ascii

BFN. Paul.

[[e-mail] [H390-MVS]]

- - - all snipped - - -

Do we care where the original data came from?

Are we investigating MVS system generation process or
its use of the assembler?

Or, are we investigation JES2 ( or DOS/VS Power or
CP SPOOL ) punching to a Hercules punch?

All already have DSN=SYS1.STAGE1.OUTPUT
I'll IDCAMS/IEBGENER/other punch it to JES2
a few times and look for file size changes.
I use the most current Fish's Hyperion so don't
expect issues but will try. I also use CRLF but
don't believe that LF/CRLF is the issue.

I can rerun dozens of times and use file-size as an indication of the error.
Something like:

//HERC01P JOB (XXXXXXXX,XXXX,1439,9999),PUNCH-HERC01,
// CLASS=A,MSGCLASS=C,
// NOTIFY=HERC01,COND=(0,NE)
//IDCAMS EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//* following statement has a space on column 1
REPRO INFILE(SYSUT1) OUTFILE(SYSUT2)
//SYSUT1 DD DISP=SHARE,DSN=SYS1.STAGE1.OUTPUT
//SYSUT2 DD SYSOUT=B,DCB=SYS1.STAGE1.OUTPUT
//*
//CHECKCC EXEC PGM=IEFBR14

Input is 14,615 card images.

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

somitcw wrote:

[...]

Post by ***@yahoo.com [H390-MVS]
All already have DSN=SYS1.STAGE1.OUTPUT
I'll IDCAMS/IEBGENER/other punch it to JES2
a few times and look for file size changes.
I use the most current Fish's Hyperion
so don't expect issues but will try.

Worth a shot. Thank you somitcw.

Post by ***@yahoo.com [H390-MVS]
I also use CRLF but don't believe that
LF/CRLF is the issue.

Agreed.

Post by ***@yahoo.com [H390-MVS]
I can rerun dozens of times and use file-size
//HERC01P JOB (XXXXXXXX,XXXX,1439,9999),PUNCH-HERC01,
// CLASS=A,MSGCLASS=C,
// NOTIFY=HERC01,COND=(0,NE)
//IDCAMS EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//* following statement has a space on column 1
REPRO INFILE(SYSUT1) OUTFILE(SYSUT2)
//SYSUT1 DD DISP=SHARE,DSN=SYS1.STAGE1.OUTPUT
//SYSUT2 DD SYSOUT=B,DCB=SYS1.STAGE1.OUTPUT
//*
//CHECKCC EXEC PGM=IEFBR14
Input is 14,615 card images.

I would be very interested in such a test, but only if you run the same test using either Hercules 3.07 or the "other" Hyperion (hercules-390/hyperion) too and not my SDL Hyperion (so we can compare the two and verify the problem does *not* occur with my hyperion but *does* occur with other Hercules versions).

Thanks.

p.s. Why did you lie to me (confuse me) with your "No card reader" claim in your prior response? :)

[[e-mail] [H390-MVS]]

[...]

Post by ***@yahoo.com [H390-MVS]
All already have DSN=SYS1.STAGE1.OUTPUT
I'll IDCAMS/IEBGENER/other punch it to JES2
a few times and look for file size changes.
I use the most current Fish's Hyperion
so don't expect issues but will try.

Worth a shot. Thank you somitcw.

Latest Fish Hyperion:
HHC01413I Hercules version 4.0.0.8906-SDL-g1035eafe (4.0.0.8906)
HHC01414I (C) Copyright 1999-2017 by Roger Bowler, Jan Jaeger, and others
HHC01417I ** The SoftDevLabs version of Hercules **
HHC01415I Build date: Nov 7 2017 at 11:44:19
HHC01417I Built with: Microsoft Visual C 150030729 1
HHC01417I Build type: Windows MSVC AMD64 host architecture build

Windows 10:
Microsoft Windows [Version 10.0.16299.248]

MVS 3.8j with many changes

Procedure:
1. Click on StartMVS desktop icon
2. Enter "/s pun" which is a reader for the JOB
3. Enter "/s shut" to shut MVS down clean
4. After shutdown complete, enter "quit" to quit Hercules

Above Procedure repeated many times.

All punch files had the same byte count.
All files compared equal with MS-DOS "fc" command

H:\MVS\pch>dir pch*
Volume in drive H is Backups
Volume Serial Number is DC1A-4842

Directory of H:\MVS\pch

Sat-2018-02-24 09:32 513,687 pch00d.2018-02-24.Sat.09.12.06.214.txt
Sat-2018-02-24 09:45 513,687 pch00d.2018-02-24.Sat.09.40.13.512.txt
Sat-2018-02-24 09:48 513,687 pch00d.2018-02-24.Sat.09.48.12.631.txt
Sat-2018-02-24 09:50 513,687 pch00d.2018-02-24.Sat.09.49.52.214.txt
Sat-2018-02-24 09:51 513,687 pch00d.2018-02-24.Sat.09.51.30.059.txt
Sat-2018-02-24 09:52 513,687 pch00d.2018-02-24.Sat.09.52.14.568.txt
Sat-2018-02-24 09:54 513,687 pch00d.2018-02-24.Sat.09.53.41.497.txt
Sat-2018-02-24 09:55 513,687 pch00d.2018-02-24.Sat.09.54.54.516.txt
Sat-2018-02-24 09:56 513,687 pch00d.2018-02-24.Sat.09.55.49.639.txt
Sat-2018-02-24 09:57 513,687 pch00d.2018-02-24.Sat.09.57.00.192.txt
Sat-2018-02-24 10:12 513,687 pch00d.2018-02-24.Sat.10.11.38.646.txt
Sat-2018-02-24 10:17 513,687 pch00d.2018-02-24.Sat.10.17.36.645.txt
Sat-2018-02-24 10:18 513,687 pch00d.2018-02-24.Sat.10.18.31.170.txt
Sat-2018-02-24 10:19 513,687 pch00d.2018-02-24.Sat.10.19.23.938.txt
Sat-2018-02-24 10:20 513,687 pch00d.2018-02-24.Sat.10.20.16.788.txt
Sat-2018-02-24 10:21 513,687 pch00d.2018-02-24.Sat.10.21.03.471.txt
Sat-2018-02-24 10:21 513,687 pch00d.2018-02-24.Sat.10.21.33.691.txt
Sat-2018-02-24 10:22 513,687 pch00d.2018-02-24.Sat.10.22.34.582.txt
Sat-2018-02-24 10:24 513,687 pch00d.2018-02-24.Sat.10.23.46.132.txt
Sat-2018-02-24 10:24 513,687 pch00d.2018-02-24.Sat.10.24.32.008.txt
Sat-2018-02-24 10:25 513,687 pch00d.2018-02-24.Sat.10.25.29.842.txt
Sat-2018-02-24 10:26 513,687 pch00d.2018-02-24.Sat.10.26.16.877.txt
Sat-2018-02-24 10:27 513,687 pch00d.2018-02-24.Sat.10.27.04.168.txt
Sat-2018-02-24 10:28 513,687 pch00d.2018-02-24.Sat.10.27.52.412.txt
Sat-2018-02-24 10:28 513,687 pch00d.2018-02-24.Sat.10.28.35.913.txt
Sat-2018-02-24 10:31 513,687 pch00d.2018-02-24.Sat.10.30.49.563.txt
Sat-2018-02-24 10:32 513,687 pch00d.2018-02-24.Sat.10.32.07.454.txt
Sat-2018-02-24 10:33 513,687 pch00d.2018-02-24.Sat.10.33.15.797.txt
28 File(s) 14,383,236 bytes
0 Dir(s) 230,245,277,696 bytes free

Post by ***@yahoo.com [H390-MVS]
I also use CRLF but don't believe that
LF/CRLF is the issue.

Agreed.

Good, I left my punch with crlf

Post by ***@yahoo.com [H390-MVS]
I can rerun dozens of times and use file-size
//HERC01P JOB (XXXXXXXX,XXXX,1439,9999),PUNCH-HERC01,
// CLASS=A,MSGCLASS=C,
// NOTIFY=HERC01,COND=(0,NE)
//IDCAMS EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//* following statement has a space on column 1
REPRO INFILE(SYSUT1) OUTFILE(SYSUT2)
//SYSUT1 DD DISP=SHARE,DSN=SYS1.STAGE1.OUTPUT
//SYSUT2 DD SYSOUT=B,DCB=SYS1.STAGE1.OUTPUT
//*
//CHECKCC EXEC PGM=IEFBR14
Input is 14,615 card images.

I would be very interested in such a test, but only if you run the
same test using either Hercules 3.07 or the "other" Hyperion
(hercules-390/hyperion) too and not my SDL Hyperion (so we
can compare the two and verify the problem does *not* occur
with my hyperion but *does* occur with other Hercules versions).
Thanks.

Done with my MVS and Hercules. See above.
If Paul will do the same with his system, we may or may not be
able to recreate the issue.

p.s. Why did you lie to me (confuse me) with your
"No card reader" claim in your prior response? :)
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com

I saw neither a card reader nor sliced salami.
Did you see different.
How did you see different?
Perhaps one of us need glasses.

It may be best for us to stop working on the
card reader or sliced salami issue because
neither a card reader issue nor sliced salami
issue has been reported or been involved.
Billions of other things that are not involved
have also not been reported.
That is no lie.

[[e-mail] [H390-MVS]]

Here is the latest test result.

I put in an explicit delete of the punch file:

C:\mvs380_work\cardbug>type build4.bat
copy save3 dasd

del pch013.txt
set HERCULES_RC=build4.rc
hercules -f sysgen.cnf >hercules.log

C:\mvs380_work\cardbug>


And I also switched off job separator pages
to make sure the comparisons are just data:

/$pprt1
pause 2
/$tpun1,s=n
pause 2

C A(0),B'11000000000000001000000000000000' &IGCRETR
R 15,15 & BR 14 & END &/* &//SG3
XXXXXXXX & & MIN

I'm now going to try somitcw's repro as the
job, omitting the sysgen, to see if I can get
repro to eventually produce junk. Actually,
I will just try the failing iebgener first.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
Here is the latest test result.

Did it come to your mind that.. eventually... your script *might* be
broken (instead of OS/MVS or hercules) ?

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
Here is the latest test result.

Did it come to your mind that.. eventually... your script *might* be
broken (instead of OS/MVS or hercules) ?

The script just executes Hercules commands.
As far as I know, Hercules doesn't have a
command that says "randomly trash the
punch". If you know of such a Hercules
command, let me know what it is and I'll do
a grep to make sure I'm not using it.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
The script just executes Hercules commands.
As far as I know, Hercules doesn't have a
command that says "randomly trash the
punch". If you know of such a Hercules
command, let me know what it is and I'll do
a grep to make sure I'm not using it.

Of course... there are inifinite hercules commands that can produce
unpredictable results.

Just give me *ONE* command that does what you claim, and I'll look into it !

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
The script just executes Hercules commands.
As far as I know, Hercules doesn't have a
command that says "randomly trash the
punch". If you know of such a Hercules
command, let me know what it is and I'll do
a grep to make sure I'm not using it.

Of course... there are inifinite hercules commands
that can produce unpredictable results.
Just give me *ONE* command that does what
you claim, and I'll look into it !

You have that the wrong way around. You give
me *ONE* command that invokes the "randomly
delete and trash bits of a punch file" feature.
It's simply not possible to do that unless it is
deliberately coded or there is a bug.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
You have that the wrong way around. You give
me *ONE* command that invokes the "randomly
delete and trash bits of a punch file" feature.
It's simply not possible to do that unless it is
deliberately coded or there is a bug.

You make claims - you must give proof...

Russel's teapot for you

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
You have that the wrong way around. You give
me *ONE* command that invokes the "randomly
delete and trash bits of a punch file" feature.
It's simply not possible to do that unless it is
deliberately coded or there is a bug.

You make claims - you must give proof...

No, YOU made the claim that it was PEBCAK
and definitely not Hercules. How you can be
so confident of 200,000 lines of Hercules
code and 10 million lines of MVS code is
beyond me.

You also made a claim that PEBCAK people
had access to diabolical commands that can
indeed cause random data in punch files, so
it is up to you to produce evidence of such a
command that can be run. I can't conceive of
how such a thing can happen short of
deliberate malicious coding or program bug
(program bug not necessarily in Hercules).

The only claim I made was that my punch
wasn't working properly, as a warning that
there was a bug out there *somewhere* in
case someone else experienced the same
thing they would know that they are not
alone.

Take another look at what I actually wrote:

https://groups.yahoo.com/neo/groups/H390-MVS/conversations/messages/17898

I only claimed that my punch was unreliable,
which it is. I also mentioned which versions
of Hercules I was using, but in no way did I
say that the problem was DEFINITELY in
Hercules. Although given that I have seen
timing bugs in Hercules such as a hang
when "quit" is typed, my *suspicions* were
certainly with Hercules, as there appear to
be timing-related bugs in Hercules. But in no
way did I ever claim with certainty that it was
Hercules causing the punch issue.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
You have that the wrong way around. You give
me *ONE* command that invokes the "randomly
delete and trash bits of a punch file" feature.
It's simply not possible to do that unless it is
deliberately coded or there is a bug.

You make claims - you must give proof...

No, YOU made the claim that it was PEBCAK
and definitely not Hercules. How you can be
so confident of 200,000 lines of Hercules
code and 10 million lines of MVS code is
beyond me.

No I wasn't making that claim. I said it is a possibility that it is a
PEBCAK.

But did you actually *investigate* and try to find any bug in hercules
or OS/MVS code *yet* you NEVER question your own code !

Remember - Any and all of the procedures you mention are intended to be
human operated - NOT automatically scripted.

So....

You write a script... it doesn't work as intended : So it's a bug
somewhere ! (but not your fault)...

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
No, YOU made the claim that it was PEBCAK
and definitely not Hercules. How you can be
so confident of 200,000 lines of Hercules
code and 10 million lines of MVS code is
beyond me.

No I wasn't making that claim. I said it is a possibility that it is a
PEBCAK.

Here is your first comment:

https://groups.yahoo.com/neo/groups/H390-MVS/conversations/messages/17916

"You keep on calling for bugs....
When most of the time it is a BCAK issue"


So when you say "most of the time", that
means 51% or more. Perhaps you can tell
me what bugs I reported that were actually
PEBCAK? All the Hercules hangs that I
reported? You're claiming that if I type in
"quit" and it hangs, that's PEBCAK?

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
But did you actually *investigate* and try to find any bug in hercules
or OS/MVS code

No, because I'm not the vendor of either of
those products.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
*yet* you NEVER question your own code !

My own code, such that it is, is simply Hercules
commands. Unless you want to blame my
.bat file that runs Hercules.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
Remember - Any and all of the procedures you
mention are intended to be
human operated - NOT automatically scripted.

If a command works when a human enters it,
but not in a script, that is a BUG. That goes
for the "quit" hang and this case. It's a
timing-sensitive bug.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
You write a script... it doesn't work as intended : So it's a bug
somewhere ! (but not your fault)...

It's WAY beyond not working as intended. It is
random data being written to a punch, which
is WAY beyond the documented ability of any
Hercules command that may be scripted.

People simply don't write commands that can
do something like that, unless it's a malicious
virus.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
No, YOU made the claim that it was PEBCAK
and definitely not Hercules. How you can be
so confident of 200,000 lines of Hercules
code and 10 million lines of MVS code is
beyond me.

No I wasn't making that claim. I said it is a possibility that it is a
PEBCAK.

https://groups.yahoo.com/neo/groups/H390-MVS/conversations/messages/17916
"You keep on calling for bugs....
When most of the time it is a BCAK issue"

That's what I said : When *MOST OF THE TIME* - Which implies clearly
that it is a possibility, not a certainty !

Post by ***@yahoo.com.au [H390-MVS]
So when you say "most of the time", that
means 51% or more. Perhaps you can tell
me what bugs I reported that were actually
PEBCAK? All the Hercules hangs that I
reported? You're claiming that if I type in
"quit" and it hangs, that's PEBCAK?

You *CLAIM* it happens - but NEVER - Ever - give a simple test case...
It always involves reproducing the EXACT situation you have (we have to
buy YOUR hardware, YOUR OS, your location, your state of minf... and
THEN we have to reproduce YOUR problem).

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
But did you actually *investigate* and try to find any bug in hercules
or OS/MVS code

No, because I'm not the vendor of either of
those products.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
*yet* you NEVER question your own code !

My own code, such that it is, is simply Hercules
commands. Unless you want to blame my
..bat file that runs Hercules.

Yes... YOUR .bat file.. Your script.. but that's never at fault is it ?

Can't you reproduce any of the problem that doesn't involve a script, a
complex OS or whatnot ?

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
Remember - Any and all of the procedures you
mention are intended to be
human operated - NOT automatically scripted.

If a command works when a human enters it,
but not in a script, that is a BUG. That goes
for the "quit" hang and this case. It's a
timing-sensitive bug.

Yes it MAY be a timing sensitive bug.. IN YOUR Darn SCRIPT !

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
You write a script... it doesn't work as intended : So it's a bug
somewhere ! (but not your fault)...

It's WAY beyond not working as intended. It is
random data being written to a punch, which
is WAY beyond the documented ability of any
Hercules command that may be scripted.
People simply don't write commands that can
do something like that, unless it's a malicious
virus.

If you erase a file before it is created, and the erase doesn't work
(since the file now exists) - it's not because the erase command doesn't
work - it's because it was invoked out of turn in a timing sensitive script..

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
PEBCAK? All the Hercules hangs that I
reported? You're claiming that if I type in
"quit" and it hangs, that's PEBCAK?

You *CLAIM* it happens - but NEVER - Ever - give a simple test case...
It always involves reproducing the EXACT situation you have (we have to
buy YOUR hardware, YOUR OS, your location, your state of minf... and
THEN we have to reproduce YOUR problem).

Wow, just wow. You're even trying to pass of
the "quit" hangs as another example of
PEBCAK rather than treating as a complicated
field bug that is difficult to debug.

I think we're probably about done now. We have
very different views of the world.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
*yet* you NEVER question your own code !

My own code, such that it is, is simply Hercules
commands. Unless you want to blame my
..bat file that runs Hercules.

Yes... YOUR .bat file.. Your script.. but that's never at fault is it ?

No Ivan. It isn't. If I type "quit" in my script,
and Hercules hangs, that's either a Hercules
bug or (very unlikely) a Windows bug or a
hardware bug that is very difficult to debug.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
Can't you reproduce any of the problem
that doesn't involve a script, a
complex OS or whatnot ?

Um, not really. If I have an intermittent fault,
then the best thing that can happen is for it
to be scripted so that the script can be
rerun to eventually reproduce a problem.

Normally if someone has a reproducible
problem like that, it is a godsend for the
vendor because it is actually debuggable.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
If a command works when a human enters it,
but not in a script, that is a BUG. That goes
for the "quit" hang and this case. It's a
timing-sensitive bug.

Yes it MAY be a timing sensitive bug.. IN YOUR Darn SCRIPT !

Just wow. I'm lost for words. You have a very
strange way of defining bugs.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
If you erase a file before it is created, and the erase doesn't work
(since the file now exists) - it's not because the erase command doesn't
work - it's because it was invoked out of turn in a timing sensitive script.

If I have a .bat file and I put the erase before
the file is created, that would indeed be a bug
in my script. If the script was also dependent
on the timing of something else, that would
also be a bug.

Running the "quit" command in a script is in
no way a timing sensitive bug that is the
fault of the user. It is a time sensitive Hercules
bug. The fact that the bug appears in the field
rather than in a nice dev lab setting of the
developer does not change that one iota.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
No Ivan. It isn't. If I type "quit" in my script,
and Hercules hangs, that's either a Hercules
bug or (very unlikely) a Windows bug or a
hardware bug that is very difficult to debug.

Wait.. You are mixing problems here.. First you talk about a card
puncher shredding cards failing unexpectedly after an abrupt powerdown
and now about the circuit breaker not cutting power as intended ?

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
Can't you reproduce any of the problem
that doesn't involve a script, a
complex OS or whatnot ?

Um, not really. If I have an intermittent fault,
then the best thing that can happen is for it
to be scripted so that the script can be
rerun to eventually reproduce a problem.

You are writing code - and are relying on undocumented and "expected"
features of a component - and YET you claim there is a bug in that
component ?

Post by ***@yahoo.com.au [H390-MVS]
Normally if someone has a reproducible
problem like that, it is a godsend for the
vendor because it is actually debuggable.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
If a command works when a human enters it,
but not in a script, that is a BUG. That goes
for the "quit" hang and this case. It's a
timing-sensitive bug.

Yes it MAY be a timing sensitive bug.. IN YOUR Darn SCRIPT !

Just wow. I'm lost for words. You have a very
strange way of defining bugs.

You are relying on undocumented features of components... the bug is
relying on that.

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
If you erase a file before it is created, and the erase doesn't work
(since the file now exists) - it's not because the erase command doesn't
work - it's because it was invoked out of turn in a timing sensitive script.

If I have a .bat file and I put the erase before
the file is created, that would indeed be a bug
in my script. If the script was also dependent
on the timing of something else, that would
also be a bug.

No... You are expecting component interfaces to provide undocumented and
unspecified features

Post by ***@yahoo.com.au [H390-MVS]
Running the "quit" command in a script is in
no way a timing sensitive bug that is the
fault of the user. It is a time sensitive Hercules
bug. The fact that the bug appears in the field
rather than in a nice dev lab setting of the
developer does not change that one iota.

Where does it say that "quit" *WILL* actually succeed within the time
YOU define and under what time it will succeed.. or *ANY* of the
commands you issue for that matter ?

--Ivan

['Dave Wade' [e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
You are writing code - and are relying on undocumented and "expected"
features of a component - and YET you claim there is a bug in that
component ?

What is he relying on that’s undocumented?


Dave

[Ivan Warren [e-mail] [H390-MVS]]

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
What is he relying on that’s undocumented?

His scripts rely on the fact that commands will complete within a
certain pre-determined amount of time.

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
What is he relying on that’s undocumented?

His scripts rely on the fact that commands will complete within a
certain pre-determined amount of time.

So THIS is what you are talking about. Sorry,
no dice. I can check the hercules log file and
see that the command did in fact terminate
within the allotted time. No bug in my
scripts there.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
So THIS is what you are talking about. Sorry,
no dice. I can check the hercules log file and
see that the command did in fact terminate
within the allotted time. No bug in my
scripts there.

Are you sure ?

Does your script examine every output of every job submitted to
determine the actual next job to submit ?

All I see is that you basically assume any job submitted will complete
within some arbitrary alloted amount of time, that the output card decks
will be punched and then pull the machine room main breaker... Not
something some human operator would do.

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
So THIS is what you are talking about. Sorry,
no dice. I can check the hercules log file and
see that the command did in fact terminate
within the allotted time. No bug in my
scripts there.

Are you sure ?
Does your script examine every output of every job submitted to
determine the actual next job to submit ?

No, it doesn't need to. I can easily validate
that after the fact.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
All I see is that you basically assume any job submitted will complete
within some arbitrary alloted amount of time, that the output card decks
will be punched and then pull the machine room main breaker... Not
something some human operator would do.

The script I am running is below, as is the
Hercules output. I have stopped pulling the
breaker at somitcw's request. And you can
see for yourself that the single job finishes
within its allotted time. It was allotted 10
seconds but finished in 1. My batch file
stops as soon as it detects a problem, so
that the hercules log file can be inspected
for any sign of problem. The below is a
problem run.

Even if there was a problem with me pulling
the circuit breaker too early, that would result
in a loss of data at the end of the file, where
everything is stopped dead, not produce
*random data* in the *middle* of the file.

BFN. Paul.



toddrag

ipl 150

pause 2

/r 00,clpa

pause 10

/r 00,cold,noreq
#/r 00,noreq

pause 6

/$pi2-3

pause 1

/$pprt1

pause 2

/$tpun1,s=n
#/$ppun1

pause 2

devinit 012 punch.jcl eof
#devinit 012 repro.jcl eof

pause 10

/$ppun1

pause 2

/$pjes2

pause 5

/z eod

pause 2

/quiesce

pause 2

quit





07:46:12 toddrag
07:46:12 HHCPN036I TOD clock drag factor = 2.000000
07:46:12 ipl 150
07:46:12 HHCPN011I Pausing SCRIPT file processing for 2 seconds...
07:46:12 HHCAO001I Hercules Automatic Operator thread started;
07:46:12 tid=00004A58, pri=0, pid=13376
07:46:12 IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.70.VS2
07:46:12 HHC1C001A Enter input for console device 001F
07:46:14 HHCPN012I Resuming SCRIPT file processing...
07:46:14 /(001F) r 00,clpa
07:46:14 HHCPN011I Pausing SCRIPT file processing for 10 seconds...
07:46:14 HHCCD001I Readahead thread 1 started: tid=00002F48, pid=13376
07:46:14 HHCCD001I Readahead thread 2 started: tid=00003B08, pid=13376
07:46:14 HHCCD002I Writer thread 1 started: tid=000025E0, pid=13376
07:46:14 HHCCD003I Garbage collector thread started: tid=000055C8, pid=13376
07:46:15 HHCCD002I Writer thread 2 started: tid=0000575C, pid=13376
07:46:16 IEF165I // START JES2
07:46:16 IEE351I SMF SYS1.MAN RECORDING NOT BEING USED
07:46:16 *00 $HASP426 SPECIFY OPTIONS - HASP-II, VERSION JES2 4.0
07:46:24 HHCPN012I Resuming SCRIPT file processing...
07:46:24 /(001F) r 00,cold,noreq
07:46:24 #/r 00,noreq
07:46:24 HHCPN011I Pausing SCRIPT file processing for 6 seconds...
07:46:24 IEE600I REPLY TO 00 IS;SUPPRESSED
07:46:25 IEE041I THE SYSTEM LOG IS NOW ACTIVE
07:46:25 $HASP160 PRINTER1 INACTIVE - CLASS=AJ
07:46:25 $HASP160 PUNCH1 INACTIVE - CLASS=BK
07:46:25 $HASP125 READER1 SKIPPING FOR JOB CARD
07:46:25 $HASP100 INIT ON STCINRDR
07:46:25 $HASP373 INIT STARTED
07:46:25 $HASP100 INIT ON STCINRDR
07:46:25 $HASP373 INIT STARTED
07:46:25 $HASP100 INIT ON STCINRDR
07:46:25 $HASP373 INIT STARTED
07:46:25 $HASP309 INIT 1 INACTIVE ******** C=A
07:46:25 $HASP309 INIT 2 INACTIVE ******** C=BA
07:46:25 $HASP309 INIT 3 INACTIVE ******** C=CBA
07:46:25 $HASP099 ALL AVAILABLE FUNCTIONS COMPLETE
07:46:30 HHCPN012I Resuming SCRIPT file processing...
07:46:30 /(001F) $pi2-3
07:46:30 HHCPN011I Pausing SCRIPT file processing for 1 seconds...
07:46:30 $HASP000 OK
07:46:30 $HASP395 INIT ENDED
07:46:30 $HASP150 INIT ON PRINTER1
07:46:30 $HASP160 PRINTER1 INACTIVE - CLASS=AJ
07:46:30 $HASP099 ALL AVAILABLE FUNCTIONS COMPLETE
07:46:30 $HASP250 INIT IS PURGED
07:46:30 $HASP395 INIT ENDED
07:46:30 $HASP150 INIT ON PRINTER1
07:46:30 $HASP160 PRINTER1 INACTIVE - CLASS=AJ
07:46:30 $HASP099 ALL AVAILABLE FUNCTIONS COMPLETE
07:46:30 $HASP250 INIT IS PURGED
07:46:31 HHCPN012I Resuming SCRIPT file processing...
07:46:31 /(001F) $pprt1
07:46:31 HHCPN011I Pausing SCRIPT file processing for 2 seconds...
07:46:31 $HASP000 OK
07:46:31 $HASP097 PRINTER1 IS DRAINED
07:46:33 HHCPN012I Resuming SCRIPT file processing...
07:46:33 /(001F) $tpun1,s=n
07:46:33 #/$ppun1
07:46:33 HHCPN011I Pausing SCRIPT file processing for 2 seconds...
07:46:33 $HASP000 PUNCH1 013 INACTIVE F=STD.,AUTOM P=N R=LOCAL S=N Q=BK
07:46:35 HHCPN012I Resuming SCRIPT file processing...
07:46:35 devinit 012 punch.jcl eof
07:46:35 HHCPN098I Device 0:0012 initialized
07:46:35 #devinit 012 repro.jcl eof
07:46:35 HHCPN011I Pausing SCRIPT file processing for 10 seconds...
07:46:35 $HASP100 HERC01 ON READER1
07:46:35 $HASP373 HERC01 STARTED - INIT 1 - CLASS A - SYS H158
07:46:35 $HASP375 HERC01 ESTIMATED CARDS EXCEEDED
07:46:35 $HASP375 HERC01 ESTIMATED CARDS EXCEEDED BY 2000
07:46:36 $HASP375 HERC01 ESTIMATED CARDS EXCEEDED BY 4000
07:46:36 $HASP375 HERC01 ESTIMATED CARDS EXCEEDED BY 6000
07:46:36 $HASP375 HERC01 ESTIMATED CARDS EXCEEDED BY 8000
07:46:36 $HASP375 HERC01 ESTIMATED CARDS EXCEEDED BY 10000
07:46:36 $HASP375 HERC01 ESTIMATED CARDS EXCEEDED BY 12000
07:46:36 $HASP395 HERC01 ENDED
07:46:36 $HASP150 HERC01 ON PUNCH1
07:46:36 $HASP309 INIT 1 INACTIVE ******** C=A
07:46:36 $HASP160 PUNCH1 INACTIVE - CLASS=BK
07:46:36 $HASP099 ALL AVAILABLE FUNCTIONS COMPLETE
07:46:45 HHCPN012I Resuming SCRIPT file processing...
07:46:45 /(001F) $ppun1
07:46:45 HHCPN011I Pausing SCRIPT file processing for 2 seconds...
07:46:45 $HASP000 OK
07:46:45 $HASP097 PUNCH1 IS DRAINED
07:46:47 HHCPN012I Resuming SCRIPT file processing...
07:46:47 /(001F) $pjes2
07:46:47 HHCPN011I Pausing SCRIPT file processing for 5 seconds...
07:46:47 $HASP395 INIT ENDED
07:46:47 IEE043I A SYSTEM LOG DATA SET HAS BEEN QUEUED TO SYSOUT CLASS A
07:46:47 IEE037I LOG NOT ACTIVE
07:46:47 2000 20.46.30 CONSOLE IEE142I 01F NOW RECEIVING HARDCOPY
07:46:47 4000 20.46.30 IEE043I A SYSTEM LOG DATA SET HAS BEEN QUEUED TO SYSOUT CLASS A
07:46:47 4000 20.46.30 IEE037I LOG NOT ACTIVE
07:46:47 0000 20.46.30 IEF196I IEF142I JES2 JES2 - STEP WAS EXECUTED - COND CODE 0000
07:46:47 0000 20.46.30 IEF196I IEF285I SYS1.PROCLIB KEPT
07:46:47 0000 20.46.30 IEF196I IEF285I VOL SER NOS= START1.
07:46:47 0000 20.46.30 IEF196I IEF285I SYS1.HASPCKPT KEPT
07:46:47 0000 20.46.30 IEF196I IEF285I VOL SER NOS= SPOOL0.
07:46:47 0000 20.46.30 IEF196I IEF285I SYS1.HASPACE KEPT
07:46:47 0000 20.46.30 IEF196I IEF285I VOL SER NOS= SPOOL0.
07:46:52 HHCPN012I Resuming SCRIPT file processing...
07:46:52 /(001F) z eod
07:46:52 HHCPN011I Pausing SCRIPT file processing for 2 seconds...
07:46:52 4000 20.46.32 IEE334I HALT EOD SUCCESSFUL
07:46:54 HHCPN012I Resuming SCRIPT file processing...
07:46:54 /(001F) quiesce
07:46:54 HHCPN011I Pausing SCRIPT file processing for 2 seconds...
07:46:54 HHCCP011I CPU0000: Disabled wait state
07:46:54 PSW=000A0000 00000CCC
07:46:56 HHCPN012I Resuming SCRIPT file processing...
07:46:56 quit

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
No Ivan. It isn't. If I type "quit" in my script,
and Hercules hangs, that's either a Hercules
bug or (very unlikely) a Windows bug or a
hardware bug that is very difficult to debug.

Wait.. You are mixing problems here.. First you talk about a card
puncher shredding cards failing unexpectedly after an abrupt powerdown
and now about the circuit breaker not cutting power as intended ?

Because you used the plural when you said
that most of the problems I reported were
actually PEBCAK. The only problems I
remember reporting were the print file being
overwritten incorrectly (where I pointed to
the line of code in error), some card reader
error due to misuse of Windows handles
(which I debugged myself too), and various
hangs, such as hanging on "quit". I can't
think of a single instance of PEBCAK,
nevermind 51%.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
Can't you reproduce any of the problem
that doesn't involve a script, a
complex OS or whatnot ?

Um, not really. If I have an intermittent fault,
then the best thing that can happen is for it
to be scripted so that the script can be
rerun to eventually reproduce a problem.

You are writing code - and are relying on undocumented and "expected"
features of a component - and YET you claim there is a bug in that
component ?

The "quit" command is not undocumented.
You are really stretching here.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
Running the "quit" command in a script is in
no way a timing sensitive bug that is the
fault of the user. It is a time sensitive Hercules
bug. The fact that the bug appears in the field
rather than in a nice dev lab setting of the
developer does not change that one iota.

Where does it say that "quit" *WILL* actually succeed within the time
YOU define and under what time it will succeed.. or *ANY* of the
commands you issue for that matter ?

Wow, this is a really good excuse for me to use
next time someone reports one of my own
applications hanging. I can tell them to just be
patient, it's not documented as finishing on
THEIR hardware any time this century.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
Wow, this is a really good excuse for me to use
next time someone reports one of my own
applications hanging. I can tell them to just be
patient, it's not documented as finishing on
THEIR hardware any time this century.

Wow ! You *actually* have people using your "applications" ?

--Ivan

['M. Khalid Khan' [e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
Wow, this is a really good excuse for me to use
next time someone reports one of my own
applications hanging. I can tell them to just be
patient, it's not documented as finishing on
THEIR hardware any time this century.

Wow ! You *actually* have people using your "applications" ?
--Ivan

Not sure if people are using any of Paul's software but you must give
credit where credit is due. At least he tries VERY VERY HARD to get people
to use his C compiler and never lets go a chance to extol the benefits of
PDOS for the society at large.

Khalid


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

Ivan Warren wrote:

[...]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
So....
So it's a bug somewhere ! (but not your fault)...

That sure seems to be Paul's standard modus operandi alright! :(

['Dave Wade' [e-mail] [H390-MVS]]

-----Original Message-----
Sent: 24 February 2018 17:28
Subject: Re: [H390-MVS] RE: [hercules-390] Some questions (re: dodgy
punch)

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
Here is the latest test result.

Did it come to your mind that.. eventually... your script *might* be
broken (instead of OS/MVS or hercules) ?

I thought about this long and hard and couldn't conceive of a set of Hercules commands that would cause PUNCH data to be corrupt. If you can please let me know.
I believe Hercules locks the output file so corruption you can't even get images from two devices interleaved.

The script just executes Hercules commands.
As far as I know, Hercules doesn't have a command that says "randomly trash
the punch". If you know of such a Hercules command, let me know what it is
and I'll do a grep to make sure I'm not using it.
BFN. Paul.

Dave

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
repro to eventually produce junk. Actually,
I will just try the failing iebgener first.

With this simple job:

C:\mvs380_work\cardbug>type punch.jcl
//HERC01 JOB
//PUNCH EXEC PGM=IEBGENER 06740003
//* ***************************************************************** * 06750003
//* PUNCH STAGE1 OUTPUT DECK TO PCH00D OUTPUT FILE * 06760003
//* ***************************************************************** * 06770003
//SYSPRINT DD DUMMY 06780003
//SYSIN DD DUMMY 06790003
//SYSUT1 DD DISP=SHR,DSN=SYS1.STAGE1.OUTPUT,UNIT=3350,VOL=SER=WORK01 06800003
//SYSUT2 DD SYSOUT=B,DCB=BLKSIZE=80 06810003
//* END OF SUBMITTED SYSGEN01 06820003

Post by ***@yahoo.com.au [H390-MVS]
D BUILD & ORDER HMASMTMS,HMASMTRM & ORDER
SMTM1,HMASMTM2 & ORDER HMASMTM3,HMASMTM4 & ORDER HMASMTMW,HMAS
& ORDER HMASMTL1 ICT LMOD BUILD & ORDER HMASMTL2,HMASMTL3

I will now switch to REPRO.

BFN. Paul.

[Joe Monk [e-mail] [H390-MVS]]

in place of:

//SYSUT2 DD SYSOUT=B,DCB=BLKSIZE=80 06810003

try:

//SYSUT2 DD UNIT=013,DCB=BLKSIZE=80

Joe

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
repro to eventually produce junk. Actually,
I will just try the failing iebgener first.

C:\mvs380_work\cardbug>type punch.jcl
//HERC01 JOB
//PUNCH EXEC PGM=IEBGENER 06740003
//* ***************************************************************** * 06750003
//* PUNCH STAGE1 OUTPUT DECK TO PCH00D OUTPUT FILE * 06760003
//* ***************************************************************** * 06770003
//SYSPRINT DD DUMMY 06780003
//SYSIN DD DUMMY 06790003
//SYSUT1 DD DISP=SHR,DSN=SYS1.STAGE1.OUTPUT,UNIT=3350,VOL=SER=WORK01
06800003
//SYSUT2 DD SYSOUT=B,DCB=BLKSIZE=80 06810003
//* END OF SUBMITTED SYSGEN01 06820003

Post by ***@yahoo.com.au [H390-MVS]
D BUILD & ORDER HMASMTMS,HMASMTRM & ORDER
SMTM1,HMASMTM2 & ORDER HMASMTM3,HMASMTM4 & ORDER HMASMTMW,HMAS
& ORDER HMASMTL1 ICT LMOD BUILD & ORDER HMASMTL2,HMASMTL3

I will now switch to REPRO.
BFN. Paul.

[[e-mail] [H390-MVS]]

Post by Joe Monk ***@gmail.com [H390-MVS]
//SYSUT2 DD SYSOUT=B,DCB=BLKSIZE=80 06810003
//SYSUT2 DD UNIT=013,DCB=BLKSIZE=80
Joe

- - - old note snipped - - -

Yes, but more complete DCB information may be needed
depending on the utility being used.

i.e. code RECFM=F instead of chancing to default to FA
LRECL could be specified.
DSORG and BUFNO could default unless the issue
may be due to BUFNO=5

Something like:
//SYSUT2 DD UNIT=00D,
// DCB=(RECFM=F,LRECL=80,BLKSIZE=80,BUFNO=5)

So SYS1.PROCLIB(PUNCH) could be:

//PUNCH EXEC PGM=IEBGENER
//SYSPRINT DD DUMMY
//SYSIN DD DUMMY
//SYSUT1 DD DISP=SHR,DSN=SYS1.STAGE1.OUTPUT
//SYSUT2 DD UNIT=00D,
// DCB=(RECFM=F,LRECL=80,BLKSIZE=80,BUFNO=5)

If no corruption, the try:
//SYSUT2 DD SYSOUT=B,
// DCB=(RECFM=F,LRECL=80,BLKSIZE=80)

No reason to IPL between tests.
Script could be something like:

/$ppun1
/$ps1-9999
FOR 100 times, DO
devinit 00d pch/pch00d.%date%.%time%.txt
pause 1
/s punch
pause 2 seconds
ENDDO
devinit 00d pch/nothing.more.txt
/$ps1-9999

Exact syntax would depend on environment and
scripting language.

I hope all will approve of you using a script?

Listing the files would show byte count difference
if any.

cd pch
dir pch*
or
ls -l pch*

After we can recreate, we should consider doing
gigantic Hercules and MVS I/O traces.

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

somitcw wrote:

[...]

Post by ***@yahoo.com [H390-MVS]
After we can recreate, we should consider doing
gigantic Hercules and MVS I/O traces.

Yep! Step 1: create the simplest possible test that reliably reproduces the problem. Step 2: Run that test with either MVS I/O tracing enabled and/or with Hercules I/O (CCW) tracing enabled.

But Step #1 is *KEY*. We simply *must* have a simple, straightforward test case that can reliably reproduce the problem. Doing anything else before that step is first completed is a waste of time.

['Dave Wade' [e-mail] [H390-MVS]]

Folks,

I have tried to get corrupted punch output using VM and failed.

Firstly I filled a file full of cards of 80 "1" characters, then created a couple of l EXECs that punch many copies of each resulting around 250,00 copies of the card being punched.
When I run them I get outputs of consistent size after 20 runs or so. I believe that Paul said the size of his files changed on error, if that’s the case these are not corrupt.
..
I tried some other execs that punch all of CP source. I ran this 10 times and compared the outputs. Apart from the time stamps on the header cards all 10 files were the same.
I also tried running some games jobs just to load the CPU while the punching was going on. Did not make any difference.

In the absence of other evidence, such as the bug happening on both mvs3.7 and 3.8 I am inclined to think it’s a problem in the 3.7 starter system.

Has Paul reproduced this error on MVS3.8?

Dave

-----Original Message-----
Sent: 24 February 2018 21:12
Subject: RE: [H390-MVS] RE: [hercules-390] Some questions (re: dodgy
punch)
[...]

After we can recreate, we should consider doing gigantic Hercules and
MVS I/O traces.

Yep! Step 1: create the simplest possible test that reliably reproduces the
problem. Step 2: Run that test with either MVS I/O tracing enabled and/or
with Hercules I/O (CCW) tracing enabled.
But Step #1 is *KEY*. We simply *must* have a simple, straightforward test
case that can reliably reproduce the problem. Doing anything else before
that step is first completed is a waste of time.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[[e-mail] [H390-MVS]]

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
Has Paul reproduced this error on MVS3.8?

I copied the exact data from MVS 3.7 to MVS 3.8j
and did 214 runs without error.

So what I will do next is write out a test file with
just LINE00001XYZ and see what happens when
I IEBGENER that on MVS 3.7 as that will make
spotting where garbage comes from easier,
especially in traces.

BFN. Paul.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
I will now switch to REPRO.

With this repro job:

C:\mvs380_work\cardbug>type repro.jcl
//HERC01 JOB
//IDCAMS EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//* following statement has a space on column 1
REPRO INFILE(SYSUT1) OUTFILE(SYSUT2)
//SYSUT1 DD DISP=SHR,DSN=SYS1.STAGE1.OUTPUT,UNIT=3350,VOL=SER=WORK01
//SYSUT2 DD SYSOUT=B,DCB=BLKSIZE=80
//

I got missing data on the second auto run.
I didn't run again to wait for the garbage to
come up. But I will continue to use repro
for the next test.

BFN. Paul.



C:\mvs380_work\cardbug>diff goodpch-cold313ns.txt pch013.txt
10803,10826d10802
< INCLUDE AOSC5(IRARMCNS,IRARMRMR)
< INCLUDE AOSC5(IRARMSRV)
< INCLUDE AOS00(IEASMFEX,IEATLEXT,IEAQWAIT)
< INCLUDE AOSC5(IEAVGPRR,IEAVCARR)
< INCLUDE AOSC5(IEAVGFRR)
< INCLUDE AOSC5(IEAVESPR,IEAVEQV0)
< INCLUDE AOSC5(IEAVEADV,IEAVECBV,IEAVEVRR)
< INCLUDE AOSC5(IEAVELCR,IEAVEDSR,IEAVESVR)
< INCLUDE AOSC5(IEAVEIOR,IEAVEE1R,IEAVEE2R)
< INCLUDE AOSC5(IEAVEE3R,IEAVEPCR,IEAVERER)
< INCLUDE AOSC5(IEAVEPDR,IEAVESCR,IEAVEEER)
< INCLUDE AOSC5(IEAVELKR,IEAVEIPR)
< INCLUDE AOS06(IFDOLT0A)
< INCLUDE AOSC5(IEEVDUMY)
< INCLUDE AOSC5(IEAVEUPC)
< INCLUDE AOSC5(IECVEXCP,IECVEXPR)
< INCLUDE AOSC5(IECVDERP,IECVERPL)
< INCLUDE AOSC5(IECIOSAM,IECVPST)
< INCLUDE AOSC5(IECVTCCW,IECVGENA)
< INCLUDE AOSC5(IECVITRP,IECVSMGR)
< INCLUDE AOSC5(IECIHIO,IECVDAVV)
< INCLUDE AOSC5(IECVRSTI,IECVPURG)
< INCLUDE AOSC5(IECVIRST)
< INCLUDE AOSC5(IECVOID)

C:\mvs380_work\cardbug>

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
I got missing data on the second auto run.

Then don't do "auto" runs !

--Ivan

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

[...]

Post by ***@yahoo.com [H390-MVS]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
p.s. Why did you lie to me (confuse me) with your
"No card reader" claim in your prior response? :)

I saw neither a card reader nor sliced salami.
Did you see different. How did you see different?
Perhaps one of us need glasses.
It may be best for us to stop working on the card reader
or sliced salami issue because neither a card reader issue
nor sliced salami issue has been reported or been involved.
Billions of other things that are not involved have also
not been reported. That is no lie.

Always the gentleman, aren't you somitcw? ;-)

At this point I'll just say "Never mind!".

(sigh)

:)

[[e-mail] [H390-MVS]]

Not had a HEX dump from Paul. Would be usefull.

When I run with Hercules 3.13, the garbage I get
is text. There is no point displaying the text in hex.
In addition, the card punch appears to convert all
binary data into spaces anyway.

Regardless, I have already uploaded the bad punch
and a good punch to the files area. They are small
files that you can do a hex dump of.

The files that are being produced just have LF, not
CRLF. That is the default behavior of:

0013 3525 pch013.txt ascii

On 3.13. It is also default behavior to overwrite the
existing file. And given that the new bad file is
shorter than the good file, it suggests to me that
it is creating a new file rather than updating the
old one.

BFN. Paul.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
In addition, the card punch appears to convert all
binary data into spaces anyway.

Hercules 3.07 cardpch.c has:

if (dev->ascii)
{
c = guest_to_host(c);
if (!isprint(c)) c = SPACE;
}

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Not had a HEX dump from Paul. Would be usefull.

When I run with Hercules 3.13, the garbage I get
is text. There is no point displaying the text in hex.
In addition, the card punch appears to convert all
binary data into spaces anyway.

Regardless, I have already uploaded the bad punch
and a good punch to the files area. They are small
files that you can do a hex dump of.

The files that are being produced just have LF, not
CRLF. That is the default behavior of:

0013 3525 pch013.txt ascii

On 3.13. It is also default behavior to overwrite the
existing file. And given that the new bad file is
shorter than the good file, it suggests to me that
it is creating a new file rather than updating the
old one.

BFN. Paul.

---

May I ask a question, Paul?

Does the garbage pop up on the first run of
the emulator? I mean, you start the emulator,
IPL your MVS, use the punch just once, and you have garbage
on the file?

Peppe.

[[e-mail] [H390-MVS]]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
Does the garbage pop up on the first run of
the emulator? I mean, you start the emulator,
IPL your MVS, use the punch just once, and you have garbage
on the file?

Yes, it is a single IPL, writing a single file, the
stage 2 output, to the card punch.

However, most times I do the above sequence
I don't actually have a problem.

I may have to repeat the process 26 times
before I see an error. It's an intermittent
fault, ie a bugger to debug.

BFN. Paul.

[Joe Monk [e-mail] [H390-MVS]]

Paul,

Can you try this?

At the end of the SYSGEN01.jcl job, you will find this JCL:

//IEBGENER EXEC PGM=IEBGENER,COND=(0,NE,ASMBLR)
06630003
//* ***************************************************************** *
06640003
//* IF ASMBLR RC=0000, SUBMIT CONTINUATION JOB TO INTERNAL READER. *
06650003
//* ***************************************************************** *
06660003
//SYSPRINT DD DUMMY
06670003
//SYSIN DD DUMMY
06680003
//SYSUT1 DD DATA,DLM='><'
06690003
//SYSGEN01 JOB 'PUNCH STAGE 2 DECK',
06700003
// CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
06710003
/*JOBPARM CARDS=15000
06720003
//*
06730003
//PUNCH EXEC PGM=IEBGENER
06740003
//* ***************************************************************** *
06750003
//* PUNCH STAGE1 OUTPUT DECK TO PCH00D OUTPUT FILE *
06760003
//* ***************************************************************** *
06770003
//SYSPRINT DD DUMMY
06780003
//SYSIN DD DUMMY
06790003
//SYSUT1 DD DISP=SHR,DSN=SYS1.STAGE1.OUTPUT,UNIT=3350,VOL=SER=WORK01
06800003
//SYSUT2 DD SYSOUT=B,DCB=BLKSIZE=80
06810003
//* END OF SUBMITTED SYSGEN01
06820003

Post by ***@yahoo.com.au [H390-MVS]
<

06830003
//SYSUT2 DD SYSOUT=(A,INTRDR)
06840003


As you can see, that is a self-submitting job to copy the stage1 disk
output file to the punch.

I would ask you to modify it like this:

//IEBGENER EXEC PGM=IEBGENER,COND=(0,NE,ASMBLR)
06630003
//* ***************************************************************** *
06640003
//* IF ASMBLR RC=0000, SUBMIT CONTINUATION JOB TO INTERNAL READER. *
06650003
//* ***************************************************************** *
06660003
//SYSPRINT DD DUMMY
06670003
//SYSIN DD DUMMY
06680003
//SYSUT1 DD DATA,DLM='><'
06690003
//SYSGEN01 JOB 'PUNCH STAGE 2 DECK',
06700003
// CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
06710003
/*JOBPARM CARDS=15000
06720003
//*
06730003
//PUNCH EXEC PGM=IEBGENER
06740003
//* ***************************************************************** *
06750003
//* PUNCH STAGE1 OUTPUT DECK TO PCH00D OUTPUT FILE *
06760003
//* ***************************************************************** *
06770003
//SYSPRINT DD DUMMY
06780003
//SYSIN DD DUMMY
06790003
//SYSUT1 DD DISP=SHR,DSN=SYS1.STAGE1.OUTPUT,UNIT=3350,VOL=SER=WORK01
06800003
//SYSUT2 DD SYSOUT=B,DCB=BLKSIZE=80
//*
//PRINTIT EXEC PGM=IEBGENER
06840003
//* ***************************************************************** *
06850003
//* PRINT STAGE1 FILE TO PRINTER *
06860003
//* ***************************************************************** *
06870003
//SYSPRINT DD DUMMY
06880003
//SYSIN DD DUMMY
06890003
//SYSUT1 DD DISP=SHR,DSN=SYS1.STAGE1.OUTPUT,UNIT=3350,VOL=SER=WORK01
06900003
//SYSUT2 DD SYSOUT=*
06910003
//* END OF SUBMITTED SYSGEN01
06920003

Post by ***@yahoo.com.au [H390-MVS]
<

06930003
//SYSUT2 DD SYSOUT=(A,INTRDR)
06940003

That way, we will get a hardcopy of the stage1 output deck from your
printer, so we can compare to
the punch output and see if the problem is in the input data or the punch
output.

Joe

Post by ***@yahoo.com.au [H390-MVS]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
Does the garbage pop up on the first run of
the emulator? I mean, you start the emulator,
IPL your MVS, use the punch just once, and you have garbage
on the file?

Yes, it is a single IPL, writing a single file, the
stage 2 output, to the card punch.
However, most times I do the above sequence
I don't actually have a problem.
I may have to repeat the process 26 times
before I see an error. It's an intermittent
fault, ie a bugger to debug.
BFN. Paul.

[[e-mail] [H390-MVS]]

Post by Joe Monk ***@gmail.com [H390-MVS]
That way, we will get a hardcopy of the stage1
output deck from your printer, so we can compare to
the punch output and see if the problem is in the
input data or the punch output.

Joe, I already verified that the input data was
correct some time ago by simply writing the
specified file to tape, after a garbage run.
Isn't that sufficient?

BFN. Paul.

[Joe Monk [e-mail] [H390-MVS]]

You're missing the point.

If its a timing problem, the punch and the printer will exhibit the same
symptoms....

Joe

Post by ***@yahoo.com.au [H390-MVS]

Post by Joe Monk ***@gmail.com [H390-MVS]
That way, we will get a hardcopy of the stage1
output deck from your printer, so we can compare to
the punch output and see if the problem is in the
input data or the punch output.

Joe, I already verified that the input data was
correct some time ago by simply writing the
specified file to tape, after a garbage run.
Isn't that sufficient?
BFN. Paul.

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

(partial piggyback)

Post by Joe Monk ***@gmail.com [H390-MVS]

Post by Joe Monk ***@gmail.com [H390-MVS]
That way, we will get a hardcopy of the stage1
output deck from your printer, so we can compare
to the punch output and see if the problem is in
the input data or the punch output.

Joe, I already verified that the input data was correct
some time ago by simply writing the specified file to tape,
after a garbage run. Isn't that sufficient?

Yes, that's good enough for me, Paul.

Post by Joe Monk ***@gmail.com [H390-MVS]
You're missing the point.
If it's a timing problem, the punch and the printer will exhibit
the same symptoms....

How so, Joe? I would think if it's a timing problem then it would manifest itself just as readily/easily when written to pretty much *any* device. If it was a timing problem, why would you think it would be more likely to occur on a printer device than a tape device? (or any other device?!) Please explain.

[Joe Monk [e-mail] [H390-MVS]]

Printer and punch both involve JES2 spool.

Joe

On Sat, Feb 24, 2018 at 10:26 AM, ''Fish' (David B. Trout)'

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
(partial piggyback)

Post by Joe Monk ***@gmail.com [H390-MVS]

Post by Joe Monk ***@gmail.com [H390-MVS]
That way, we will get a hardcopy of the stage1
output deck from your printer, so we can compare
to the punch output and see if the problem is in
the input data or the punch output.

Joe, I already verified that the input data was correct
some time ago by simply writing the specified file to tape,
after a garbage run. Isn't that sufficient?

Yes, that's good enough for me, Paul.

Post by Joe Monk ***@gmail.com [H390-MVS]
You're missing the point.
If it's a timing problem, the punch and the printer will exhibit
the same symptoms....

How so, Joe? I would think if it's a timing problem then it would manifest
itself just as readily/easily when written to pretty much *any* device. If
it was a timing problem, why would you think it would be more likely to
occur on a printer device than a tape device? (or any other device?!)
Please explain.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

[...]

Post by Joe Monk ***@gmail.com [H390-MVS]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]

Post by Joe Monk ***@gmail.com [H390-MVS]
You're missing the point.
If it's a timing problem, the punch and the printer will
exhibit the same symptoms....

How so, Joe? I would think if it's a timing problem then it
would manifest itself just as readily/easily when written to
pretty much *any* device.. If it was a timing problem, why
would you think it would be more likely to occur on a printer
device than a tape device? (or any other device?!) Please
explain.

Printer and punch both involve JES2 spool.

(Doh!) Of course. THANK YOU. I wasn't thinking.

So okay then, your suggestion to insert the printer step is a good one, and Paul's test of writing the same data to tape isn't as good. It's good in that it obviously does READ from the spool, but your proposed test is better because it both *reads* and WRITES to the spool (which should have a much better chance of triggering an MVS JES2 spooler timing bug than just reading from the spool would).

Thank you Joe. I needed that. :)

[[e-mail] [H390-MVS]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
So okay then, your suggestion to insert the printer
step is a good one, and Paul's test of writing the
same data to tape isn't as good. It's good in that
it obviously does READ from the spool,

Writing to tape goes from disk dataset to tape
dataset, not involving the spool.

That is the best way of proving the data itself
is fine.

Anyway, I have drained the punch and am now
writing directly from disk to punch, bypassing
JES2 to see if the problem comes up still.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
Joe, I already verified that the input data was
correct some time ago by simply writing the
specified file to tape, after a garbage run.
Isn't that sufficient?
BFN. Paul.

You verified *what* ?
What is a "garbage" run ?
What is sufficient ?

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
Joe, I already verified that the input data was
correct some time ago by simply writing the
specified file to tape, after a garbage run.
Isn't that sufficient?

You verified *what* ?
What is a "garbage" run ?
What is sufficient ?

A garbage run is a run that produces garbage,
and there is a question of whether the data on
the disk itself is actually good or not.

But I verified that the data on the disk is good
by writing to tape and getting good results.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
Joe, I already verified that the input data was
correct some time ago by simply writing the
specified file to tape, after a garbage run.
Isn't that sufficient?

You verified *what* ?
What is a "garbage" run ?
What is sufficient ?

A garbage run is a run that produces garbage,
and there is a question of whether the data on
the disk itself is actually good or not.
But I verified that the data on the disk is good
by writing to tape and getting good results.

You run WHAT ? what is a "run" ?

You claim something (a bug) but provide no proof relating to S/370 I/O,
architectural or guest operating system issue *except* that you are
scripting some powerup/commands/powerdown.

If you claim there is a bug, please provide an actual, non OS specific,
non time dependent specific test case to prove there is an actual
"hercules" bug !

--Ivan

[Ivan Warren [e-mail] [H390-MVS]]

That is simply not how production bugs are solved.

Are you claiming your project is intended for "production" ?

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

That is simply not how production bugs are solved.

Are you claiming your project is intended for "production" ?

It's a problem that is found in the field, instead of
a nice clean bug found in the lab during development.
You can call it "field bug" instead of "production bug"
if you like. If you don't wish to fix field bugs, that's fine.
If you don't want to fix lab bugs, that's also fine.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
It's a problem that is found in the field, instead of
a nice clean bug found in the lab during development.
You can call it "field bug" instead of "production bug"
if you like. If you don't wish to fix field bugs, that's fine.
If you don't want to fix lab bugs, that's also fine.

That is not a "nice clean bug" - this is a problem found in a very
convoluted undocumented process in which YOU claim that *one* component
is faulty.

To prove it is an hercules bug you must have a procedure that proves
that the problem can be reproduced *outside* your whole procedure which
includes many other components.

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
It's a problem that is found in the field, instead of
a nice clean bug found in the lab during development.
You can call it "field bug" instead of "production bug"
if you like. If you don't wish to fix field bugs, that's fine.
If you don't want to fix lab bugs, that's also fine.

That is not a "nice clean bug" - this is a problem found in a very
convoluted undocumented process in which YOU claim that *one* component
is faulty.

No, I just *guessed* that it was that one component.
It could be a Windows bug for all I know.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
To prove it is an hercules bug you must have a procedure that proves
that the problem can be reproduced *outside* your whole procedure which
includes many other components.

Crikey. I'm not disputing that! Yes, I absolutely
100% agree that I have in no way proven that
it is a Hercules bug.

That doesn't alter the fact that it's a real world
problem, involving Hercules, where normal
production procedures are required to debug
a production problem. You have multiple
vendors here, and you have no way of knowing
which one has the faulty code.

That's actually one of the benefits of buying
pure IBM. Hardware and software. If your
system isn't working you have a one stop
shop to get your problem solved. Otherwise
different vendors try to hive it off onto some
other vendor, with every single vendor in
the loop swearing blind that it couldn't
possibly be their software at fault because
of xyz reason. And all the developers
demanding a dev testcase before they will even
consider it to be a problem with their product.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
It's a problem that is found in the field, instead of
a nice clean bug found in the lab during development.
You can call it "field bug" instead of "production bug"
if you like. If you don't wish to fix field bugs, that's fine.
If you don't want to fix lab bugs, that's also fine.

That is not a "nice clean bug" - this is a problem found in a very
convoluted undocumented process in which YOU claim that *one* component
is faulty.

No, I just *guessed* that it was that one component.
It could be a Windows bug for all I know.

Did you call Microsoft support yet ?

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
To prove it is an hercules bug you must have a procedure that proves
that the problem can be reproduced *outside* your whole procedure which
includes many other components.

Crikey. I'm not disputing that! Yes, I absolutely
100% agree that I have in no way proven that
it is a Hercules bug.
That doesn't alter the fact that it's a real world
problem, involving Hercules, where normal
production procedures are required to debug
a production problem. You have multiple
vendors here, and you have no way of knowing
which one has the faulty code.

It's not a real world problem... It's a "Paul convoluted construct
doesn't work as he think it should project" problem..

Post by ***@yahoo.com.au [H390-MVS]
That's actually one of the benefits of buying
pure IBM. Hardware and software. If your
system isn't working you have a one stop
shop to get your problem solved. Otherwise
different vendors try to hive it off onto some
other vendor, with every single vendor in
the loop swearing blind that it couldn't
possibly be their software at fault because
of xyz reason. And all the developers
demanding a dev testcase before they will even
consider it to be a problem with their product.

I can guarantee - If you went to IBM - even with supported hardware and
software claiming it's their fault because YOUR program doesn't work as
expected you'd get rebuffed right away !

You *ALWAYS* have to provide a test case which isolates the issue and
doesn't involve your own development and/or your interpretation of
someone else's documentation.

Believe me, I've opened a few APARs back then...

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
No, I just *guessed* that it was that one component.
It could be a Windows bug for all I know.

Did you call Microsoft support yet ?

No, because they will blame Hercules/MVS,
if they even cared about fixing bugs at all.
From my point of view, Windows is unsupported
too.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
It's not a real world problem... It's a "Paul convoluted construct
doesn't work as he think it should project" problem..

If you don't share my vision that random junk
written to a punch randomly is something that
is universally "doesn't work as it should", then
I guess we have nothing further to discuss.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
That's actually one of the benefits of buying
pure IBM. Hardware and software. If your
system isn't working you have a one stop
shop to get your problem solved. Otherwise
different vendors try to hive it off onto some
other vendor, with every single vendor in
the loop swearing blind that it couldn't
possibly be their software at fault because
of xyz reason. And all the developers
demanding a dev testcase before they will even
consider it to be a problem with their product.

I can guarantee - If you went to IBM - even with supported hardware and
software claiming it's their fault because YOUR program doesn't work as
expected you'd get rebuffed right away !

No way. IBM are professionals. They're not
egg-heads on the internet.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
You *ALWAYS* have to provide a test case which isolates the issue and
doesn't involve your own development and/or your interpretation of
someone else's documentation.

This *is* the test case. I run an IEBGENER
(IBM software), running under an IBM
operating system. It's their problem unless
I'm using non-IBM hardware.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
Believe me, I've opened a few APARs back then...

Believe me, I've opened a few too, and IBM
are normally very professional. They don't
ask me to fix the software myself. They fully
support their software themselves.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
Believe me, I've opened a few too, and IBM
are normally very professional. They don't
ask me to fix the software myself. They fully
support their software themselves.

They are usually very happy to debug your code - for a price !

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
Believe me, I've opened a few too, and IBM
are normally very professional. They don't
ask me to fix the software myself. They fully
support their software themselves.

They are usually very happy to debug your code - for a price !

No. They debug THEIR code, for no extra charge
than the normal maintenance fee.

In this case the software that is being run has
no maintenance fee, or is out of support
altogether, and in either case is a mixture of
vendors for hardware and software which
makes it real easy for both sides to blame
the other.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
Believe me, I've opened a few too, and IBM
are normally very professional. They don't
ask me to fix the software myself. They fully
support their software themselves.

They are usually very happy to debug your code - for a price !

No. They debug THEIR code, for no extra charge
than the normal maintenance fee.

Because of course it's NEVER your fault !

our scripts are flawless .. ALWAYS !

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
Believe me, I've opened a few too, and IBM
are normally very professional. They don't
ask me to fix the software myself. They fully
support their software themselves.

They are usually very happy to debug your code - for a price !

No. They debug THEIR code, for no extra charge
than the normal maintenance fee.

Because of course it's NEVER your fault !
our scripts are flawless .. ALWAYS !

You have moved this conversation into
some sort of existential question which is
fascinating in its own right.

ie how do we know when a bug exists. Or,
when is the appropriate time for a vendor
to get involved in a bug. You are challenging
something fundamental.

If I submit an IEBGENER job, and it fails
to reproduce the input data to the output
file (or output device), and it does this in
a non-deterministic manner, ie the failure
happens randomly, then yes, my first
thought is not "I'm exercising the machine
too much, maybe I should copy the file
manually or something", it is "there is a
bug somewhere". The reported effects,
be it a system hang (like "quit") or
garbage being printed to the output, is
something that I consider to be beyond
the remit of the user to produce. ie
software is simply not supposed to open
up a path to the user to produce garbage
output or to send the application into a
loop. The application is meant to guard
against such things and behave in a
predictable manner, regardless of the
input.

BFN. Paul.


P.S. to somitcw - count is now 176.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
You have moved this conversation into
some sort of existential question which is
fascinating in its own right.
ie how do we know when a bug exists. Or,
when is the appropriate time for a vendor
to get involved in a bug. You are challenging
something fundamental.

Of course.. The question always lies as to - WHERE is the bug ?

You *always* claim it is not your fault but *NEVER* give a test case
that doesn't involve your own code.

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
You have moved this conversation into
some sort of existential question which is
fascinating in its own right.
ie how do we know when a bug exists. Or,
when is the appropriate time for a vendor
to get involved in a bug. You are challenging
something fundamental.

Of course.. The question always lies as to - WHERE is the bug ?
You *always* claim it is not your fault but *NEVER* give a test case

Never? What about the situations where I point
out the line of code that is wrong?

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
that doesn't involve your own code.

That's because it's a FIELD BUG not a DEV BUG.

If you are interested in producing a quality
product, you have to deal with field bugs
instead of demanding that end users
reproduce the problem in a dev setting.

If you are not interested in producing a
quality product, that's fine too. Just be
honest about it.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
That's because it's a FIELD BUG not a DEV BUG.

What friggin field ?

It's you - and your project  - that you are currently developping for
your own need in your own little lab....I wouldn't call that a "field" !

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
That's because it's a FIELD BUG not a DEV BUG.

What friggin field ?

When you release software, you find that there
are bugs that occur on other people's systems
that don't occur on your own dev system.

The normal thing you do when a bug that wasn't
found in dev is found on someone else's system
is to debug it.

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
It's you - and your project - that you are currently developping for
your own need in your own little lab....I wouldn't call that a "field" !

That's exactly the point. I'm an end user of Hercules,
and I am using it to run jobs under MVS 3.7. It is
thus doing a real world exercise that has invoked
a bug somewhere (Windows/Hercules/MVS 3.7/hardware).

This is all perfectly normal in the software development
life cycle. Some bugs occur outside of the developer's
lab. The normal thing to do is to try to debug the
software, at least to the point of proving that it is MVS
or Windows rather than Hercules, rather than blaming
the messenger for entering diabolical commands,
including but not limited to "quit".

MVS appears to be a professional environment
where the software developers ask for traces to
be activated (tracing their own code, not just
CCWs), rather than delegating it to the "too hard"
basket.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]
When you release software, you find that there
are bugs that occur on other people's systems
that don't occur on your own dev system.
The normal thing you do when a bug that wasn't
found in dev is found on someone else's system
is to debug it.

Then go ahead.. debug your scripts !

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
It's you - and your project - that you are currently developping for
your own need in your own little lab....I wouldn't call that a "field" !

That's exactly the point. I'm an end user of Hercules,
and I am using it to run jobs under MVS 3.7. It is
thus doing a real world exercise that has invoked
a bug somewhere (Windows/Hercules/MVS 3.7/hardware).
This is all perfectly normal in the software development
life cycle. Some bugs occur outside of the developer's
lab. The normal thing to do is to try to debug the
software, at least to the point of proving that it is MVS
or Windows rather than Hercules, rather than blaming
the messenger for entering diabolical commands,
including but not limited to "quit".
MVS appears to be a professional environment
where the software developers ask for traces to
be activated (tracing their own code, not just
CCWs), rather than delegating it to the "too hard"
basket.
BFN. Paul.

When people develop software and the first thing they blame is the
compiler or the library, the first thing that is asked is something that
*PROVES* the problem is with the compiler or the library. A test case
that independently shows and demonstrates the bug is in the
compiler/library/environment - and NOT in the application being
developped in itself.

YOU are the application developper here, and it is YOUR lab !

--Ivan

[[e-mail] [H390-MVS]]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
When people develop software and the first thing they blame is the
compiler or the library, the first thing that is asked is something that
*PROVES* the problem is with the compiler or the library. A test case
that independently shows and demonstrates the bug is in the
compiler/library/environment - and NOT in the application being
developped in itself.
YOU are the application developper here, and it is YOUR lab !

No, the application is MVS 3.7. If MVS 3.7 was
supported by IBM I could indeed go to IBM and
say that I trust my hardware so the problem is
more likely to be in JES2.

IBM may well turn around and blame the OEM
hardware vendor.

Anyway, that's why I posted in H390-MVS not
hercules-390 as I don't know which bit of
software, including Windows is at fault. I just
documented an issue. I didn't expect anyone
to be interested enough to even take over from
IBM and try to debug MVS.

The quit hang bug I documented in hercules-390
as MVS should not have the power to hang
Hercules like that, even though MVS is what I
was using as the testcase.

BFN. Paul.

[Joe Monk [e-mail] [H390-MVS]]

"I could indeed go to IBM and
say that I trust my hardware so the problem is
more likely to be in JES2."

And IBM would laugh at you and say put it on real iron. If it doesn't work
then call us back.

Microsoft has exactly the same policy with VMWARE.

Joe

Post by ***@yahoo.com.au [H390-MVS]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
When people develop software and the first thing they blame is the
compiler or the library, the first thing that is asked is something that
*PROVES* the problem is with the compiler or the library. A test case
that independently shows and demonstrates the bug is in the
compiler/library/environment - and NOT in the application being
developped in itself.
YOU are the application developper here, and it is YOUR lab !

No, the application is MVS 3.7. If MVS 3.7 was
supported by IBM I could indeed go to IBM and
say that I trust my hardware so the problem is
more likely to be in JES2.
IBM may well turn around and blame the OEM
hardware vendor.
Anyway, that's why I posted in H390-MVS not
hercules-390 as I don't know which bit of
software, including Windows is at fault. I just
documented an issue. I didn't expect anyone
to be interested enough to even take over from
IBM and try to debug MVS.
The quit hang bug I documented in hercules-390
as MVS should not have the power to hang
Hercules like that, even though MVS is what I
was using as the testcase.
BFN. Paul.

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

Ivan Warren wrote:

[...]

Post by Ivan Warren ***@vmfacility.fr [H390-MVS]
That is not a "nice clean bug" - this is a problem found
in a very convoluted undocumented process in which YOU claim
that *one* component is faulty.
To prove it is an hercules bug you must have a procedure that
proves that the problem can be reproduced *outside* your whole
procedure which includes many other components.

Precisely! That's what I've been trying to get through his thick skull: until we have a simple reproducible test case -- and by simple I mean a simple start herc, ipl guest, enter command to submit job that produces punch output, shutdown guest -- then we are wasting our time.

Having a test case that DOESN'T use his automation scripts but DOES reproduce the problem IS KEY!! It is something we simply MUST HAVE.

Without it we're all just pissing in the wind.

[[e-mail] [H390-MVS]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
Having a test case that DOESN'T use his
automation scripts but DOES reproduce the
problem IS KEY!! It is something we simply MUST HAVE.

If having a nice neat dev testcase is something
that you MUST HAVE, then all that does is
prove that Windows is a joke environment
for debugging software, unlike MVS where you
can activate traces on the code itself to find
out where the problem is occurring. The
developers can match up their distributed
load module with their compiler listings.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
Without it we're all just pissing in the wind.

Yes, Windows apparently sucks when it comes
to field bugs.

BFN. Paul.

[Ivan Warren [e-mail] [H390-MVS]]

Le 2/24/2018 à 10:03 PM, ''Fish' (David B. Trout)'

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [H390-MVS]
Having a test case that DOESN'T use his automation scripts but DOES
reproduce the problem IS KEY!! It is something we simply MUST HAVE.
Without it we're all just pissing in the wind.

Unfortunately, I think you are right....

I'll just shut up now (and as you say - I have to stop feeding the troll)....

--Ivan

['\'Fish\' (David B. Trout)' [e-mail] [H390-MVS]]

Joe Monk wrote:

[...]

Post by Joe Monk ***@gmail.com [H390-MVS]
//PRINTIT EXEC PGM=IEBGENER
//* ***************************************************************** *
//* PRINT STAGE1 FILE TO PRINTER *
//* ***************************************************************** *
//SYSPRINT DD DUMMY
//SYSIN DD DUMMY
//SYSUT1 DD DISP=SHR,DSN=SYS1.STAGE1.OUTPUT,UNIT=3350,VOL=SER=WORK01
//SYSUT2 DD SYSOUT=*
//* END OF SUBMITTED SYSGEN01

<

That way, we will get a hardcopy of the stage1 output deck
from your printer, so we can compare to the punch output
and see if the problem is in the input data or the punch output.

That's a darn good idea!

['Dave Wade' [e-mail] [H390-MVS]]

-----Original Message-----
Sent: 24 February 2018 12:38
Subject: Re: [H390-MVS] RE: [hercules-390] Some questions (re: dodgy
punch)

Does the garbage pop up on the first run of the emulator? I mean, you
start the emulator, IPL your MVS, use the punch just once, and you
have garbage on the file?

Yes, it is a single IPL, writing a single file, the stage 2 output, to the card
punch.
However, most times I do the above sequence I don't actually have a
problem.
I may have to repeat the process 26 times before I see an error. It's an
intermittent fault, ie a bugger to debug.

And after thinking about this it could still be an MVS bug. Are we still in 3.7 when it goes wrong. If so it could well be an MVS bug.
IBM probably wouldn't fix intermittent faults in starter systems. They are specifically distributed to provide the minimum features needed to get a system up and running.

If it’s a bug that doesn't happen on slow hardware IBM would never see it..

BFN. Paul.

Dave

[[e-mail] [H390-MVS]]

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
And after thinking about this it could still be an
MVS bug. Are we still in 3.7 when it goes wrong.
If so it could well be an MVS bug.

Yes, it is still in MVS 3.7.

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
IBM probably wouldn't fix intermittent faults in
starter systems. They are specifically distributed
to provide the minimum features needed to get
a system up and running.

Ok, that's a good point. They wouldn't want
to cut new starter tapes. Although MVS 3.7
would have been based on earlier software
which I would hope would be robust.

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
If it’s a bug that doesn't happen on slow
hardware IBM would never see it..

Ok. True.

BFN. Paul.

['Dave Wade' [e-mail] [H390-MVS]]

-----Original Message-----
Sent: 24 February 2018 18:16
Subject: RE: [H390-MVS] RE: [hercules-390] Some questions (re: dodgy
punch)

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
And after thinking about this it could still be an MVS bug. Are we
still in 3.7 when it goes wrong.
If so it could well be an MVS bug.

Yes, it is still in MVS 3.7.

And was the simple job you you ran also on 3.7? Is so can we run the same job on a 3.8j MVS ?

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
IBM probably wouldn't fix intermittent faults in starter systems. They
are specifically distributed to provide the minimum features needed to
get a system up and running.

Ok, that's a good point. They wouldn't want to cut new starter tapes.
Although MVS 3.7 would have been based on earlier software which I would
hope would be robust.

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
If it’s a bug that doesn't happen on slow hardware IBM would never see it..

Ok. True.
BFN. Paul.

Dave

Note:- That whilst Sherlock Holmes may have been fictional, it has been my experience that when you rule out the impossible, which IMHO is a script that can generate garbage, then what you are left with, i.e. Hercules and MVS must be the cause.
Whilst both are robust and well tested they undoubtable contain bugs. The last failure on NATS, the UK Air Traffic Control System in 2014 was caused by a table overflow in code that was over 20 years old...

https://www.theregister.co.uk/2014/12/12/iregi_confirms_it_was_dodgy_flight_server_that_took_down_uk_air_traffic_control/

[[e-mail] [H390-MVS]]

Post by 'Dave Wade' ***@gmail.com [H390-MVS]

Post by 'Dave Wade' ***@gmail.com [H390-MVS]

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
And after thinking about this it could still be an MVS bug. Are we
still in 3.7 when it goes wrong.

If so it could well be an MVS bug.
Yes, it is still in MVS 3.7.

And was the simple job you you ran also on 3.7?

Which simple job? The iebgener and the repro
were both run on MVS 3.7.

However, some time ago I also wrote a simple
C program to generate lots of lines, and I used
that to test the MVS 3.8j punch and I did not
experience a problem.

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
Is so can we run the same job on a 3.8j MVS ?

Yes, now that the problem shows up with a
simple iebgener/repro I can transfer the file
to my normal MVS 3.8j-like system and see
if that exact data can be punched a lot of
times without error.

Note that I'm still running Joe's direct to
013 test, and so far I have done 60 runs
without triggering a fault.

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
Note:- That whilst Sherlock Holmes may have
been fictional, it has been my experience that
when you rule out the impossible, which IMHO
is a script that can generate garbage,

I'm loathe to call anything "impossible" :-) but
if a script can generate garbage then I would
expect that to be classified as a bug. Script
processing can have wild pointers in it too.

Post by 'Dave Wade' ***@gmail.com [H390-MVS]
then what you are left with, i.e. Hercules and
MVS must be the cause.
Whilst both are robust and well tested they
undoubtable contain bugs. The last failure
on NATS, the UK Air Traffic Control System
in 2014 was caused by a table overflow in
code that was over 20 years old...

Yeah, exactly right.

Note that even though those are the elephants
in the room, it's still theoretically possible to be
all sorts of other things - hardware error that
someone suggested, Windows, any authorized
program running on my Windows system.

BFN. Paul.

[[e-mail] [H390-MVS]]

- - - In H390-***@yahoogroups.com, <***@...> wrote:
- - - beginning snipped - - -

Post by ***@yahoo.com.au [H390-MVS]
Note that I'm still running Joe's direct to
013 test, and so far I have done 60 runs
without triggering a fault.

MVS 3.8j QSAM defaults to 2 buffers and
MVS 3.8j IEBGENER is hardcoded at 2 buffers.
JES2 is probably chaining more records.
My poor memory say 5 record but an I/O trace
or checking JES2 source should say.

If you switch back to the SYSOUT=B and add back
the JES2 commands of one $tpun1,s=n with many
$ppun1 and $spun1 does the issue return?

Note: I'm starting to suspect a JES2 4K SPOOL
block not being read, as in dropped, because the
missing data is more than 2 to five records.

Is it always about 4K bytes being dropped.

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

- - - beginning snipped - - -

Post by ***@yahoo.com.au [H390-MVS]
Note that I'm still running Joe's direct to
013 test, and so far I have done 60 runs
without triggering a fault.

MVS 3.8j QSAM defaults to 2 buffers and
MVS 3.8j IEBGENER is hardcoded at 2 buffers.
JES2 is probably chaining more records.
My poor memory say 5 record but an I/O trace
or checking JES2 source should say.

If you switch back to the SYSOUT=B and add back
the JES2 commands of one $tpun1,s=n with many
$ppun1 and $spun1 does the issue return?

Note: I'm starting to suspect a JES2 4K SPOOL
block not being read, as in dropped, because the
missing data is more than 2 to five records.

Is it always about 4K bytes being dropped.

---

Mmm ... Paul did you even tried to "reformat"
your JES2 MVS3.7 JES2 spool space?

I mean redone

/r 0,format,noreq

at JES2 4.0 prompt, after IPL?

Peppe.

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by ***@yahoo.com [H390-MVS]
- - - beginning snipped - - -

Post by ***@yahoo.com.au [H390-MVS]
Note that I'm still running Joe's direct to
013 test, and so far I have done 60 runs
without triggering a fault.

MVS 3.8j QSAM defaults to 2 buffers and
MVS 3.8j IEBGENER is hardcoded at 2 buffers.
JES2 is probably chaining more records.
My poor memory say 5 record but an I/O trace
or checking JES2 source should say.
If you switch back to the SYSOUT=B and add back
the JES2 commands of one $tpun1,s=n with many
$ppun1 and $spun1 does the issue return?
Note: I'm starting to suspect a JES2 4K SPOOL
block not being read, as in dropped, because the
missing data is more than 2 to five records.
Is it always about 4K bytes being dropped.
---
Mmm ... Paul did you even tried to "reformat"
your JES2 MVS3.7 JES2 spool space?
I mean redone
/r 0,format,noreq
at JES2 4.0 prompt, after IPL?
Peppe.

If I remember (memory) one of your posts,
you had a "JES2 catastrophic error", didn't you?

Peppe.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com [H390-MVS]
If you switch back to the SYSOUT=B and add back
the JES2 commands of one $tpun1,s=n with many
$ppun1 and $spun1 does the issue return?

How many $ppun1/spun1 would you like me to
add and for what purpose and where? How many
runs directly to device 013 (that Joe suggested)
would you like me to complete first?

Post by ***@yahoo.com [H390-MVS]
Note: I'm starting to suspect a JES2 4K SPOOL
block not being read, as in dropped, because the
missing data is more than 2 to five records.
Is it always about 4K bytes being dropped.

No, see below for a full diff of one run. The first
block of deleted data is 2000 bytes, and the
next block is changed rather than deleted,
and is 1360 bytes replaced with another 1360
bytes. Those calculations are for F80 records.

BFN. Paul.



4986,5010d4985
< INCLUDE AOSU0(IDCCDRS)
< NAME IDCCDRS(R)
< INCLUDE AOSU0(IDCRS01)
< INCLUDE AOSU0(IDCRS02)
< INCLUDE AOSU0(IDCRS03)
< INCLUDE AOSU0(IDCRS04)
< INCLUDE AOSU0(IDCRS05)
< INCLUDE AOSU0(IDCRS06)
< INCLUDE AOSU0(IDCRS07)
< ENTRY IDCRS01
< NAME IDCRS01(R)
< INCLUDE AOSU0(IDCTSRS0)
< NAME IDCTSRS0(R)
< /*
< //SG11 EXEC LINKS,
< // PARM='NCAL,LIST,XREF,REUS,LET',
< // UNIT='3350',SER=MVSRES,N=SYS1,NAME=LINKLIB,P1='(',
< // MOD=IEHDASDR,P2=')',OBJ=OBJPDS02,CLASS=A
< //AOSU0 DD DISP=SHR,VOLUME=(,RETAIN),DSNAME=SYS1.AOSU0
< //SYSLIN DD *
< INCLUDE AOSU0(IEHDASDR)
< SETCODE AC(1)
< NAME IEHDASDR(R)
< INCLUDE AOSU0(IEHDASDS,IEHDCONS)
< ENTRY IEHDASDS
5080,5096c5055,5071
< NAME IEBGENER(R)
< INCLUDE AOSU0(IEBCROOT,IEBCOMPM,IEBCULET)
< INCLUDE AOSU0(IEBCCS02,IEBCANAL)
< INCLUDE AOSU0(IEBCMAIN,IEBCQSAM)
< ENTRY COMPARE
< NAME IEBCOMPR(R)
< INCLUDE AOSU0(IEBUPDTE,IEBUPLOG,IEBUPDT2,IEBUPXIT)
< INCLUDE AOSU0(IEBUPNIT)
< INCLUDE AOSU0(IEBASCAN,IEBBSCAN)
< ENTRY IEBUPDTE
< NAME IEBUPDTE(R)
< INCLUDE AOSU0(IEBDSCPY,IEBVMS)
< INCLUDE AOSU0(IEBDV1,IEBLDUL)
< INCLUDE AOSU0(IEBSCN)
< INCLUDE AOSU0(IEBVCT)
< INCLUDE AOSU0(IEBIOE)
< INCLUDE AOSU0(IEBRSAM,IEBCNVT,IEBDRD)
---

Post by ***@yahoo.com [H390-MVS]
SU0(IEHMVESI) & NAME
IEHMVESI(R) & INCLUDE AOSU0(IEHMVESH) & NAME
IEHMVESH(R) & INCLUDE AOSU0(IEHMVE
& NAME IEHMVESO(R) & INCLUDE A
0(IEHMVESP) & N
IEHMVESP(R) & I
UDE AOSU0(IEHMVESC) & NAME IEHMVESC(R) & INCLUD
OSU0(IEHMVESK) & NAME
IEHMVESK(R) & INCLUDE AOSU0(IEHMVESR
& NAME IEH
SR(R) & INCLUDE AOSU0(
MVESJ) & NAME IEHMVESJ(R)
&/* &//SG15 EXEC LINKS,
&// PARM='NCAL,LIST,X
,REUS', &// UNIT='
0',SER=MVSRES,N=SYS1,NAM
INKLIB,P1='(', &// MOD=IEHMVXSF,P2='

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
If you switch back to the SYSOUT=B and add back
the JES2 commands of one $tpun1,s=n with many
$ppun1 and $spun1 does the issue return?

How many $ppun1/spun1 would you like me to
add and for what purpose and where?

SYS1.PROCLIB(PUNCH) could be:

//PUNCH EXEC PGM=IEBGENER
//SYSPRINT DD DUMMY
//SYSIN DD DUMMY
//SYSUT1 DD DISP=SHR,DSN=SYS1.STAGE1.OUTPUT
//SYSUT2 DD SYSOUT=B,
// DCB=(RECFM=F,LRECL=80,BLKSIZE=80)


Translate to your scripting language:

/$ppun1
/$ps1-9999
pause 1 second
FOR 100 times, DO
devinit 00d pch/pch00d.%date%.%time%.txt
pause 1 second
/$spun1
/s punch
pause 2 seconds
/$ppun1
pause 1 second
ENDDO
/$ppun1
devinit 00d pch/nothing.more.txt
/$ps1-9999

should run in less than 2 minutes with about
1.5 million records total.

Post by ***@yahoo.com.au [H390-MVS]
How many runs directly to device 013 (that Joe suggested)
would you like me to complete first?

I believe that that horse is dead.
You got a JES2 error on the second try earlier,
you have enough runs trying to bypass JES2
with no errors.

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
Note: I'm starting to suspect a JES2 4K SPOOL
block not being read, as in dropped, because the
missing data is more than 2 to five records.
Is it always about 4K bytes being dropped.

No, see below for a full diff of one run. The first
block of deleted data is 2000 bytes, and the
next block is changed rather than deleted,
and is 1360 bytes replaced with another 1360
bytes. Those calculations are for F80 records.
BFN. Paul.

Your missing data looks larger than the punch
having 2 to 5 records chained together being
lost or overlaid. Of course the trace could show
JES2 surprising us.

Just guessing but you may have TRUNC set for
that JES2 output CLASS so data is stored on
SPOOL without trailing spaces?
1360 and 2000 bytes could hold 4K bytes of
truncated cards?
With NOTRUNC plus JES2 overhead could
cause it to go the other way.

Another possibility is a SPOOL block could be
only partially overlaid on disk or in memory.

We will see if we can get the error with a
SPOOL volume trace and punch device I/O
trace running.


4986,5010d4985
< INCLUDE AOSU0(IDCCDRS)
< NAME IDCCDRS(R)
< INCLUDE AOSU0(IDCRS01)
< INCLUDE AOSU0(IDCRS02)
< INCLUDE AOSU0(IDCRS03)
< INCLUDE AOSU0(IDCRS04)
< INCLUDE AOSU0(IDCRS05)
< INCLUDE AOSU0(IDCRS06)
< INCLUDE AOSU0(IDCRS07)
< ENTRY IDCRS01
< NAME IDCRS01(R)
< INCLUDE AOSU0(IDCTSRS0)
< NAME IDCTSRS0(R)
< /*
< //SG11 EXEC LINKS,
< // PARM='NCAL,LIST,XREF,REUS,LET',
< // UNIT='3350',SER=MVSRES,N=SYS1,NAME=LINKLIB,P1='(',
< // MOD=IEHDASDR,P2=')',OBJ=OBJPDS02,CLASS=A
< //AOSU0 DD DISP=SHR,VOLUME=(,RETAIN),DSNAME=SYS1.AOSU0
< //SYSLIN DD *
< INCLUDE AOSU0(IEHDASDR)
< SETCODE AC(1)
< NAME IEHDASDR(R)
< INCLUDE AOSU0(IEHDASDS,IEHDCONS)
< ENTRY IEHDASDS

5080,5096c5055,5071
< NAME IEBGENER(R)
< INCLUDE AOSU0(IEBCROOT,IEBCOMPM,IEBCULET)
< INCLUDE AOSU0(IEBCCS02,IEBCANAL)
< INCLUDE AOSU0(IEBCMAIN,IEBCQSAM)
< ENTRY COMPARE
< NAME IEBCOMPR(R)
< INCLUDE AOSU0(IEBUPDTE,IEBUPLOG,IEBUPDT2,IEBUPXIT)
< INCLUDE AOSU0(IEBUPNIT)
< INCLUDE AOSU0(IEBASCAN,IEBBSCAN)
< ENTRY IEBUPDTE
< NAME IEBUPDTE(R)
< INCLUDE AOSU0(IEBDSCPY,IEBVMS)
< INCLUDE AOSU0(IEBDV1,IEBLDUL)
< INCLUDE AOSU0(IEBSCN)
< INCLUDE AOSU0(IEBVCT)
< INCLUDE AOSU0(IEBIOE)
< INCLUDE AOSU0(IEBRSAM,IEBCNVT,IEBDRD)
---

Post by ***@yahoo.com.au [H390-MVS]
SU0(IEHMVESI) & NAME
IEHMVESI(R) & INCLUDE AOSU0(IEHMVESH) & NAME
IEHMVESH(R) & INCLUDE AOSU0(IEHMVE
& NAME IEHMVESO(R) & INCLUDE A
0(IEHMVESP) & N
IEHMVESP(R) & I
UDE AOSU0(IEHMVESC) & NAME IEHMVESC(R) & INCLUD
OSU0(IEHMVESK) & NAME
IEHMVESK(R) & INCLUDE AOSU0(IEHMVESR
& NAME IEH
SR(R) & INCLUDE AOSU0(
MVESJ) & NAME IEHMVESJ(R)
&/* &//SG15 EXEC LINKS,
&// PARM='NCAL,LIST,X
,REUS', &// UNIT='
0',SER=MVSRES,N=SYS1,NAM
INKLIB,P1='(', &// MOD=IEHMVXSF,P2='

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
If you switch back to the SYSOUT=B and add back
the JES2 commands of one $tpun1,s=n with many
$ppun1 and $spun1 does the issue return?

Yes, the issue returned after 6 auto runs. Just
missing data though. I am rerunning to try to
get garbage too.
I am not aware of/familiar with looping ability
in Hercules scripts, but regardless, I don't see
anything wrong with my current test setup
which stops on the first error.

Post by ***@yahoo.com [H390-MVS]

Post by ***@yahoo.com.au [H390-MVS]
How many runs directly to device 013 (that Joe suggested)
would you like me to complete first?

I believe that that horse is dead.
You got a JES2 error on the second try earlier,
you have enough runs trying to bypass JES2
with no errors.

Ok, so it was 207 runs without error.

Post by ***@yahoo.com [H390-MVS]
Just guessing but you may have TRUNC set for
that JES2 output CLASS so data is stored on
SPOOL without trailing spaces?

I don't know.

Post by ***@yahoo.com [H390-MVS]
We will see if we can get the error with a
SPOOL volume trace and punch device I/O
trace running.

Ok, if you give me the command I'll try it.

BFN. Paul.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
If you switch back to the SYSOUT=B and add back
the JES2 commands of one $tpun1,s=n with many
$ppun1 and $spun1 does the issue return?

Yes, the issue returned after 6 auto runs. Just
missing data though. I am rerunning to try to
get garbage too.

Good. If you catch one error, you might have caught both?
Don't worry about which one or both yet.

Pick either I/O trace.
Running one could prevent the error from
happening and running both together would
change the timing worse.

From my poor memory:
The simplest I/O trace to set up is in Hercules.
Start Hercules redirecting the output to a file like:
hercules.exe > log/%date%.%time%.Hercules.log.txt
Get your punch and SPOOL hardware addresses.
/$ppun1
run your punch JOB or started task.
When JES2 has the punch data:
Enter the Hercules I/O trace for the devices.
Something like
t+00d
t+123
/$spun1
wait for pun1 to be paused waiting for work.
/$ppun1
shut down MVS and Hercules normally.
The trace will end with Hercules so no
reason to t-00d or t-123 to end tracing.
We will get to see if there are shutdown
issues with 00d and 123.

From my poor memory:
The MVS equivalent is starting GTF with a large
SYS1.TRACE data set or tape specified in
SYS1.PROCLIB(GTF) and check your
SYS1.PARMLIB(GTFPARM) or other,
/s gtf.gtf
replying to prompt but PARMLIB may have done some?
for SIO and IO, trace=siop,iop, and then specify
devices for IO=SIO=(00D,123) or you can specify
io=, sio=, and for each device separately..and then
"end" for or on the last parameter.
run test.
/d a,l to insure that gtf has a step name of gtf but
if not, /stoP whatever the JOB and step names are:.
/p gtf.gtf or /p gtf.234
Then use A/I/HMDPRDMP to print the dump to
SPOOL or to a normal disk data set.
I normally would just browse SYS1.TRACE

Find the line before the error in the file.
locate that in the trace listing.
See what it says and report back.

[Joe Monk [e-mail] [H390-MVS]]

Paul,

What happened when you wrote directly to the punch?

Joe

Post by ***@yahoo.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
If you switch back to the SYSOUT=B and add back
the JES2 commands of one $tpun1,s=n with many
$ppun1 and $spun1 does the issue return?

Yes, the issue returned after 6 auto runs. Just
missing data though. I am rerunning to try to
get garbage too.

Good. If you catch one error, you might have caught both?
Don't worry about which one or both yet.
Pick either I/O trace.
Running one could prevent the error from
happening and running both together would
change the timing worse.
The simplest I/O trace to set up is in Hercules.
hercules.exe > log/%date%.%time%.Hercules.log.txt
Get your punch and SPOOL hardware addresses.
/$ppun1
run your punch JOB or started task.
Enter the Hercules I/O trace for the devices.
Something like
t+00d
t+123
/$spun1
wait for pun1 to be paused waiting for work.
/$ppun1
shut down MVS and Hercules normally.
The trace will end with Hercules so no
reason to t-00d or t-123 to end tracing.
We will get to see if there are shutdown
issues with 00d and 123.
The MVS equivalent is starting GTF with a large
SYS1.TRACE data set or tape specified in
SYS1.PROCLIB(GTF) and check your
SYS1.PARMLIB(GTFPARM) or other,
/s gtf.gtf
replying to prompt but PARMLIB may have done some?
for SIO and IO, trace=siop,iop, and then specify
devices for IO=SIO=(00D,123) or you can specify
io=, sio=, and for each device separately..and then
"end" for or on the last parameter.
run test.
/d a,l to insure that gtf has a step name of gtf but
if not, /stoP whatever the JOB and step names are:.
/p gtf.gtf or /p gtf.234
Then use A/I/HMDPRDMP to print the dump to
SPOOL or to a normal disk data set.
I normally would just browse SYS1.TRACE
Find the line before the error in the file.
locate that in the trace listing.
See what it says and report back.

[[e-mail] [H390-MVS]]

Post by Joe Monk ***@gmail.com [H390-MVS]
What happened when you wrote directly to the punch?

207 runs without a problem.

BFN. Paul.

[Joe Monk [e-mail] [H390-MVS]]

Ok ... so then we're all wasting our time.

This is obviously a problem with the starter system, which is not running
patched, up-to-date versions of code. It is meant to be just enough to get
you thru a sysgen.

Let's stop now while we are all still sane, and chalk this up to what it is..

Joe

Post by ***@yahoo.com.au [H390-MVS]

Post by Joe Monk ***@gmail.com [H390-MVS]
What happened when you wrote directly to the punch?

207 runs without a problem.
BFN. Paul.

[[e-mail] [H390-MVS]]

I'm inclined to agree.

But if somitcw wishes to beat this dead horse, I can
continue to get data. But perhaps we should move
it to the os380 group.

Latest data I have from the "line test" is that I
can reproduce the problem, and the junk is
mostly just repeated lines, ie this line now
appears twice:

C:\mvs380_work\cardbug_line>grep -n 12971 pch013.txt
12863:LINE12971XYZ
12893:LINE12971XYZ

And only at the end did I see data that wasn't
in my file:

C:\mvs380_work\cardbug_line>

LINE12969XYZ
LINE12970XYZ
LINE12971XYZ
!
A
D.********
*********
************
u < A
STD.**
***
****************
*****
( A
********
****

BFN. Paul.




---In H390-***@yahoogroups.com, <***@...> wrote :

Ok ... so then we're all wasting our time.

This is obviously a problem with the starter system, which is not running patched, up-to-date versions of code. It is meant to be just enough to get you thru a sysgen.


Let's stop now while we are all still sane, and chalk this up to what it is.


Joe

What happened when you wrote directly to the punch?

207 runs without a problem.

BFN. Paul.

[[e-mail] [H390-MVS]]

Post by ***@yahoo.com [H390-MVS]
The simplest I/O trace to set up is in Hercules.

I did this, with this script:

devinit 012 punch.jcl eof
#devinit 012 repro.jcl eof

pause 10

t+013
t+151

/$spun1

pause 5

/$ppun1


And this situation was a cleaner/simpler situation,
with missing data, like this:

C:\mvs380_work\cardbug_line>diff goodline.txt pch013.txt | head
5149,5196d5148
< LINE05149XYZ
< LINE05150XYZ
< LINE05151XYZ
< LINE05152XYZ
< LINE05153XYZ
< LINE05154XYZ
< LINE05155XYZ
< LINE05156XYZ
< LINE05157XYZ

C:\mvs380_work\cardbug_line>grep 5149 pch013.txt

C:\mvs380_work\cardbug_line>


And I confirmed that the data was traced:

12:49:40 HHCCP048I 0013:CCW=4149EBCF 60000010=>D3C9D5C5 F0F5F1F4 F7E7E8E9 40404040 LINE05147XYZ
12:49:40 HHCCP075I 0013:Stat=0C00 Count=0000
12:49:40 HHCCP048I 0013:CCW=4149EBE2 60000010=>D3C9D5C5 F0F5F1F4 F8E7E8E9 40404040 LINE05148XYZ
12:49:40 HHCCP075I 0013:Stat=0C00 Count=0000
12:49:40 HHCCP048I 0013:CCW=03000000 200080C0=>040E0000 0001AB6E 00000000 00000000 .......>........
12:49:40 HHCCP075I 0013:Stat=0C00 Count=80C0
12:49:40 HHCCP049I 0013:Stat=0C00 Count=80C0 CCW=4A0448
12:49:40 HHCCP048I 0013:CCW=4149EF85 60000010=>D3C9D5C5 F0F5F1F9 F7E7E8E9 40404040 LINE05197XYZ
12:49:40 HHCCP075I 0013:Stat=0C00 Count=0000
12:49:40 HHCCP048I 0013:CCW=4149EF98 60000010=>D3C9D5C5 F0F5F1F9 F8E7E8E9 40404040 LINE05198XYZ
12:49:40 HHCCP075I 0013:Stat=0C00 Count=0000


Full log plus good and bad punch files available here:

https://groups.yahoo.com/neo/groups/H390-MVS/files/somtrace1.zip


I recommend that if you wish to continue/reply
you post your reply in the os380 group.

BFN. Paul.