没有调度程序的 JCL 作业依赖性
我正在尝试在 JES2 环境中实现一个 JCL,它启动一组具有依赖项的作业,例如:
JOB_A -> JOB_B )
JOB_C -> JOB_D ) -> JOB_E
换句话说,JOB_E 仅在 JOB_B 和 JOB_D 完成时启动。
我可以通过 JOB_A 和 JOB_C 中的作业内部读取器启动 JOB_B 和 JOB_D,但我无法不创建 JOB_E 的依赖项。
我尝试探索JCL资源锁,以便我可以锁定JOB_E所需的JOB_B和JOB_D中的数据集,以便JOB_E仅在所有数据集可用时启动,但JCL仅请求STEP级别的数据集并随后释放它们。如果 JCL 可以在启动之前请求所有数据集,我可以在作业中实现某种互斥体,例如:
JOB_A locks data set DSN_A
JOB_B waits to get data set DSN_A
JOB_C locks data set DSN_C
JOB_D waits to get data set DSN_C
JOB_E waits to get data set DSN_A and DSN_C
如何做到这一点?
我需要它在开发环境中测试 JCL 集,而无需访问调度程序。
I'm trying to implement a JCL, in a JES2 environment, that launches a set of jobs with dependencies in it, for example:
JOB_A -> JOB_B )
JOB_C -> JOB_D ) -> JOB_E
In other words, JOB_E is only launched when JOB_B and JOB_D are finished.
I can launch JOB_B and JOB_D through job internal reader in JOB_A and JOB_C but I can't not create the dependencies for JOB_E.
I tried to explore JCL resource lock so that I could lock a data set in JOB_B and JOB_D that JOB_E needed so that JOB_E would only start when all data set's are available but the JCL only requests data set in STEP level and release them afterwards. If JCL could request all data set before start I could implement some sort of mutex in the JOBs, for example:
JOB_A locks data set DSN_A
JOB_B waits to get data set DSN_A
JOB_C locks data set DSN_C
JOB_D waits to get data set DSN_C
JOB_E waits to get data set DSN_A and DSN_C
How to do this?
I need this to test set of JCL's in a development environment without access to a scheduler.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您的评论是您需要在无法访问调度程序的开发环境中进行测试,这让我想知道您的商店是否有用于生产环境的调度程序。如果是这样,那么您的测试实际上不会测试生产环境中将使用的内容。如果您还没有的话,请考虑一下。
为了回答您的问题,一种技术是在一项作业的最后一步使用 IEBGENER 等实用程序来提交后续作业。
例如,JOB_A 的最后一步将执行 IEBGENER,SYSUT1 包含 JOB_B 的执行 JCL,SYSUT2 指向 INTRDR。这是您可以使用的一种技术,但让 JOB_E 运行以使其不干扰任何其他作业可能会很棘手,因为 JOB_E 需要在 JOB_B 和 JOB_D 完成后运行。
另一种技术是使用 Rexx< /a> 在 批处理模式使用内部阅读器提交作业,然后使用SDSF Rexx 界面 来监视它们何时完成。本质上,您将编写一个专门针对您的作业集的专用作业调度程序。
十年后更新...
从 z/OS 2.2 开始,IBM 添加了 JES2 执行控制语句,它“定义一组作业和作业本身的执行顺序”。在使用此功能之前,您的 z/OS 系统程序员必须完成一些配置。
Your comment that you need this to test in a development environment without access to a scheduler makes me wonder if your shop has a scheduler for the production environment. If it does, then your testing will not actually test what will be used in your production environment. Just something to think about if you haven't already.
In answer to your question, One technique is to use a utility such as IEBGENER in the last step of one job to submit a subsequent job.
For example, The last step of JOB_A would execute IEBGENER with SYSUT1 containing the execution JCL for JOB_B and SYSUT2 pointing at INTRDR. This is one technique you could use, though getting JOB_E to run so that it doesn't interfere with any of the other jobs might be tricky, as JOB_E needs to run after both JOB_B and JOB_D complete.
Another technique would be to use Rexx in batch mode to submit your jobs using the internal reader and then use the SDSF Rexx interface to watch for when they complete. Essentially you will be writing a special-purpose job scheduler, specific to your set of jobs.
Update, ten years later...
As of z/OS 2.2 IBM has added JES2 Execution Control Statements which "define the execution sequencing of a group of jobs and the jobs themselves". Prior to use of this feature, some configuration must be done my your z/OS Systems Programmer.
我想知道为什么要投入宝贵的时间来测试一组作业,其中 PROD 集完全不同并且将由某些 xyz 调度程序处理。如果我听起来很疯狂,请不要介意,但让我也提出我的建议:
假设:您的作业需要可管理的 CPU,并且不需要并行运行。
现在,让我感谢你们的解决方案,我们可以通过 REXX 来管理作业的提交,这也创建了虚拟和主观的调度。
I'm wondering why to invest precious time to test a set of jobs, where the PROD set is entirely different and will be handled by some xyz scheduler. Don't mind, if I sound crazy but lemme propose mine too:
Assumption: Your jobs take manageable CPU and NO NEED to be run parallely.
Now, lemme appreciate you both for such resolution that we can manage submission of jobs by means of REXX that too creating a virtual and subjective scheduling.