|
View previous topic :: View next topic
|
| Author |
Message |
AlexSalas95
New User
Joined: 18 Mar 2024
Posts: 13
Location: United States
|
|
|
|
Trying to be as brief as possible, we receive a file via FTP, which then triggers a script which updates a jcl text file and submits the jcl to the internal reader to execute. This jcl simply demands in another job, which triggers the rest of the process flow.
This works fine and dandy when we receive one file at a time, with plenty of time between them. However, we experience issues when we receive multiple files at the same time. These processes start trying to use the same datasets and as expected, bad things happen.
Now, I'm trying to rewrite this process to fix these issues. It's my understanding that our system does not allow jobs of the same name to run concurrently. These jobs will be queued in the order they are submitted and executed one at a time. So, my first thought was to move the entire flow into the jcl text file that is submitted to the JES internal reader. Which I think would probably work fine, but I don't really like that solution for several reasons.
Also, the senior members of my team don't have a lot of experience updating scripts on a network drive or FTPing encrypted files etc. So, maintaining the subsequent jobs would be difficult. Also, just philosophically I think jobs our system executes should reside, well... on the system. Not in some text file, on a random server directory. I think most of the actual logic should be installed and maintained like the rest of our processes.
So, ideally what I'd like to happen is;
File is received -> script executes and modifies jcl.txt -> jcl.txt is submitted to the internal reader -> jcl.txt demands in another job but waits on it to finish before completing itself.
That way, no matter how many files we receive at once, only one job flow will be running at a given time.
Since this process is run on-demand, at any given time, initially triggered by something the system knows nothing about, it couldn't be managed by our scheduler
Is there a way to do this? Or am I overthinking this? |
|
| Back to top |
|
 |
Joerg.Findeisen
Senior Member
Joined: 15 Aug 2015
Posts: 1387
Location: Bamberg, Germany
|
|
|
|
| See what JOBGROUP can do for you, depending on the frequency of the incoming dataset. |
|
| Back to top |
|
|
AlexSalas95
New User
Joined: 18 Mar 2024
Posts: 13
Location: United States
|
|
|
|
Thank you @Joerg.Findeisen! A quick search through my company's libraries had me a little nervous since, as far as I can tell nobody in our shop uses JOBGROUPs  . However, I was able to rig a simple test for it and got it to work!
I will still have to figure out exactly how to use it in my situation, but this is very interesting. Thanks again for the tip!
I'll post an example of the test jcl I was able to come up with below;
| Code: |
//*********************************************************************
//MULTI1 JOBGROUP
//SLEEPTST GJOB
//EMAILSND GJOB
// AFTER NAME=SLEEPTST,
// WHEN=(RC=0)
//MULTI1 ENDGROUP
//*********************************************************************
//* JOB 1
//*********************************************************************
//SLEEPTST JOB (....),____,CLASS=_,MSGCLASS=_
// SCHEDULE JOBGROUP=MULTI1
//STEP0001 EXEC PGM=AOPBATCH,PARM='sleep 60'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDIN DD DUMMY
//*********************************************************************
//* JOB 2
//*********************************************************************
//EMAILSND JOB (....),____,CLASS=_,MSGCLASS=_
// SCHEDULE JOBGROUP=MULTI1
//MAILA EXEC MAILFILE,LETTER=[HLQ].SEQ.EMAIL.FILE
//********************************************************************* |
|
|
| Back to top |
|
|
Joerg.Findeisen
Senior Member
Joined: 15 Aug 2015
Posts: 1387
Location: Bamberg, Germany
|
|
|
|
| What you might have to consider is, that the group must be registered before the members of it are scheduled. So a HOLDUNTL can be useful in the participating jobs. But if it's needed depends a bit on your JES2. |
|
| Back to top |
|
|
AlexSalas95
New User
Joined: 18 Mar 2024
Posts: 13
Location: United States
|
|
|
|
| Unfortunately, I don't think I can use this in my case. After doing some testing with JOBGROUPS, I found that you cannot create multiple instances with the same names. If any subsequent JOBGROUPS are submitted for the first is finished, they will fail |
|
| Back to top |
|
|
|
|
|
