#cobol #jcl #gnucobol
#cobol #jcl #gnucobol
Вопрос:
У меня есть следующая простая программа на языке COBOL, написанная для ПК. Он просто считывает файл с компьютера и записывает в файл:
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT CUSTOMER-FILE ASSIGN TO
"C:Customers.dat"
ORGANIZATION IS LINE SEQUENTIAL.
DATA DIVISION.
FILE SECTION.
FD CUSTOMER-FILE.
01 CUSTOMER-RECORD.
05 FIRST-NAME PIC X(20).
05 LAST-NAME PIC X(20).
WORKING-STORAGE SECTION.
01 WS-CUSTOMER-RECORD.
05 WS-FIRST-NAME PIC X(20).
05 WS-LAST-NAME PIC X(20).
01 WS-EOF PIC X.
PROCEDURE DIVISION.
OPEN OUTPUT CUSTOMER-FILE
PERFORM UNTIL CUSTOMER-RECORD = SPACES
DISPLAY "Enter the first and last name for the customer"
ACCEPT CUSTOMER-RECORD
WRITE CUSTOMER-RECORD
END-PERFORM
CLOSE CUSTOMER-FILE
DISPLAY "Output from the Customer File:"
OPEN INPUT CUSTOMER-FILE.
PERFORM UNTIL WS-EOF = 'Y'
READ CUSTOMER-FILE INTO WS-CUSTOMER-RECORD
AT END MOVE 'Y' TO WS-EOF
NOT AT END DISPLAY WS-CUSTOMER-RECORD
END-READ
END-PERFORM.
CLOSE CUSTOMER-FILE.
GOBACK.
Мой вопрос: я не слишком знаком с JCL. Итак, если бы я поместил эту программу на мэйнфрейм, что бы я сделал для JCL?
Комментарии:
1. считывает файл с компьютера и записывает в файл Это предполагает, что у вас есть файлы . У вас , конечно, этого не будет
C:
.
Ответ №1:
Я предполагаю, что ваш отдел идентификации потерялся в результате инцидента с вырезанием и вставкой на пути к переполнению стека; вам это понадобится.
Текущее воплощение IBM Enterprise COBOL не допускает свободный формат исходного кода, поэтому для компиляции вашего кода вам придется переформатировать и следовать традиционному фиксированному формату.
Вместо ссылки на ваш файл данных по имени, ваше предложение Assign должно ссылаться на имя (не более 8 символов), которое соответствует имени DD в вашем JCL. Выберите что-нибудь значимое, насколько это возможно, из 8 символов, возможно, КЛИЕНТА.
Поскольку вы работаете с JCL, ваш оператор Accept будет работать немного по-другому. Вероятно, данные будут поступать из SYSIN DD.
Ваш JCL будет выглядеть примерно так…
[job card, which is shop-specific]
//TOMSPGM EXEC PGM=yourProgramName
//STEPLIB DD DISP=SHR,DSN=mainframe.dataset.where.you.bound.your.program
//SYSIN DD *
[your customer records]
//CUSTOMER DD DISP=(NEW,CATLG,DELETE),
// DSN=mainframe.dataset.where.your.data.should.end.up,
// LRECL=40,
// AVGREC=U,
// RECFM=FB,
// SPACE=(40,(10,10),RLSE) Adjust to your needs
//SYSOUT SYSOUT=*
//CEEDUMP SYSOUT=*
Я не уверен, как это будет работать с вашим созданием файла customer и последующим чтением его в той же программе. За 30 лет работы на мэйнфреймах я никогда такого не видел.
Комментарии:
1. Я не вижу причины, по которой чтение набора данных, созданного и записанного на одном шаге, не будет работать с COBOL. Как только набор данных закрывается после записи, система получает информацию, необходимую для открытия для ввода.
2. Это очень полезно!
Ответ №2:
Добавление к ответу от @cschneid.
Приятно видеть AVGREC
, что оператор DD используется для выделения места для набора данных. Это намного лучше, чем использовать старомодные CYL
TRK
модули или. К сожалению, ИМХО, архитекторы IBM z / OS пропустили внедрение более современного, чтобы указать пространство: KiB или MiB. (ISPF поддерживает КБ и МБ в качестве единицы пространства, JCL этого не делает.)
При AVGREC
этом вы сообщаете системе, что SPACE=
первичные и вторичные значения пространства — это количество записей, а не физические единицы, такие как дорожки или цилиндры.
//CUSTOMER DD ...
// AVGREC=U,
// SPACE=(40,(10,20),RLSE)
Приведенное выше утверждение сообщает системе, что записанные записи будут иметь среднюю длину 40 байт (это полностью не зависит от RECFM=
, или LRECL=
!). С AVGREC=U
помощью ( U
означает единицы измерения) это дополнительно указывает системе выделить начальное (основное) пространство для 10 записей и добавлять дополнительное пространство для 20 записей каждый раз, когда требуется больше места (с верхним пределом).
Физические распределения все еще находятся в дорожках или цилиндрах под капотом. Система вычисляет дорожки или цилиндры, необходимые из
"average record length" * "number of records" * avgrec-unit
Для основного распределения это
40 * 10 * 1 = 400 bytes
Хорошо. Но как мы можем указать наши потребности в пространстве в КБ или MiB, используя эти ключевые слова?
Помните, что средняя длина записи в SPACE=
параметре полностью не соответствует фактической длине записи, указанной через LRECL=
. Отлично, так что мы можем свободно выбирать среднюю длину записи и устанавливать ее, скажем, на 1. И давайте также изменим формулировку «количество записей * в приведенном выше форуме» на «количество единиц». Формула становится:
1 * "number of units" * avgrec-unit
или
"number of units" * avgrec-unit
AVGREC=
поддерживает единицы U
измерения (1), K
(1024) и M
(1024*1024). Итак, чтобы выделить место в мегабайтах (MiB), мы просто кодируем:
//CUSTOMER DD ...
// AVGREC=M,
// SPACE=(1,(10,20),RLSE)
Это выделит 10 МБ первичного пространства и 20 МБ вторичного пространства. Каждое распределение округляется в большую сторону до следующего целого числа дорожек или цилиндров, в зависимости от физической структуры диска. Вам просто больше не нужно беспокоиться. Здорово, не правда ли?