Это несколько вопросов ... два самых важных:
Существуют ли какие-либо операции COBOL, которые можно выполнить только с помощью абзацев / разделов?
Да. Вероятно, неполный список:
USE утверждения в DECLARATIVES могут применяться только к абзацу или разделу. Они используются для обработки ошибок файлов и исключений. Не все компиляторы полностью поддерживают эту стандартную функцию COBOL. - Сегментация (основная: программа, которая загружается в память лишь частично) возможна только с разделами; но это следует рассматривать как «устаревшую функцию» (по крайней мере, я не знаю людей, действительно использующих ее таким образом явно); см. комментарий Гилберта Ле Блана c для получения дополнительной информации об этом
- провале, многие другие языки имеют эту функцию с своего рода оператором
switch (COBOL's EVALUATE, который не совпадает с обычным switch, но может использоваться аналогично, имеет явное break и без провала) GO TO DEPENDING ON (может быть перекодирован для достижения чего-то подобного с помощью EVALUATE а затем либо PERFORM, если абзацы ожидаются, пропадут, что не редкость, тогда это создает много дополнительного кода) GO TO в целом и особенно приятно - старый устаревший оператор ALTER PERFORM, формат 1 «вне линии» - состояние файла используется совместно только программами, если вы определяете его как
EXTERNAL, и вы часто хотите, чтобы состояние файла было ограничено одной программой - до оператора COBOL85:
EXIT (просто без чего-либо другого, фактически ничего не делая, кроме как CONTINUE)
Какая польза от использования para графики и разделы для выполнения фрагментов кода вместо использования подпрограммы?
- общие данные (я думаю, вам известны программы с
static данными или другими (модульными) глобальными данными, которые используются совместно функции / методы, а также различные файлы исходного кода) - гораздо меньше накладных расходов, чем
CALL это - согласованность:
- вы знаете, что в вашем коде, вы не знать, что делает другая программа (или, по крайней мере: вы не можете гарантировать, что она будет делать то же самое через несколько лет точно так же)
- проще расширить / изменить: добавить другую переменную (а также удалить ее часть, изменить его размер) до
CALL USING означает, что вам также необходимо настроить вызываемую программу - и все программы, которые вызывают это, даже когда вы помещаете полное определение в тетрадь, что очень разумно, это означает, что вам нужно перекомпилировать все программы которые используют этот - раздел / абзац всегда доступен (он уже загружен при запуске программы), программа
CALL ed am может быть недоступен или привести к исключению, например, потому что он не может быть загружен, так как его параметры изменились
- меньше кода
Примечание: Хотя не все компиляторы поддерживают это, вы можете обойти почти все накладные расходы времени выполнения и проблему согласованности, когда вы используете один исходный файл с несколькими определениями программ в (возможно, вложенными) и используя соглашение о вызовах stati c. Это, вероятно, дает вам "современный" вид, к которому вы стремитесь, с ограничением области действия переменных внутри программ, либо постоянных (например, local-stati c), когда они определены в WORKING-STORAGE, либо всегда передаются, когда в LINKAGE или «local -time "когда в LOCAL-STORAGE.
Должен ли весь код приложения быть в одной программе?
[Я добавил это, чтобы не делать неверных предположений] Конечно, нет!
Использование подпрограмм, а также определяемых пользователем функций (возможно, даже вложенных, предоставляющих возможность для «ограниченных» и «общих» данных) - это хорошо, когда у вас есть «граница функции» (например: доступ к данным, пользовательскому интерфейсу, ... ) или с «современным» COBOL, где у вас есть «языковая граница» (например: прямые CALL с C / Java / что угодно), но это не «только для ограничения счетчика разделом» - в этом case: либо определите переменную, состояние которой не гарантированно будет доступно после любого PERFORM, либо определите переменную для раздела / абзаца; в обоих случаях было бы разумно использовать префикс, сообщающий вам об этом. Использование подхода «разделение по границам» также устраняет проблему «плохой привычки, когда все видят все» (что в любом случае справедливо только для «всех разделов / параграфов в одной программе)». Личное примечание: я бы использовал только абзацы, где это «правило магазина / команды» (лучше оставаться последовательным, чем делать что-то другое, «просто потому, что они лучше» [все еще предоставляя возможность, возможно, изменить общее правило] ) или для GO TO, который я обычно не использую. SECTION s и EXIT SECTION + EXIT PERFORM [CYCLE] (и очень редко GOBACK / EXIT PROGRAM) делают абзацы практически ненужными.