Программа PC COBOL для JCL

#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 МБ вторичного пространства. Каждое распределение округляется в большую сторону до следующего целого числа дорожек или цилиндров, в зависимости от физической структуры диска. Вам просто больше не нужно беспокоиться. Здорово, не правда ли?