Re: JCL "COMMAND" statements - Follow-up question

2016-05-18 Thread Paul Gilmartin 
On Wed, 18 May 2016 12:23:33 -0400, Tony Thigpen wrote:

>One other question.
>
>Is there a way to wait between multiple commands when using the TSO
>command processor?
>
>I am guessing that I will need to create a small REXX that waits based
>on a parm.
> 
could you call BPXBATCH or BPXWUNIX to issue a "sleep" command?

-- gil

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

Re: JCL "COMMAND" statements - Follow-up question

2016-05-18 Thread Leonardo Vaz 
"CALL *(BPXBATCH) 'SH sleep 20' ASIS" is what I usually use

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Wednesday, May 18, 2016 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL "COMMAND" statements - Follow-up question

One other question.

Is there a way to wait between multiple commands when using the TSO command 
processor?

I am guessing that I will need to create a small REXX that waits based on a 
parm.

Tony Thigpen

Tony Thigpen wrote on 05/17/2016 08:01 AM:
> Thanks.
>
> It turns out that "OC" is part of OPS/MVS, so I now can document the job.
>
> Tony Thigpen
>
> Jeremy Nicoll wrote on 05/17/2016 07:30 AM:
>> On Tue, 17 May 2016, at 12:19, Tony Thigpen wrote:
>>> OK, dumb question time.
>>>
>>> My job is working with some JCL I found in another job:
>>> //STEP01   EXEC PGM=IKJEFT1A,REGION=0M
>>> //SYSPRINT DD SYSOUT=*
>>> //SYSTSPRT  DD SYSOUT=*
>>> //SYSTERM  DD SYSOUT=*
>>> //SYSTSOUT DD SYSOUT=*
>>> //SYSTSIN  DD *
>>>OC C('DS QD,TYPE=ALL,ONLINE')
>>> /*
>>>
>>> But, I want to look at the "OC" rexx and I can not find it in any of 
>>> the normal libraries that I have been told are used by our jobs.
>>
>> Wouldn't it be a TSO Command Processor (not a rexx exec), and thus in 
>> SYS1.CMDLIB ?
>>
>
> --
> 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

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

Re: JCL "COMMAND" statements - Follow-up question

2016-05-18 Thread Tony Thigpen 

One other question.

Is there a way to wait between multiple commands when using the TSO 
command processor?


I am guessing that I will need to create a small REXX that waits based 
on a parm.


Tony Thigpen

Tony Thigpen wrote on 05/17/2016 08:01 AM:

Thanks.

It turns out that "OC" is part of OPS/MVS, so I now can document the job.

Tony Thigpen

Jeremy Nicoll wrote on 05/17/2016 07:30 AM:

On Tue, 17 May 2016, at 12:19, Tony Thigpen wrote:

OK, dumb question time.

My job is working with some JCL I found in another job:
//STEP01   EXEC PGM=IKJEFT1A,REGION=0M
//SYSPRINT DD SYSOUT=*
//SYSTSPRT  DD SYSOUT=*
//SYSTERM  DD SYSOUT=*
//SYSTSOUT DD SYSOUT=*
//SYSTSIN  DD *
   OC C('DS QD,TYPE=ALL,ONLINE')
/*

But, I want to look at the "OC" rexx and I can not find it in any of the
normal libraries that I have been told are used by our jobs.


Wouldn't it be a TSO Command Processor (not a rexx exec), and thus in
SYS1.CMDLIB ?



--
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: JCL "COMMAND" statements - Follow-up question

2016-05-17 Thread Steve Beaver 
Where is your SYSEXEC and/or SYSPROC

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Ted MacNEIL
Sent: Tuesday, May 17, 2016 3:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL "COMMAND" statements - Follow-up question

OC is part of OPS/MVS. So you need to look in its libraries.

-teD
  Original Message
From: Jeremy Nicoll
Sent: Tuesday, May 17, 2016 07:30
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: JCL "COMMAND" statements - Follow-up question

On Tue, 17 May 2016, at 12:19, Tony Thigpen wrote:
> OK, dumb question time.
> 
> My job is working with some JCL I found in another job:
> //STEP01 EXEC PGM=IKJEFT1A,REGION=0M
> //SYSPRINT DD SYSOUT=*
> //SYSTSPRT DD SYSOUT=*
> //SYSTERM DD SYSOUT=*
> //SYSTSOUT DD SYSOUT=*
> //SYSTSIN DD *
> OC C('DS QD,TYPE=ALL,ONLINE')
> /*
> 
> But, I want to look at the "OC" rexx and I can not find it in any of 
> the normal libraries that I have been told are used by our jobs.

Wouldn't it be a TSO Command Processor (not a rexx exec), and thus in
SYS1.CMDLIB ?

--
Jeremy Nicoll - my opinions are my own.

--
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

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

Re: JCL "COMMAND" statements - Follow-up question

2016-05-17 Thread Ted MacNEIL 
OC is part of OPS/MVS. So you need to look in its libraries.

-teD
  Original Message  
From: Jeremy Nicoll
Sent: Tuesday, May 17, 2016 07:30
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: JCL "COMMAND" statements - Follow-up question

On Tue, 17 May 2016, at 12:19, Tony Thigpen wrote:
> OK, dumb question time.
> 
> My job is working with some JCL I found in another job:
> //STEP01 EXEC PGM=IKJEFT1A,REGION=0M
> //SYSPRINT DD SYSOUT=*
> //SYSTSPRT DD SYSOUT=*
> //SYSTERM DD SYSOUT=*
> //SYSTSOUT DD SYSOUT=*
> //SYSTSIN DD *
> OC C('DS QD,TYPE=ALL,ONLINE')
> /*
> 
> But, I want to look at the "OC" rexx and I can not find it in any of the 
> normal libraries that I have been told are used by our jobs.

Wouldn't it be a TSO Command Processor (not a rexx exec), and thus in
SYS1.CMDLIB ?

-- 
Jeremy Nicoll - my opinions are my own.

--
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: JCL "COMMAND" statements - Follow-up question

2016-05-17 Thread Jesse 1 Robinson 
A major clue that 'OC' is not an exec is the absence of SYSPROC or SYSEXEC in 
the job stream. That pretty much indicates a load module somewhere in linklist 
or LPA. There are tools previously discussed here to track down such a module. 

.
.
.
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 Tony Thigpen
Sent: Tuesday, May 17, 2016 5:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: JCL "COMMAND" statements - Follow-up question

Thanks.

It turns out that "OC" is part of OPS/MVS, so I now can document the job.

Tony Thigpen

Jeremy Nicoll wrote on 05/17/2016 07:30 AM:
> On Tue, 17 May 2016, at 12:19, Tony Thigpen wrote:
>> OK, dumb question time.
>>
>> My job is working with some JCL I found in another job:
>> //STEP01   EXEC PGM=IKJEFT1A,REGION=0M
>> //SYSPRINT DD SYSOUT=*
>> //SYSTSPRT  DD SYSOUT=*
>> //SYSTERM  DD SYSOUT=*
>> //SYSTSOUT DD SYSOUT=*
>> //SYSTSIN  DD *
>>OC C('DS QD,TYPE=ALL,ONLINE')
>> /*
>>
>> But, I want to look at the "OC" rexx and I can not find it in any of 
>> the normal libraries that I have been told are used by our jobs.
>
> Wouldn't it be a TSO Command Processor (not a rexx exec), and thus in 
> SYS1.CMDLIB ?

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

Re: JCL "COMMAND" statements

2016-05-17 Thread Jousma, David 
Many ways to skin the cat.  Your way works fine too, and is one less line of 
code :)

_
Dave Jousma
Assistant Vice President, Manager, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 17, 2016 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL "COMMAND" statements

On 2016-05-16, at 13:08, Jousma, David wrote:
> ...   
>   exit
> 
> 
> /* Allocate results output file  */
> ddnm = 'DD'||random(1,9)   
> Address TSO "Alloc Fi("ddnm") SYSOUT"  
>  
I'll grant that the likeihood of a collision is minuscule, the Birthday Problem 
doesn't apply here, but why not spare your reviewers the mental gymnastics of 
verifying that by reducing it to zero:

/* Allocate results output file  */
call BPXWDYN( "Alloc rtddn(ddnm) SYSOUT msg(WTP)" )

-- gil

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: JCL "COMMAND" statements

2016-05-17 Thread Paul Gilmartin 
On 2016-05-16, at 13:08, Jousma, David wrote:
> ...   
>   exit
> 
> 
> /* Allocate results output file  */
> ddnm = 'DD'||random(1,9)   
> Address TSO "Alloc Fi("ddnm") SYSOUT"  
>  
I'll grant that the likeihood of a collision is minuscule,
the Birthday Problem doesn't apply here, but why not spare
your reviewers the mental gymnastics of verifying that by
reducing it to zero:

/* Allocate results output file  */
call BPXWDYN( "Alloc rtddn(ddnm) SYSOUT msg(WTP)" )

-- gil

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

Re: JCL "COMMAND" statements

2016-05-17 Thread Greg Shirey 
No, not me...   My main contributions to the CBT are found in your stuff -- 
FILE452.   But thanks for the thought. 

Greg Shirey
Ben E. Keith Company 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dan D
Sent: Tuesday, May 17, 2016 7:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL "COMMAND" statements

I find the SDSF interface a little *clunky* and awkward.  I prefer the CMD REXX 
from CBT (Greg Shirey maybe) ...

 

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

Re: JCL "COMMAND" statements

2016-05-17 Thread Dan D 
I find the SDSF interface a little *clunky* and awkward.  I prefer the CMD
REXX from CBT (Greg Shirey maybe) ...

/* rexx */   
Address TSO  
Arg con_command  
  cart   = sysvar('SYSUID')  
  uidlen = length(cart)  
  name   = right(cart,uidlen)
  x = MSG('OFF') 
 'CONSOLE DEACTIVATE'
 'CONSPROF SOLDISP(NO) SOLNUM(400) UNSOLNUM(400) UNSOLDISP(NO)'  
 'CONSPROF'  
  x = MSG('ON')  
 'CONSOLE ACTIVATE CART('cart') NAME('name')'
 'CONSOLE SYSCMD('con_command')  CART('cart')'   
  getcode = GETMSG('cons_msg.','SOL',cart,,30)   
  Say con_command
  If cons_msg.0 > 0 then do  
 Do i = 1 to cons_msg.0  
   Say cons_msg.i
 End 
  End
 'CONSOLE DEACTIVATE'
 'CONSPROF SOLDISP(YES) UNSOLDISP(YES)'  
  Return 

Then it's just "CMD D T" in SYSTSIN or even as PARM=.
The benefit of using CONSOLE/SDSF is security.  MGCR(e) code does not unless
you issue the SAF call yourself.

DanD

"Itschak Mugzach"..
> OK. my version is based on TSO CONSOLE command. It reads command and
> verification value from sysin (see rexx test below), execure the command
> and verifies that the command response equal to the one read from sysin.
it
> can be easily modified to read multiple commands and verification strings.
> The idea behind the verification is to ensure that the command executed as
> expected (file was closed, job was started, etc.). igone the copywrite
> statement of course...
> 
> Best,
> ITschak
> 
> /* MugiRexx V1.3 */
 

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

Re: JCL "COMMAND" statements - Follow-up question

2016-05-17 Thread Tony Thigpen 

Thanks.

It turns out that "OC" is part of OPS/MVS, so I now can document the job.

Tony Thigpen

Jeremy Nicoll wrote on 05/17/2016 07:30 AM:

On Tue, 17 May 2016, at 12:19, Tony Thigpen wrote:

OK, dumb question time.

My job is working with some JCL I found in another job:
//STEP01   EXEC PGM=IKJEFT1A,REGION=0M
//SYSPRINT DD SYSOUT=*
//SYSTSPRT  DD SYSOUT=*
//SYSTERM  DD SYSOUT=*
//SYSTSOUT DD SYSOUT=*
//SYSTSIN  DD *
   OC C('DS QD,TYPE=ALL,ONLINE')
/*

But, I want to look at the "OC" rexx and I can not find it in any of the
normal libraries that I have been told are used by our jobs.


Wouldn't it be a TSO Command Processor (not a rexx exec), and thus in
SYS1.CMDLIB ?



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

Re: JCL "COMMAND" statements - Follow-up question

2016-05-17 Thread Tony Thigpen 
2016 at 10:08 PM, Jousma, David <david.jou...@53.com> wrote:


This is similar to Charles, using SDSF, but it captures the output, and
writes it to DD, you can stack as many commands in there as you wish.

//OPERCMD   EXEC PGM=IKJEFT1B,PARM='%OPERCMDB'
//SYSEXEC   DD   DSN=your.sysexec.dataset,DISP=SHR
//SYSIN DD   *
D ASM
/*
//SYSTSIN  DD   DUMMY
//SYSTSPRT DD   DUMMY
//

/* REXX */
/* this REXX exec will issue operator commands via SDSF REXX interface
security is based on the person using the command.  this exec is to be
used for batch only   */
'EXECIO * DISKR SYSIN (STEM mycmd. FINIS'
if rc > 0 then do
say 'Return code from OPEN was' rc
say 'Aborting...'
exit
end

/* Allocate results output file  */
ddnm = 'DD'||random(1,9)
Address TSO "Alloc Fi("ddnm") SYSOUT"

/* Process all input commands*/
Do c=1 to mycmd.0
  oper_command.0 = 1
  oper_command.1 = mycmd.c
  Call Main_process
End

/* Free results output file  */
Address TSO "Free Fi("ddnm")"
Return 0

Main_process:
/* process all data from SYSIN   */
rc=isfcalls('ON')
Address SDSF ISFSLASH "("oper_command.") (WAIT)"
l_cnt = 0
If datatype(isfulog.0) = "NUM" Then Do
  If isfulog.0 <> 0 Then Do
   l_cnt = l_cnt + 1
   l.l_cnt = substr(isfulog.1,1,43)
   Do ix=1 to isfulog.0
ll = length(isfulog.ix)
qdata = substr(isfulog.ix,44,ll-43)
l_cnt = l_cnt + 1
l.l_cnt = qdata
   End
  End
Else Do
  l_cnt = l_cnt + 1
  l.l_cnt = "No command response available"
  End
End
Else Do
  l_cnt = l_cnt + 1
  l.l_cnt = "Error in command reponse"
End
rc=isfcalls("OFF")
If (l_cnt = 0) Then Do
  l_cnt = l_cnt + 1
  l.l_cnt = ' /* no data produced */'
End
l.0 = l_cnt
Address MVS "ExecIO "l_cnt" DiskW "ddnm" (Finis Stem l.)"
l_cnt = 0
Return

_
Dave Jousma
Assistant Vice President, Manager, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Monday, May 16, 2016 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL "COMMAND" statements

Don't know the answer to 'normal' but you are welcome to this FWIW

/* CONSCMD: Rexx to issue any arbitrary console command via SDSF */
rc=isfcalls('ON')
Address SDSF ,
   "ISFEXEC '/" || Arg(1) || "'"
rc=isfcalls('OFF')

//stepname EXEC PGM=IRXJCL,
// PARM='CONSCMD  some.console.command  '
//* :: :
//* NAME OF EXEC <-->: :
//* ARGUMENT :<--------------->:
//SYSEXEC  DD   DSN=pds.where.above.stored,DISP=SHR

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony Thigpen
Sent: Monday, May 16, 2016 8:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL "COMMAND" statements

I have spent most of my life as a z/VSE and z/VM systems programmer, but
during the last year, I have been managing a couple of z/OS systems in our
small outsourcing shop.

At this point, I would consider myself just a very knowledgeable, but
still novice z/OS systems programmer. So, be gentle with your replies. :-)
And, please don't laugh.

Last night/this morning, I have stumped because I noticed that some JCL
set up by a previous systems programmer was not working as it appeared it
should. [At least, until I read the manual.]

We have many jobs set up something like thus:

//STEP1EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPTOR'
//WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP2EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPDOR'
//WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP3EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPAOR1'
//COMMD1   COMMAND 'S CICSPAOR2'
//WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//*

I, of course, though the commands would be synchronized with the execution
JCL. But, we were seeing timing errors that could not be corrected by just
increasing the wait timers. So, I started looking for the problem and found
that all the commands were being issued to the console before the first
IEFBR14 even executed.

I was totally surprised when I found that IBM documents the COMMAND jcl
card as being processed during the JCL conversion phase and not during the
execution phase. *And* that a previous systems programmer must not have
known it either.

So, now I have 2 questions for the knowledgeable people on the list:

1) Are there any other jcl statements that are executed outside the normal
execution phase?

2) What is the 'normal' method to issue console commands synchronized with
the job execution?

--
Tony Thigpen

--

Re: JCL "COMMAND" statements

2016-05-16 Thread Itschak Mugzach 
ed for batch only   */
> 'EXECIO * DISKR SYSIN (STEM mycmd. FINIS'
> if rc > 0 then do
>say 'Return code from OPEN was' rc
>say 'Aborting...'
>exit
>end
>
> /* Allocate results output file  */
> ddnm = 'DD'||random(1,9)
> Address TSO "Alloc Fi("ddnm") SYSOUT"
>
> /* Process all input commands*/
> Do c=1 to mycmd.0
>  oper_command.0 = 1
>  oper_command.1 = mycmd.c
>  Call Main_process
> End
>
> /* Free results output file  */
> Address TSO "Free Fi("ddnm")"
> Return 0
>
> Main_process:
> /* process all data from SYSIN   */
> rc=isfcalls('ON')
> Address SDSF ISFSLASH "("oper_command.") (WAIT)"
> l_cnt = 0
> If datatype(isfulog.0) = "NUM" Then Do
>  If isfulog.0 <> 0 Then Do
>   l_cnt = l_cnt + 1
>   l.l_cnt = substr(isfulog.1,1,43)
>   Do ix=1 to isfulog.0
>ll = length(isfulog.ix)
>qdata = substr(isfulog.ix,44,ll-43)
>l_cnt = l_cnt + 1
>l.l_cnt = qdata
>   End
>  End
> Else Do
>  l_cnt = l_cnt + 1
>  l.l_cnt = "No command response available"
>  End
> End
> Else Do
>  l_cnt = l_cnt + 1
>  l.l_cnt = "Error in command reponse"
> End
> rc=isfcalls("OFF")
> If (l_cnt = 0) Then Do
>  l_cnt = l_cnt + 1
>  l.l_cnt = ' /* no data produced */'
> End
> l.0 = l_cnt
> Address MVS "ExecIO "l_cnt" DiskW "ddnm" (Finis Stem l.)"
> l_cnt = 0
> Return
>
> _________________
> Dave Jousma
> Assistant Vice President, Manager, Mainframe Engineering
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
> p 616.653.8429
> f 616.653.2717
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Monday, May 16, 2016 11:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL "COMMAND" statements
>
> Don't know the answer to 'normal' but you are welcome to this FWIW
>
> /* CONSCMD: Rexx to issue any arbitrary console command via SDSF */
> rc=isfcalls('ON')
> Address SDSF ,
>   "ISFEXEC '/" || Arg(1) || "'"
> rc=isfcalls('OFF')
>
> //stepname EXEC PGM=IRXJCL,
> // PARM='CONSCMD  some.console.command  '
> //* :: :
> //* NAME OF EXEC <-->: :
> //* ARGUMENT :<--->:
> //SYSEXEC  DD   DSN=pds.where.above.stored,DISP=SHR
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tony Thigpen
> Sent: Monday, May 16, 2016 8:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JCL "COMMAND" statements
>
> I have spent most of my life as a z/VSE and z/VM systems programmer, but
> during the last year, I have been managing a couple of z/OS systems in our
> small outsourcing shop.
>
> At this point, I would consider myself just a very knowledgeable, but
> still novice z/OS systems programmer. So, be gentle with your replies. :-)
> And, please don't laugh.
>
> Last night/this morning, I have stumped because I noticed that some JCL
> set up by a previous systems programmer was not working as it appeared it
> should. [At least, until I read the manual.]
>
> We have many jobs set up something like thus:
>
> //STEP1EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPTOR'
> //WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //STEP2EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPDOR'
> //WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //STEP3EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPAOR1'
> //COMMD1   COMMAND 'S CICSPAOR2'
> //WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //*
>
> I, of course, though the commands would be synchronized with the execution
> JCL. But, we were seeing timing errors that could not be corrected by just
> increasing the wait timers. So, I started looking for the problem and found
> that all the commands were being issued to the console before the first
> IEFBR14 even executed.
>
> I was totally surprised when I found that IBM documents the COMMAND jcl
> card as being processed during the JCL conversion phase and not during the
> execution phase. *And* that a previous systems programmer must not have
> known it either.
>
> So, now I have 2 questions for the knowledgeable people on the list:
>
> 1) Are there any other jcl statements that are executed outside the normal
> execution phase?
>
> 2) What is the 'normal' method to issue co

Re: JCL "COMMAND" statements

2016-05-16 Thread Jousma, David 
om: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, May 16, 2016 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL "COMMAND" statements

Don't know the answer to 'normal' but you are welcome to this FWIW

/* CONSCMD: Rexx to issue any arbitrary console command via SDSF */  
rc=isfcalls('ON') 
Address SDSF ,
  "ISFEXEC '/" || Arg(1) || "'"   
rc=isfcalls('OFF')

//stepname EXEC PGM=IRXJCL,   
// PARM='CONSCMD  some.console.command  ' 
//* :: :  
//* NAME OF EXEC <-->: :  
//* ARGUMENT :<--->:  
//SYSEXEC  DD   DSN=pds.where.above.stored,DISP=SHR 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Monday, May 16, 2016 8:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL "COMMAND" statements

I have spent most of my life as a z/VSE and z/VM systems programmer, but during 
the last year, I have been managing a couple of z/OS systems in our small 
outsourcing shop.

At this point, I would consider myself just a very knowledgeable, but still 
novice z/OS systems programmer. So, be gentle with your replies. :-) And, 
please don't laugh.

Last night/this morning, I have stumped because I noticed that some JCL set up 
by a previous systems programmer was not working as it appeared it should. [At 
least, until I read the manual.]

We have many jobs set up something like thus:

//STEP1EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPTOR'
//WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP2EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPDOR'
//WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP3EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPAOR1'
//COMMD1   COMMAND 'S CICSPAOR2'
//WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//*

I, of course, though the commands would be synchronized with the execution JCL. 
But, we were seeing timing errors that could not be corrected by just 
increasing the wait timers. So, I started looking for the problem and found 
that all the commands were being issued to the console before the first IEFBR14 
even executed.

I was totally surprised when I found that IBM documents the COMMAND jcl card as 
being processed during the JCL conversion phase and not during the execution 
phase. *And* that a previous systems programmer must not have known it either.

So, now I have 2 questions for the knowledgeable people on the list:

1) Are there any other jcl statements that are executed outside the normal 
execution phase?

2) What is the 'normal' method to issue console commands synchronized with the 
job execution?

--
Tony Thigpen

--
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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

2016-05-16 Thread John McKown 
On Mon, May 16, 2016 at 11:25 AM, Charles Mills  wrote:

> I'm not even real familiar with UNIX export and I expected it to work the
> other way. You set a value and then you send (export) it somewhere, no?
>
> Charles
>
>
​Actually, at least in BASH on Linux, you can either export then set or set
then export. They have the same effect. What export does​

​make a shell environment variable "available" to ​a sub-shell or a
program. Example transcript which may help a bit:

$ printenv X # no value yet
$ sh -c 'printenv X' # likewise in subshell
$ X='a' # set value
$ printenv X # show it's here
a
$ sh -c 'printenv X' # but not here
$ export X
[tsh009@it-johnmckown-linux ~]$ sh -c 'printenv X' # export makes it
available
a
[tsh009@it-johnmckown-linux ~]$ printenv Y # try again - not there
[tsh009@it-johnmckown-linux ~]$ sh -c 'printenv Y' # not here either
[tsh009@it-johnmckown-linux ~]$ export Y # export it
[tsh009@it-johnmckown-linux ~]$ printenv Y # still no value
[tsh009@it-johnmckown-linux ~]$ sh -c 'printenv Y' # likewise
[tsh009@it-johnmckown-linux ~]$ Y="bye bye" #set value
[tsh009@it-johnmckown-linux ~]$ printenv Y # ow, wow - it's here!
bye bye
[tsh009@it-johnmckown-linux ~]$ sh -c 'printenv Y' # likewise, wow.
bye bye
[tsh009@it-johnmckown-linux ~]$

​Actually the export does not "make an environment variable available".
What happens in UNIX is that the shell create a _new_ environment array (an
array of pointers to pointers to chars - char **envp) based upon what has
been exported. I.e. the only name/values exported are copies into a _NEW_
environment block which is sent to the command. That's why a shell script
or program cannot affect the environment of its parent.




-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

2016-05-16 Thread Paul Gilmartin 
On Mon, 16 May 2016 09:25:14 -0700, Charles Mills wrote:

>I'm not even real familiar with UNIX export and I expected it to work the 
>other way. You set a value and then you send (export) it somewhere, no?
> 
POSIX shell:  Either way (almost).  Note the surprising semantics of special
builtins.  "unset" complicates things.

C Shell has distinct "set" and "setenv" commands, with irritatingly different 
syntax.
(cf. Tom Christiansen; we don't need a thread bemoaning C shell.)

-- gil

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

Re: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

2016-05-16 Thread Paul Gilmartin 
("Yes" only if you haven't been following my posts.)

On Mon, 16 May 2016 08:51:08 -0700, Ed Jaffe wrote:
>
>Made the mistake more than once of placing the EXPORT statement *after*
>the SET statements. But, really it's only counterintuitive if you're
>used to UNIX-style export (as apparently we both are). Otherwise, it's
>just "the way it works..."
> 
I got accustomed to the "the way [EXPORT] works."  But then I was truly
astonished by:

//  SET X=BEFORE
//SYSUT1  DD  *,SYMBOLS=JCL

//  SET X=AFTER

versus (untested; my guess):

//  SET A=BEFORE
//  SET X=  (JCL Ref. is fuzzy about validity of this.  RCF submitted.)
//SYSUT1  DD  SYMBOLS=JCL

//  SET A=AFTER

And:

//SYSUT1  DD  *
//  SET X=BEFORE
//DD  *,SYMBOLS=JCL  /* (JCL error here; documented.)  */


versus:

//SYSUT1  DD  *
//SYSUT1  DD  *
//  SET X=BEFORE
//DD  *,SYMBOLS=JCL  /* (JCL syntax OK.)  */


-- gil

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

Re: JCL "COMMAND" statements

2016-05-16 Thread Tony Thigpen 
These are 'system' jobs that are running with higher security. Most are 
nightly to stop some regions for nightly processes.


Tony Thigpen

Jeremy Nicoll wrote on 05/16/2016 12:19 PM:

On Mon, 16 May 2016, at 17:03, Itschak Mugzach wrote:

Tony. You may already seen that the //comand1 is not a dd nor exe jcl
card.
It is a jcl command statement and has nothing to do with the job steps.
Jcl
commands and jes /* commands are executed at conversion tome independed
with the job status. They are executed even if the job will never run.

As others explained, u can use tso console command and even verify
response. This way u can use a single jobstep.


Quite a few years ago, we used steps which issued a WTOR asking for
something to be done, and
either - even longer ago - real operators then did it, or more recently
AOC would issue the command
PROVIDED THE JOB ASKING FOR IT WAS ALLOWED TO DO IT and then reply to
the WTOR.

Generally I discouraged people from coding actual commands in the WTOR
text, and made the AOC
code NOT execute the arbitrary contents of the WTOR as a command.  So we
end up with, if you like,
plain text requests "PLEASE DO SOMETHING OR OTHER" and translated them
into the actual
command or commands required.

I can't imagine working in a site that would allow any job to issue any
arbitrary command!



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

Re: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

2016-05-16 Thread Charles Mills 
I'm not even real familiar with UNIX export and I expected it to work the other 
way. You set a value and then you send (export) it somewhere, no?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, May 16, 2016 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" 
statements")

On 5/16/2016 8:45 AM, Charles Mills wrote:
> OT, but me too. I found the order of  EXPORT and SET to be counterintuitive.

Made the mistake more than once of placing the EXPORT statement *after* the SET 
statements. But, really it's only counterintuitive if you're used to UNIX-style 
export (as apparently we both are). Otherwise, it's just "the way it works..."

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

Re: JCL "COMMAND" statements

2016-05-16 Thread Tony Thigpen 

Thanks all.

After the many suggestions, it 'rang a bell' with something I had worked 
on before:


//STEP01   EXEC PGM=IKJEFT1A,REGION=0M
//SYSPRINT DD SYSOUT=*
//SYSTSPRT  DD SYSOUT=*
//SYSTERM  DD SYSOUT=*
//SYSTSOUT DD SYSOUT=*
//SYSTSIN  DD *
 OC C('DS QD,TYPE=ALL,ONLINE')
/*

I have used the same OC exec to make one of my jobs work right.

Tony Thigpen

Nims,Alva John (Al) wrote on 05/16/2016 11:46 AM:

Check CBTTAPE.ORG there might be a couple of them there.

Create a REXX program to interface with TSO "OPERATOR" command or interface 
with SDSF API.
Can check results

IEBGENER to STDRDR, use $VS'' to issue MVS commands.
   Can't check results.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Monday, May 16, 2016 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL "COMMAND" statements

I have spent most of my life as a z/VSE and z/VM systems programmer, but during 
the last year, I have been managing a couple of z/OS systems in our small 
outsourcing shop.

At this point, I would consider myself just a very knowledgeable, but still 
novice z/OS systems programmer. So, be gentle with your replies. :-) And, 
please don't laugh.

Last night/this morning, I have stumped because I noticed that some JCL set up 
by a previous systems programmer was not working as it appeared it should. [At 
least, until I read the manual.]

We have many jobs set up something like thus:

//STEP1EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPTOR'
//WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP2EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPDOR'
//WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP3EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPAOR1'
//COMMD1   COMMAND 'S CICSPAOR2'
//WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//*

I, of course, though the commands would be synchronized with the execution JCL. 
But, we were seeing timing errors that could not be corrected by just 
increasing the wait timers. So, I started looking for the problem and found 
that all the commands were being issued to the console before the first IEFBR14 
even executed.

I was totally surprised when I found that IBM documents the COMMAND jcl card as 
being processed during the JCL conversion phase and not during the execution 
phase. *And* that a previous systems programmer must not have known it either.

So, now I have 2 questions for the knowledgeable people on the list:

1) Are there any other jcl statements that are executed outside the normal 
execution phase?

2) What is the 'normal' method to issue console commands synchronized with the 
job execution?

--
Tony Thigpen

--
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




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

Re: JCL "COMMAND" statements

2016-05-16 Thread Jeremy Nicoll 
On Mon, 16 May 2016, at 17:03, Itschak Mugzach wrote:
> Tony. You may already seen that the //comand1 is not a dd nor exe jcl
> card.
> It is a jcl command statement and has nothing to do with the job steps.
> Jcl
> commands and jes /* commands are executed at conversion tome independed
> with the job status. They are executed even if the job will never run.
> 
> As others explained, u can use tso console command and even verify
> response. This way u can use a single jobstep.

Quite a few years ago, we used steps which issued a WTOR asking for
something to be done, and
either - even longer ago - real operators then did it, or more recently
AOC would issue the command 
PROVIDED THE JOB ASKING FOR IT WAS ALLOWED TO DO IT and then reply to
the WTOR.

Generally I discouraged people from coding actual commands in the WTOR
text, and made the AOC
code NOT execute the arbitrary contents of the WTOR as a command.  So we
end up with, if you like,
plain text requests "PLEASE DO SOMETHING OR OTHER" and translated them
into the actual 
command or commands required.

I can't imagine working in a site that would allow any job to issue any
arbitrary command!

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: JCL "COMMAND" statements

2016-05-16 Thread Itschak Mugzach 
Tony. You may already seen that the //comand1 is not a dd nor exe jcl card.
It is a jcl command statement and has nothing to do with the job steps. Jcl
commands and jes /* commands are executed at conversion tome independed
with the job status. They are executed even if the job will never run.

As others explained, u can use tso console command and even verify
response. This way u can use a single jobstep.

Best
ITschak
בתאריך 16 במאי 2016 18:22,‏ "Tony Thigpen"  כתב:

> I have spent most of my life as a z/VSE and z/VM systems programmer, but
> during the last year, I have been managing a couple of z/OS systems in our
> small outsourcing shop.
>
> At this point, I would consider myself just a very knowledgeable, but
> still novice z/OS systems programmer. So, be gentle with your replies. :-)
> And, please don't laugh.
>
> Last night/this morning, I have stumped because I noticed that some JCL
> set up by a previous systems programmer was not working as it appeared it
> should. [At least, until I read the manual.]
>
> We have many jobs set up something like thus:
>
> //STEP1EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPTOR'
> //WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //STEP2EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPDOR'
> //WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //STEP3EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPAOR1'
> //COMMD1   COMMAND 'S CICSPAOR2'
> //WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //*
>
> I, of course, though the commands would be synchronized with the execution
> JCL. But, we were seeing timing errors that could not be corrected by just
> increasing the wait timers. So, I started looking for the problem and found
> that all the commands were being issued to the console before the first
> IEFBR14 even executed.
>
> I was totally surprised when I found that IBM documents the COMMAND jcl
> card as being processed during the JCL conversion phase and not during the
> execution phase. *And* that a previous systems programmer must not have
> known it either.
>
> So, now I have 2 questions for the knowledgeable people on the list:
>
> 1) Are there any other jcl statements that are executed outside the normal
> execution phase?
>
> 2) What is the 'normal' method to issue console commands synchronized with
> the job execution?
>
> --
> Tony Thigpen
>
> --
> 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: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

2016-05-16 Thread Ed Jaffe 

On 5/16/2016 8:45 AM, Charles Mills wrote:

OT, but me too. I found the order of  EXPORT and SET to be counterintuitive.


Made the mistake more than once of placing the EXPORT statement *after* 
the SET statements. But, really it's only counterintuitive if you're 
used to UNIX-style export (as apparently we both are). Otherwise, it's 
just "the way it works..."


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: JCL "COMMAND" statements

2016-05-16 Thread Nims,Alva John (Al) 
Check CBTTAPE.ORG there might be a couple of them there.

Create a REXX program to interface with TSO "OPERATOR" command or interface 
with SDSF API.
   Can check results

IEBGENER to STDRDR, use $VS'' to issue MVS commands.
  Can't check results.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Monday, May 16, 2016 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL "COMMAND" statements

I have spent most of my life as a z/VSE and z/VM systems programmer, but during 
the last year, I have been managing a couple of z/OS systems in our small 
outsourcing shop.

At this point, I would consider myself just a very knowledgeable, but still 
novice z/OS systems programmer. So, be gentle with your replies. :-) And, 
please don't laugh.

Last night/this morning, I have stumped because I noticed that some JCL set up 
by a previous systems programmer was not working as it appeared it should. [At 
least, until I read the manual.]

We have many jobs set up something like thus:

//STEP1EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPTOR'
//WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP2EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPDOR'
//WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP3EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPAOR1'
//COMMD1   COMMAND 'S CICSPAOR2'
//WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//*

I, of course, though the commands would be synchronized with the execution JCL. 
But, we were seeing timing errors that could not be corrected by just 
increasing the wait timers. So, I started looking for the problem and found 
that all the commands were being issued to the console before the first IEFBR14 
even executed.

I was totally surprised when I found that IBM documents the COMMAND jcl card as 
being processed during the JCL conversion phase and not during the execution 
phase. *And* that a previous systems programmer must not have known it either.

So, now I have 2 questions for the knowledgeable people on the list:

1) Are there any other jcl statements that are executed outside the normal 
execution phase?

2) What is the 'normal' method to issue console commands synchronized with the 
job execution?

--
Tony Thigpen

--
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

Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

2016-05-16 Thread Charles Mills 
> I found the counterintuitive interaction between SET and DD SYMBOLS=JCL 
> rudely astonishing.

OT, but me too. I found the order of  EXPORT and SET to be counterintuitive. 
That was the fat-fingering I was referring to that slowed me down on my 
"condition a jobstep on symbol comparison" quest. If IEBCOMPR did not log what 
it was seeing I might still be trying to figure out the problem.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 16, 2016 8:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL "COMMAND" statements

On Mon, 16 May 2016 11:21:00 -0400, Tony Thigpen wrote:
>
>1) Are there any other jcl statements that are executed outside the 
>normal execution phase?
> 
I found the counterintuitive interaction between SET and DD SYMBOLS=JCL rudely 
astonishing.

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

Re: JCL "COMMAND" statements

2016-05-16 Thread Paul Gilmartin 
On Mon, 16 May 2016 11:21:00 -0400, Tony Thigpen wrote:
>
>1) Are there any other jcl statements that are executed outside the
>normal execution phase?
> 
I found the counterintuitive interaction between SET and DD SYMBOLS=JCL
rudely astonishing.

>2) What is the 'normal' method to issue console commands synchronized
>with the job execution?
>
My guess: a program issuing MGCR?

-- gil

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

Re: JCL "COMMAND" statements

2016-05-16 Thread Charles Mills 
Don't know the answer to 'normal' but you are welcome to this FWIW

/* CONSCMD: Rexx to issue any arbitrary console command via SDSF */  
rc=isfcalls('ON') 
Address SDSF ,
  "ISFEXEC '/" || Arg(1) || "'"   
rc=isfcalls('OFF')

//stepname EXEC PGM=IRXJCL,   
// PARM='CONSCMD  some.console.command  ' 
//* :: :  
//* NAME OF EXEC <-->: :  
//* ARGUMENT :<--->:  
//SYSEXEC  DD   DSN=pds.where.above.stored,DISP=SHR 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Monday, May 16, 2016 8:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL "COMMAND" statements

I have spent most of my life as a z/VSE and z/VM systems programmer, but during 
the last year, I have been managing a couple of z/OS systems in our small 
outsourcing shop.

At this point, I would consider myself just a very knowledgeable, but still 
novice z/OS systems programmer. So, be gentle with your replies. :-) And, 
please don't laugh.

Last night/this morning, I have stumped because I noticed that some JCL set up 
by a previous systems programmer was not working as it appeared it should. [At 
least, until I read the manual.]

We have many jobs set up something like thus:

//STEP1EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPTOR'
//WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP2EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPDOR'
//WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP3EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPAOR1'
//COMMD1   COMMAND 'S CICSPAOR2'
//WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//*

I, of course, though the commands would be synchronized with the execution JCL. 
But, we were seeing timing errors that could not be corrected by just 
increasing the wait timers. So, I started looking for the problem and found 
that all the commands were being issued to the console before the first IEFBR14 
even executed.

I was totally surprised when I found that IBM documents the COMMAND jcl card as 
being processed during the JCL conversion phase and not during the execution 
phase. *And* that a previous systems programmer must not have known it either.

So, now I have 2 questions for the knowledgeable people on the list:

1) Are there any other jcl statements that are executed outside the normal 
execution phase?

2) What is the 'normal' method to issue console commands synchronized with the 
job execution?

--
Tony Thigpen

--
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: JCL "COMMAND" statements

2016-05-16 Thread John McKown 
On Mon, May 16, 2016 at 10:21 AM, Tony Thigpen  wrote:

> I have spent most of my life as a z/VSE and z/VM systems programmer, but
> during the last year, I have been managing a couple of z/OS systems in our
> small outsourcing shop.
>
> At this point, I would consider myself just a very knowledgeable, but
> still novice z/OS systems programmer. So, be gentle with your replies. :-)
> And, please don't laugh.
>
> Last night/this morning, I have stumped because I noticed that some JCL
> set up by a previous systems programmer was not working as it appeared it
> should. [At least, until I read the manual.]
>
> We have many jobs set up something like thus:
>
> //STEP1EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPTOR'
> //WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //STEP2EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPDOR'
> //WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //STEP3EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPAOR1'
> //COMMD1   COMMAND 'S CICSPAOR2'
> //WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //*
>
> I, of course, though the commands would be synchronized with the execution
> JCL. But, we were seeing timing errors that could not be corrected by just
> increasing the wait timers. So, I started looking for the problem and found
> that all the commands were being issued to the console before the first
> IEFBR14 even executed.
>
> I was totally surprised when I found that IBM documents the COMMAND jcl
> card as being processed during the JCL conversion phase and not during the
> execution phase. *And* that a previous systems programmer must not have
> known it either.
>
> So, now I have 2 questions for the knowledgeable people on the list:
>
> 1) Are there any other jcl statements that are executed outside the normal
> execution phase?
>

​If you see anything like:

/*$VS,'... some z/OS command'

it will be executed when read.


>
> 2) What is the 'normal' method to issue console commands synchronized with
> the job execution?


​I know three. The first is "insecure" and has what many consider a "nasty"
requirement. That is to use IEBGENER to copy the command(s) to the INTRDR.
This is insecure and a security problem because it allows anyone to issue
commands via the INTRDR. The INTRDR needs to be granted the authority to do
this.

A better way is to download file 246 from
http://www.cbttape.org/cbtdowns.htm . This is a batch program which will
use the MGCR macro to issue z/OS operator commands. It must be in an APF
authorized library. You can user its use by _not_ placing it on the
LINKLIST, and securing access to the APF library using your ESM (RACF, TSS,
ACF2, other).​

​The last method is to run SDSF in batch and issue commands like you would
as a TSO user.​

I just saw where Ed has a fourth method.




-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: JCL "COMMAND" statements

2016-05-16 Thread Ed Jaffe 

On 5/16/2016 8:21 AM, Tony Thigpen wrote:
2) What is the 'normal' method to issue console commands synchronized 
with the job execution?


You can send "synchronized" commands in an executable step using the 
TSO/E CONSOLE or any software product (such as (E)JES, SDSF, IOF, etc.) 
that can issue commands... Here is an example using TSO/E CONSOLE that 
issues the 'DISPLAY ASM' command:


//COMMAND EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD DATA,DLM='@@'
CONSOLE ACTIVATE
CONSOLE SYSCMD(D ASM)
@@

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

JCL "COMMAND" statements

2016-05-16 Thread Tony Thigpen 
I have spent most of my life as a z/VSE and z/VM systems programmer, but 
during the last year, I have been managing a couple of z/OS systems in 
our small outsourcing shop.


At this point, I would consider myself just a very knowledgeable, but 
still novice z/OS systems programmer. So, be gentle with your replies. :-)

And, please don't laugh.

Last night/this morning, I have stumped because I noticed that some JCL 
set up by a previous systems programmer was not working as it appeared 
it should. [At least, until I read the manual.]


We have many jobs set up something like thus:

//STEP1EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPTOR'
//WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP2EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPDOR'
//WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP3EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPAOR1'
//COMMD1   COMMAND 'S CICSPAOR2'
//WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//*

I, of course, though the commands would be synchronized with the 
execution JCL. But, we were seeing timing errors that could not be 
corrected by just increasing the wait timers. So, I started looking for 
the problem and found that all the commands were being issued to the 
console before the first IEFBR14 even executed.


I was totally surprised when I found that IBM documents the COMMAND jcl 
card as being processed during the JCL conversion phase and not during 
the execution phase. *And* that a previous systems programmer must not 
have known it either.


So, now I have 2 questions for the knowledgeable people on the list:

1) Are there any other jcl statements that are executed outside the 
normal execution phase?


2) What is the 'normal' method to issue console commands synchronized 
with the job execution?


--
Tony Thigpen

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