AW: Re: TIME= on JOB card vs. EXEC card

[Peter Hunkeler]

>If you put TIME= on the JOB card, then this trounces the JOBCLASS TIME=, and 
>none of your steps, either the first step or in total, can exceed the TIME on 
>the JOB card.




While I agree with the second part, I do not with the first.


As I described earlier, the job level TIME= defines how much CPU time *all* 
steps may use in total. The JOBCLASS TIME= value will still be the default for 
every step *not* specifying TIME= on the EXEC statement.


However, the effective amount available to a step depends on how much is left 
in the job level bucket. And this may be less than asked for if the job level 
bucket is limited, i.e. if TIME= is specified on the JOB statement.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

JCLLIB RECFM?

[Paul Gilmartin]

in:  z/OS 2.1.0
z/OS MVS
z/OS MVS JCL Reference
JCLLIB statement
Description
Considerations for using the JCLLIB statement

I read:
   ...
The private library must have the same data set attributes as a system library, 
which are:
...
Fixed length records (RECFM=F or RECFM=FB). If the JCLLIB data set is a 
PDSE,
the record format can only be RECFM=FB.

... But I just tried one with DSNTYPE=LIBRARY,RECFM=F with no problem.
RCF?  Why would they make such a rule anyway?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL: Re: many OMVSKERN task not stop

[Anthony Thompson]

Just so. Check the AUTOLOG statement in the TCPIP PROFILE deck.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Wednesday, 26 October 2016 3:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: many OMVSKERN task not stop

My suspicion is you are starting your Telnet Server out of your TCPIP proccess 
with an auto start. When your Telnet server abends it gets auto started once 
TCPIP notices.


On Tue, 2016-10-25 at 18:42 +0100, Giovanni Bozzetti wrote:
> Lizette
>
> Is during normal work.
>
> Seems to me that TCPIP is restarting INETD many times, I did find a 
> message that TCPIP is in loop
>
> Seems TCPIP is not understand the port where INETD is working and try 
> to restart all the time
>
> We just see this task this month we have sure that last month they are 
> not there, can be some maintenance, we are looking
>
> Regards
> Giovanni
> System Programmer
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Tuesday, October 25, 2016 05:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: many OMVSKERN task not stop
>
> I am not sure I understand.
>
> Is this during a shutdown for an IPL?
>
> A normal process where you want to shutdown OMVS?
>
> Could you provide an example or more details?
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@listserv.ua.ed 
> > U] On Behalf Of Giovanni Bozzetti
> > Sent: Tuesday, October 25, 2016 6:10 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: many OMVSKERN task not stop
> >
> > Hi
> >
> >
> >
> > We have z/OS 1.13 and z/OS 2.1  running with all last APAR but now 
> > we observe that OMVSKERN task didn't stop anymore
> >
> >
> >
> > We can find lot of this task started we can cancel but after some 
> > time it appears again.
> >
> >
> >
> > Someone know why this is happen ?
> >
> >
> >
> > Regards
> >
> > Giovanni
> >
> > System Programmer
> >
>
> ---
> ---
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ---
> ---
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN
--
Jerry Whitteridge  

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Does anyone use HFS files extensively with HLASM?

[Paul Gilmartin]

On Tue, 25 Oct 2016 16:49:46 -0700, Charles Mills wrote:
>
>Yeah, I could test the basic issues but I am wondering if anyone is doing
>this extensively and "happy with it." What are the gotchas? Those are tough
>questions to answer via experimentation.
> 
It's purportedly supported.  IBM has fixed all the problems I reported
but overhead and latency has been a PITA.

>Is anyone using HFS files as their main repository of source code input to
>and/or object code output from HLASM? The HLASM manuals are strangely silent
>on the issues:
>
>- Is the assembler "happy" with serial UNIX file type input, with records of
>varying lengths up to but not exceeding 80?
>
Yes.  Use RECFM=FB,LRECL=80,FILEDATA=TEXT.  (FILEDATA=BINARY might
work if the data are formatted that way.)

>- How about SYSLIB? I know technically a USS directory can satisfy BPAM --
>is HLASM happy with directories as libraries? Does it work if you
>concatenate your own HFS directory(ies) to SYS1.MACLIB and the like?
>- How about output? Does SYSLIN output to a USS folder seem to work out?
>
I've had a couple problems with this, both fixed by APAR, both occurring
with nested COPY instructions (macros are effectively not nested) and
references between HFS and CKD.
o POINT didn't get back to the place of the NOTE.  This could be masked
  if BLKSIZE>size of member.  Support tried to tell me, "Don't use
  BLKSIZE=80."  I argued and won.
o ABENDs because of storage key incompatibility between HFS and CKD.

Since then, we converted largely to a cross-assembler.  I haven't checked
for regression lately.

In Binder SYSLIB, HFS directories must not be concatenated; they must
appear solitaire.  But you can use multiple DDNAMEs:
//LINK  EXEC  PGM=IEWL,PARM=CASE(MIXED)
  INCLUDE HFS1(foo)
  INCLUDE HFS2(bar)
  INCLUDE CKDCAT(WOMBAT)

In Binder SYSLIN (and SYSLIB?) FILEDATA=TEXT is ignored; it is quietly
overridden to BINARY.  (I tried this with SYSLIN containing only commands,
no SYSPUNCH.)  I submitted an RCF on this.  Pubs complained bitterly,
"Everyone ought to know that!"  I argued; I think I won, but I haven't
checked the doc recently.

>Why do I ask? I have C code in HFS and assembler code in PDSEs and the
>"management" details are a little incompatible. Not hopelessly so, but
>somewhat. It might make sense to consolidate the high level structure.
> 
If you're perversely clever, you can interleave control block definitions:

#define MACRO /* nothing */
#include 

and in structure.h (untested):

 MACRO /*
   WOMBAT 
*/ struct wombat { /*
 NUM  DS  F
*/   long num;  /*
 MEND
*/   }

... if you want to do that sort of thing.

cc/c99/xlc will invoke HLASM for filename extension ".s".
But I found that SYSPARM is forced to upper case.  (Why?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Does anyone use HFS files extensively with HLASM?

[Charles Mills]

Yeah, I know, there's an assembler listserve and this isn't it. I'm not on
it and I think most of its members are also here. This IS a mainframe
question ...

Yeah, I could test the basic issues but I am wondering if anyone is doing
this extensively and "happy with it." What are the gotchas? Those are tough
questions to answer via experimentation.

Is anyone using HFS files as their main repository of source code input to
and/or object code output from HLASM? The HLASM manuals are strangely silent
on the issues:

- Is the assembler "happy" with serial UNIX file type input, with records of
varying lengths up to but not exceeding 80? 
- How about SYSLIB? I know technically a USS directory can satisfy BPAM --
is HLASM happy with directories as libraries? Does it work if you
concatenate your own HFS directory(ies) to SYS1.MACLIB and the like?
- How about output? Does SYSLIN output to a USS folder seem to work out?

Why do I ask? I have C code in HFS and assembler code in PDSEs and the
"management" details are a little incompatible. Not hopelessly so, but
somewhat. It might make sense to consolidate the high level structure.

Thanks,

Charles 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMP/E and RFPREFIX

[Paul Gilmartin]

On Tue, 25 Oct 2016 16:08:25 -0700, Phil Smith wrote:
>
>2) Is there a cleaner way to specify this than just adding 
>RFPREFIX(whatever) when needed? I had hoped to be able to provide, say, 
>RFPREFIX() and then use a set symbol, but I know that won't work.
>
Why not?  Is it because the substitutions must be made both in
JCL statements and in SYSIN lines?  Would SYSIN SYMBOLS= be an
answer?  (But can you rely on all users having a suitably recent
z/OS?)

There are already instructions in the provided JCL that say to make some global 
changes, so I'm thinking that I should include it with something clearly 
invalid, maybe: RFPREFIX(!prefix!) and add it to the list of things to change, 
with a note that if your data sets really are just VSH.whatever, to remove it 
completely.
>
Or supply an Edit macro or a Tailoring script to automate the changes?
Overkill if only one member needs to be changed (and they get it right
on the first attempt); more valuable if multiple members need to be
changed.

A colleague once used a JCLLIB member for this purpose but that
merely regressed the burden for my unit testing -- I needed to
tailor the JCLLIB DSN in each JCL member.  (Would it work to
incorporate  in the JCLLIB declaration?)

For private use, I wrap JCL in UNIX shell scripts.  That is unlikely
to fly with our customers.

>Just trying to make this as easy/painless as possible for people.
>
>Thanks in advance for any insights!

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

SMP/E and RFPREFIX

[Phil Smith]

OK, I feel stupid. Not an unfamiliar feeling, especially when SMP/E is 
involved. But I think I mostly figured this out, and am looking for 
confirmation.

I have a package that installs fine, but recently someone said "You should 
support using RFPREFIX in your provided JCL". This was prompted by a note in 
our Program Directory:
Note: SMP/E requires the high-level qualifier in the RFDSNPFX field to be 
single-level: for example, BANANA.PEEL will cause GIM20311E errors.

And that note, of course, was based on our having found that to be true.

The only quasi-decent description of RFPREFIX I could find is in:
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim1000/gim1123.htm

Reading that doc and experimentation suggests that RFPREFIX pretty well does 
that it sounds like: gets prefixed to the RFDSNPFX value. So if the SMPMCS 
contains:
++FUNCTION(VVSH710) FILES(2) RFDSNPFX(VSH) REWORK(2016166)

Then if RFPREFIX(BANANA) were added to the RECEIVE command in the provided JCL, 
it would look for
BANANA.VSH.VVSH710.F1 and BANANA.VSH.VVSH710.F2
instead of VSH.VVSH710.F1 and VSH.VVSH710.F2

So my questions are:

1) Is this correct? Have I missed any subtleties that come to mind?

2) Is there a cleaner way to specify this than just adding 
RFPREFIX(whatever) when needed? I had hoped to be able to provide, say, 
RFPREFIX() and then use a set symbol, but I know that won't work. 
There are already instructions in the provided JCL that say to make some global 
changes, so I'm thinking that I should include it with something clearly 
invalid, maybe: RFPREFIX(!prefix!) and add it to the list of things to change, 
with a note that if your data sets really are just VSH.whatever, to remove it 
completely.
Just trying to make this as easy/painless as possible for people.

Thanks in advance for any insights!
--
...phsiii

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with orphan in FIFO control block chain

[Binyamin Dissen]

Where do you set R1?

On Tue, 25 Oct 2016 11:25:02 -0500 Donald Likens 
wrote:

:>I posted before on this issue and you all were a great help because I was 
using CS and PLO to serialize. However I changed the code and the issue still 
exists. The issue looks like, I create a control block but it does not get 
added to the chain… I think the term is orphan. The control block structure is 
above the bar, FIFO, and has a first and last pointer. The entries in the chain 
are removed by one address space and added-to in many address spaces.
:>
:>Here is the code to add the control block to the chain:
:>
:>*C R8 = address of newly built control block
:>DOX378   DS0H 
:>*C SET R6 = LAST_CONTROL_BLOCK_ADDR   
 
:> LGR6,LAST_CONTROL_BLOCK_ADDR 
 
:>*C IF FIRST_CONTROL_BLOCK_ADDR AND LAST_CONTROL_BLOCK_ADDR EQ 0   
 
:>*C SET FIRST_CONTROL_BLOCK_ADDR AND LAST_CONTROL_BLOCK_ADDR = NEW 
Control_block ADDRESS   
:> STG   R8,OPERAND1R   (REPLACES LAST_CONTROL_BLOCK_ADDR)  
 
:> XCOPERAND1,OPERAND1  (COMPARISON VALUE)
:> XCOPERAND3,OPERAND3  (COMPARISON VALUE)
:> STG   R8,OPERAND3R   (REPLACES WHERE OPERAND4 POINTS)  
:> LAR0,DCSG  
:> LGR   R3,R8
:> LAR4,FIRST_CONTROL_BLOCK_ADDR
  
:> STG   R4,OPERAND4  
:> PLO   0,LAST_CONTROL_BLOCK_ADDR,0,PL 
 
:>*   
:>*  IF DOUBLE COMPARE AND SWAP IS SPECIFIED, THE FIRSTOPERAND  
:>*  COMPARISON VALUE AND THE SECOND
:>*  OPERAND ARE COMPARED. IF THEY ARE EQUAL, THE   
:>*  THIRD-OPERAND COMPARISON VALUE AND THE FOURTH  
:>*  OPERAND ARE COMPARED. IF BOTH COMPARISONS INDICATE 
:>*  EQUALITY, THE FIRST-OPERAND AND THIRD-OPERAND  
:>*  REPLACEMENT VALUES ARE STORED AT THE SECONDOPERAND 
:>*  LOCATION AND FOURTH-OPERAND LOCATION,  
:>*  RESPECTIVELY. IF THE FIRST COMPARISON INDICATES INEQUALITY,
:>*  THE SECOND OPERAND IS PLACED IN THE FIRSTOPERAND-  
:>*  COMPARISON-VALUE LOCATION AS A NEW FIRSTOPERAND
:>*  COMPARISON VALUE. IF THE FIRST COMPARISON  
:>*  INDICATES EQUALITY BUT THE SECOND DOES NOT, THE
:>*  FOURTH OPERAND IS PLACED IN THE THIRD-OPERANDCOMPARISON-   
:>*  VALUE LOCATION AS A NEW THIRD-OPERAND  
:>*  COMPARISON VALUE.  
:>* 
:>*C   ELSE 
:> BC8,EDOX378(if success ... done) 
 
:>*C IF LAST_CONTROL_BLOCK_ADDR = R6 (ORIGINAL LAST_CONTROL_BLOCK_ADDR VALUE)   

:>*C   SET LAST_CONTROL_BLOCK_ADDR = POINTER_TO_NEW_MSEG (R8)   
 
:>*C   SET NEXT_CONTROL_BLOCK_ADDRESS.OF.LAST.ONCHAIN= POINTER_TO_NEW_MSEG (R8) 

:> STG   R6,OPERAND1(COMPARISON VALUE)
:> STG   R8,OPERAND1R   (REPLACEMENT VALUE)   
:> LAR0,CSSTG 
:> LGR   R3,R8
:> DROP  R8   
:> USING MSEGCB,R6
:> LAR4,NEXT_CONTROL_BLOCK_ADDRESS   NEXT_CONTROL_BLOCK_ADDRESS IS 
IN CSA 
:> STG   R4,OPERAND4  
:> STG   R8,OPERAND3R 
:> PLO   0,LAST_CONTROL_BLOCK_ADDR,0,PL 
 
:>*  THE FIRST-OPERAND COMPARISON VALUE AND THE SECOND OPERAND ARE
:>*  COMPARED.  IF THEY ARE EQUAL, THE FIRST-OPERAND REPLACEMENT VALUE
:>*  IS STORED AT THE SECOND-OPERAND LOCATION, AND THE THIRD OPERAND IS   
:>*  STORED AT THE FOURTH-OPERAND LOCATION.   
:> BNZ   DOX378   (if not successful start over)

:>EDOX378  DS0H 
  
:>Here is the code to remove the control block from the chain.
:>*C IF 

Re: Just when you thought it was really dead

[Kirk Wolf]

Is this new RPG cloud and analytics enabled?  :-)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Oct 25, 2016 at 4:02 PM, Charles Mills  wrote:

> Can OORPG be far behind?
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Edward Gould
> Sent: Tuesday, October 25, 2016 1:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Just when you thought it was really dead
>
> > Who Knew You Could Do That with RPG IV? Modern RPG for the Modern
> > Programmer
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Just when you thought it was really dead

[Charles Mills]

Can OORPG be far behind?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Tuesday, October 25, 2016 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Just when you thought it was really dead

> Who Knew You Could Do That with RPG IV? Modern RPG for the Modern 
> Programmer

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Just when you thought it was really dead

[Edward Gould]

> Who Knew You Could Do That with RPG IV? Modern RPG for the Modern Programmer
> 
> A draft IBM Redbooks publication
> 
> View online
> 
> Download PDF (5.6 MB) 
> 
> Get Adobe® Reader® 
> More options
> 
> Discuss this book (5 comments)
>  
> 
> Tips for viewing 
> Permanent link 
> 
> Abstract
> 
> Application development is a key part of the IBM® i businesses. The IBM i 
> operating system is a very modern robust platform to create and develop 
> applications. The RPG language has been around for a long time, but has not 
> stopped being transformed into a modern business language.
> 
> This IBM Redbooks® publication is focused on helping the IBM i development 
> community understand what is modern RPG. The world of application development 
> has been rapidly changing over the past years. The good news is that IBM i 
> has been changing right along with it, and has made significant changes to 
> the RPG language. This book is intended to help developers understand what 
> modern RPG looks like and how to move from older versions of RPG to a newer 
> modern version. Additionally, this book covers the basics of ILE, interfacing 
> with many other languages, and the best tools for doing development on IBM i.
> 
> Using modern tools, methodologies, and languages are key to continuing to 
> stay relevant in today’s world. Being able to find the right talent for you 
> shop is key to your continued success. Leveraging the guidelines and 
> principles in this book can help set you up to find that talent today and 
> into the future.
> 
> This publication is the result of work that was done by IBM, industry 
> experts, business partners, and some of the original authors of the first two 
> editions of this IBM Redbooks publication. Not only is the information 
> important for developers, it is important for the business decision makers 
> (CIO for example) to understand that the IBM i is not an ‘old’ system. The 
> IBM i has modern languages and tools, its really just a matter of what you 
> choose to do with the IBM i that defines its age.
> 
> 
> Table of contents
> 
> Chapter 1. Introduction to RPG IV
> Chapter 2. Programming RPG IV with style
> Chapter 3. Subprocedures
> Chapter 4. An ILE guide for the RPG programmer
> Chapter 5. Application programming interfaces
> Chapter 6. Database access with RPG IV
> Chapter 7. Exception and error handling
> Chapter 8. Interfacing
> Chapter 9. IBM Rational Developer for IBM i
> Chapter 10. Modern RPG comparison as viewed from a young developer
> Appendix A. Additional material
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIME= on JOB card vs. EXEC card

[R.S.]

W dniu 2016-10-25 o 19:15, Jesse 1 Robinson pisze:

Answer inline

It's interesting to see varying opinions and interpretations. To reiterate: my 
question is not 'how to accomplish something' but merely how it actually works. 
So:

-- No TIME= of any kind coded on JOB or EXEC card

Then jobcard valu is used


-- JES2 time for a particular JOBCLASS is 3

Then it's 3 minutes per each step



-- Five steps in the job

Every step has 3 minutes (my fault in previous post)


-- No IEFUTL action

So the above is as I described. IEFUTL coudl change it.



-- No ISV product or RYO code

As above.




As I understand it, each step can use up to a maximum of 3. The whole job 
cannot use more than 15, the simple sum of all the steps. This is not an 
implicit limit, just the (coincidental) effect of 5*3 minutes of accumulated 
step time. Exceeding 3 on any step will cause S322; otherwise no abend.

Yes



Now, to accomplish my actual goal of abending runaway hard-loop jobs, we could 
add TIME= to the JOB card, which will effectively limit the step sum regardless 
of what any individual step(s) have coded. In other words, S322 for exceeding 
the JOB card value regardless of TIME= on any or all steps. Is this right?
Yes, but I would suggest coding TIME on EXEC card. You have 5 steps. I 
think only one of them is "suspected", isn't it?

So, remaining 4 steps do not need special control.



HTH
R.S.




-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, October 25, 2016 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TIME= on JOB card vs. EXEC card

Correct.
The JOBCLASS TIME will rule all TIME= for that class.  If you do not exceed the 
JOBCLASS TIME= limit then either the JOBCARD or STEP will then enforce the 
limit.

If the JOBCLASS TIME=30 is coded (30 mins) then it will not matter to code
TIME=60 on the JOBCARD or the STEP.  The 30Mins for the JOBCLASS will enforce 
the time limit.



Lizette



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Burrell, Todd
Sent: Tuesday, October 25, 2016 4:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TIME= on JOB card vs. EXEC card

I thought that the jobclass time limit overrides everything - so for
this example wouldn't the time be 60?

Examples (for one-step job):
jobclass ; JOBcard ; EXEC ; effective
60  ; none  ; 90 ; 90 - increased

I thought that the jobclass was the maximum regardless of what you set
on the exec or job card?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of R.S.
Sent: Tuesday, October 25, 2016 5:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TIME= on JOB card vs. EXEC card

W dniu 2016-10-25 o 04:55, Jesse 1 Robinson pisze:

OK, consider this case. All defaults, no TIME= coded anywhere. JES2
parms

have TIME=3. Five steps. How long will the job run?
Answer: it depends.
First: we talk about CPU time, not "wall clock" time.

CORRECTION: the below is valid for JOB TIME=3

Second: we know there is a limit 3 minutes for whole job. Maybe each
step consume 2 seconds, then 2x5steps = 10s CPU.
Assumed first step consumed 30s the limit for the rest of the job is (2,30).
Assumed second step consumed 10s, the limit for the remaining steps is
(2,20), etc.

Geeneral rules:
TIME=value coded in JOB can only DECREASE default value.
TIME=NOLIMIT or TIME=1440 in JOB card INCREASE the default to infinity
(no time limit)

TIME coded in EXEC can INCREASE or DECREASE default value.
TIME=NOLIMIT or TIME=1440 in EXEC card INCREASE the default to
infinity (no time limit)

When coded both JOB and EXEC, the most restrictive value is in effect.

Examples (for one-step job):
jobclass ; JOBcard ; EXEC ; effective
60  ; none  ; none ; 60
60  ; none  ; 10 ; 10
60  ; 70  ; none ; 60 - job value ignored
60  ; 20  ; none ; 20 - job value decreased default
60  ; 20  ; 10 ; 10 - most restrictive from
(job, exec)
60  ; 20  ; 90 ; 20 - most restrictive from
(job, exec)
60  ; none  ; 90 ; 90 - increased
60  ; 50  ; 1440 ; 50 - most restrictive from (job,
exec)
60  ; 1440 ; none  ; NOLIMIT
60  ; none ; 1440  ; NOLIMIT

Rule of thumb: KISS!
Keep It Simple!

Don't code TIME in both JOB and EXEC
Be generous when setting default values. In case of TIME exhaustion
abend the most common scenario is to repeat the job with (hopefully!) bigger 
time limit.
So, setting time default small is a waste of time! ;-)


HTH

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.




--
Radoslaw Skorupka

Re: TIME= on JOB card vs. EXEC card

[Bill Woodger]

Yes.

The TIME= from the JOBCLASS only affects any EXEC which doesn't have an 
explicit TIME= (all of yours). If you put TIME= on the JOB card, then this 
trounces the JOBCLASS TIME=, and none of your steps, either the first step or 
in total, can exceed the TIME on the JOB card.

(you've not mentioned the use of PROCs, so I'll avoid pursuing that little 
discovery for now - I'm going to assume that that only kicks in with an 
explicit TIME= on the EXEC of the PROC).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIME= on JOB card vs. EXEC card

[R.S.]

W dniu 2016-10-25 o 18:28, Lizette Koehler pisze:

Correct.
The JOBCLASS TIME will rule all TIME= for that class.  If you do not exceed the
JOBCLASS TIME= limit then either the JOBCARD or STEP will then enforce the
limit.

If the JOBCLASS TIME=30 is coded (30 mins) then it will not matter to code
TIME=60 on the JOBCARD or the STEP.  The 30Mins for the JOBCLASS will enforce
the time limit.


No, EXEC TIME can increase the limit from the jobclass
JCL Reference is clear here:
"You can use the TIME parameter on an EXEC statement to increase or 
decrease the

amount of processor time available to a job step over the default value."

--
Radoslaw Skorupka
Lodz, Poland






---
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL: Re: many OMVSKERN task not stop

[Jerry Whitteridge]

My suspicion is you are starting your Telnet Server out of your TCPIP
proccess with an auto start. When your Telnet server abends it gets
auto started once TCPIP notices.


On Tue, 2016-10-25 at 18:42 +0100, Giovanni Bozzetti wrote:
> Lizette
>
> Is during normal work.
>
> Seems to me that TCPIP is restarting INETD many times, I did find a
> message
> that TCPIP is in loop
>
> Seems TCPIP is not understand the port where INETD is working and try
> to
> restart all the time
>
> We just see this task this month we have sure that last month they
> are not
> there, can be some maintenance, we are looking
>
> Regards
> Giovanni
> System Programmer
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> Behalf Of Lizette Koehler
> Sent: Tuesday, October 25, 2016 05:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: many OMVSKERN task not stop
>
> I am not sure I understand.
>
> Is this during a shutdown for an IPL?
>
> A normal process where you want to shutdown OMVS?
>
> Could you provide an example or more details?
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@listserv.ua.ed
> > U]
> > On Behalf Of Giovanni Bozzetti
> > Sent: Tuesday, October 25, 2016 6:10 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: many OMVSKERN task not stop
> >
> > Hi
> >
> >
> >
> > We have z/OS 1.13 and z/OS 2.1  running with all last APAR but now
> > we
> > observe that OMVSKERN task didn't stop anymore
> >
> >
> >
> > We can find lot of this task started we can cancel but after some
> > time
> > it appears again.
> >
> >
> >
> > Someone know why this is happen ?
> >
> >
> >
> > Regards
> >
> > Giovanni
> >
> > System Programmer
> >
>
> ---
> ---
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ---
> ---
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN
--
Jerry Whitteridge 

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: many OMVSKERN task not stop

[Giovanni Bozzetti]

Lizette

Is during normal work.

Seems to me that TCPIP is restarting INETD many times, I did find a message
that TCPIP is in loop

Seems TCPIP is not understand the port where INETD is working and try to
restart all the time

We just see this task this month we have sure that last month they are not
there, can be some maintenance, we are looking

Regards
Giovanni
System Programmer


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Tuesday, October 25, 2016 05:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: many OMVSKERN task not stop

I am not sure I understand.
 
Is this during a shutdown for an IPL?

A normal process where you want to shutdown OMVS?

Could you provide an example or more details?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Giovanni Bozzetti
> Sent: Tuesday, October 25, 2016 6:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: many OMVSKERN task not stop
> 
> Hi
> 
> 
> 
> We have z/OS 1.13 and z/OS 2.1  running with all last APAR but now we 
> observe that OMVSKERN task didn't stop anymore
> 
> 
> 
> We can find lot of this task started we can cancel but after some time 
> it appears again.
> 
> 
> 
> Someone know why this is happen ?
> 
> 
> 
> Regards
> 
> Giovanni
> 
> System Programmer
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: HMC logs

[Tom Mathias]

Andy,

I am one of the HMC/SE team leaders and I've been talking to another team 
leader and we would like to help you to get this working.  There are two basic 
approaches to getting the HMC logs.  One would be to use the Scheduled 
Operations task to setup a scheduled op to collect the "audit and log 
management" data and have this sent weekly to an "FTP" server.  This sounds 
like it might be the approach you are trying.  The other would be to use the 
Web Services APIs to collect the desired log data and then that API caller 
could store the data any way it would want to.  

Perhaps you can elaborate on exactly what you are doing and what your setup is 
here or perhaps you would like to contact me directly (mathi...@us.ibm.com).  
Either way, we would like to try to help you get this working.  

Tom Mathias
HMC/SE Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIME= on JOB card vs. EXEC card

[Jesse 1 Robinson]

It's interesting to see varying opinions and interpretations. To reiterate: my 
question is not 'how to accomplish something' but merely how it actually works. 
So:

-- No TIME= of any kind coded on JOB or EXEC card
-- JES2 time for a particular JOBCLASS is 3
-- Five steps in the job
-- No IEFUTL action 
-- No ISV product or RYO code 

As I understand it, each step can use up to a maximum of 3. The whole job 
cannot use more than 15, the simple sum of all the steps. This is not an 
implicit limit, just the (coincidental) effect of 5*3 minutes of accumulated 
step time. Exceeding 3 on any step will cause S322; otherwise no abend. 

Now, to accomplish my actual goal of abending runaway hard-loop jobs, we could 
add TIME= to the JOB card, which will effectively limit the step sum regardless 
of what any individual step(s) have coded. In other words, S322 for exceeding 
the JOB card value regardless of TIME= on any or all steps. Is this right?


.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, October 25, 2016 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TIME= on JOB card vs. EXEC card

Correct. 
The JOBCLASS TIME will rule all TIME= for that class.  If you do not exceed the 
JOBCLASS TIME= limit then either the JOBCARD or STEP will then enforce the 
limit.

If the JOBCLASS TIME=30 is coded (30 mins) then it will not matter to code
TIME=60 on the JOBCARD or the STEP.  The 30Mins for the JOBCLASS will enforce 
the time limit.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Burrell, Todd
> Sent: Tuesday, October 25, 2016 4:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIME= on JOB card vs. EXEC card
> 
> I thought that the jobclass time limit overrides everything - so for 
> this example wouldn't the time be 60?
> 
> Examples (for one-step job):
> jobclass ; JOBcard ; EXEC ; effective
> 60  ; none  ; 90 ; 90 - increased
> 
> I thought that the jobclass was the maximum regardless of what you set 
> on the exec or job card?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of R.S.
> Sent: Tuesday, October 25, 2016 5:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIME= on JOB card vs. EXEC card
> 
> W dniu 2016-10-25 o 04:55, Jesse 1 Robinson pisze:
> > OK, consider this case. All defaults, no TIME= coded anywhere. JES2 
> > parms
> have TIME=3. Five steps. How long will the job run?
> >
> Answer: it depends.
> First: we talk about CPU time, not "wall clock" time.
> Second: we know there is a limit 3 minutes for whole job. Maybe each 
> step consume 2 seconds, then 2x5steps = 10s CPU.
> Assumed first step consumed 30s the limit for the rest of the job is (2,30).
> Assumed second step consumed 10s, the limit for the remaining steps is 
> (2,20), etc.
> 
> Geeneral rules:
> TIME=value coded in JOB can only DECREASE default value.
> TIME=NOLIMIT or TIME=1440 in JOB card INCREASE the default to infinity 
> (no time limit)
> 
> TIME coded in EXEC can INCREASE or DECREASE default value.
> TIME=NOLIMIT or TIME=1440 in EXEC card INCREASE the default to 
> infinity (no time limit)
> 
> When coded both JOB and EXEC, the most restrictive value is in effect.
> 
> Examples (for one-step job):
> jobclass ; JOBcard ; EXEC ; effective
> 60  ; none  ; none ; 60
> 60  ; none  ; 10 ; 10
> 60  ; 70  ; none ; 60 - job value ignored
> 60  ; 20  ; none ; 20 - job value decreased default
> 60  ; 20  ; 10 ; 10 - most restrictive from
> (job, exec)
> 60  ; 20  ; 90 ; 20 - most restrictive from
> (job, exec)
> 60  ; none  ; 90 ; 90 - increased
> 60  ; 50  ; 1440 ; 50 - most restrictive from (job,
> exec)
> 60  ; 1440 ; none  ; NOLIMIT
> 60  ; none ; 1440  ; NOLIMIT
> 
> Rule of thumb: KISS!
> Keep It Simple!
> 
> Don't code TIME in both JOB and EXEC
> Be generous when setting default values. In case of TIME exhaustion 
> abend the most common scenario is to repeat the job with (hopefully!) bigger 
> time limit.
> So, setting time default small is a waste of time! ;-)
> 
> 
> HTH
> 
> --
> Radoslaw Skorupka
> Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: many OMVSKERN task not stop

[Lizette Koehler]

I am not sure I understand.
 
Is this during a shutdown for an IPL?

A normal process where you want to shutdown OMVS?

Could you provide an example or more details?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Giovanni Bozzetti
> Sent: Tuesday, October 25, 2016 6:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: many OMVSKERN task not stop
> 
> Hi
> 
> 
> 
> We have z/OS 1.13 and z/OS 2.1  running with all last APAR but now we observe
> that OMVSKERN task didn't stop anymore
> 
> 
> 
> We can find lot of this task started we can cancel but after some time it
> appears again.
> 
> 
> 
> Someone know why this is happen ?
> 
> 
> 
> Regards
> 
> Giovanni
> 
> System Programmer
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIME= on JOB card vs. EXEC card

[Lizette Koehler]

Correct. 
The JOBCLASS TIME will rule all TIME= for that class.  If you do not exceed the
JOBCLASS TIME= limit then either the JOBCARD or STEP will then enforce the
limit.

If the JOBCLASS TIME=30 is coded (30 mins) then it will not matter to code
TIME=60 on the JOBCARD or the STEP.  The 30Mins for the JOBCLASS will enforce
the time limit.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Burrell, Todd
> Sent: Tuesday, October 25, 2016 4:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIME= on JOB card vs. EXEC card
> 
> I thought that the jobclass time limit overrides everything - so for this
> example wouldn't the time be 60?
> 
> Examples (for one-step job):
> jobclass ; JOBcard ; EXEC ; effective
> 60  ; none  ; 90 ; 90 - increased
> 
> I thought that the jobclass was the maximum regardless of what you set on the
> exec or job card?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Tuesday, October 25, 2016 5:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIME= on JOB card vs. EXEC card
> 
> W dniu 2016-10-25 o 04:55, Jesse 1 Robinson pisze:
> > OK, consider this case. All defaults, no TIME= coded anywhere. JES2 parms
> have TIME=3. Five steps. How long will the job run?
> >
> Answer: it depends.
> First: we talk about CPU time, not "wall clock" time.
> Second: we know there is a limit 3 minutes for whole job. Maybe each step
> consume 2 seconds, then 2x5steps = 10s CPU.
> Assumed first step consumed 30s the limit for the rest of the job is (2,30).
> Assumed second step consumed 10s, the limit for the remaining steps is (2,20),
> etc.
> 
> Geeneral rules:
> TIME=value coded in JOB can only DECREASE default value.
> TIME=NOLIMIT or TIME=1440 in JOB card INCREASE the default to infinity (no
> time limit)
> 
> TIME coded in EXEC can INCREASE or DECREASE default value.
> TIME=NOLIMIT or TIME=1440 in EXEC card INCREASE the default to infinity (no
> time limit)
> 
> When coded both JOB and EXEC, the most restrictive value is in effect.
> 
> Examples (for one-step job):
> jobclass ; JOBcard ; EXEC ; effective
> 60  ; none  ; none ; 60
> 60  ; none  ; 10 ; 10
> 60  ; 70  ; none ; 60 - job value ignored
> 60  ; 20  ; none ; 20 - job value decreased default
> 60  ; 20  ; 10 ; 10 - most restrictive from
> (job, exec)
> 60  ; 20  ; 90 ; 20 - most restrictive from
> (job, exec)
> 60  ; none  ; 90 ; 90 - increased
> 60  ; 50  ; 1440 ; 50 - most restrictive from (job,
> exec)
> 60  ; 1440 ; none  ; NOLIMIT
> 60  ; none ; 1440  ; NOLIMIT
> 
> Rule of thumb: KISS!
> Keep It Simple!
> 
> Don't code TIME in both JOB and EXEC
> Be generous when setting default values. In case of TIME exhaustion abend the
> most common scenario is to repeat the job with (hopefully!) bigger time limit.
> So, setting time default small is a waste of time! ;-)
> 
> 
> HTH
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIME= on JOB card vs. EXEC card

[Lizette Koehler]

Or products like Trident Software z/OSEM or MVS Solutions (?) Thruput Manager.

You could also look a EASYEXIT by DTS Software.

So if the JOBCLASS definition does not include a TIME= parm the default for that
class is 30 mins
If there is a JOBCARD TIME= it controls all steps.  So the total time on the
steps cannot exceed the TIME= On the jobcard 
  STEP1 TIME=2
  STEP2 TIME=3
  STEP3 TIME=2
  STEP4 TIME=8
  STEP5 TIME=3

So if the JOBCARD has TIME=5 (5 mins) the job would fail on step 3.
If there is no TIME coded on the JOBCARD.  Each step would get the time they
specify so long as it does not exceed the TIME= on the JOBCLASS

This is not clock time but CPU Time.  So the job may run longer (clock time) due
to being swapped out (I think) and not hit the TIME= limit.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: Tuesday, October 25, 2016 5:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIME= on JOB card vs. EXEC card
> 
> Try Jes2 Exit 6 to enforce the limits. I had some fun a while back writing
> some code to process the internal text of the job and force the values I
> wanted for the time parameter.
> 
> If TIME= was coded, it was forced to the expected value.
> 
> May also be done (I think) in IEFUSI or IEFUJI.
> 
> HTH,
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Monday, October 24, 2016 10:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIME= on JOB card vs. EXEC card
> 
> Issue: we're trying to limit jobs to a particular amount of CPU time. I'm not
> sure of the relationship between JOB time and STEP time. I understand that
> TIME=3 on the STEP limits that step to 3. With 5 steps, what is the limit for
> the whole job?
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Monday, October 24, 2016 8:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: TIME= on JOB card vs. EXEC card
> 
> Specifies the default for the maximum processor time that each job step may
> run.
> And that CPU Time not clock time.
> 
> So each step no more than 3 minutes.  3 mins 1 sec it fails on that step.
> 
> So is there a specific issue you are trying to resolve?
> 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jesse 1 Robinson
> > Sent: Monday, October 24, 2016 7:56 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: TIME= on JOB card vs. EXEC card
> >
> > OK, consider this case. All defaults, no TIME= coded anywhere. JES2
> > parms have TIME=3. Five steps. How long will the job run?
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-302-7535 Office
> > robin...@sce.com
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Anthony Thompson
> > Sent: Monday, October 24, 2016 6:50 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: TIME= on JOB card vs. EXEC card
> >
> > As Lizette said. Default job TIME is set in the JOBCLASS definition in
> > the
> > JES2 parameter deck.
> >
> > If JOBCLASS doesn't specify a CPU time limit, the IBM default is 30 minutes.
> >
> > Ant.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Lizette Koehler
> > Sent: Tuesday, 25 October 2016 9:36 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: TIME= on JOB card vs. EXEC card
> >
> > My understanding is the step is the step - but if coded on the JOBCARD
> > it rules it all.
> >
> > Also, if your JES2 JOBCLASS has a time lime, then that will control all of
> it.
> >
> > Found that out the hard way.
> >
> > So if you have a time limit on the JOBCLASS def in JES2, it takes
> > precedent If nothing major in the JOBCLAS def, but you have a STEP
> > TIME coded, then so long as the step time does not exceed the JOBCLASS
> > it will work If you have TIME coded on the JOB and it does not exceed
> > the JOBCLASS, it will work If you have TIME coded on the JOB and the
> > STEP then the JOB TIME limit will restrict the STEPs.  If the total
> > time executed for all steps exceeds the TIME= on the JOBCARD then it abends.
> >
> > Good write up on KB here
> >
> > http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2
> > r2.ieab5
> > 00
> > /iea3b5_JOB_and_EXEC_TIME_parameter.htm
> >
> >
> > By coding TIME=1440 or TIME=NOLIMIT, the TIME parameter can instead be
> > used to 

Help with orphan in FIFO control block chain

[Donald Likens]

I posted before on this issue and you all were a great help because I was using 
CS and PLO to serialize. However I changed the code and the issue still exists. 
The issue looks like, I create a control block but it does not get added to the 
chain… I think the term is orphan. The control block structure is above the 
bar, FIFO, and has a first and last pointer. The entries in the chain are 
removed by one address space and added-to in many address spaces.

Here is the code to add the control block to the chain:

*C R8 = address of newly built control block
DOX378   DS0H 
*C SET R6 = LAST_CONTROL_BLOCK_ADDR 
   
 LGR6,LAST_CONTROL_BLOCK_ADDR   
   
*C IF FIRST_CONTROL_BLOCK_ADDR AND LAST_CONTROL_BLOCK_ADDR EQ 0 
   
*C SET FIRST_CONTROL_BLOCK_ADDR AND LAST_CONTROL_BLOCK_ADDR = NEW 
Control_block ADDRESS   
 STG   R8,OPERAND1R   (REPLACES LAST_CONTROL_BLOCK_ADDR)
   
 XCOPERAND1,OPERAND1  (COMPARISON VALUE)
 XCOPERAND3,OPERAND3  (COMPARISON VALUE)
 STG   R8,OPERAND3R   (REPLACES WHERE OPERAND4 POINTS)  
 LAR0,DCSG  
 LGR   R3,R8
 LAR4,FIRST_CONTROL_BLOCK_ADDR  

 STG   R4,OPERAND4  
 PLO   0,LAST_CONTROL_BLOCK_ADDR,0,PL   
   
*   
*  IF DOUBLE COMPARE AND SWAP IS SPECIFIED, THE FIRSTOPERAND  
*  COMPARISON VALUE AND THE SECOND
*  OPERAND ARE COMPARED. IF THEY ARE EQUAL, THE   
*  THIRD-OPERAND COMPARISON VALUE AND THE FOURTH  
*  OPERAND ARE COMPARED. IF BOTH COMPARISONS INDICATE 
*  EQUALITY, THE FIRST-OPERAND AND THIRD-OPERAND  
*  REPLACEMENT VALUES ARE STORED AT THE SECONDOPERAND 
*  LOCATION AND FOURTH-OPERAND LOCATION,  
*  RESPECTIVELY. IF THE FIRST COMPARISON INDICATES INEQUALITY,
*  THE SECOND OPERAND IS PLACED IN THE FIRSTOPERAND-  
*  COMPARISON-VALUE LOCATION AS A NEW FIRSTOPERAND
*  COMPARISON VALUE. IF THE FIRST COMPARISON  
*  INDICATES EQUALITY BUT THE SECOND DOES NOT, THE
*  FOURTH OPERAND IS PLACED IN THE THIRD-OPERANDCOMPARISON-   
*  VALUE LOCATION AS A NEW THIRD-OPERAND  
*  COMPARISON VALUE.  
* 
*C   ELSE 
 BC8,EDOX378(if success ... done)   
   
*C IF LAST_CONTROL_BLOCK_ADDR = R6 (ORIGINAL LAST_CONTROL_BLOCK_ADDR VALUE) 
  
*C   SET LAST_CONTROL_BLOCK_ADDR = POINTER_TO_NEW_MSEG (R8) 
   
*C   SET NEXT_CONTROL_BLOCK_ADDRESS.OF.LAST.ONCHAIN= POINTER_TO_NEW_MSEG (R8)   
  
 STG   R6,OPERAND1(COMPARISON VALUE)
 STG   R8,OPERAND1R   (REPLACEMENT VALUE)   
 LAR0,CSSTG 
 LGR   R3,R8
 DROP  R8   
 USING MSEGCB,R6
 LAR4,NEXT_CONTROL_BLOCK_ADDRESS   NEXT_CONTROL_BLOCK_ADDRESS IS IN 
CSA 
 STG   R4,OPERAND4  
 STG   R8,OPERAND3R 
 PLO   0,LAST_CONTROL_BLOCK_ADDR,0,PL   
   
*  THE FIRST-OPERAND COMPARISON VALUE AND THE SECOND OPERAND ARE
*  COMPARED.  IF THEY ARE EQUAL, THE FIRST-OPERAND REPLACEMENT VALUE
*  IS STORED AT THE SECOND-OPERAND LOCATION, AND THE THIRD OPERAND IS   
*  STORED AT THE FOURTH-OPERAND LOCATION.   
 BNZ   DOX378   (if not successful start over)  
  
EDOX378  DS0H   

Here is the code to remove the control block from the chain.
*C IF NEXT_CONTROL_BLOCK_ADDRESS = 0
  
*C   SET LAST_CONTROL_BLOCK_ADDR = 0
   
*C   SET FIRST_CONTROL_BLOCK_ADDR = 0  

Re: many OMVSKERN task not stop

[Giovanni Bozzetti]

Elardus

Thank you

Did a more detailed investigation and is related with INETD1  and seems TCPIP 
is doing a loop and restart many times INETD1 this is the cause to have many 
OMVSKERN it use this task when use BPXAS start

$HASP100 BPXASON STCINRDR
$HASP373 BPXASSTARTED
BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB INETD1 RUNNING IN ASID 
 0026
BPXF024I (TCPIP) Oct 25 01:30:10 inetd 16842760 : FOMN0087 925   
*:otelnet/tcp server failing (looping), service terminated   
IEF196I IEF237I 1001 ALLOCATED TO SYS00074   
IEF196I IEF285I   CEE.SCEERUN  KEPT  
IEF196I IEF285I   VOL SER NOS= VTMVSC.   
$HASP100 BPXASON STCINRDR
$HASP373 BPXASSTARTED
BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB INETD1 RUNNING IN ASID 
 0026
$HASP100 BPXASON STCINRDR
$HASP373 BPXASSTARTED
BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB INETD1 RUNNING IN ASID

We will contact IBM on this

Regards
Giovanni
System Programmer

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Tuesday, October 25, 2016 02:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: many OMVSKERN task not stop

Giovanni Bozzetti wrote:

>We have z/OS 1.13 and z/OS 2.1  running with all last APAR but now we 
>observe that OMVSKERN task didn't stop anymore We can find lot of this task 
>started we can cancel but after some time it appears again.

What OMVS tasks? Could you see what are they doing? 

Did you changed something that an automatic restart was implemented?

It also depends on the 'father' task which is probably needed to stop 'child' 
task/process. [1] Also, perhaps there are some enqueue preventing the shutdown 
process(es) to finish?

>Someone know why this is happen ?

I think you should give some more background so IBM-MAIN members can help you.

Groete / Greetings
Elardus Engelbrecht

[1] - zSecure Visual has two different procedures. One to start ('fork') some 
child processes and then dies immediately while the child tasks are running and 
serving clients. Then you have another process which if you start it, it issue 
the right cleanup tasks and then the 'kill' command for them.  

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: many OMVSKERN task not stop

[Elardus Engelbrecht]

Giovanni Bozzetti wrote:

>We have z/OS 1.13 and z/OS 2.1  running with all last APAR but now we observe 
>that OMVSKERN task didn't stop anymore
>We can find lot of this task started we can cancel but after some time it 
>appears again.

What OMVS tasks? Could you see what are they doing? 

Did you changed something that an automatic restart was implemented?

It also depends on the 'father' task which is probably needed to stop 'child' 
task/process. [1]
Also, perhaps there are some enqueue preventing the shutdown process(es) to 
finish?

>Someone know why this is happen ?

I think you should give some more background so IBM-MAIN members can help you.

Groete / Greetings
Elardus Engelbrecht

[1] - zSecure Visual has two different procedures. One to start ('fork') some 
child processes and then dies immediately while the child tasks are running and 
serving clients. Then you have another process which if you start it, it issue 
the right cleanup tasks and then the 'kill' command for them.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

many OMVSKERN task not stop

[Giovanni Bozzetti]

Hi

 

We have z/OS 1.13 and z/OS 2.1  running with all last APAR but now we
observe that OMVSKERN task didn't stop anymore

 

We can find lot of this task started we can cancel but after some time it
appears again.

 

Someone know why this is happen ?

 

Regards

Giovanni

System Programmer


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIME= on JOB card vs. EXEC card

[Allan Staller]

Try Jes2 Exit 6 to enforce the limits. I had some fun a while back writing some 
code to process the internal text of the job and force the values I wanted for 
the time parameter.

If TIME= was coded, it was forced to the expected value.

May also be done (I think) in IEFUSI or IEFUJI.

HTH,

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, October 24, 2016 10:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TIME= on JOB card vs. EXEC card

Issue: we're trying to limit jobs to a particular amount of CPU time. I'm not 
sure of the relationship between JOB time and STEP time. I understand that 
TIME=3 on the STEP limits that step to 3. With 5 steps, what is the limit for 
the whole job? 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, October 24, 2016 8:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TIME= on JOB card vs. EXEC card

Specifies the default for the maximum processor time that each job step may run.
And that CPU Time not clock time.

So each step no more than 3 minutes.  3 mins 1 sec it fails on that step.

So is there a specific issue you are trying to resolve?


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jesse 1 Robinson
> Sent: Monday, October 24, 2016 7:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIME= on JOB card vs. EXEC card
> 
> OK, consider this case. All defaults, no TIME= coded anywhere. JES2 
> parms have TIME=3. Five steps. How long will the job run?
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Anthony Thompson
> Sent: Monday, October 24, 2016 6:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: TIME= on JOB card vs. EXEC card
> 
> As Lizette said. Default job TIME is set in the JOBCLASS definition in 
> the
> JES2 parameter deck.
> 
> If JOBCLASS doesn't specify a CPU time limit, the IBM default is 30 minutes.
> 
> Ant.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Tuesday, 25 October 2016 9:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIME= on JOB card vs. EXEC card
> 
> My understanding is the step is the step - but if coded on the JOBCARD 
> it rules it all.
> 
> Also, if your JES2 JOBCLASS has a time lime, then that will control all of it.
> 
> Found that out the hard way.
> 
> So if you have a time limit on the JOBCLASS def in JES2, it takes 
> precedent If nothing major in the JOBCLAS def, but you have a STEP 
> TIME coded, then so long as the step time does not exceed the JOBCLASS 
> it will work If you have TIME coded on the JOB and it does not exceed 
> the JOBCLASS, it will work If you have TIME coded on the JOB and the 
> STEP then the JOB TIME limit will restrict the STEPs.  If the total 
> time executed for all steps exceeds the TIME= on the JOBCARD then it abends.
> 
> Good write up on KB here
> 
> http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2
> r2.ieab5
> 00
> /iea3b5_JOB_and_EXEC_TIME_parameter.htm
> 
> 
> By coding TIME=1440 or TIME=NOLIMIT, the TIME parameter can instead be 
> used to give a job or step an unlimited amount of time. Specifically, 
> the system allows a step to remain in a continuous wait state for an 
> unlimited time, rather than the time limit established through SMF. 
> However, if TIME=1440 is specified on the JOB statement, any TIME 
> values on an EXEC statement and any default TIME values will be 
> nullified. All steps within the job will have unlimited time, as with 
> TIME=1440 or TIME=NOLIMIT.
> 
> 
> Note: the JES2 JOBCLASS definition can make things interesting.
> 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
> > Sent: Monday, October 24, 2016 3:31 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: TIME= on JOB card vs. EXEC card
> >
> > It's embarrassing to have to ask this question after decades in the 
> > biz, but I want to confirm my understanding of the TIME parameter 
> > and how it works on the JOB card vs. EXEC PGM= (step) card.
> >
> > The doc is pretty clear about the step level. What you code (or 
> > accept as default from JES) sets the limit for that step. When you 
> > reach that limit, IEFUTL gets control. This is true for each 
> > individual step 

Re: TIME= on JOB card vs. EXEC card

[Elardus Engelbrecht]

Radoslaw Skorupka wrote:

>Answer: it depends.

Absolutely. For once, I have TIME to agree with you.
I wish I have TIME (sic!) to test your one step job examples, but... 


>Rule of thumb: KISS!
>Keep It Simple!

Indeed.


>Don't code TIME in both JOB and EXEC

We tell people to rather sit any TIME= in the JOB card, not in EXEC card, 
simply for KISS reason. 

Or, we just tell them use jobclass for classes reserved for TIME=1440.


>Be generous when setting default values. 

Yup, why bother with S322? S322 is so ancient...

We may be generous except in two/three classes reserved for quick and dirty 
short jobs (small TIME and REGION) with one step usually and no 
tapes/cartridges. 

We also don't use IEFUTL for batch jobs for this reason: KISS

Of course there are tradeoffs. If the system is really that busy, priority for 
jobs with TIME=1440 + excessive cumulative CPU usage are sometimes lowered.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIME= on JOB card vs. EXEC card

[Burrell, Todd]

I thought that the jobclass time limit overrides everything - so for this 
example wouldn't the time be 60?

Examples (for one-step job):
jobclass ; JOBcard ; EXEC ; effective
60  ; none  ; 90 ; 90 - increased

I thought that the jobclass was the maximum regardless of what you set on the 
exec or job card?  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, October 25, 2016 5:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TIME= on JOB card vs. EXEC card

W dniu 2016-10-25 o 04:55, Jesse 1 Robinson pisze:
> OK, consider this case. All defaults, no TIME= coded anywhere. JES2 parms 
> have TIME=3. Five steps. How long will the job run?
>
Answer: it depends.
First: we talk about CPU time, not "wall clock" time.
Second: we know there is a limit 3 minutes for whole job. Maybe each step 
consume 2 seconds, then 2x5steps = 10s CPU.
Assumed first step consumed 30s the limit for the rest of the job is (2,30). 
Assumed second step consumed 10s, the limit for the remaining steps is (2,20), 
etc.

Geeneral rules:
TIME=value coded in JOB can only DECREASE default value.
TIME=NOLIMIT or TIME=1440 in JOB card INCREASE the default to infinity (no time 
limit)

TIME coded in EXEC can INCREASE or DECREASE default value.
TIME=NOLIMIT or TIME=1440 in EXEC card INCREASE the default to infinity (no 
time limit)

When coded both JOB and EXEC, the most restrictive value is in effect.

Examples (for one-step job):
jobclass ; JOBcard ; EXEC ; effective
60  ; none  ; none ; 60
60  ; none  ; 10 ; 10
60  ; 70  ; none ; 60 - job value ignored
60  ; 20  ; none ; 20 - job value decreased default
60  ; 20  ; 10 ; 10 - most restrictive from 
(job, exec)
60  ; 20  ; 90 ; 20 - most restrictive from 
(job, exec)
60  ; none  ; 90 ; 90 - increased
60  ; 50  ; 1440 ; 50 - most restrictive from (job, 
exec)
60  ; 1440 ; none  ; NOLIMIT
60  ; none ; 1440  ; NOLIMIT

Rule of thumb: KISS!
Keep It Simple!

Don't code TIME in both JOB and EXEC
Be generous when setting default values. In case of TIME exhaustion abend the 
most common scenario is to repeat the job with (hopefully!) bigger time limit.
So, setting time default small is a waste of time! ;-)


HTH

--
Radoslaw Skorupka
Lodz, Poland






---
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
http://secure-web.cisco.com/1XhGrmetHLO9M1ggjBw161tA19oX0d7sQHzG-5ETRvY2DIDklDQo15AZbOpa7n4RGMW2JvnO5BgjwD6y_JjXWO11xlViSw-4QbeQXAWLta-WG052OLzgFjTZFt1QCY_kWRbi6KLtGtPFpjxSen-l-W9NQivgvh5cNsM20sW6woUo0euyvFuWVpxyeYvEPoqkQ8TZw0MVw7fu6QP8EpOxY8FKROyoYcne1Zuf9N1sbsRa81jQySZgO3n7dPXwh5l3ji9scsMLfEsQbYACly2252MkN0BYaHa2Fvwgb6eZr9d9XnkQwKXHGm_qH3L1LWkSttCWudHLiI-gRA0Id2Htxd65sNkbflur1ubIghp1vAR5sl7vomow4sgA1Nzk5M6iN/http%3A%2F%2Fwww.mBank.pl%2C%20e-mail%3A%20kontakt%40mBank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information 

Re: System REXX

[John McKown]

On Mon, Oct 24, 2016 at 7:37 PM, Steve Horein 
wrote:

> >
> >
> Thank you for the explanation and reasoning sir!
> I supported OPS/MVS in a previous life (loved it), and I am now supporting
> NetView automation (love it), so I am lucky to be able to currently work
> with "COMMON" variables, which are accessible to any NetView task, very
> similar to OPS' Global variables. There is also the concept of NetView
> "task" level variables, known only to the specific task. It's good to know
> the overhead associated with filesystems is not as bad as "traditional"
> datasets, especially the buffering aspects. On a side note, I always
> thought you would be a fun guy to work with, based on the things you do!
>
>
​Thank you for the kind words about possibly being "fun to work with". But
this place definitely isn't fun. We're dying ("cloud" sourcing) & I'm
looking. Some of the things that I do are simply because we are, and have
always been, cheap (vs. frugal). So I'm always looking for "zero dollar"
solutions to make my work easier. Part of making my work easier is making
other people's work easier (because then they don't bug me ). I am
"creatively lazy", I guess.


-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIME= on JOB card vs. EXEC card

[Tom Marchant]

On Tue, 25 Oct 2016 11:47:34 +0200, R.S. wrote:

W dniu 2016-10-25 o 04:55, Jesse 1 Robinson pisze:
> OK, consider this case. All defaults, no TIME= coded anywhere. JES2 parms 
> have TIME=3. Five steps. How long will the job run?
>
>Assumed first step consumed 30s the limit for the rest of the job is 
>(2,30). Assumed second step consumed 10s, the limit for the remaining 
>steps is (2,20), etc.

Nope. From the JES2 Init and Tuning reference:


TIME=(mm,ss)|(30,0)  Specifies the default for the maximum processor time 
that each job step may run. The "mm" indicates minutes (0-357912); the "ss" 
indicates seconds (0-59). The value specified is subject to the limits 
described for the TIME parameter in z/OS MVS JCL Reference.

This default TIME= specification is used when no TIME parameter is specified on 
the JCL EXEC statement. (See z/OS MVS JCL Reference for further details on 
specifying the TIME parameter on the EXEC statement. See notes for $T job 
C=class in z/OS JES2 Commands for further details concerning the results of 
changing the job class.)

Modification: $T JOBCLASS operator command or cold start

Note: This parameter only defaults the TIME for the EXEC statement; not for the 
JOB statement.


-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIME= on JOB card vs. EXEC card

[Tom Marchant]

On Mon, 24 Oct 2016 17:06:00 -0700, Lizette Koehler wrote:

>Good write up on KB here
>
>http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieab500/iea3b5_JOB_and_EXEC_TIME_parameter.htm

This is from the JCL User's Guide.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TIME= on JOB card vs. EXEC card

[R.S.]

W dniu 2016-10-25 o 04:55, Jesse 1 Robinson pisze:

OK, consider this case. All defaults, no TIME= coded anywhere. JES2 parms have 
TIME=3. Five steps. How long will the job run?


Answer: it depends.
First: we talk about CPU time, not "wall clock" time.
Second: we know there is a limit 3 minutes for whole job. Maybe each 
step consume 2 seconds, then 2x5steps = 10s CPU.
Assumed first step consumed 30s the limit for the rest of the job is 
(2,30). Assumed second step consumed 10s, the limit for the remaining 
steps is (2,20), etc.


Geeneral rules:
TIME=value coded in JOB can only DECREASE default value.
TIME=NOLIMIT or TIME=1440 in JOB card INCREASE the default to infinity 
(no time limit)


TIME coded in EXEC can INCREASE or DECREASE default value.
TIME=NOLIMIT or TIME=1440 in EXEC card INCREASE the default to infinity 
(no time limit)


When coded both JOB and EXEC, the most restrictive value is in effect.

Examples (for one-step job):
jobclass ; JOBcard ; EXEC ; effective
60  ; none  ; none ; 60
60  ; none  ; 10 ; 10
60  ; 70  ; none ; 60 - job value ignored
60  ; 20  ; none ; 20 - job value decreased default
60  ; 20  ; 10 ; 10 - most restrictive from 
(job, exec)
60  ; 20  ; 90 ; 20 - most restrictive from 
(job, exec)

60  ; none  ; 90 ; 90 - increased
60  ; 50  ; 1440 ; 50 - most restrictive from (job, 
exec)

60  ; 1440 ; none  ; NOLIMIT
60  ; none ; 1440  ; NOLIMIT

Rule of thumb: KISS!
Keep It Simple!

Don't code TIME in both JOB and EXEC
Be generous when setting default values. In case of TIME exhaustion 
abend the most common scenario is to repeat the job with (hopefully!) 
bigger time limit.

So, setting time default small is a waste of time! ;-)


HTH

--
Radoslaw Skorupka
Lodz, Poland






---
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: AW: Re: TIME= on JOB card vs. EXEC card

[Peter Hunkeler]

>I didn't know that about the EXEC of a PROC.


Nor did I. Interesting.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: Re: TIME= on JOB card vs. EXEC card

[Bill Woodger]

There's a useful description with examples here: 
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieab500/iea3b5_JOB_and_EXEC_TIME_parameter.htm

I didn't know that about the EXEC of a PROC.

How it works must hark back to long ago. You booked your time to use on the 
machine...

If trying to limit the CPU of multiple-step JOBs, remember that programmers are 
cunning, and will immediately switch to single-step JOBs. (warning for the use 
of a rude word) https://xkcd.com/810/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: TIME= on JOB card vs. EXEC card

[Peter Hunkeler]

>So each step no more than 3 minutes.  3 mins 1 sec it fails on that step.


Think of it as there being a big CPU time bucket for *the job*.
There is a limited amount of CPU time in it when TIME= *is* specified on the 
JOB statement, or an unlimited amount, when TIME= *is not* specified on the JOB 
statement.

Then, there is another CPU time bucket for *the step*.
At step initiation each step gets the bucket replenished from the job level 
bucket. The amount the system *tries* to fill in is the value of the TIME= 
parameter on the EXEC, if present, or the value from the JOBCLASS (JES2, don't 
know about JES3) otherwise. If the job bucket does *not* have unlimited 
amounts, the step can only get the amount assigned if there is enought left in 
the job bucket. So a step might not get as much as it was assigned.
At step end, the system puts back into the job bucket whatever the step has 
*not* used.


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN