Makes me wonder if anything unusual is returned from $D PERFDATA or MASDEF with
regards to this *feature* mod.
Mark Zelden <[EMAIL PROTECTED]> wrote: On Thu, 3 Apr 2008 12:47:59 -0700,
Edward Jaffe
wrote:
>Mark Zelden wrote:
>> On Thu, 3 Apr 2008 14:27:11 -0400, Craddock, Chris
>> wrote:
>>
On Thu, 3 Apr 2008 12:47:59 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:
>Mark Zelden wrote:
>> On Thu, 3 Apr 2008 14:27:11 -0400, Craddock, Chris <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Yes the job can run anywhere that has an available initiator for the job
>>> class. However as a practical matte
Ed said;
> ROTFLMAO! This JES2 job scheduling design flaw has been around since
> before I started programming for a living!
Aw geez Ed, don't sit on the fence. Tell us what you really think :-)
--
For IBM-MAIN subscribe / signof
Mark Zelden wrote:
On Thu, 3 Apr 2008 14:27:11 -0400, Craddock, Chris <[EMAIL PROTECTED]>
wrote:
Yes the job can run anywhere that has an available initiator for the job
class. However as a practical matter (at least with JES2) the job almost
always runs on the same system where it is submitt
Sorry, I should have looked before I typed. It is on the INTRDR
statement:
$HASP838 INTRDR AUTH=(DEVICE=NO,JOB=YES,SYSTEM=YES),BATCH=YES,
$HASP838 CLASS=A,HOLD=NO,HONORLIM=NO,PRTYINC=0,
$HASP838 PRTYLIM=15,SYSAFF=(LPR3),TRACE=NO
Z/os 1.7.
When the
On Thu, 3 Apr 2008 14:27:11 -0400, Craddock, Chris <[EMAIL PROTECTED]>
wrote:
>> If you do not use a SYSAFF card thereby taking the default of
>SYSAFF=ANY
>> will a job run only on the LPAR that it is submitted from? Can it ever
>run
>> on an LPAR other than the
Oh? What level of JES2 allows for a SYSAFF setting on the JOBCLASS ?
INTRDR has a SYSAFF. JOBCLASS has a QAFF (at least on z/OS 1.8 JES2).
But I'm not recalling any vaguely current JES2 with SYSAFF on JOBCLASS...
-
On Thu, 3 Apr 2008 13:44:49 -0500, Hal Merritt wrote:
>Well,
Well, actually, there is no default. The action taken depends on the
SYSAFF setting for the job class. And I'm too lazy to look up -that-
default :-)
Our scheduler runs on a 'penalty box' (an LPAR capped to save on
software costs) and submits jobs there as do our TSO users. Ho
> If you do not use a SYSAFF card thereby taking the default of
SYSAFF=ANY
> will a job run only on the LPAR that it is submitted from? Can it ever
run
> on an LPAR other than the one submitted without a SYSAFF card?
Yes the job can run anywhere that has an available initiator for the
Yes, the default is SYSAFF=ANY, which will allow the job to run in any system
in the MAS. There is a command which can be executed at JES2 initialization
(from the init parms), that will set the INTRDR default to *, which will
effectivly change the default so that jobs will run only on the
and delete this e-mail from your system.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Bill Johnson
Sent: Thursday, April 03, 2008 11:35 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: SYSAFF card
If you do not use a SYSAFF card thereby taking the
Bill Johnson wrote:
> If you do not use a SYSAFF card thereby taking the default of SYSAFF=ANY will
> a job run only on the LPAR that it is submitted from? Can it ever run on an
> LPAR other than the one submitted without a SYSAFF card?
>
> TIA
>
> Bill Johns
If you do not use a SYSAFF card thereby taking the default of SYSAFF=ANY will a
job run only on the LPAR that it is submitted from? Can it ever run on an LPAR
other than the one submitted without a SYSAFF card?
TIA
Bill Johnson
-
You rock
1) STATUS=ACTIVE,PERCENT=1
>$HASP893 VOLUME(SPOO04) STATUS=ACTIVE,PERCENT=62
>
>After, I've thrown 3 jobs, for diferent systems, and each job has gone to the
>SPOO01.
>
>I begin thinking that the jobs choose the SPOOL disc with minor percentage,
>in this case SPOO01. If
've thrown 3 jobs, for diferent systems, and each job has gone to the
SPOO01.
I begin thinking that the jobs choose the SPOOL disc with minor percentage,
in this case SPOO01. If this hypothesis is true, what is the SYSAFF parameter
us
Raquel,
Is it possible that spool volume SPOO04 is full?
I've experienced that if a SYSAFF assigned spool volume fills, other spool
volumes in the JES2 MAS will be used so a given JES2 does not halt. IBM has
confirmed this as a normal operation.
Hope this helps,
Paul
On Wed, 5 Dec
Hi,
we have a 3-way-sysplex (SYSA/SYSB/SYSC) with z/OS 1.8 (JES2 MAS).
We want to divert joblogs to a specific disc of SPOOL according to the CPU
executions of each one.
With this command /$TSPL(SPOO0%),SYSAFF=SYS% we've assign a disc of
SPOOL for each system. We
On Wed, 29 Aug 2007 10:49:15 -0500, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:
>On Wed, 29 Aug 2007 15:02:27 +, Ted MacNEIL wrote:
>
>>This has been discussed many times.
>>IBM's design choice is based on a simple premise:
>>When do you convert the system symbols?
>>On the submitting system?
>>
>NJE is NJE. You're thinking of RJE vs RJP.
IIRC, it was called NJP 23 years ago, when I worked in a JES3 shop.
Of course, I only have my memory to go by.
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff /
Ted MacNEIL wrote:
And why does NJE make a difference?
Where do you convert? At the sending or the receiving site?
(NJP is not in my vocabulary).
Network Job Processing (JES3)
NJE is NJE. You're thinking of RJE vs RJP.
--
Edward E Jaffe
Phoenix Software International, Inc
>Rhetorical questions: Why not, then, allow the programmer, through a control
>statement or symbol qualifier, to choose among those three alternatives?
As I already said (and you snipped).
Stop b*tching on IBM-Main and open a requirement with IBM (with a
justification).
-
Too busy driving to s
>And why does NJE make a difference?
Where do you convert? At the sending or the receiving site?
>(NJP is not in my vocabulary).
Network Job Processing (JES3)
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / sign
On Wed, 29 Aug 2007 10:49:15 -0500, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:
>>
>Many programmers feel that even if IBM were to choose one of the
>alternatives above, they would benefit; it would be right for them.
>Those to whom the facility would be no benefit would be not be harmed
>by it if i
On Wed, 29 Aug 2007 15:02:27 +, Ted MacNEIL wrote:
>>(Not that I agree with IBM's design choice here.)
>
>This has been discussed many times.
>IBM's design choice is based on a simple premise:
>When do you convert the system symbols?
>On the submitting system?
>On the converting system?
>On th
On Wed, 29 Aug 2007 15:02:27 +, Ted MacNEIL <[EMAIL PROTECTED]>
wrote:
>>(Not that I agree with IBM's design choice here.)
>
>This has been discussed many times.
>IBM's design choice is based on a simple premise:
>When do you convert the system symbols?
>On the submitting system?
>On the conv
>(Not that I agree with IBM's design choice here.)
This has been discussed many times.
IBM's design choice is based on a simple premise:
When do you convert the system symbols?
On the submitting system?
On the converting system?
On the executing system?
What about NJE/NJP?
Any choice can/will be
tly for that
>DSN
>on each LPAR, right? Still with me so far?
>
>But the suggestion to use /*XMIT would work, so that JES2 converts the JCL
>on the EXECUTION system, right? Just as SYSAFF= would, right?!
>
Nope. You're SOL here. JES simply doesn't permit it
On Wed, 29 Aug 2007 07:35:07 -0500, Mark H. Young wrote:
>
>Two different levels of z/OS on each of two LPARs in a MAS. Each image has
>*different* system symbols, like the z/OS level, right? And as part of the
DSN
>construct, a variable in the JCL (proc) would translate differently for that
>D
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark H. Young
Sent: Wednesday, August 29, 2007 7:35 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: JES2 converter via /*JOBPARM SYSAFF=
But the suggestion to use /*XMIT would work, so that JES2
dataset names correctly on the EXECUTING system?
>>
>
>In JES2, if you code SYSAFF= on the /*JOBPARM statement, conversion,
>interpretation, and execution will occur on the same system image. I'm
>not exactly sure what you mean by "resolve the data set names correctly"
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark H. Young
Sent: Tuesday, August 28, 2007 2:35 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: JES2 converter via /*JOBPARM SYSAFF=
In a JES2 MAS (Multi Access SPOOL) environ with two different
Mark H. Young wrote:
OK, then how do I submit a batch job on system with z/OS 1.4 and have
it execute on system with z/OS 1.7 in that MAS, and have the job
resolve the dataset names correctly on the EXECUTING system?
In JES2, if you code SYSAFF= on the /*JOBPARM statement
On Tue, 28 Aug 2007 20:01:37 +, Ted MacNEIL <[EMAIL PROTECTED]>
wrote:
>>want it to go thru conversion on system (for correct system symbol
resolution), AND for
>execution on system , you would code a:
>/*JOBPARM SYSAFF= correct?
>
>No. Symbol resolut
>want it to go thru conversion on system (for correct system symbol
>resolution), AND for
execution on system , you would code a:
/*JOBPARM SYSAFF= correct?
No. Symbol resolution is not supported for batch JCL.
This has been discussed many times on the list.
-
Too busy d
In a JES2 MAS (Multi Access SPOOL) environ with two different levels of z/OS
running, if you submit a batch job on system , but want it to go thru
conversion on system (for correct system symbol resolution), AND for
execution on system , you would code a: /*JOBPARM SYSAFF=
Thanks so much I can't believe it was that simple. As advised I added a
$T INTRDR,SYSAFF=&SYSNAME to the JES Parmlib member and it works. I just
wish I knew this a month ago before I advised my used they would have to
manually code the /*JOBPARM SYSAFF stmt to run it on teh job
f Data
*
/* THIS IS THE BEND LPAR SPECIFIC JES2 PARM MEMBER */
/*ALLOC VIA THE JES2 PROC CONCAT (JES2PARM,JES2&SYSUID) */
/* */
$T MEMBER(BEND),IND=Y
$T INTRDR,SYSAFF
rame Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Tony Wiggett
Sent: Wednesday, August 09, 2006 2:56 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Need JES2 Exit to add /*JOBPARM SYSAFF stmt
Does anyone have a copy of a JES2 Exit (Exit 6 I guess) which will do
the
following:
1. When a user submits a
I had a very similar task. I used a pair of exits: 20 & 44 if memory
serves me. You can use the $SETAFF JES2 macro. I used the pair because I
had to pass a data. Not sure I have a soft copy to share; I'll dig around.
--
For
will
do
> >the
> >> following:
> >>
> >> 1. When a user submits a batch job, check to see if they have
> >/*JOBPARM
> >> SYSAFF=systemname specified.
> >> 2. If they do then allow job to run without change
> >> 3. If no /*JOBPAR
On Wed, 9 Aug 2006 11:27:10 +0200, Vernooy, C.P. - SPLXM
<[EMAIL PROTECTED]> wrote:
>> Does anyone have a copy of a JES2 Exit (Exit 6 I guess) which will do
>the
>> following:
>>
>> 1. When a user submits a batch job, check to see if they have
>/*JOBPARM
>
""Tony Wiggett"" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Does anyone have a copy of a JES2 Exit (Exit 6 I guess) which will do
the
> following:
>
> 1. When a user submits a batch job, check to see if they have
/*JOBPARM
&g
Does anyone have a copy of a JES2 Exit (Exit 6 I guess) which will do the
following:
1. When a user submits a batch job, check to see if they have /*JOBPARM
SYSAFF=systemname specified.
2. If they do then allow job to run without change
3. If no /*JOBPARM SYSAFF statement is coded, then add one
43 matches
Mail list logo
