|
View previous topic :: View next topic
|
| Author |
Message |
pmvino
New User
Joined: 22 Aug 2008
Posts: 20
Location: india
|
|
|
|
Hi,
In my requirement
The JCL1 will execute a Rexx program which will submit another one JCL2 through the INTRDR using TSO SUBMIT command. The rexx program waits till the INTRDR job gets over. In the INTRDR, the VSAM file is getting copied to PS file.
After the completion of this step, the JCL1 will submit a rexx to sleep for 30 minutes.
Can any one tell me whether the VSAM file is getting locked for 30 Minutes or untill the execution of the INTRDR JOB (JCL2).
Please help me in the confusion
Thanks in advance,
VInodh P M |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
Your subject line is misleading -- INTRDR is not executed, it is a facility available to the system. JCL copied to the internal reader will be submitted to the system similarly to doing a TSO SUBMIT command.
Does the job you are submitting to the internal reader end with /*EOF? If not, typically the job will not be submitted until either the internal reader is closed (by the end of the step) or another job is submitted by your program which will cause the first submitted job to go to converter / interpreter. So the VSAM file could be getting locked, depending upon how you've coded up your jobs. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| Quote: |
| After the completion of this step, the JCL1 will submit a rexx to sleep for 30 minutes. |
Why do you want to block an initiator for 30 minutes
What is the reason for the wait |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| Why do you want to block an initiator for 30 minutes |
My guess? To measure operator response time -- to see how fast they will cancel the job, since this practice violates production standards at most places I've worked.  |
|
| Back to top |
|
|
pmvino
New User
Joined: 22 Aug 2008
Posts: 20
Location: india
|
|
|
|
1) THE JCL1 submits the following REXX program in step 1:
Please find the REXX pgm that submits the JCL
"ispexec ftopen temp"
"ispexec ftincl VSAMTOPS"
"ispexec ftclose"
"ISPEXEC VGET (ZTEMPF)"
JCL=ZTEMPF
X = OUTTRAP('LOG.')
ADDRESS TSO SUBMIT "'"JCL"'"
Where the VSAMTOPS is the member of my SKEL LIB. The Rexx is coded such a way that, after completion of the JOB, The job will get purged.
In VSAMTOPS member I am having the JCL like Below
//STEP100 EXEC PGM=IDCAMS
//SYSPRINT DD &SARW
//VSAM DD DSN=SYS2.OPCP.NCP,DISP=SHR
//SEQ DD DSN=&NVSAM..&MODE..OPC.NCP,UNIT=&SYSDA,
// SPACE=(TRK,(10,10)),
// DISP=(NEW,CATLG,CATLG),
// DCB=(LRECL=32004,RECFM=VB)
//SYSIN DD DSN=&NVSAM..&MODE..REXX.OPC.SCHDLE.CNTL(VSAMTOPS),
// DISP=SHR
//*
2) THE JCL1 has the Second Step to execute a rexx program for SLEEP 30 MIn
I must need this step, For allowing the third party to execute their prcocess.
Once this process gets completed then the scheduler will submit the next JOB for the sequent process.
My question is ..... Can the Third Party update the VSAM file within the JCL1 get finishes (ie During the execution of the JCL1 or with in 30 MIn).
Please Reply.....
Thank,
Vinodh P M |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
I must need this step, For allowing the third party to execute their prcocess.
Once this process gets completed then the scheduler will submit the next JOB for the sequent process. |
Sorry, No, you don't. . .
There is no reason for the "delay" job. Everything you need can (and should) be done by scheduling. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| My question is ..... Can the Third Party update the VSAM file within the JCL1 get finishes (ie During the execution of the JCL1 or with in 30 MIn). |
Your answer is ... it depends.
First, you absolutely do not ever, under any circumstances, want to force a 30-minute wait in a batch job. Waits are for transaction systems -- batch systems do not do transaction processing. If you need another job run 30 minutes from now, use the scheduling system installed at your site to start the new job -- but don't put a wait in a batch job; it ties up resources and frequently gets canceled.
Second, depending on whether or not your job has exclusive access to the VSAM file, another process may or may not be able to update the VSAM file. If multiple processes (jobs, TSO sessions, online sessions, or started tasks) need to update the VSAM file at the same time, you must use enqueue and dequeue mechanisms to enforce serialization of updates. Otherwise, your data will be corrupted -- maybe not today, maybe not tomorrow -- but at some point in time it will be corrupted.
Since you're just restating your problem over and over without providing any additional information (which job(s) need to UPDATE the VSAM file, for example), we cannot provide any clearer guidance to you. |
|
| Back to top |
|
|
|
|
