开云体育

On Fri, 18 Sep 2020, Greg Price wrote:

On 2020-09-18 4:14 AM, Jay Moseley wrote:

I have never had anyone make a suggestion that I change any JES2 parameters.

Well, you probably shouldn't have to...

Since I am used to never printing any of my jobs, I direct my batch jobs to a HELD SYSOUT class, which also facilitates viewing the SYSOUT via the TSO OUTPUT command (and any front end to that such as RFE, RPF, etc.).

HELD SYSOUT output groups do not use any JOEs at this level of JES2.

Well, Greg, of course it is a personal preference.

I had not any intention to require a change for the
"Moseley SYSGEN" with my post, the only goal was
an advice, a reference, to a possible JES2PARM
parameter which may solve the issue, if it happens
a user fall in this trap.

From the other side, Juergen Winkelmann, probably,
choosed a larger value for his TK4-. The parameter
is still 500 in TK3/TK3UP (I verified), so it has
been changed to 1200 somewhere between TK3UP and TK4-.

If it has been Juergen, to commit this change to
TK4 JES2PARM, I had never regret to follow a Juergen
advice :-)

Peppe.

On 2020-09-18 4:14 AM, Jay Moseley wrote:

I have never had anyone make a suggestion that I change any JES2 parameters.

Well, you probably shouldn't have to...

Since I am used to never printing any of my jobs, I direct my batch jobs to a HELD SYSOUT class, which also facilitates viewing the SYSOUT via the TSO OUTPUT command (and any front end to that such as RFE, RPF, etc.).

HELD SYSOUT output groups do not use any JOEs at this level of JES2.

Cheers,
Greg

On 9/17/20 12:33 PM, Giuseppe Vitillaro wrote:

This is a problem I faced when I began to use my Moseley
sysgen, coming from TK4-.
Not sure if I did the right thing, but, as the problem seems
to recurr, specially if you keep your MVS3.8j up for long times,
I looked to the TK4- JES2PARM, trying to understand why TK4-
doesn't show this problem, at least it didn't show up for my
average use.
The difference I've found is how the Moseley sysgen jobs
configure this JES2PARM parameter:
sysgen02.jcl:&NUMJOES=512?????????????????? NUMBER OF JOB OUTPUT ELEMENTS
where TK4- has:
&NUMJOES=1200????????????????????? NO. OF JOES
So, I changed this parm in my personal sysgen jobs to
the TK4- default.
Never seen this problem again.
Yet :-)
Peppe.

Thanks for supplying this. I just put together a page talking about JES2 queue elements that will address some of these problems - . I will probably add some additional information there, and can include suggested changes. As I say on the page, the parameters I use were assembled from a set of several JES2 parameter sets shared to the Hercules forums over the decades and then tweaked by suggestions provided in forum discussions. I have never had anyone make a suggestion that I change any JES2 parameters. I keep my queue almost empty, so I have rarely had problems.

Regards,
Jay

And I've a great respect for the MVS3.8j parameters stored by your JCL in the SYS1.PARMLIB dataset, I barely changed a couple of them for multiple JES2 spool volumes and these NUMJOES parm, I actually got from TK4-.

This parm actually become a trouble if a lazy user, like me, have developed the bad habit to keep a large number of jobs stored on large spool volumes.

I vaguely remember I verified in the IBM JES2 4.x manuals these change shouldn't give any side effect, beside solving this issue. But my experience is just the experience of an hercules MVS hobbyst.

Starting from your MVS3.8j sysgen JCL I've developed, using a "Moseley MVS3.8j base sysgen" as a "starter kit", like you used the MVS3.7 starter kit, without VTAM/TSO interactive env, just the base JES2 system, a "personal set" of sysgen JCL scripts, which I adapted to build what I call a "Moseley-Volker sysgen", an hybrid between your sysgen and the Volker TK3/TK4- sysgen, with most, if not all, the PTF and USERMOD required to get a system which aim to be "compatible" with both environments.

Not sure I succeeded, but, at least, my MV-MVS3.8j looks stable over time and correcly run what I tested from your SYSCPK volume and looks reasonable similar to TK4-, although my scripts are still a mess
of patched JCL and notes I kept in my logbooks.

Thanks again for your precious hard work, from your work I got basically everything I know about MVS.

Regards, Peppe.

On 9/17/20 12:33 PM, Giuseppe Vitillaro wrote:

This is a problem I faced when I began to use my Moseley
sysgen, coming from TK4-.
Not sure if I did the right thing, but, as the problem seems
to recurr, specially if you keep your MVS3.8j up for long times,
I looked to the TK4- JES2PARM, trying to understand why TK4-
doesn't show this problem, at least it didn't show up for my
average use.
The difference I've found is how the Moseley sysgen jobs
configure this JES2PARM parameter:
sysgen02.jcl:&NUMJOES=512?????????????????? NUMBER OF JOB OUTPUT ELEMENTS
where TK4- has:
&NUMJOES=1200????????????????????? NO. OF JOES
So, I changed this parm in my personal sysgen jobs to
the TK4- default.
Never seen this problem again.
Yet :-)
Peppe.

Thanks for supplying this. I just put together a page talking about JES2 queue elements that will address some of these problems - . I will probably add some additional information there, and can include suggested changes. As I say on the page, the parameters I use were assembled from a set of several JES2 parameter sets shared to the Hercules forums over the decades and then tweaked by suggestions provided in forum discussions. I have never had anyone make a suggestion that I change any JES2 parameters. I keep my queue almost empty, so I have rarely had problems.

Regards,
Jay

On Wed, 16 Sep 2020, blametroi@... wrote:

I see this has been asked once before, but if there was a resolution I didn't
understand it.
I'm running MVS3.8j built from Jay Moseley's instructions with no mods yet. I've been
running without problem for several days but when I tried logging into TSO after
leaving the system idle for the afternoon my TSO logon session locked up and I saw
$HASP050 JES2 RESOURCE SHORTAGE. CODE = JQES on the console.

This is a problem I faced when I began to use my Moseley
sysgen, coming from TK4-.

Not sure if I did the right thing, but, as the problem seems
to recurr, specially if you keep your MVS3.8j up for long times,
I looked to the TK4- JES2PARM, trying to understand why TK4-
doesn't show this problem, at least it didn't show up for my
average use.

The difference I've found is how the Moseley sysgen jobs
configure this JES2PARM parameter:

sysgen02.jcl:&NUMJOES=512 NUMBER OF JOB OUTPUT ELEMENTS

where TK4- has:

&NUMJOES=1200 NO. OF JOES

So, I changed this parm in my personal sysgen jobs to
the TK4- default.

Never seen this problem again.

Yet :-)

Peppe.

And thanks also Joe and Kevin. I had guessed that I could just do a
reformat but didn't want to do so without knowing more. I'd also
forgotten that bit from the FAQ. I did read everything but I won't
claim to have retained enough :) Happily learning here.

Troy,

On Thu, Sep 17, 2020 at 06:32:59AM -0400, BlameTroi wrote:

APF and exits still be to researched, but I was able to purge the
output from the operator console once I used `QUEUE ST *` to find job
numbers (and started tasks and terminal users) via `$C Jxxx,p`.

Or, from Jay Moseley's JES2 FAQ page:



$PS1-9999 purge all started task output
$PT1-9999 purge all TSO output
$PJ1-9999 purge all batch job output



--

Kevin



Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.

APF and exits still be to researched, but I was able to purge the
output from the operator console once I used `QUEUE ST *` to find job
numbers (and started tasks and terminal users) via `$C Jxxx,p`.

Problem solved well enough for now and in an understandable manner.
One to the next thing.

Thanks again,

Troy.

Thanks all.

Greg, that's some good stuff to sink my teeth into. Fun day of research ahead. Or maybe days :)

Regardless, it'll be fun digging in.

On 2020-09-17 12:52 PM, Rahim Azizarab via groups.io wrote:

Re-ipl your system; and start with a could ipl? r 0,clpa,cmd=co.

Er, I don't think the CLPA has much to do with it...

Yes, there are numerous types of "cold" starts - MVS, JES2, CICS, etc. but the one relevant to the spool is a JES2 cold start.

CLPA - clear link pack area - that is, rebuild the PLPA - is what is referred to as a "cold start IPL".
CVIO - clear VIO - is referred to as a "quick start IPL".
Neither CLLPA nor CVIO gives what is known as a "warm start IPL".

The info below is from memory, so check it out yourself, but...

A JES2 cold start will wipe everything from the spool.
S JES2,PARM=COLD is one way to do that.

A cold start option is to format the spool.
S JES2,PARM='COLD,FORMAT' might cause that to happen.

The usual start is a warm start caused by something like
S JES2,PARM='WARM,NOREQ'

If JES2 crashes - "by itself" or from a $PJES2,ABEND - such that other jobs are still running (until hitting a wait waiting for JES2 services like allocating more spool space) - and JES2 is restarted, this is known as a hot start.

Various parameter changes are ignored on a hot start.

Changing some parameters such as MAXJOBS and NUMJOES will stop a JES2 warm start because they require a cold start to be changed - because they affect the structure of the data in the JES2 checkpoint data set.

_____________________________________

How to purge jobs from TSO:

Method 1

Register QUEUE as an APF authorized TSO command (or give it an alias that already is and invoke it using that name).
Use a TSO user ID that can issue the OPERATOR (OPER for short) TSO command.
Issue QUEUE STATUS * and put P beside the job(s) you want to purge and press <enter>.

If you only have a 20th century version of QUEUE then issue CAN jobid P for each job.


Method 2

Install a version of IKJEFF53 which allows user IDs to use the CANCEL and OUPUT TSO commands for any job name.
My preferred logic is to restrict this ability to users with the OPER privilege - but it's your system.

Go into RFE option 3.8 and issue ST * and put P beside the job(s) you want to purge and press <enter>.

With the IBM-supplied IKJEFF53 you will only be able to process jobs with names beginning with your TSO user ID.

Member IKJEFF53 of CBT file 134 contains a suitable version.


Cheers,
Greg

I see this has been asked once before, but if there was a resolution I didn't understand it.

I'm running MVS3.8j built from Jay Moseley's instructions with no mods yet. I've been running without problem for several days but when I tried logging into TSO after leaving the system idle for the afternoon my TSO logon session locked up and I saw $HASP050 JES2 RESOURCE SHORTAGE. CODE = JQES on the console.

I'm new to JES, old school VM/VSE operator here, and everything I saw to try in the manuals wasn't helpful.

There are many old jobs that I recognize in (I think) class Y, plus the started tasks such as ZTIMER.

I'm unable to remove these entries from the system, I've tried from the console and from QUEUE in TSO. At some point I was able to get into TSO and deleted/purged the three listings I'd left in the queue, but there's still a ton of stuff out there. Looking at the output from $DN I see jobs from the SYSGEN, the ZTIMERs, some TSO logons, and so on.

$DN returned 121 jobs, and spool utilization was 4%.

I could do a cold start/reformat but that doesn't seem like the right thing to do. Ideas/guidance?

Sample from console:

STC   93  $HASP000 TSO      PRT LOCAL    PUN LOCAL    PRIO 14 ANY
STC   92  $HASP000 NET      PRT LOCAL    PUN LOCAL    PRIO 14 ANY
STC   89  $HASP000 INIT     PRT LOCAL    PUN LOCAL    PRIO 14 ANY
STC   91  $HASP000 INIT     PRT LOCAL    PUN LOCAL    PRIO 14 ANY
STC   90  $HASP000 INIT     PRT LOCAL    PUN LOCAL    PRIO 14 ANY
STC  101  $HASP000 SETPFKEY PRT LOCAL    PUN LOCAL    PRIO 14 ANY
STC  102  $HASP000 ZTIMER   PRT LOCAL    PUN LOCAL    PRIO 14 ANY
STC  107  $HASP000 TSO      PRT LOCAL    PUN LOCAL    PRIO 13 ANY
STC  106  $HASP000 NET      PRT LOCAL    PUN LOCAL    PRIO 13 ANY
STC  103  $HASP000 INIT     PRT LOCAL    PUN LOCAL    PRIO 13 ANY
STC  105  $HASP000 INIT     PRT LOCAL    PUN LOCAL    PRIO 13 ANY
STC  104  $HASP000 INIT     PRT LOCAL    PUN LOCAL    PRIO 13 ANY
STC  109  $HASP000 SETPFKEY PRT LOCAL    PUN LOCAL    PRIO 13 ANY
STC  110  $HASP000 ZTIMER   PRT LOCAL    PUN LOCAL    PRIO 13 ANY
STC  116  $HASP000 ZTIMER   PRT LOCAL    PUN LOCAL    PRIO 11 ANY

Thanks,

Troy.

Hello James,

Am 16.09.2020 um 06:47 schrieb James Butler via groups.io <jnbutler1815@...>:

That's what I have Joe, TK4-

It's important to be precise in your descriptions, so people know what's meant instead of guessing. ;-)

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE -

Hello,

Am 15.09.2020 um 20:35 schrieb jnbutler1815 via groups.io <jnbutler1815@...>:

I have Hercules started and when I start MVS it says it is waiting for port 3270 to become free.

This sounds if some application (or another instance of Hercules) is already running on Port 3270.

You can search manually with netstat in the terminal, or just reboot and see if that fixes the issue.

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE -