#compilation #versioning #cobol #zos
Вопрос:
У меня есть работа по компиляции COBOL, которую я не писал, и я пытаюсь понять, как это работает. Это выглядит примерно так:
//COB EXEC PGM=IGYCRCTL,COND=(0,NE,TRN),
// PARM=('DTR,NUMPROC(PFD),NOADV,LIST,LIB,TRUNC(BIN)', *
// 'NOSEQ,DYN,RMODE(ANY),OUT(SYSPRINT),MAP')
//STEPLIB DD DISP=SHR,DSN=SYS1.IGY.SIGYCOMP
//SYSPRINT DD DSN=xxx..xxx..xxx.LST(amp;NAME),DISP=SHR
//SYSUT1 DD UNIT=SYSDA,SPACE=(460,(1700,1000))
...
//SYSLIB DD DISP=SHR,DSN=xxx..xxx..xxx.CPY
// DD DISP=SHR,DSN=SYSQ.MQS710A.SCSQCOBC MQ-SERIES
Это не настоящая работа, я изменил некоторые части на «xxx», потому что не могу выдать реальный код.
Я понимаю, что наборы данных после SYSLIB являются зависимостями программы, которую я компилирую. Чего я не понимаю, так это того, как здесь работает управление версиями для тетрадей. Он будет извлекать все, что находится в наборе данных под классификатором «xxx..xxx..xxx.CPY». Как я узнаю, что есть все необходимые тетради (ошибка компиляции?) и что они являются правильной версией, которую намеревался использовать оригинальный программист.
Для набора данных тетрадей серии MQ, похоже, есть номер версии в названии «MQS710A». Так ли это должно быть в z/OS?
В другом наборе данных «xxx..xxx..xxx.CPY» в названии нет ничего похожего на версию, «xxx» — это просто набор букв.
Ответ №1:
Когда на ТЕТРАДЬ ссылаются, она выбирается на основе первого набора данных, в котором найдена ТЕТРАДЬ. Компилятор не смотрит на имя набора данных, в котором вы видите номер версии. Номер версии — это соглашение, позволяющее контролировать, когда в среду вносятся новые изменения.
В качестве примера предположим, что установлена новая версия MQ. Набор данных можно изменить, чтобы ссылаться на более новую версию. Это будет зависеть от того, как системные программисты внесут изменения в окружающую среду. Это более сложный ответ, чем то, о чем говорит ваш пост.
Если вы «управляете версиями», вы должны упорядочить последовательность наборов данных в объединении. Например, вы можете увидеть что-то вроде:
//SYSLIB DD DISP=SHR,DSN=xxx.DEV.xxx.CPY
// DD DISP=SHR,DSN=xxx.PROD.xxx.CPY
// DD DISP=SHR,DSN=SYSQ.MQS710A.SCSQCOBC MQ-SERIES
Этот подход позволяет разработчикам собирать тетради, которые изменяются в рамках новой функции, а затем извлекать оставшиеся из текущих рабочих версий.
Все это говорит о том, что если вы используете систему управления исходными кодами, их процесс компиляции будет отличаться от простого объединения.
Если ТЕТРАДЬ не найдена, вы получите сообщение об ошибке компиляции.
Комментарии:
1. Спасибо вам за ваш ответ. Для меня, исходящего из java-фона, это сбивает с толку и выглядит опасным. У меня был ПОМ Maven, в котором я устанавливал определенную версию своих зависимостей. Итак, вы хотите сказать, что я должен убедиться, что зависимость является правильной версией, которую я намерен использовать, проверив набор данных? В вашем примере я должен был бы проверить, что наборы данных DEV и PROD не перекрываются непреднамеренным образом?
2. Способ объединения наборов данных MVS заключается в том, что вы помещаете наборы данных в список, а затем по запросу (в вашем случае это тетрадь) используется первый набор данных с именем. Таким образом, порядок наборов данных находится в желаемом порядке. Для разработчиков вы хотите, чтобы ваши тесты были на высоте. Если это ответ на ваш вопрос, пожалуйста, отметьте вопрос как таковой. Новые вопросы приветствуются, и я уверен, что их будет много.