Зависимость работы JCL без планировщика

Question

Я пытаюсь реализовать JCL в среде JES2, которая запускает набор заданий с зависимостями, например:

JOB_A  -> JOB_B   ) 
JOB_C  -> JOB_D   ) -> JOB_E

Другими словами, JOB_E запускается только после завершения JOB_B и JOB_D.

Я могу запустить JOB_B и JOB_D через внутреннюю программу чтения заданий в JOB_A и JOB_C, но не могу не создать зависимости для JOB_E.

Я попытался изучить блокировку ресурса JCL, чтобы можно было заблокировать набор данных в JOB_B и JOB_D, который необходим JOB_E, чтобы JOB_E запускался только тогда, когда все наборы данных доступны, но JCL запрашивает только набор данных на уровне STEP и освобождает их после этого. Если бы JCL мог запросить весь набор данных перед запуском, я мог бы реализовать некоторый вид мьютекса в JOB, например:

 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 в среде разработки без доступа к планировщику.

Answer 1

Ваш комментарий о том, что это необходимо для тестирования в среде разработки без доступа к планировщику , заставляет задуматься, есть ли в вашем магазине планировщик для производственной среды. Если это произойдет, то ваше тестирование не будет фактически проверять то, что будет использоваться в вашей производственной среде. Просто о чем подумать, если вы еще этого не сделали.

В ответ на ваш вопрос один из методов - использовать утилиту, например IEBGENER, на последнем шаге одного задания для отправки следующего задания.

Например, последний шаг JOB_A будет выполнять IEBGENER с SYSUT1, содержащим исполняемый JCL для JOB_B и SYSUT2, указывающим на INTRDR . Это одна из техник, которую вы могли бы использовать, хотя заставить JOB_E работать так, чтобы она не мешала выполнению каких-либо других заданий, может быть сложно, так как JOB_E должен запускаться после выполнения * JOB_B и JOB_D.

Другим методом будет использование Rexx в пакетном режиме для отправки ваших заданий с помощью внутреннего считывателя, а затем с помощью SDSF Rexx-интерфейс для отслеживания того, когда они завершены. По сути, вы будете писать специальный планировщик заданий, соответствующий вашему набору заданий.

Answer 2

Мне интересно, зачем тратить драгоценное время на тестирование набора заданий, где набор PROD совершенно другой и будет обрабатываться каким-то планировщиком xyz.Не возражайте, если я покажу себя сумасшедшим, но позвольте мне предложить и мое:

Предположение: Ваши задания требуют управляемого процессора и НЕ НУЖДАЮТСЯ в параллельном запуске.* A запускает B запускает C запускает D запускает E (я знаю, что это не заслуживает внимания, но ваше тестирование проходит успешно) Я просто изложил это здесь, думая, что бы я сделал на вашем месте.Мне в основном нужно, чтобы мои тесты проходили быстро и хорошо.Позвольте мне знать ваш клише.

Теперь, позвольте мне поблагодарить вас обоих за такое разрешение, что мы можем управлять представлением заданий с помощью REXX, что тоже создает виртуальное и субъективное планирование.