[hercules-390] Hercules hogs 100% CPU

[Philippe de Rochambeau [e-mail] [hercules-390]]

Hello,
after I compiled a Hello World C program with GCCMVS in MVS tk-4 on MacOSX, Hercules hogged 100% of my CPU.
The tk4- log contains the following entries:

09:57:33 08.57.33 JOB 130 $HASP100 HERC02A ON INTRDR Test GCC
09:57:33 08.57.33 JOB 130 $HASP118 HERC02A -- INVALID /* CONTROL STATEMENT
09:57:33 08.57.33 JOB 130 $HASP119 HERC02A DELETED
09:57:33 08.57.33 $HASP125 INTRDR SKIPPING FOR JOB CARD
10:06:29 09.06.29 STC 622 $HASP150 MF1 ON PRINTER1 212 LINES
10:06:29 09.06.29 $HASP160 PRINTER1 INACTIVE - CLASS=A
10:06:29 09.06.29 STC 622 IRB101I MF/1 REPORT AVAILABLE FOR PRINTING

Can anyone suggest ways to investigate the 100%-CPU-hogging issue?

Cheers,

Philippe

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hello,
after I compiled a Hello World C program with GCCMVS in MVS tk-4 on
MacOSX, Hercules hogged 100% of my CPU.
09:57:33 08.57.33 JOB 130 $HASP100 HERC02A ON INTRDR Test GCC
09:57:33 08.57.33 JOB 130 $HASP118 HERC02A -- INVALID /* CONTROL STATEMENT
09:57:33 08.57.33 JOB 130 $HASP119 HERC02A DELETED
09:57:33 08.57.33 $HASP125 INTRDR SKIPPING FOR JOB CARD
10:06:29 09.06.29 STC 622 $HASP150 MF1 ON PRINTER1 212 LINES
10:06:29 09.06.29 $HASP160 PRINTER1 INACTIVE - CLASS=A
10:06:29 09.06.29 STC 622 IRB101I MF/1 REPORT AVAILABLE FOR PRINTING

None of that looks relevant: those lines tell you that a job (JCL) you
submitted, named
HERC02A, was completely ignored because it was syntactically invalid,
then a little
later you printed a listing named "MF1".

For your 100% CPU problem, one of the problems (if I remember right,
I've deleted the
post) was it was generating hundreds of thousands of lines of print
output. We'd need
to see the C source, and maybe also the JCL and the sysout from that JCL
of the job you
used to compile and link your C program.

[[e-mail] [hercules-390]]

Hello, after I compiled a Hello World C
program with GCCMVS

From the log, I can see that your
JCL was never actually run,
because it had an error.

in MVS tk-4
on MacOSX, Hercules hogged 100% of my CPU.

I have no explanation for why a
failed compile/run would cause
such a thing to happen.


Does the problem occur if you
instead run a job that actually
works, ie a valid compile and
a valid execution?


BFN. Paul.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]
From the log, I can see that your
JCL was never actually run,
because it had an error.

It did run; he's just shown us completely irrelevant syslog lines. See
his earlier post
which showed excessive sysout production and spool full messages...

[[e-mail] [hercules-390]]

Post by Jeremy Nicoll ***@letterboxes.org [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
From the log, I can see that your
JCL was never actually run,
because it had an error.

It did run; he's just shown us completely irrelevant syslog lines.

You don't know that this is the same
problem. This particular problem he
showed (this time) was a JCL error,
not a spool full error, nor was there
any sign of a spool full error, despite
the fact that he kept his system up
for a while.

BFN. Paul.

[Philippe de Rochambeau [e-mail] [hercules-390]]

Hi Jeremy,

here’s the JCL job as it was right before Hercules hogged 100% of my CPU. I ended up killing the emulator.
I’ve submitted the below job again to MVS, but it hasn’t caused any CPU-hogging issues.
I’ll fix the typing error below, and submit the job several times to see if such actions have an effect on Hercules.

Philippe
————————

//HERC02A JOB (SETUP),
// 'Test GCC',
// CLASS=A,
// MSGCLASS=H,
// REGION=8M,
// MSGLEVEL=(1,1)
//*
//* NAME: HERC02.CCODE.SOURCE(HEL1)
//*
//S1 EXEC GCCCLG,COPTS='-v'
//COMP.SYSIN DD *
#include <stdio.h>
#include <stdlib.h>

int main()
{
printf("Hello World!\n");
exit(0);
}
/*
/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)


———————————————

Post by ***@yahoo.com.au [hercules-390]
From the log, I can see that your
JCL was never actually run,
because it had an error.

It did run; he's just shown us completely irrelevant syslog lines. See
his earlier post
which showed excessive sysout production and spool full messages...
--
Jeremy Nicoll - my opinions are my own.

[Philippe de Rochambeau [e-mail] [hercules-390]]

Submitting the JCL program below 3 times with the following line at the end

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

and three times with the following line at the end

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

hasn’t had any effect on the CPU. The problem is therefore elsewhere.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hi Jeremy,
here’s the JCL job as it was right before Hercules hogged 100% of my CPU. I ended up killing the emulator.
I’ve submitted the below job again to MVS, but it hasn’t caused any CPU-hogging issues.
I’ll fix the typing error below, and submit the job several times to see if such actions have an effect on Hercules.
Philippe
————————
//HERC02A JOB (SETUP),
// 'Test GCC',
// CLASS=A,
// MSGCLASS=H,
// REGION=8M,
// MSGLEVEL=(1,1)
//*
//* NAME: HERC02.CCODE.SOURCE(HEL1)
//*
//S1 EXEC GCCCLG,COPTS='-v'
//COMP.SYSIN DD *
#include <stdio.h>
#include <stdlib.h>
int main()
{
printf("Hello World!\n");
exit(0);
}
/*
/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)
———————————————

Post by ***@yahoo.com.au [hercules-390]
From the log, I can see that your
JCL was never actually run,
because it had an error.

It did run; he's just shown us completely irrelevant syslog lines. See
his earlier post
which showed excessive sysout production and spool full messages...
--
Jeremy Nicoll - my opinions are my own.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Submitting the JCL program below 3 times with the following line at the end

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

Did this one not produce syslog error messages each time - "/*COMP"
is not valid. You need
to comment lines out with "//*".

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
and three times with the following line at the end

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

Did these three jobs run?

And, if they did run, did they work?

[Philippe de Rochambeau [e-mail] [hercules-390]]

Hi Jeremy,
the 3 jobs with the //COMP.SYSOUT line worked OK (although the log contains a warning about GO not being found in the DS, but that’s irrelevant, I think).

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Submitting the JCL program below 3 times with the following line at the end

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

Did this one not produce syslog error messages each time - "/*COMP"
is not valid. You need
to comment lines out with "//*".

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
and three times with the following line at the end

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

Did these three jobs run?
And, if they did run, did they work?
--
Jeremy Nicoll - my opinions are my own.

[[e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Submitting the JCL program below 3 times with the following line at the end
/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)
and three times with the following line at the end
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

BTW, where did you see this
"COMP.SYSOUT"? I just checked
my copy of gccclg.prc and it does
not have any such DD statement:

C:\devel\gcc\gcc>grep SYSOUT gccclg.prc
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*

C:\devel\gcc\gcc>


In addition, PDPCLIB doesn't support
RECFM=FBA and I don't know what
happens when you use it.

Also, what are you concerned the most
about? High CPU or your compile and
run not working?

BFN. Paul.

[Philippe de Rochambeau [e-mail] [hercules-390]]

Hi Paul,

as you can tell, I’m a Hercules + MVS newbie fumbling in the dark :-)

I added the following line to the end of my JCL program

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

hoping that it would redirect the output to SYSOUT.

Before I added that line, the program ran OK, but didn’t display any output.

To answer your question, the 100% CPU issue is the reason why I’ve written to this list.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Submitting the JCL program below 3 times with the following line at the end
/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)
and three times with the following line at the end
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

BTW, where did you see this
"COMP.SYSOUT"? I just checked
my copy of gccclg.prc and it does
C:\devel\gcc\gcc>grep SYSOUT gccclg.prc
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
C:\devel\gcc\gcc>
In addition, PDPCLIB doesn't support
RECFM=FBA and I don't know what
happens when you use it.
Also, what are you concerned the most
about? High CPU or your compile and
run not working?
BFN. Paul.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hi Paul,
as you can tell, I’m a Hercules + MVS newbie fumbling in the dark :-)
I added the following line to the end of my JCL program

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

hoping that it would redirect the output to SYSOUT.

That might work if the step of the procedure that runs the compiled job
is named "COMP",
and if your program defines an output device whose name is "SYSOUT".

But it's more common to write to something called "SYSPRINT".

Does your program actually write to "//SYSOUT DD ..." ?

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
To answer your question, the 100% CPU issue is the reason why I’ve
written to this list.

When did the 100% cpu use start?

Was it around the time you were submitting jobs?

Does it ever recover (ie cpu drop to something reasonable) if you leave
it alone?

Do you have any other jobs running at the time?

Has this happened more than once?

[Philippe de Rochambeau [e-mail] [hercules-390]]

Hi all,
Running this code causes the 100% CPU issue.

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

//HERC02T JOB (SETUP),
// 'Test JCC',
// CLASS=A,
// MSGCLASS=H,
// REGION=8M,
// MSGLEVEL=(1,1)
//********************************************************************
//*
//* Name: SYS2.JCLLIB(TESTJCC)
//*
//* Desc: JCC compile and go
//*
//********************************************************************
//*
//BEER EXEC JCCCG
//COMPILE.SYSIN DD *
#include <stdio.h>
#include <stdlib.h>

static void song( int bottles )
{
while( (printf(" %d bottles of beer on the wall, %d bottles of beer.\n"
" Take one down and pass it around, %d bottle%s of beer on the wall.\n\n",
bottles, bottles, bottles-1, bottles>2? "s":""), bottles > 2) )
while( (--bottles,0) ) {}
while( (puts(" 1 bottle of beer on the wall, 1 bottle of beer.\n"
" Take one down and pass it around, no more bottles of beer on the wall.\n\n"
" No more bottles of beer on the wall, no more bottles of beer.\n"
" Go to the store and buy some more, 99 bottles of beer on the wall."),0) ) {}
}

int main()
{
while( (song(99), exit(0), 0) ) {}
}
/*
//

Post by Jeremy Nicoll ***@letterboxes.org [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hi Paul,
as you can tell, I’m a Hercules + MVS newbie fumbling in the dark :-)
I added the following line to the end of my JCL program

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

hoping that it would redirect the output to SYSOUT.

That might work if the step of the procedure that runs the compiled job
is named "COMP",
and if your program defines an output device whose name is "SYSOUT".
But it's more common to write to something called "SYSPRINT".
Does your program actually write to "//SYSOUT DD ..." ?

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
To answer your question, the 100% CPU issue is the reason why I’ve
written to this list.

When did the 100% cpu use start?
Was it around the time you were submitting jobs?
Does it ever recover (ie cpu drop to something reasonable) if you leave
it alone?
Do you have any other jobs running at the time?
Has this happened more than once?
--
Jeremy Nicoll - my opinions are my own.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hi all,
Running this code causes the 100% CPU issue.

And, just to make sure we're talking about the same thing, it's the
emulator itself, Hercules
that's going mad, not the emulated machine? So MacOS sees the problem?

Within MacOS are there tools for investigating what a loopoing program
is doing?

Does your Mac have more than one cpu in it - when this happens are you
able to do anything
at all, or do you have to shutdown the whole real machine?

When it happens can you still issue commands on the MVS console?

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//HERC02T JOB (SETUP),
// 'Test JCC',
// CLASS=A,
// MSGCLASS=H,
// REGION=8M,
// MSGLEVEL=(1,1)
//********************************************************************
//*
//* Name: SYS2.JCLLIB(TESTJCC)
//*
//* Desc: JCC compile and go
//*
//********************************************************************
//*
//BEER EXEC JCCCG
//COMPILE.SYSIN DD *
#include <stdio.h>
#include <stdlib.h>
static void song( int bottles )
{
while( (printf(" %d bottles of beer on the wall, %d bottles of beer.\n"
" Take one down and pass it around, %d bottle%s of beer on the wall.\n\n",
bottles, bottles, bottles-1, bottles>2? "s":""), bottles > 2) )
while( (--bottles,0) ) {}
while( (puts(" 1 bottle of beer on the wall, 1 bottle of beer.\n"
" Take one down and pass it around, no more bottles of beer on the wall.\n\n"
" No more bottles of beer on the wall, no more bottles of beer.\n"
" Go to the store and buy some more, 99 bottles of beer on the wall."),0) ) {}
}
int main()
{
while( (song(99), exit(0), 0) ) {}
}
/*
//

I don't have these files in front of me to look at. Is this test job
being run
exactly as it was supplied, or (apart from the jobcard) have you changed
anything?

I note this is EXEC JCCCG which is not the procedure you were using
before.
This is a compile & go; do you know if the GO step actually starts to
execute?

Do you know if the job ends? Or how far it gets?

Are there any warning messages from the compile step?

[Philippe de Rochambeau [e-mail] [hercules-390]]

The emulator says 100% CPU and MacOSX says that Hercules takes up 102%+ of the CPU. I can email you screenshots, if you want.

My CPU is a quad-core Intel i7.

I’m not sure about tools being available to investigate a looping program, but I can find out. MacOSX is a BSD-based OS, so there’s bound to be such tools.

Yes, you can still type commands in the MVS emulator.

Here’s the output that was displayed after I ran the HERC02T job a few minutes ago:

---------------
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY 1750000
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY 1755000
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY 1760000
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY 1765000
11.25.04 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY 1770000
11.25.04 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY 1775000
11.25.04 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY 1780000
11.25.04 $HASP355 SPOOL VOLUMES ARE FULL
---------------

Closing the terminal window doesn’t kill hercules. I have to manually kill it in the Activity Monitor.

Regarding the BEER code:

- the code was copied from SYS2.JCLLIB(TESTJCC)

- I replaced the job’s name by HERC02T (from TESTJCC) to that the output would appear in HERC02’s logs

- I changed MSGCLASS to H from A so that the log messages would be held (as recommended by moshix here:

http://youtu.be/YA3FQOzr0ag

- I can’t read the log after running the program because MVS is frozen (i.e., typing commands in c3270 has no effect).

Philippe

Post by Jeremy Nicoll ***@letterboxes.org [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hi all,
Running this code causes the 100% CPU issue.

And, just to make sure we're talking about the same thing, it's the
emulator itself, Hercules
that's going mad, not the emulated machine? So MacOS sees the problem?
Within MacOS are there tools for investigating what a loopoing program
is doing?
Does your Mac have more than one cpu in it - when this happens are you
able to do anything
at all, or do you have to shutdown the whole real machine?
When it happens can you still issue commands on the MVS console?

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//HERC02T JOB (SETUP),
// 'Test JCC',
// CLASS=A,
// MSGCLASS=H,
// REGION=8M,
// MSGLEVEL=(1,1)
//********************************************************************
//*
//* Name: SYS2.JCLLIB(TESTJCC)
//*
//* Desc: JCC compile and go
//*
//********************************************************************
//*
//BEER EXEC JCCCG
//COMPILE.SYSIN DD *
#include <stdio.h>
#include <stdlib.h>
static void song( int bottles )
{
while( (printf(" %d bottles of beer on the wall, %d bottles of beer.\n"
" Take one down and pass it around, %d bottle%s of beer on the wall.\n\n",
bottles, bottles, bottles-1, bottles>2? "s":""), bottles > 2) )
while( (--bottles,0) ) {}
while( (puts(" 1 bottle of beer on the wall, 1 bottle of beer.\n"
" Take one down and pass it around, no more bottles of beer on the wall.\n\n"
" No more bottles of beer on the wall, no more bottles of beer.\n"
" Go to the store and buy some more, 99 bottles of beer on the wall."),0) ) {}
}
int main()
{
while( (song(99), exit(0), 0) ) {}
}
/*
//

I don't have these files in front of me to look at. Is this test job
being run
exactly as it was supplied, or (apart from the jobcard) have you changed
anything?
I note this is EXEC JCCCG which is not the procedure you were using
before.
This is a compile & go; do you know if the GO step actually starts to
execute?
Do you know if the job ends? Or how far it gets?
Are there any warning messages from the compile step?
--
Jeremy Nicoll - my opinions are my own.

[Joe Monk [e-mail] [hercules-390]]

I would suggest on the next IPL a cold start with a queue format. This
should take care of the problem.

I'd be willing to bet he has a hung job on the spool that JES restarts...

Joe

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
The emulator says 100% CPU and MacOSX says that Hercules takes up 102%+ of
the CPU. I can email you screenshots, if you want.
My CPU is a quad-core Intel i7.
I’m not sure about tools being available to investigate a looping program,
but I can find out. MacOSX is a BSD-based OS, so there’s bound to be such
tools.
Yes, you can still type commands in the MVS emulator.
---------------
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1750000
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1755000
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1760000
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1765000
11.25.04 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1770000
11.25.04 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1775000
11.25.04 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1780000
11.25.04 $HASP355 SPOOL VOLUMES ARE FULL
---------------
Closing the terminal window doesn’t kill hercules. I have to manually kill
it in the Activity Monitor.
- the code was copied from SYS2.JCLLIB(TESTJCC)
- I replaced the job’s name by HERC02T (from TESTJCC) to that the output
would appear in HERC02’s logs
- I changed MSGCLASS to H from A so that the log messages would be held
(as recommended by moshix here: https://www.youtube.com/
watch?v=YA3FQOzr0ag)
- I can’t read the log after running the program because MVS is frozen
(i.e., typing commands in c3270 has no effect).
Philippe

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hi all,
Running this code causes the 100% CPU issue.

And, just to make sure we're talking about the same thing, it's the
emulator itself, Hercules
that's going mad, not the emulated machine? So MacOS sees the problem?
Within MacOS are there tools for investigating what a loopoing program
is doing?
Does your Mac have more than one cpu in it - when this happens are you
able to do anything
at all, or do you have to shutdown the whole real machine?
When it happens can you still issue commands on the MVS console?

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//HERC02T JOB (SETUP),
// 'Test JCC',
// CLASS=A,
// MSGCLASS=H,
// REGION=8M,
// MSGLEVEL=(1,1)
//********************************************************************
//*
//* Name: SYS2.JCLLIB(TESTJCC)
//*
//* Desc: JCC compile and go
//*
//********************************************************************
//*
//BEER EXEC JCCCG
//COMPILE.SYSIN DD *
#include <stdio.h>
#include <stdlib.h>
static void song( int bottles )
{
while( (printf(" %d bottles of beer on the wall, %d bottles of beer.\n"
" Take one down and pass it around, %d bottle%s of beer on the wall.\n\n",
bottles, bottles, bottles-1, bottles>2? "s":""), bottles > 2) )
while( (--bottles,0) ) {}
while( (puts(" 1 bottle of beer on the wall, 1 bottle of beer.\n"
" Take one down and pass it around, no more bottles of beer on the wall.\n\n"
" No more bottles of beer on the wall, no more bottles of beer.\n"
" Go to the store and buy some more, 99 bottles of beer on the wall."),0) ) {}
}
int main()
{
while( (song(99), exit(0), 0) ) {}
}
/*
//

I don't have these files in front of me to look at. Is this test job
being run
exactly as it was supplied, or (apart from the jobcard) have you changed
anything?
I note this is EXEC JCCCG which is not the procedure you were using
before.
This is a compile & go; do you know if the GO step actually starts to
execute?
Do you know if the job ends? Or how far it gets?
Are there any warning messages from the compile step?
--
Jeremy Nicoll - my opinions are my own.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Joe Monk ***@gmail.com [hercules-390]
I would suggest on the next IPL a cold start with a queue format. This
should take care of the problem.
I'd be willing to bet he has a hung job on the spool that JES restarts...

It must be something like that...

Someone told him how to clear spool in response to the earlier thread,
but if he's
not also investigated what that job is doing and why, that would explain
a lot.

I was also wondering about the timing of things. How long after a
restart of Hercules
does he re-ipl, restart jes and so on. DO initiators get started
automatically or minutes
later just before he wants to run the test job he's submitting? Does
the cpu busy only
occur after a test job's submitted because that's when the presumed-hung
job restarts?

[Philippe de Rochambeau [e-mail] [hercules-390]]

I’ve just IPLd MVS again.

Strangely enough, the Hercules CPU is still at 100%.

Here’s what top says:

Processes: 251 total, 4 running, 10 stuck, 237 sleeping, 1104 threads 13:32:52
Load Avg: 5.75, 3.33, 2.68 CPU usage: 11.63% user, 3.99% sys, 84.37% idle
SharedLibs: 214M resident, 22M data, 31M linkedit. MemRegions: 36753 total, 2519M resident, 127M private, 1049M shared.
PhysMem: 7494M used (2023M wired), 8882M unused. VM: 1213G vsize, 533M framework vsize, 0(0) swapins, 0(0) swapouts.
Networks: packets: 97983/115M in, 43810/6740K out. Disks: 232992/4774M read, 33305/1382M written.

PID COMMAND %CPU TIME #TH #WQ #PORT MEM PURG CMPR PGRP PPID STATE BOOSTS %CPU_ME %CPU_OTHRS
...
690 hercules 102.1 02:15.19 58/1 0 73 29M 0B 0B 683 683 running *0[1] 0.00000 0.00000

As you can see, hercules still uses 102.1% of the CPU and the number of threads is 58.

I’ve tried killing « hercules » again with kill -9, but to no avail, as, when I rerun it, CPU is back at 100%. I will therefore have to reboot my machine.

Because investigating hercules CPU-hogging issues on MacOSX seems quite time-consuming, from now on, I will be careful not to write C program in MVS that go into endless loop.

Many thanks to all for your help.

Post by Jeremy Nicoll ***@letterboxes.org [hercules-390]

Post by Joe Monk ***@gmail.com [hercules-390]
I would suggest on the next IPL a cold start with a queue format. This
should take care of the problem.
I'd be willing to bet he has a hung job on the spool that JES restarts...

It must be something like that...
Someone told him how to clear spool in response to the earlier thread,
but if he's
not also investigated what that job is doing and why, that would explain
a lot.
I was also wondering about the timing of things. How long after a
restart of Hercules
does he re-ipl, restart jes and so on. DO initiators get started
automatically or minutes
later just before he wants to run the test job he's submitting? Does
the cpu busy only
occur after a test job's submitted because that's when the presumed-hung
job restarts?
--
Jeremy Nicoll - my opinions are my own.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I’ve just IPLd MVS again.
Strangely enough, the Hercules CPU is still at 100%.

It's not strange if the re-IPL has enabled a previously running job to
restart.

You really do need to get to the bottom of what the HERC02I job (the one
that's filling the
spool up) is doing. It's that job, probably, that's making Hercules
busy.

[Philippe de Rochambeau [e-mail] [hercules-390]]

OK.
I’ll run the job 1, 2, 3, 
 10 times and see what happens.

Post by Jeremy Nicoll ***@letterboxes.org [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I’ve just IPLd MVS again.
Strangely enough, the Hercules CPU is still at 100%.

It's not strange if the re-IPL has enabled a previously running job to
restart.
You really do need to get to the bottom of what the HERC02I job (the one
that's filling the
spool up) is doing. It's that job, probably, that's making Hercules
busy.
--
Jeremy Nicoll - my opinions are my own.

[Philippe de Rochambeau [e-mail] [hercules-390]]

I can’t log into MVS anymore and Hercule’s CPU usage is back at 100%.

I think that Hercules is damanged. I’ll have to reinstall it.


Here’s what the Macosx log says about hercules:

16/07/2017 14:03:50,000 kernel[0]: process hercules[507] caught causing excessive wakeups. Observed wakeups rate (per sec): 7504; Maximum permitted wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime number of wakeups: 45050
16/07/2017 14:03:51,238 spindump[437]: Saved wakeups_resource.diag report for hercules version ??? (???) to /Library/Logs/DiagnosticReports/hercules_2017-07-16-140351_xxx.wakeups_resource.diag

and here’s what the diag report says:

Powerstats for: spindump
UUID: 9B00539D-D2CA-39A0-8711-B7396488113F
Start time: 2017-07-16 14:03:50 +0200
End time: 2017-07-16 14:03:50 +0200
Microstackshots: 1 samples (16%)
Primary state: 1 samples Non-Frontmost App, Kernel mode, Thread QoS Legacy
User Activity: 0 samples Idle, 1 samples Active
Power Source: 0 samples on Battery, 1 samples on AC
1 start_wqthread + 13 (libsystem_pthread.dylib) [0x7fff93e62341]
1 _pthread_wqthread + 1129 (libsystem_pthread.dylib) [0x7fff93e644de]
1 _dispatch_worker_thread3 + 91 (libdispatch.dylib) [0x7fff88b61b00]
1 _dispatch_root_queue_drain + 1890 (libdispatch.dylib) [0x7fff88b6229b]
1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff88b5e40b]
1 _dispatch_call_block_and_release + 12 (libdispatch.dylib) [0x7fff88b6993d]
1 ??? (spindump + 129010) [0x10d5087f2]
1 ??? (spindump + 34869) [0x10d4f1835]
1 ??? (spindump + 95736) [0x10d5005f8]
1 _dispatch_barrier_sync_f_invoke + 74 (libdispatch.dylib) [0x7fff88b5f9f2]
1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff88b5e40b]
1 ??? (spindump + 96217) [0x10d5007d9]
1 CSSymbolicatorCreateWithPidFlagsAndNotification + 58 (CoreSymbolication) [0x7fff8e0837d6]
1 ??? (CoreSymbolication + 112113) [0x7fff8e0835f1]
1 ??? (CoreSymbolication + 7597) [0x7fff8e069dad]
1 ??? (CoreSymbolication + 12118) [0x7fff8e06af56]
1 ??? (CoreSymbolication + 12443) [0x7fff8e06b09b]
1 ??? (CoreSymbolication + 12622) [0x7fff8e06b14e]
1 ??? (CoreSymbolication + 13230) [0x7fff8e06b3ae]
1 thread_set_exception_ports + 112 (libsystem_kernel.dylib) [0x7fff956f0a71]
1 mach_msg_trap + 10 (libsystem_kernel.dylib) [0x7fff956f3f72]

Binary Images:
0x10d4e9000 - 0x10d51afff spindump (197.1) <9B00539D-D2CA-39A0-8711-B7396488113F> /usr/sbin/spindump
0x7fff88b5c000 - 0x7fff88b89fff libdispatch.dylib (501.40.12) <C7499857-61A5-3D7D-A5EA-65DCC8C3DF92> /usr/lib/system/libdispatch.dylib
0x7fff8e068000 - 0x7fff8e0f0fff com.apple.CoreSymbolication 3.1 (58048.1) <C1A1A8DB-8A51-3A21-865A-3CEF22A0E67A> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
0x7fff93e61000 - 0x7fff93e6aff7 libsystem_pthread.dylib (138.10.4) <3DD1EF4C-1D1B-3ABF-8CC6-B3B1CEEE9559> /usr/lib/system/libsystem_pthread.dylib
0x7fff956e3000 - 0x7fff95701ff7 libsystem_kernel.dylib (3248.60.11.5.3) <F8228B30-AF62-3D47-A3A9-4A360787B238> /usr/lib/system/libsystem_kernel.dylib

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
OK.
I’ll run the job 1, 2, 3, 
 10 times and see what happens.

Post by Jeremy Nicoll ***@letterboxes.org [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I’ve just IPLd MVS again.
Strangely enough, the Hercules CPU is still at 100%.

It's not strange if the re-IPL has enabled a previously running job to
restart.
You really do need to get to the bottom of what the HERC02I job (the one
that's filling the
spool up) is doing. It's that job, probably, that's making Hercules
busy.
--
Jeremy Nicoll - my opinions are my own.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I can’t log into MVS anymore and Hercule’s CPU usage is back at 100%.
I think that Hercules is damanged. I’ll have to reinstall it.

There's no evidence of that. There's plenty of evidence that your
Hercules system is running
a job, possibly one you started a day or two ago, and that job has used
all of the MVS system's
resources...

Is there an option to ipl MVS and either

- start no workload after that, in particular don't start JES

or

- to 'cold start' jes?

The latter would empty the spool, get rid of previously-running jobs
that might restart, and so
on.

[Philippe de Rochambeau [e-mail] [hercules-390]]

Hi Jeremy,

you were right a job still running.

I issued the command $PS, $PT and $PJ commands and CPU usage is now back to 0%.

The MVS log seems to indicate that HERC02I was running before the purge.

Is it necessary to purge jobs every time they go haywire?

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


14:31:01 HHC00008I /$PS1-9999
14:31:01 IEE041I THE SYSTEM LOG IS NOW ACTIVE
14:31:01 IEE341I BSPPILOT NOT ACTIVE
14:31:01 $HASP355 SPOOL VOLUMES ARE FULL
14:31:01 $HASP000 SYSLOG AWAITING PURGE PRIO 15 PURGE ANY
14:31:01 $HASP000 SYSLOG AWAITING PURGE PRIO 15 PURGE ANY
14:31:01 $HASP000 SYSLOG AWAITING PURGE PRIO 15 PURGE ANY
14:31:01 $HASP000 SYSLOG AWAITING PURGE PRIO 15 PURGE ANY
14:31:01 $HASP000 BSPPILOT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 NET AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 TP AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 MF1 AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 TSO AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 SNASOL AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 JRP AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP160 PUNCH1 INACTIVE - CLASS=B
14:31:01 $HASP250 SYSLOG IS PURGED
14:31:01 $HASP250 SYSLOG IS PURGED
14:31:01 $HASP250 SYSLOG IS PURGED


HHC00008I /$PJ1-9999
13.34.40 JOB 115 $HASP000 TESTPL1 PRT LOCAL PUN LOCAL PRIO 4 PURGE ANY
13.34.40 JOB 141 $HASP000 HERC01C PRT LOCAL PUN LOCAL PRIO 2 PURGE ANY
13.34.40 JOB 142 $HASP000 HERC01D PRT LOCAL PUN LOCAL PRIO 1 PURGE ANY
13.34.40 JOB 146 $HASP000 HERC02A PRT LOCAL PUN LOCAL PRIO 1 PURGE ANY
13.34.40 JOB 147 $HASP000 HERC02I PRT LOCAL PUN LOCAL PRIO 1 PURGE ANY
13.34.40 $HASP093 100% SPOOL UTILIZATION
13.34.40 JOB 115 $HASP250 TESTPL1 IS PURGED
13.34.40 JOB 141 $HASP250 HERC01C IS PURGED
13.34.40 JOB 142 $HASP250 HERC01D IS PURGED
13.34.40 JOB 146 $HASP250 HERC02A IS PURGED
13.34.40 JOB 147 $HASP250 HERC02I IS PURGED
HHC00008I /$PT1-9999
13.35.02 $HASP000 JOB(S) NOT FOUND

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I can’t log into MVS anymore and Hercule’s CPU usage is back at 100%.
I think that Hercules is damanged. I’ll have to reinstall it.

There's no evidence of that. There's plenty of evidence that your
Hercules system is running
a job, possibly one you started a day or two ago, and that job has used
all of the MVS system's
resources...
Is there an option to ipl MVS and either
- start no workload after that, in particular don't start JES
or
- to 'cold start' jes?
The latter would empty the spool, get rid of previously-running jobs
that might restart, and so
on.
--
Jeremy Nicoll - my opinions are my own.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hi Jeremy,
you were right a job still running.

The credit is due to Joe Monk, not me.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I issued the command $PS, $PT and $PJ commands and CPU usage is now back to 0%.
The MVS log seems to indicate that HERC02I was running before the purge.
Is it necessary to purge jobs every time they go haywire?

It would be usual) in the real world back in the days when MVS38J was
state of the art, for
the system operator (a person) to see the 'lines exceeded' messages on
the console and
cancel the job. On a real system they'd know which real user submitted
the job and might
(In my experience) ring you and ask what the hell you think you're doing
first, but the job
would be cancelled to protect the system.

In your situation the job wasn't cancelled, so restarted each time you
got JES going again.

The purge commands wouldn't be needed if a job was cancelled quickly,
but might be needed
if the cancel was delayed.

$PS, $PT and $PJ purge different sorts of spool contents - for S -
'started tasks' - things with
jobnumber like STC01234, TSO users - TSU01234, and batch jobs JOB01234.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
14:31:01 HHC00008I /$PS1-9999
14:31:01 IEE041I THE SYSTEM LOG IS NOW ACTIVE
14:31:01 IEE341I BSPPILOT NOT ACTIVE
14:31:01 $HASP355 SPOOL VOLUMES ARE FULL
14:31:01 $HASP000 SYSLOG AWAITING PURGE PRIO 15 PURGE ANY
14:31:01 $HASP000 SYSLOG AWAITING PURGE PRIO 15 PURGE ANY
14:31:01 $HASP000 SYSLOG AWAITING PURGE PRIO 15 PURGE ANY
14:31:01 $HASP000 SYSLOG AWAITING PURGE PRIO 15 PURGE ANY

- those lines say that the SYSLOG itself is going to be purged

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
14:31:01 $HASP000 BSPPILOT AWAITING PURGE PRIO 1 PURGE ANY

- and that task

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY
14:31:01 $HASP000 INIT AWAITING PURGE PRIO 1 PURGE ANY

and the sysout from each of the JES initiators

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
14:31:01 $HASP000 NET AWAITING PURGE PRIO 1 PURGE ANY

and VTAM

and so on...

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
HHC00008I /$PJ1-9999
13.34.40 JOB 115 $HASP000 TESTPL1 PRT LOCAL PUN LOCAL PRIO 4 PURGE ANY
13.34.40 JOB 141 $HASP000 HERC01C PRT LOCAL PUN LOCAL PRIO 2 PURGE ANY
13.34.40 JOB 142 $HASP000 HERC01D PRT LOCAL PUN LOCAL PRIO 1 PURGE ANY
13.34.40 JOB 146 $HASP000 HERC02A PRT LOCAL PUN LOCAL PRIO 1 PURGE ANY
13.34.40 JOB 147 $HASP000 HERC02I PRT LOCAL PUN LOCAL PRIO 1 PURGE ANY

and that's showing purge of generated print files

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Jeremy Nicoll ***@letterboxes.org [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I can’t log into MVS anymore and Hercule’s CPU usage is back at 100%.
I think that Hercules is damanged. I’ll have to reinstall it.

There's no evidence of that. There's plenty of evidence that your
Hercules system is running
a job, possibly one you started a day or two ago, and that job has used
all of the MVS system's
resources...
Is there an option to ipl MVS and either
- start no workload after that, in particular don't start JES

Hmm, after a quick google and a squint at the tk-4 documentation, the
user manual
says on p 14 that if you reply

r 00,cmd=03

to the prompt

IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2

then the system will ipl without starting JES etc. That would be worth
a try - because it will
prove that MVS and Hercules are ok, even if JES and the spool are not.

[Let me say that in a real MVS system that the appearrance of the
IEA101A prompt always used
to make me relax (as an on-call MVS sysprog). The things that can go
wrong before that message
is displayed are hard to fix in the middle of the night... Once one
has (in theory) an MVS system
willing to do what you tell it to do, it's MUCH easier to solve
problems.]

Of course I understand that you don't have the knowledge... but I have
NEVER run a TK system
under Hercules, so you have some advantages over me. The first MVS
system I ever worked
with, for real, on a real machine, wasn't much more advanced than MVS38J
though... On the
other hand I was a trainee sysprog then, so didn't know much about the
underlying system.

After a while I was expert, and MVS had advanced to z/OS... but it was
still 20 years ago... so I'm
not able to give precise instructions. I keep meaning to find time to
try a MVS38J system but
never seem to get around to it.

[Joe Monk [e-mail] [hercules-390]]

ITS NOT HERCULES. HERCULES IS MERELY EXECUTING MVS.

YOU NEED TO START JES2 WITH A COLD START AND FORMAT THE SPOOL.

Sorry for the caps..

Joe

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I can’t log into MVS anymore and Hercule’s CPU usage is back at 100%.
I think that Hercules is damanged. I’ll have to reinstall it.
16/07/2017 14:03:50,000 kernel[0]: process hercules[507] caught causing
excessive wakeups. Observed wakeups rate (per sec): 7504; Maximum permitted
wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime
number of wakeups: 45050
16/07/2017 14:03:51,238 spindump[437]: Saved wakeups_resource.diag report
for hercules version ??? (???) to /Library/Logs/
DiagnosticReports/hercules_2017-07-16-140351_xxx.wakeups_resource.diag
Powerstats for: spindump
UUID: 9B00539D-D2CA-39A0-8711-B7396488113F
Start time: 2017-07-16 14:03:50 +0200
End time: 2017-07-16 14:03:50 +0200
Microstackshots: 1 samples (16%)
Primary state: 1 samples Non-Frontmost App, Kernel mode, Thread QoS Legacy
User Activity: 0 samples Idle, 1 samples Active
Power Source: 0 samples on Battery, 1 samples on AC
1 start_wqthread + 13 (libsystem_pthread.dylib) [0x7fff93e62341]
1 _pthread_wqthread + 1129 (libsystem_pthread.dylib) [0x7fff93e644de]
1 _dispatch_worker_thread3 + 91 (libdispatch.dylib) [0x7fff88b61b00]
1 _dispatch_root_queue_drain + 1890 (libdispatch.dylib) [0x7fff88b6229b]
1 _dispatch_client_callout + 8 (libdispatch.dylib)
[0x7fff88b5e40b]
1 _dispatch_call_block_and_release + 12 (libdispatch.dylib) [0x7fff88b6993d]
1 ??? (spindump + 129010) [0x10d5087f2]
1 ??? (spindump + 34869) [0x10d4f1835]
1 ??? (spindump + 95736) [0x10d5005f8]
1 _dispatch_barrier_sync_f_invoke + 74
(libdispatch.dylib) [0x7fff88b5f9f2]
1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff88b5e40b]
1 ??? (spindump + 96217) [0x10d5007d9]
1 CSSymbolicatorCreateWithPidFlagsAndNotification
+ 58 (CoreSymbolication) [0x7fff8e0837d6]
1 ??? (CoreSymbolication + 112113)
[0x7fff8e0835f1]
1 ??? (CoreSymbolication + 7597)
[0x7fff8e069dad]
1 ??? (CoreSymbolication + 12118) [0x7fff8e06af56]
1 ??? (CoreSymbolication + 12443) [0x7fff8e06b09b]
1 ??? (CoreSymbolication + 12622) [0x7fff8e06b14e]
1 ??? (CoreSymbolication + 13230) [0x7fff8e06b3ae]
1 thread_set_exception_ports + 112
(libsystem_kernel.dylib) [0x7fff956f0a71]
1 mach_msg_trap + 10
(libsystem_kernel.dylib) [0x7fff956f3f72]
0x10d4e9000 - 0x10d51afff spindump (197.1)
<9B00539D-D2CA-39A0-8711-B7396488113F> /usr/sbin/spindump
0x7fff88b5c000 - 0x7fff88b89fff libdispatch.dylib (501.40.12)
<C7499857-61A5-3D7D-A5EA-65DCC8C3DF92> /usr/lib/system/libdispatch.dylib
0x7fff8e068000 - 0x7fff8e0f0fff com.apple.CoreSymbolication 3.1
(58048.1) <C1A1A8DB-8A51-3A21-865A-3CEF22A0E67A> /System/Library/
PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
0x7fff93e61000 - 0x7fff93e6aff7 libsystem_pthread.dylib
(138.10.4) <3DD1EF4C-1D1B-3ABF-8CC6-B3B1CEEE9559>
/usr/lib/system/libsystem_pthread.dylib
0x7fff956e3000 - 0x7fff95701ff7 libsystem_kernel.dylib
(3248.60.11.5.3) <F8228B30-AF62-3D47-A3A9-4A360787B238>
/usr/lib/system/libsystem_kernel.dylib
OK.
I’ll run the job 1, 2, 3, 
 10 times and see what happens.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I’ve just IPLd MVS again.
Strangely enough, the Hercules CPU is still at 100%.

It's not strange if the re-IPL has enabled a previously running job to
restart.
You really do need to get to the bottom of what the HERC02I job (the one
that's filling the
spool up) is doing. It's that job, probably, that's making Hercules
busy.
--
Jeremy Nicoll - my opinions are my own.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Joe Monk ***@gmail.com [hercules-390]
ITS NOT HERCULES. HERCULES IS MERELY EXECUTING MVS.
YOU NEED TO START JES2 WITH A COLD START AND FORMAT THE SPOOL.
Sorry for the caps..

Yes... and I think (following up my previous post about IPLing without
having
things starting automatically) that after MVS starts etc you'd need to
issue


S JES2,PARM=(COLD,NOREQ)

then when jes says it's started, issue

$P JES2

to stop the newly empty-spool jes,

then shutdown as normal (however that's done), then reipl and try and
get the system
to start automatically. Hopefully it'd then start with the empty spool
and not have the
problems it currently does.

(But I may be wrong. It's been ages since I last did this.)

[Philippe de Rochambeau [e-mail] [hercules-390]]

Joe,
how do you start JES2 with a cold start and format the spool?

Post by Joe Monk ***@gmail.com [hercules-390]
ITS NOT HERCULES. HERCULES IS MERELY EXECUTING MVS.
YOU NEED TO START JES2 WITH A COLD START AND FORMAT THE SPOOL.
Sorry for the caps..
Joe
I can’t log into MVS anymore and Hercule’s CPU usage is back at 100%.
I think that Hercules is damanged. I’ll have to reinstall it.
16/07/2017 14:03:50,000 kernel[0]: process hercules[507] caught causing excessive wakeups. Observed wakeups rate (per sec): 7504; Maximum permitted wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime number of wakeups: 45050
16/07/2017 14:03:51,238 spindump[437]: Saved wakeups_resource.diag report for hercules version ??? (???) to /Library/Logs/DiagnosticReports/hercules_2017-07-16-140351_xxx.wakeups_resource.diag
Powerstats for: spindump
UUID: 9B00539D-D2CA-39A0-8711-B7396488113F
Start time: 2017-07-16 14:03:50 +0200
End time: 2017-07-16 14:03:50 +0200
Microstackshots: 1 samples (16%)
Primary state: 1 samples Non-Frontmost App, Kernel mode, Thread QoS Legacy
User Activity: 0 samples Idle, 1 samples Active
Power Source: 0 samples on Battery, 1 samples on AC
1 start_wqthread + 13 (libsystem_pthread.dylib) [0x7fff93e62341]
1 _pthread_wqthread + 1129 (libsystem_pthread.dylib) [0x7fff93e644de]
1 _dispatch_worker_thread3 + 91 (libdispatch.dylib) [0x7fff88b61b00]
1 _dispatch_root_queue_drain + 1890 (libdispatch.dylib) [0x7fff88b6229b]
1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff88b5e40b]
1 _dispatch_call_block_and_release + 12 (libdispatch.dylib) [0x7fff88b6993d]
1 ??? (spindump + 129010) [0x10d5087f2]
1 ??? (spindump + 34869) [0x10d4f1835]
1 ??? (spindump + 95736) [0x10d5005f8]
1 _dispatch_barrier_sync_f_invoke + 74 (libdispatch.dylib) [0x7fff88b5f9f2]
1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff88b5e40b]
1 ??? (spindump + 96217) [0x10d5007d9]
1 CSSymbolicatorCreateWithPidFlagsAndNotification + 58 (CoreSymbolication) [0x7fff8e0837d6]
1 ??? (CoreSymbolication + 112113) [0x7fff8e0835f1]
1 ??? (CoreSymbolication + 7597) [0x7fff8e069dad]
1 ??? (CoreSymbolication + 12118) [0x7fff8e06af56]
1 ??? (CoreSymbolication + 12443) [0x7fff8e06b09b]
1 ??? (CoreSymbolication + 12622) [0x7fff8e06b14e]
1 ??? (CoreSymbolication + 13230) [0x7fff8e06b3ae]
1 thread_set_exception_ports + 112 (libsystem_kernel.dylib) [0x7fff956f0a71]
1 mach_msg_trap + 10 (libsystem_kernel.dylib) [0x7fff956f3f72]
0x10d4e9000 - 0x10d51afff spindump (197.1) <9B00539D-D2CA-39A0-8711-B7396488113F> /usr/sbin/spindump
0x7fff88b5c000 - 0x7fff88b89fff libdispatch.dylib (501.40.12) <C7499857-61A5-3D7D-A5EA-65DCC8C3DF92> /usr/lib/system/libdispatch.dylib
0x7fff8e068000 - 0x7fff8e0f0fff com.apple.CoreSymbolication 3.1 (58048.1) <C1A1A8DB-8A51-3A21-865A-3CEF22A0E67A> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
0x7fff93e61000 - 0x7fff93e6aff7 libsystem_pthread.dylib (138.10.4) <3DD1EF4C-1D1B-3ABF-8CC6-B3B1CEEE9559> /usr/lib/system/libsystem_pthread.dylib
0x7fff956e3000 - 0x7fff95701ff7 libsystem_kernel.dylib (3248.60.11.5.3) <F8228B30-AF62-3D47-A3A9-4A360787B238> /usr/lib/system/libsystem_kernel.dylib

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
OK.
I’ll run the job 1, 2, 3, 
 10 times and see what happens.

Post by Jeremy Nicoll ***@letterboxes.org [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I’ve just IPLd MVS again.
Strangely enough, the Hercules CPU is still at 100%.

It's not strange if the re-IPL has enabled a previously running job to
restart.
You really do need to get to the bottom of what the HERC02I job (the one
that's filling the
spool up) is doing. It's that job, probably, that's making Hercules
busy.
--
Jeremy Nicoll - my opinions are my own.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Joe,
how do you start JES2 with a cold start and format the spool?

See my previous post. You don't need to format the spool - it's
already formatted. You
just need to empty it (which a cold start will do).

[Joe Monk [e-mail] [hercules-390]]

r xx,cold,format,noreq

to the JES parameters reply where xx= reply num

Joe

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Joe,
how do you start JES2 with a cold start and format the spool?
ITS NOT HERCULES. HERCULES IS MERELY EXECUTING MVS.
YOU NEED TO START JES2 WITH A COLD START AND FORMAT THE SPOOL.
Sorry for the caps..
Joe

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I can’t log into MVS anymore and Hercule’s CPU usage is back at 100%.
I think that Hercules is damanged. I’ll have to reinstall it.
16/07/2017 14:03:50,000 kernel[0]: process hercules[507] caught causing
excessive wakeups. Observed wakeups rate (per sec): 7504; Maximum permitted
wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime
number of wakeups: 45050
16/07/2017 14:03:51,238 spindump[437]: Saved wakeups_resource.diag report
for hercules version ??? (???) to /Library/Logs/DiagnosticReport
s/hercules_2017-07-16-140351_xxx.wakeups_resource.diag
Powerstats for: spindump
UUID: 9B00539D-D2CA-39A0-8711-B7396488113F
Start time: 2017-07-16 14:03:50 +0200
End time: 2017-07-16 14:03:50 +0200
Microstackshots: 1 samples (16%)
Primary state: 1 samples Non-Frontmost App, Kernel mode, Thread QoS Legacy
User Activity: 0 samples Idle, 1 samples Active
Power Source: 0 samples on Battery, 1 samples on AC
1 start_wqthread + 13 (libsystem_pthread.dylib) [0x7fff93e62341]
1 _pthread_wqthread + 1129 (libsystem_pthread.dylib) [0x7fff93e644de]
1 _dispatch_worker_thread3 + 91 (libdispatch.dylib)
[0x7fff88b61b00]
1 _dispatch_root_queue_drain + 1890 (libdispatch.dylib) [0x7fff88b6229b]
1 _dispatch_client_callout + 8 (libdispatch.dylib)
[0x7fff88b5e40b]
1 _dispatch_call_block_and_release + 12 (libdispatch.dylib) [0x7fff88b6993d]
1 ??? (spindump + 129010) [0x10d5087f2]
1 ??? (spindump + 34869) [0x10d4f1835]
1 ??? (spindump + 95736) [0x10d5005f8]
1 _dispatch_barrier_sync_f_invoke + 74
(libdispatch.dylib) [0x7fff88b5f9f2]
1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff88b5e40b]
1 ??? (spindump + 96217) [0x10d5007d9]
1 CSSymbolicatorCreateWithPidFlagsAndNotification
+ 58 (CoreSymbolication) [0x7fff8e0837d6]
1 ??? (CoreSymbolication + 112113) [0x7fff8e0835f1]
1 ??? (CoreSymbolication + 7597) [0x7fff8e069dad]
1 ??? (CoreSymbolication + 12118) [0x7fff8e06af56]
1 ??? (CoreSymbolication + 12443) [0x7fff8e06b09b]
1 ??? (CoreSymbolication + 12622) [0x7fff8e06b14e]
1 ??? (CoreSymbolication + 13230) [0x7fff8e06b3ae]
1 thread_set_exception_ports +
112 (libsystem_kernel.dylib) [0x7fff956f0a71]
1 mach_msg_trap + 10
(libsystem_kernel.dylib) [0x7fff956f3f72]
0x10d4e9000 - 0x10d51afff spindump (197.1)
<9B00539D-D2CA-39A0-8711-B7396488113F> /usr/sbin/spindump
0x7fff88b5c000 - 0x7fff88b89fff libdispatch.dylib (501.40.12)
<C7499857-61A5-3D7D-A5EA-65DCC8C3DF92> /usr/lib/system/libdispatch.dylib
0x7fff8e068000 - 0x7fff8e0f0fff com.apple.CoreSymbolication
3.1 (58048.1) <C1A1A8DB-8A51-3A21-865A-3CEF22A0E67A>
/System/Library/PrivateFrameworks/CoreSymbolication.framewor
k/Versions/A/CoreSymbolication
0x7fff93e61000 - 0x7fff93e6aff7 libsystem_pthread.dylib
(138.10.4) <3DD1EF4C-1D1B-3ABF-8CC6-B3B1CEEE9559>
/usr/lib/system/libsystem_pthread.dylib
0x7fff956e3000 - 0x7fff95701ff7 libsystem_kernel.dylib
(3248.60.11.5.3) <F8228B30-AF62-3D47-A3A9-4A360787B238>
/usr/lib/system/libsystem_kernel.dylib
OK.
I’ll run the job 1, 2, 3, 
 10 times and see what happens.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I’ve just IPLd MVS again.
Strangely enough, the Hercules CPU is still at 100%.

It's not strange if the re-IPL has enabled a previously running job to
restart.
You really do need to get to the bottom of what the HERC02I job (the one
that's filling the
spool up) is doing. It's that job, probably, that's making Hercules
busy.
--
Jeremy Nicoll - my opinions are my own.

[Philippe de Rochambeau [e-mail] [hercules-390]]

Joe,

Is ‘r' a TSO command or a Hercules command?

Furthermore, what’s the ‘reply num’?

Cheers,

Philippe

Post by Joe Monk ***@gmail.com [hercules-390]
r xx,cold,format,noreq
to the JES parameters reply where xx= reply num
Joe
Joe,
how do you start JES2 with a cold start and format the spool?

Post by Joe Monk ***@gmail.com [hercules-390]
ITS NOT HERCULES. HERCULES IS MERELY EXECUTING MVS.
YOU NEED TO START JES2 WITH A COLD START AND FORMAT THE SPOOL.
Sorry for the caps..
Joe
I can’t log into MVS anymore and Hercule’s CPU usage is back at 100%.
I think that Hercules is damanged. I’ll have to reinstall it.
16/07/2017 14:03:50,000 kernel[0]: process hercules[507] caught causing excessive wakeups. Observed wakeups rate (per sec): 7504; Maximum permitted wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime number of wakeups: 45050
16/07/2017 14:03:51,238 spindump[437]: Saved wakeups_resource.diag report for hercules version ??? (???) to /Library/Logs/DiagnosticReports/hercules_2017-07-16-140351_xxx.wakeups_resource.diag
Powerstats for: spindump
UUID: 9B00539D-D2CA-39A0-8711-B7396488113F
Start time: 2017-07-16 14:03:50 +0200
End time: 2017-07-16 14:03:50 +0200
Microstackshots: 1 samples (16%)
Primary state: 1 samples Non-Frontmost App, Kernel mode, Thread QoS Legacy
User Activity: 0 samples Idle, 1 samples Active
Power Source: 0 samples on Battery, 1 samples on AC
1 start_wqthread + 13 (libsystem_pthread.dylib) [0x7fff93e62341]
1 _pthread_wqthread + 1129 (libsystem_pthread.dylib) [0x7fff93e644de]
1 _dispatch_worker_thread3 + 91 (libdispatch.dylib) [0x7fff88b61b00]
1 _dispatch_root_queue_drain + 1890 (libdispatch.dylib) [0x7fff88b6229b]
1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff88b5e40b]
1 _dispatch_call_block_and_release + 12 (libdispatch.dylib) [0x7fff88b6993d]
1 ??? (spindump + 129010) [0x10d5087f2]
1 ??? (spindump + 34869) [0x10d4f1835]
1 ??? (spindump + 95736) [0x10d5005f8]
1 _dispatch_barrier_sync_f_invoke + 74 (libdispatch.dylib) [0x7fff88b5f9f2]
1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff88b5e40b]
1 ??? (spindump + 96217) [0x10d5007d9]
1 CSSymbolicatorCreateWithPidFlagsAndNotification + 58 (CoreSymbolication) [0x7fff8e0837d6]
1 ??? (CoreSymbolication + 112113) [0x7fff8e0835f1]
1 ??? (CoreSymbolication + 7597) [0x7fff8e069dad]
1 ??? (CoreSymbolication + 12118) [0x7fff8e06af56]
1 ??? (CoreSymbolication + 12443) [0x7fff8e06b09b]
1 ??? (CoreSymbolication + 12622) [0x7fff8e06b14e]
1 ??? (CoreSymbolication + 13230) [0x7fff8e06b3ae]
1 thread_set_exception_ports + 112 (libsystem_kernel.dylib) [0x7fff956f0a71]
1 mach_msg_trap + 10 (libsystem_kernel.dylib) [0x7fff956f3f72]
0x10d4e9000 - 0x10d51afff spindump (197.1) <9B00539D-D2CA-39A0-8711-B7396488113F> /usr/sbin/spindump
0x7fff88b5c000 - 0x7fff88b89fff libdispatch.dylib (501.40.12) <C7499857-61A5-3D7D-A5EA-65DCC8C3DF92> /usr/lib/system/libdispatch.dylib
0x7fff8e068000 - 0x7fff8e0f0fff com.apple.CoreSymbolication 3.1 (58048.1) <C1A1A8DB-8A51-3A21-865A-3CEF22A0E67A> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
0x7fff93e61000 - 0x7fff93e6aff7 libsystem_pthread.dylib (138.10.4) <3DD1EF4C-1D1B-3ABF-8CC6-B3B1CEEE9559> /usr/lib/system/libsystem_pthread.dylib
0x7fff956e3000 - 0x7fff95701ff7 libsystem_kernel.dylib (3248.60.11.5.3) <F8228B30-AF62-3D47-A3A9-4A360787B238> /usr/lib/system/libsystem_kernel.dylib

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
OK.
I’ll run the job 1, 2, 3, 
 10 times and see what happens.

Post by Jeremy Nicoll ***@letterboxes.org [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I’ve just IPLd MVS again.
Strangely enough, the Hercules CPU is still at 100%.

It's not strange if the re-IPL has enabled a previously running job to
restart.
You really do need to get to the bottom of what the HERC02I job (the one
that's filling the
spool up) is doing. It's that job, probably, that's making Hercules
busy.
--
Jeremy Nicoll - my opinions are my own.

[Joe Monk [e-mail] [hercules-390]]

During IPL, you should get a message similar to:

*01 $HASP426 SPECIFY OPTIONS - HASP-II, VERSION JES2 4.1

The 01 in that message after the splat is called the reply id... so your
reply would be:

r 01,cold,noreq

which would tell JES2 to cold start the system and kill anything on the
spool.

Joe

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Joe,
Is ‘r' a TSO command or a Hercules command?
Furthermore, what’s the ‘reply num’?
Cheers,
Philippe
r xx,cold,format,noreq
to the JES parameters reply where xx= reply num
Joe

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Joe,
how do you start JES2 with a cold start and format the spool?
ITS NOT HERCULES. HERCULES IS MERELY EXECUTING MVS.
YOU NEED TO START JES2 WITH A COLD START AND FORMAT THE SPOOL.
Sorry for the caps..
Joe

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I can’t log into MVS anymore and Hercule’s CPU usage is back at 100%.
I think that Hercules is damanged. I’ll have to reinstall it.
16/07/2017 14:03:50,000 kernel[0]: process hercules[507] caught causing
excessive wakeups. Observed wakeups rate (per sec): 7504; Maximum permitted
wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime
number of wakeups: 45050
16/07/2017 14:03:51,238 spindump[437]: Saved wakeups_resource.diag
report for hercules version ??? (???) to /Library/Logs/DiagnosticReport
s/hercules_2017-07-16-140351_xxx.wakeups_resource.diag
Powerstats for: spindump
UUID: 9B00539D-D2CA-39A0-8711-B7396488113F
Start time: 2017-07-16 14:03:50 +0200
End time: 2017-07-16 14:03:50 +0200
Microstackshots: 1 samples (16%)
Primary state: 1 samples Non-Frontmost App, Kernel mode, Thread QoS Legacy
User Activity: 0 samples Idle, 1 samples Active
Power Source: 0 samples on Battery, 1 samples on AC
1 start_wqthread + 13 (libsystem_pthread.dylib) [0x7fff93e62341]
1 _pthread_wqthread + 1129 (libsystem_pthread.dylib)
[0x7fff93e644de]
1 _dispatch_worker_thread3 + 91 (libdispatch.dylib)
[0x7fff88b61b00]
1 _dispatch_root_queue_drain + 1890 (libdispatch.dylib) [0x7fff88b6229b]
1 _dispatch_client_callout + 8 (libdispatch.dylib)
[0x7fff88b5e40b]
1 _dispatch_call_block_and_release + 12 (libdispatch.dylib)
[0x7fff88b6993d]
1 ??? (spindump + 129010) [0x10d5087f2]
1 ??? (spindump + 34869) [0x10d4f1835]
1 ??? (spindump + 95736) [0x10d5005f8]
1 _dispatch_barrier_sync_f_invoke + 74
(libdispatch.dylib) [0x7fff88b5f9f2]
1 _dispatch_client_callout + 8
(libdispatch.dylib) [0x7fff88b5e40b]
1 ??? (spindump + 96217) [0x10d5007d9]
1 CSSymbolicatorCreateWithPidFlagsAndNotification
+ 58 (CoreSymbolication) [0x7fff8e0837d6]
1 ??? (CoreSymbolication + 112113) [0x7fff8e0835f1]
1 ??? (CoreSymbolication + 7597) [0x7fff8e069dad]
1 ??? (CoreSymbolication + 12118) [0x7fff8e06af56]
1 ??? (CoreSymbolication + 12443) [0x7fff8e06b09b]
1 ??? (CoreSymbolication + 12622) [0x7fff8e06b14e]
1 ??? (CoreSymbolication + 13230)
[0x7fff8e06b3ae]
1 thread_set_exception_ports +
112 (libsystem_kernel.dylib) [0x7fff956f0a71]
1 mach_msg_trap + 10
(libsystem_kernel.dylib) [0x7fff956f3f72]
0x10d4e9000 - 0x10d51afff spindump (197.1)
<9B00539D-D2CA-39A0-8711-B7396488113F> /usr/sbin/spindump
0x7fff88b5c000 - 0x7fff88b89fff libdispatch.dylib
(501.40.12) <C7499857-61A5-3D7D-A5EA-65DCC8C3DF92>
/usr/lib/system/libdispatch.dylib
0x7fff8e068000 - 0x7fff8e0f0fff com.apple.CoreSymbolication
3.1 (58048.1) <C1A1A8DB-8A51-3A21-865A-3CEF22A0E67A>
/System/Library/PrivateFrameworks/CoreSymbolication.framewor
k/Versions/A/CoreSymbolication
0x7fff93e61000 - 0x7fff93e6aff7 libsystem_pthread.dylib
(138.10.4) <3DD1EF4C-1D1B-3ABF-8CC6-B3B1CEEE9559>
/usr/lib/system/libsystem_pthread.dylib
0x7fff956e3000 - 0x7fff95701ff7 libsystem_kernel.dylib
(3248.60.11.5.3) <F8228B30-AF62-3D47-A3A9-4A360787B238>
/usr/lib/system/libsystem_kernel.dylib
OK.
I’ll run the job 1, 2, 3, 
 10 times and see what happens.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
I’ve just IPLd MVS again.
Strangely enough, the Hercules CPU is still at 100%.

It's not strange if the re-IPL has enabled a previously running job to
restart.
You really do need to get to the bottom of what the HERC02I job (the one
that's filling the
spool up) is doing. It's that job, probably, that's making Hercules
busy.
--
Jeremy Nicoll - my opinions are my own.

[Gerhard Postpischil [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Is ‘r' a TSO command or a Hercules command?
Furthermore, what’s the ‘reply num’?

You never got an answer to your question. "r" is short for reply, and it
is a system command to reply to a question displayed on the console.

In a system with multiple jobs and multiple consoles, having a single
reply would be a huge bottleneck. So the console task keeps track of
questions (WTOR - Write To Operator with Reply) by assigning a unique
number to each. Numbers are incremented until they reach 99, then go
back to 00.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Philippe de Rochambeau [e-mail] [hercules-390]]

Interesting.

You fellows on this list are living encyclopaedias :-)

Post by Gerhard Postpischil ***@charter.net [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Is ‘r' a TSO command or a Hercules command?
Furthermore, what’s the ‘reply num’?

You never got an answer to your question. "r" is short for reply, and it
is a system command to reply to a question displayed on the console.
In a system with multiple jobs and multiple consoles, having a single
reply would be a huge bottleneck. So the console task keeps track of
questions (WTOR - Write To Operator with Reply) by assigning a unique
number to each. Numbers are incremented until they reach 99, then go
back to 00.
Gerhard Postpischil
Bradford, VT
---
This email has been checked for viruses by AVG.
http://www.avg.com <http://www.avg.com/>

[Philippe de Rochambeau [e-mail] [hercules-390]]

There’s no trace of $HASP426 in tk4-’s log, although the following lines appear

21:51:04 IEF677I WARNING MESSAGE(S) FOR JOB JES2 ISSUED
21:51:04 $HASP493 JES2 QUICK-START IS IN PROGRESS

Post by Gerhard Postpischil ***@charter.net [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Is ‘r' a TSO command or a Hercules command?
Furthermore, what’s the ‘reply num’?

You never got an answer to your question. "r" is short for reply, and it
is a system command to reply to a question displayed on the console.
In a system with multiple jobs and multiple consoles, having a single
reply would be a huge bottleneck. So the console task keeps track of
questions (WTOR - Write To Operator with Reply) by assigning a unique
number to each. Numbers are incremented until they reach 99, then go
back to 00.
Gerhard Postpischil
Bradford, VT
---
This email has been checked for viruses by AVG.
http://www.avg.com <http://www.avg.com/>

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
There’s no trace of $HASP426 in tk4-’s log, although the following lines appear
21:51:04 IEF677I WARNING MESSAGE(S) FOR JOB JES2 ISSUED
21:51:04 $HASP493 JES2 QUICK-START IS IN PROGRESS

I think you're using a pre-defined startup of the system that just tells
MVS what to do.

I think you need to ipl mvs and tell it not to start everything, then
manually start jes
(as I said in an earlier reply), do that so it does a cold start, then
shutdown and re-ipl
in whatever your normal method is.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
The emulator says 100% CPU and MacOSX says that Hercules takes up 102%+
of the CPU. I can email you screenshots, if you want.
My CPU is a quad-core Intel i7.
I’m not sure about tools being available to investigate a looping
program, but I can find out. MacOSX is a BSD-based OS, so there’s bound
to be such tools.

Presumably that means either 4 threads (or maybe 8 if your cpu has
hyperthreading and
Mac OS can take advantage) are all running at once.

There must be tools - maybe even in the Mac OS - that will tell you how
many cores or
threads are executing Hercules stuff. How easy it is to identify which
ones are running
the emulator itself vv its workload, I don't know. Any maybe the
emulator and emulated
os don't get divided up into threads that make sense externally anyway.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Yes, you can still type commands in the MVS emulator.

Maybe repeated D A,L would show something?

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
---------------
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1750000

But that's a different job - HERC02I is not HERC02T

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1755000
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1760000
11.25.03 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1765000
11.25.04 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1770000
11.25.04 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1775000
11.25.04 JOB 147 $HASP375 HERC02I ESTIMATED LINES EXCEEDED BY
1780000
11.25.04 $HASP355 SPOOL VOLUMES ARE FULL

If you can recreate this, as soon as you see an 'estimated lines
exceeded' message
cancel the job that's doing it, ie issue at the console C jobname

I wonder if there's any clue (maybe an error message?) being written
hundreds of
thousands of times to a sysout dataset.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Closing the terminal window doesn’t kill hercules. I have to manually
kill it in the Activity Monitor.
- I can’t read the log after running the program because MVS is frozen
(i.e., typing commands in c3270 has no effect).

If you change the proc used from a compile & go one, to one that just
compiles
does the the compiler run with a zero completeion code (ie no warnings)?

[[e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Running this code causes the 100% CPU issue.
while( (song(99), exit(0), 0) ) {}

It's a long shot, but try changing 99 to 3.
You might be exceeding the hardcoded
stack size.

Otherwise, as was previously mentioned,
you need to cancel the job when it issues
"lines exceeded" and then show us the
output. Just a bit of the output, not
thousands of pages.

BFN. Paul.

[Harold Grovesteen [e-mail] [hercules-390]]

Hercules hogging the host CPU is indicative of a program loop.  That is
a normal result of this condition.

Has anyone actually looked at the C code to determine if it makes
sense?

This looks to be using the JCC rather than the GCC compiler.  Responses
assuming GCC may not apply.

Harold Grovesteen

On Sun, 2017-07-16 at 11:53 +0200, Philippe de Rochambeau

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hi all,
Running this code causes the 100% CPU issue.
-------------------------------------------------------------------
--------
//HERC02T JOB (SETUP),
//            'Test JCC',
//            CLASS=A,
//            MSGCLASS=H,
//            REGION=8M,
//            MSGLEVEL=(1,1)
//*******************************************************************
*
//*
//* Name: SYS2.JCLLIB(TESTJCC)
//*
//* Desc: JCC compile and go
//*
//*******************************************************************
*
//*
//BEER    EXEC JCCCG
//COMPILE.SYSIN DD *
#include <stdio.h>
#include <stdlib.h>
static void song( int bottles )
{
 while( (printf(" %d bottles of beer on the wall, %d bottles of
beer.\n"
      " Take one down and pass it around, %d bottle%s of beer on the
wall.\n\n",
         bottles, bottles, bottles-1, bottles>2? "s":""), bottles >
2) )
  while( (--bottles,0) ) {}
 while( (puts(" 1 bottle of beer on the wall, 1 bottle of beer.\n"
   " Take one down and pass it around, no more bottles of beer on the
wall.\n\n"
      " No more bottles of beer on the wall, no more bottles of
beer.\n"
  " Go to the store and buy some more, 99 bottles of beer on the
wall."),0) ) {}
}
int main()
{
 while( (song(99), exit(0), 0) ) {}
}
/*
//

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
r

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hi Paul,
 
as you can tell, I’m a Hercules + MVS newbie fumbling in the dark

:-)

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
 
I added the following line to the end of my JCL program
 

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//COMP.SYSOUT DD

SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

Post by Philippe de Rochambeau ***@free.fr [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
 

 
hoping that it would redirect the output to SYSOUT.

That might work if the step of the procedure that runs the compiled job
is named "COMP",
and if your program defines an output device whose name is
"SYSOUT".
But it's more common to write to something called "SYSPRINT".
Does your program actually write to "//SYSOUT DD ..." ?  

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
To answer your question, the 100% CPU issue is the reason why

I’ve

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
written to this list.

When did the 100% cpu use start?  
Was it around the time you were submitting jobs?
Does it ever recover (ie cpu drop to something reasonable) if you leave
it alone?
Do you have any other jobs running at the time?
Has this happened more than once?
-- 
Jeremy Nicoll - my opinions are my own.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Before I added that line, the program ran OK, but didn’t display any output.

Hang on... the ONLY thing your sample program is meant to do is
display output.
So if it "ran OK, but didn’t display any output", what did it do?

How do you know it "ran ok"?

[Philippe de Rochambeau [e-mail] [hercules-390]]

Hi Jeremy,

after submitting the following job a few minutes ago, the « Hello World! » output appeared in the log.

I now know how to write to STDOUT.

Thank you for your help.



—————

//HERC02A JOB (SETUP),
// 'Test GCC',
// CLASS=A,
// MSGCLASS=H,
// REGION=8M,
// MSGLEVEL=(1,1)
//*
//* NAME: HERC02.CCODE.SOURCE(HEL1)
//*
//S1 EXEC GCCCLG,COPTS='-v'
//COMP.SYSIN DD *
#include <stdio.h>
#include <stdlib.h>

int main()
{
printf("Hello World!\n");
}


———

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Before I added that line, the program ran OK, but didn’t display any output.

Hang on... the ONLY thing your sample program is meant to do is
display output.
So if it "ran OK, but didn’t display any output", what did it do?
How do you know it "ran ok"?
--
Jeremy Nicoll - my opinions are my own.

['Dave Wade' [e-mail] [hercules-390]]

Folks,

Is there any concept of ROOT on MacOS. I see that Hercules was unable to adjust the priority of the background i/o thread. If it’s a single CPU/Core then it may be the I/O thread is getting swamped..

Dave



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 16 July 2017 10:30
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-390] Re: Hercules hogs 100% CPU








Hi Paul,



as you can tell, I’m a Hercules + MVS newbie fumbling in the dark :-)



I added the following line to the end of my JCL program



//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)



hoping that it would redirect the output to SYSOUT.



Before I added that line, the program ran OK, but didn’t display any output.



To answer your question, the 100% CPU issue is the reason why I’ve written to this list.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Submitting the JCL program below 3 times with the following line at the end
/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)
and three times with the following line at the end
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

BTW, where did you see this
"COMP.SYSOUT"? I just checked
my copy of gccclg.prc and it does
not have any such DD statement:

C:\devel\gcc\gcc>grep SYSOUT gccclg.prc
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*

C:\devel\gcc\gcc>

In addition, PDPCLIB doesn't support
RECFM=FBA and I don't know what
happens when you use it.

Also, what are you concerned the most
about? High CPU or your compile and
run not working?

BFN. Paul.

[Guy Sotomayor Jr [e-mail] [hercules-390]]

Yes. OS X is Unix (has actually received the certification from x/open making it the largest install base of Unix). You typically don’t log in to root directly. You’ll typically “sudo”.

TTFN - Guy

Post by 'Dave Wade' ***@gmail.com [hercules-390]
Folks,
Is there any concept of ROOT on MacOS. I see that Hercules was unable to adjust the priority of the background i/o thread. If it’s a single CPU/Core then it may be the I/O thread is getting swamped..
Dave
  <>
Sent: 16 July 2017 10:30
Subject: Re: [hercules-390] Re: Hercules hogs 100% CPU
Hi Paul,
as you can tell, I’m a Hercules + MVS newbie fumbling in the dark :-)
I added the following line to the end of my JCL program

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

hoping that it would redirect the output to SYSOUT.
Before I added that line, the program ran OK, but didn’t display any output.
To answer your question, the 100% CPU issue is the reason why I’ve written to this list.

Post by Philippe de Rochambeau ***@free.fr [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Submitting the JCL program below 3 times with the following line at the end
/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)
and three times with the following line at the end
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

BTW, where did you see this
"COMP.SYSOUT"? I just checked
my copy of gccclg.prc and it does
C:\devel\gcc\gcc>grep SYSOUT gccclg.prc
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
C:\devel\gcc\gcc>
In addition, PDPCLIB doesn't support
RECFM=FBA and I don't know what
happens when you use it.
Also, what are you concerned the most
about? High CPU or your compile and
run not working?
BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

"In addition, PDPCLIB doesn't support
RECFM=FBA and I don't know what
happens when you use it."

It doesnt have to. MVS does. The "A" on the end means that column 1 is the
carriage control for the printer, and MVS automatically move the text over
1 character. So, when PDPCLIB writes a skip to the top of the page, that
will be represented by the number "1" in the first column, followed by the
printed text in the remainder of the line.

Joe

Post by ***@yahoo.com.au [hercules-390]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Submitting the JCL program below 3 times with the following line at the

end

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)
and three times with the following line at the end
//COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

BTW, where did you see this
"COMP.SYSOUT"? I just checked
my copy of gccclg.prc and it does
C:\devel\gcc\gcc>grep SYSOUT gccclg.prc
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
C:\devel\gcc\gcc>
In addition, PDPCLIB doesn't support
RECFM=FBA and I don't know what
happens when you use it.
Also, what are you concerned the most
about? High CPU or your compile and
run not working?
BFN. Paul.

[Jeremy Nicoll [e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
Hi Jeremy,
here’s the JCL job as it was right before Hercules hogged 100% of my CPU.

OK, /THIS/ JCL is the jcl that did not get run because of the invalid
"/*" lines. Whereas
a line starting "//*" is ok as a comment, "/*" lines are not. The're
known as JECL lines
and need to have a keyword immediately after the asterisk, eg
"/*JOBPARM".

In the syslog you showed at the start of this thread there was a
6-minute period between
the JCL being rejected and you printing something.

When did the 100% cpu problem start?



As Paul pointed out, I mistakenly assumed that this problem is the
same thing as your
earlier posts with the same subject. Do you think it's a different
problem?

Did you find out why your earlier job was creating hundreds of thousands
of lines of
print at the same time that it (or something else) was causing Hercules
to use 100%
cpu?

Is that 100% cpu figure something that your underlying OS told you about
(MAC OS??)
or something that the emulator said about the emulated hardware?

[[e-mail] [hercules-390]]

Post by Philippe de Rochambeau ***@free.fr [hercules-390]
here’s the JCL job

Took me a while to figure this one out.

This line is incorrect:

/*COMP.SYSOUT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=161,BLKSIZE=16100)

Either delete it, or add another "/", so
that it becomes:

//*COM...

which is a comment.

You should probably move MVS
problems like this to H390-MVS.

BFN. Paul.