Современный COBOL: руководство по реализации микросервиса
Предварительные условия
Вы знаете основные принципы, методы и стандарты COBOL. В этом руководстве мы используем GnuCOBOL — бесплатный компилятор COBOL, реализующий значительную часть стандартов COBOL 85, COBOL 2002, COBOL 2014 и X/Open COBOL, а также многие расширения, включённые в другие компиляторы COBOL.
Вы знакомы с протоколом HTTP — форматами запросов и ответов.
У вас есть аккаунт на GitHub для публикации микросервисов.
Полный исходный код этого руководства на GitHub.
Спецификации
Одна из сильных сторон COBOL — это десятичные вычисления. В этом руководстве мы создадим высокоточный микросервис обмена валют, обрабатывающий HTTP API и возвращающий сумму в евро в формате JSON.
Обменные курсы — это курсы евро, опубликованные Европейским центральным банком. Ежедневные обновления курса и поддержка многопоточности выходят за рамки этого руководства.
Структура
Наконец, создадим пустые файлы microservice.cbl и microservice-test.cbl в каталогах src и tests соответственно. Они понадобятся нам позже.
Зависимости
Наш микросервис зависит от:
Этот файл, уже известный как COBOL Copybook, включает в себя все прямые и унаследованные зависимости для микросервиса. Мы используем его внутри нашей программы на следующем этапе.
Программа
По сути наша программа должна:
Программа receive-tcp — это сервер, который принимает входящие соединения, считывает содержимое запроса в буфер и делится буфером с программой обратного вызова. Обратный вызов парсит содержимое и заменяет буфер ответом. Сервер отправляет ответ обратно клиенту. Полный листинг программы на GitHub.
Давайте установим среду выполнения GnuCOBOL Docker:
В этом руководстве мы используем GnuCOBOL 2.2, единственный стабильный GnuCOBOL компилятор, доступный в настоящее время в бинарных дистрибутивах. Вы так же можете найти его и установить в исходном формате на свой компьютер.
Наш микросервис будет следовать практике непрерывной интеграции, когда разработчики интегрируют исходный код в общий репозиторий, где каждая интеграция тестируется автоматически. Для тестирования воспользуемся простой тестовой средой GCBLUnit, уже установленной ранее как зависимость для отладки.
Давайте создадим Dockerfile микросервиса:
Мы открываем 8000 порт и выполняем работу microservice-test при каждой сборке образа. Последний элемент всей картины — это тест-файл microservice-test.cbl :
Для целей тестирования я подготовил минимальное CSV содержимое только с одной валютой — USD. Как видно из определения буфера, тест запрашивает конвертацию 1 USD. Мы ожидаем ненулевые HTTP-заголовки, а также обменную сумму с высокой точностью 0.8750437521876093. Последняя строка включает в себя основную тестируемую программу.
Контейнер
Создадим образ Docker:
Прекрасно! Наш образ Docker успешно прошёл тест, рассчитав 4 выражения, и готов к запуску:
Откроем http://localhost:8000/USD/99.99 и http://localhost:8000/ABC/1 в браузере и посмотрим, что произойдёт. Чтобы остановить и удалить контейнер, запустим:
GitHub
Заключение
Мы реализовали микросервис с помощью библиотеки Git, менеджера пакетов, модульного тестирования и виртуализации в рамках подхода непрерывной интеграции. COBOL, которому уже 60 лет, подходит для современной разработки программного обеспечения!
Источник
Enterprise COBOL: пример проекта
Эта статья завершает Курс программирования на COBOL, освещая важные аспекты разработки программного обеспечения, такие как модульность кодовой базы, зависимости, модульное тестирование, мокинг, DevOps на z/OS и автодокументация. Современный подход представлен здесь наилучшим образом — на примере.
Photo by Hunter Haley on Unsplash
Предварительные условия
Предполагается, что вы уже знакомы с основными принципами, методами и стандартами IBM Enterprise COBOL для z/OS — проприетарного компилятора COBOL, который реализует значительную часть стандартов COBOL 85, COBOL 2002 и COBOL 2014. Мы будем запускать проект на z/OS — проприетарной 64-разрядной операционной системе для мэйнфреймов IBM, которая вышла в октябре 2000 года и все еще обратно совместима с функциями, появившимися с 1960-х годов.
Убедитесь, что у вас установлен NPM, менеджер пакетов для JavaScript:
У вас есть аккаунт мэйнфрейма IBM.
Вы можете получить аккаунт в учебных целях бесплатно. Зарегистрируйтесь в IBM и следуйте инструкциям. Вы получите емейл с указанным USER ID, IP и PORT. Затем войдите в Open Mainframe Project Slack и добавьте приложение zih через Apps меню. Отправьте приложению сообщение, например, Hi, и бот попросит ввести емейл и USER ID, которые вы получили. Отправьте эти данные, и бот создаст ваш PASSWORD.
Вам понадобится COBOLget, менеджер пакетов для COBOL:
Вам понадобится Zowe, платформа управления для мэйнфреймов с открытым исходным кодом, и ваш профиль Zowe, созданный с использованием указанных выше данных:
Вы можете выбрать любой текстовый редактор по вашему желанию, но я рекомендую Visual Studio Code с установленным расширением IBM Z Open Editor.
Спецификация
У хороших проектов есть исчерпывающее описание функциональности и ограничений. Наш проект Sales суммирует вымышленные продажи в определенном регионе. Данные о продажах представлены в формате CSV, где каждая строка (кроме заголовка) описывает одну продажу следующим образом:
Декомпозиция
Благодаря Zowe программисты COBOL могут создавать любую структуру проекта, свободную от условностей и ограничений мэйнфреймов. Современная разработка имеет тенденцию фокусироваться на проблемной области, делегируя специфичные для платформы задачи на уровень DevOps.
Разберем спецификацию на функциональные блоки. В основном программа:
Читает файл продаж.
Разбирает строки одну за другой.
Проверяет Region на соответствие.
Агрегирует Total Revenue.
Отображает агрегированное значение.
Таким образом, можно выделить как минимум четыре блока — три программы и одну copybook. Точка входа определяет фильтр по региону, вызывает Reader и отображает результат. Программа Reader инкапсулирует операции с файлами (DataSet) и анализирует записи CSV, возвращаемые Parser. Программа Parser преобразует строки CSV в записи.
Другими словами, наша copybook — это структурированная форма строки CSV, совместно используемая в Reader и Parser. Поместим ее в файл CPY:
Зависимости
До того, как Zowe разделил среду разработки и исполнения, инженеры Enterprise COBOL использовали следующие блоки комментариев для документирования изменений:
Этот метод не вполне отражает историю программы и не может использоваться для ретроспективного анализа. Напротив, Системы Контроля Версий в настоящее время являются стандартом в разработке программного обеспечения, позволяя командам сотрудничать через пространство, время и границы организаций. Эксперименты с кодом, параллельные версии, атомарные модификации и обзоры кода помогают разрабатывать софт эффективно с низким уровнем риска.
Тенденция разделения монолитных программ с огромным количеством SECTIONS на более мелкие и многократно используемые блоки была бы невозможна без Семантического Версионирования и Управления Пакетами. Несмотря на то, что в наших модулях мы не использовали никакой внешний код, встроенных в COBOL функций (Intrinsic functions) обычно недостаточно в более сложных проектах.
С 2020 года у COBOL есть собственный менеджер пакетов COBOLget, который стандартизирует повторное использования исходного кода разработчиками как открытого, так и проприетарного кода. Инструмент командной строки автоматизирует процесс установки и обновления библиотек, разрешения зависимостей и интеграции внешнего кода COBOL в проекты. Реестр COBOLget аккумулирует библиотеки на диалектах GnuCOBOL и Enterprise COBOL, помогая доставлять публичный и закрытый код командам.
Сердце COBOLget — это Манифест modules.json, который описывает проект и его зависимости.
Как видно, структура очень похожа на манифест в NPM. В свойствах modules перечислены COBOL-модули проекта, свойство dialect определяет целевую платформу. Назначение зависимости ecblunit будет объяснено в следующей главе.
Тестирование
Инструменты
Для этого IBM предлагает проприетарную среду модульного тестирования — zUnit. zUnit реализует стандарт xUnit, позволяющий разрабатывать, выполнять и оценивать результаты тестов на любом языке z/OS. Конвейер выглядит так:
Test Runner читает файл Test Suite;
Test Runner по очереди вызывает Test Cases;
ADDTESTS добавляет тестовые программы в Test Case;
SETUP выделяет необходимые ресурсы;
тестовая программа вызывает модуль и проверяет результат;
TEARDOWN высвобождает выделенные ресурсы.
Test Runner — программа z/OS, которая управляет процессом тестирования.
Test Suite — XML-файл, в котором перечислены Test Cases для Test Runner.
Test Case — COBOL программа, вызывающая модуль.
Assertion — COBOL условие, сравнивающее ожидаемые и фактические значения.
Test Fixture — COBOL программы для настройки, запуска и завершения тестов.
Проблема в том, что для одного минимального теста zUnit требуется более 100 строк типового кода, что в простых случаях применения чрезмерно. К счастью, имеется альтернатива с открытым исходным кодом — ECBLUnit. В отличие от zUnit, этот инструмент ориентирован только на элементы Test Runner и Assertion. Написанный на Enterprise COBOL, инструмент полностью совместим с z/OS. Тесты ECBLUnit — это программы на COBOL, намного более простые, чем тесты zUnit. Поскольку ECBLUnit это обычный пакет COBOLget, мы можем добавить его как зависимость:
Мокинг
Кажется, в нашем проекте полностью изолированным элементом является только Parser. Reader требует поддержки z/OS для доступа к CSV-файлу. Тем не менее, мы можем изолировать Reader, создав его alter ego — Мок. Цель имитации — сосредоточиться на тестируемом коде, а не на поведении или состоянии его окружения. Мок реализует контракт исходного модуля с поддельной реализацией:
Поскольку в процессе тестирования JCL компилирует мок сразу после настоящих модулей, тестовая программа не замечает подмены.
Этот простой подход позволяет тестировать бизнес-логику любой сложности, избегая нежелательных зависимостей. Давайте теперь соберем и протестируем наши модули на z/OS:
DevOps
Не отчаивайтесь, если приведенная выше команда не сработала. В scripts манифеста вы найдете все необходимые сценарии для согласования сред разработки и выполнения. Вы можете запускать эти команды отдельно или в группах, указав начальное имя сценария. Замените все в скриптах на свой и попробуйте создать датасеты мэйнфрейма разом:
Если датасет уже существует, команда завершится ошибкой. Тогда придется создать датасеты по одному, например:
Если все прошло успешно, то теперь можно развернуть и запустить проект Sales на z/OS:
Сценарии сборки, развертывания, тестирования и демонстрации запущены и работают. Отлично!
Проект следует практике Непрерывной Интеграции, где каждая модификация кода тестируется в репозитории. Среди файлов проекта вы можете найти два шаблона:
nodejs.yml — для GitHub
.gitlab-ci.yml — для GitLab
Оба шаблона повторяют шаги, описанные выше, и имеют похожий синтаксис. GitLab и GitHub будут запускать CI процессы автоматически и сообщать о прогрессе во вкладках Pipelines и Actions соответственно. Ненулевой код выхода на любом этапе пометит процесс как сбойный.
Если вы решите опубликовать проект в своем репозитории, не забудьте объявить переменные HOST, PORT, USER и PASS в Settings->CI/CD->Variables в GitLab или в Settings->Actions secrets в GitHub.
Документация
Программисты постоянно читают код. Обычно соотношение времени, потраченного на чтение и на запись, намного превышает 10:1. Говорящие названия переменных, разделов, абзацев, множество комментариев объясняют читателю, что происходит и почему. IBM рекомендует использовать IDENTIFICATION DIVISION для описания программ. Вот фрагмент, вставляемый IBM Z Open Editor:
С точки зрения модульности, такая документация не предоставляет исчерпывающую информацию о контракте модуля без необходимости его тщательного изучения. Поэтому вендоры COBOL добавили в комментарии дополнительные теги, распознаваемые генераторами автодокументации. Внедрение автоматического документирования сокращает объем вмешательства, необходимого для его поддержки, снижает затраты и улучшает качество, делая отражение изменений в кодовой базе более эффективным.
В 2020 году Bruno Pacheco выпустил инструмент с открытым исходным кодом, который генерирует документацию из исходного кода COBOL — coboldoc. Инструмент решает проблему несовместимости стандартов документации между диалектами COBOL. Coboldoc распознает теги Microfocus, MSDN и Free Format и может создавать документацию в форматах HTML и Markdown.
Имея некоторый опыт работы с последователями Javadoc, вы найдете данный фрагмент очевидным. Теперь установим Coboldoc и сгенерируем документацию для модулей:
Заключение
60-летний язык программирования по-прежнему актуален. По оценкам Micro Focus, COBOL используется в 70% глобальных систем обработки транзакций, на нем написаны 220 миллиардов строк кода. Надеюсь, что аспекты, освещенные в этой статье, вдохновят вас на дальнейшее развитие экосистемы. Спасибо за чтение!
Вы энтузиаст COBOL? Давайте разрабатывать недостающие библиотеки вместе — читайте далее Enterprise COBOL: реализация библиотеки.
Источник
COBOL: в поисках свежей крови
В настоящее время COBOL поддерживает 90% бизнес-систем, используемых корпорациями из списка Fortune 500 и используется в 85% всех ежедневных финансовых (бизнес) транзакций. Отсюда вывод — обучение языку COBOL в университетах даст студентам знания, полезные в жизни, они смогут их использовать дальше — в организациях, напрямую связанных с бизнесом. Без этого же, риски для бизнеса, использующего COBOL, будут повышаться.
Хорошей новостью является то, что Micro Focus расширила программу поддержки учебных заведений, предприятий и студентов с целью помочь образованию нового поколения разработчиков на языке COBOL.
По словам Micro Focus, новая программа поддержки будет стимулировать развитие языка COBOL в учебных заведениях, будут проводиться соревнования с последующими награждениями с возможностью стажировок.
Брерли также добавил, что предприятия сегодня должны понимать — мир движется вперед, и чтобы не отставать — необходимо преодолеть разрыв в уровнях квалификации между поколениями разработчиков, объединить их и их знания.
Micro Focus предоставляет эту программу бесплатно, включая продукты Enterprise Developer и Visual COBOL. А также всю необходимую документацию.
Статистика
В то же время, редактор известного журнала CRN, Sander Hulsman пишет, что в 73% университетов регулярное преподавание COBOL не развивается. Интересно, что такое положение дел не совпадает с мнением директоров высших учебных заведений. Из опрошенных по всему миру 119 директоров, 58% заявили, что преподавать и развивать Cobol необходимо. Также отметим, что 27% процентов университетов по-прежнему продолжают преподавать этот старейший язык программирования.
Увы, в учебных заведениях COBOL вытесяняется языками Java, C# и C++ (наиболее популярным языком является Java).
Это потверждает и Huib Klink, старший консультант по продажам компании Micro Focus: «Новые языки программирования, такие как Java и C#, очень популярны среди студентов. Но язык COBOL прочно закрепился на предприятиях и еще долго будет спрос на COBOL-программистов. Наше исследование показало, что семь из десяти университетов, по крайней мере в ближайшие десять лет, по-прежнему будут работать с приложениями, написанными на языке COBOL. А 25% вместо десяти называют двадцать лет».
И, повторяет, сказанные выше слова Кевина Брерли: если не изучать COBOL — повысятся риски, связанные с бизнесом.
Из постов на Хабре также может быть интересно интервью с Грейс Хоппер («бабушка COBOL») и высказывание Дейкстры об этом языке.
P.S. Пара примеров кода на COBOL
В списке, подсвечиваемых Хабром языков, нет Кобола, однако…
Самая короткая программа:
Источник
Знакомимся с COBOL — ч.1
Этой статьей я планирую начать целый цикл, который может быть со временем соберется в книгу. Информация про COBOL на русском представлена фактически статьей в Википедии и двумя советскими ГОСТами. Вы можете спросить меня зачем я начинаю “раскапывать труп” и прочие аналогичные вопросы. Ответ прост – а просто так. Потому что я люблю COBOL, потому что он вовсе не мертвый, потому что он интересный, потому что это часть важной истории и он продолжит оставаться частью будущего. Потому что COBOL – это событие. И пусть его ругает Дейкстра и другие, это ничуть не умаляет его объемов и его влияния на ИТ в бизнес.
Хватит введения, перейдем к самому изучаемому. COBOL – один из старейших языков программирования, расшифровывается его название как COmmon Business-Oriented Language, появившийся в 1959 году, благодаря “бабушке” Грейс Хоппер, и в основном применявшийся в различных финансовых и административных системах. Более подробно можно узнать его историю в ближайшем интернет-поисковике или (ну прям для совсем ленивых) — notes.sochi.org.ru/1333 (рус. яз.) или en.wikipedia.org/wiki/COBOL (eng.).
Для того, чтобы приступить к практическому изучению языка нам необходимо две вещи – редактор текстовый (1 шт.) и компилятор (1 шт.)
Если с редакторами все просто, тут подойдет даже Notepad и vi, emacs, nano и т.д. и т.п. Главное требование “классическое” это должен быть текстовые редактор, а не тексовый процессор (не помню что еще писали в достаточно старых книгах на эту тему 😉 ).
С компиляторами несколько сложнее, есть коммерческие, которые стоят безумных денег, есть студенческие версии коммерческих, есть версии старых компиляторов, есть даже несколько компиляторов с открытым кодом. Выбор остается за читателем, я лишь приведу список со своими комментариями.
www.opencobol.org OpenCOBOL (open-source, моя личная рекомендация, мультиплатформенный)
tiny-cobol.sourceforge.net TinyCobol (open-source, по сообщению автора 1 января 2011 года – прекратил развитие, да и до этого был не особо активен)
sourceforge.net/projects/cobolforgcc Cobol for GCC (open-source, преальфа, последние обновления 2009г.)
homepages.paradise.net.nz/jsoeberg COBOL 12 (freeware, 16-битный компилятор под DOS / Windows)
cev.cemotel.cz/cobol/cb_en/mx_all.htm Cevela MX COBOL (freeware, Windows)
www.microfocus.com/promotions/wwemvctd0510/default.aspx?page=form Micro Focus Visual COBOL R2 (trial, windows)
www.thekompany.com/products/kobol KOBOL (trial, linux, windows)
Также есть богатый выбор древних компиляторов под DOS.
Лично я использую OpenCOBOL, что в какой то мере единственный реальный вариант, на данный момент.
Теперь, когда вы все установили и готовы ринуться в бой – начнем. Естесственно, с Hello World.
Наберем в редакторе следующий код:
Теперь давайте разберем этот код.
Начнем с внешнего вида. Это “классический” код. Со всеми требованиями, что были и 50 лет назад. Почему его использую я:
1. Код в таком формате подойдет любому компилятору.
2. Это “олдскулл”, “крутатенюшка” и просто мне нравится.
3. Всегда лучше начинаться со стандартных требований, а потом уже смотреть на возможности компилятора и собственный вкус.
Строка COBOL программы состоит из 80 символов.
Символ 1-6: номер строки (необязателен)
Символ 7: “индикатор”
* — строка комментарий,
— — строка “продолжение”,
D- строка debug.
Символ 8 – 11: Зона А. В ней должны начинаться DIVISION’ы, SECTION’ы, имена и заголовки параграфов, а также индикаторы и номера “уровней” (это все рассмотрим позже).
Символ 12-72: Зона Б. Собственно здесь должны начинаться сами по себе выражения “кода”.
Символ 73-80: Зона комментария. Не обрабатывается компилятором и полностью предоставлена програмисту.
С горизонтальной плоскостью разобрались, перейдем к вертикали.
Каждая COBOL программа содержит 4 раздела – DIVISION, идут они в строгом порядке и содержат определенные элементы.
DIVISION ПЕРВЫЙ. Вдохновляющий.
IDENTIFICATION DIVISION. — описывает программу и содержит такие параграфы, как
Содержимое этих параграфов представляет собой обычный комментарий и в принципе записать туда можно хоть “2011 год от Рождества Христова”.
DIVISION ВТОРОЙ. Мистический.
ENVIRONMENT DIVISION. — Описывает ту среду, как и следует из названия, в которой пишется программа. Состоит из двух секций.
CONFIGURATION SECTION. Которая включает в себя параграфы SOURCE-COMPUTER. и OBJECT-COMPUTER. и SPECIAL-NAMES. Первые два несут сугубо комментирующую функцию и описывают на каком компьютере, для какого компьютера программа написана.
SPECIAL-NAMES. представляет собой достаточно глубинную штуку, которая будет рассмотрена позже (или можете поискать пока на эту тему сами информацию).
INPUT-OUTPUT SECTION. Описывает, как следует из названия ввод-вывод, очень нужно, очень важно и очень скоро мы с этим уже встретимся. Включает в себя параграфы FILE-CONTROL. и I-O-CONTROL.
DIVISION ТРЕТИЙ. Законодательный.
DATA DIVISION. — Содержит описания всех переменных. Включает в себя 4 секции:
FILE SECTION. — описывает структуру файлов.
WORKING-STORAGE SECTION. — описывает переменные.
LOCAL-STORAGE SECTION. — описывает переменные, которые создаются и инициализируются каждый раз при выполнении (поподробней в следующие разы).
LINKAGE SECTION. — описывает данные, которые мы получаем при вызове других программ.
DIVISION ЧЕТВЕРТЫЙ. Рабочий.
PROCEDURE DIVISION. — Содержит “саму” программу, которая делится на пользовательские секции, параграфы, которые и содержат выражения. В нашем случае
BEGIN. — пользовательский параграф.
DISPLAY “Hello World!”.
STOP RUN. Собственно сами выражения.
И напоследок. Каждое выражение должно заканчиваться “точкой”.
Спасибо за внимание. Жду вопросов в комментариях, которые обязательно будут отвечены и включены либо в следующие, либо в правку этой статьи.
Источник
Знакомимся с COBOL — ч.2
Ну что же, продолжим наше знакомство дальше, в первой статье мы узнали, из чего состоит COBOL программа, какие правила существуют по ее написанию и запустили нашу первую программу. Пора двигаться дальше, в этот раз мы начнем работать с переменными и совершать первые осмысленные действия с ними.
Итак, вернемся назад к нашей программе.
Добавим в DATA DIVISION. новые строчки, а именно секцию WORKING-STORAGE SECTION. и парочку переменных WS-A и WS-B.
Выглядеть это будет так:
В PROCEDURE DIVISION. соответственно будут следующие строки:
Запускаем удачно собранный исполняемый файл и видим, например:
300 и 100 ввел я, остальное вывела программа. Результаты говорят сами за себя, а теперь рассмотрим новые строчки кода, которые мы ввели повнимательней.
Начнем с новинок в DATA DIVISION.
С точки зрения смысловой нагрузки эти три строчки идентичны, они определяют три переменных с уровнем 01, следом идет имя переменной (WS-A, WS-B и WS-RESULT), далее идет оператор PIC (который также можно записывать в его более старой форме как PICTURE IS), который устанавливает формат и размер переменной. И вот тут начинается главный сюрприз для тех, кто знаком с другими языками. Размер и формат указывается не количеством выделяемых бит, а количеством максимальных символов.
В нашем случае мы описали две переменных, которые будут содержать 3-х ЗНАЧНОЕ число и одну переменную, которая будет содержать 6-ти ЗНАЧНОЕ число.
Поподробней об описании формата. 9 – говорит компилятору, что переменная будет числовая, количество символов указывает на количество разрядов, естесственно, что для больших чисел неудобно писать и считать что-нибудь а ля 999999999999999 и была сделана форма записи 9(15), то есть в скобках указывается количество раз, которые повторяется символ перед скобками.
Перейдем к PROCEDURE DIVISION.
DISPLAY — как можно понять из программы и ее вывода занимается одной из самых полезных функций в мире. Выводит указанную переменную или текст на экран. Пользовательский текст должен быть заключен в двойные кавычки “”. Можно выводить несколько переменных или текстов, как видно в случае с
001700 DISPLAY “Summ is: ”, WS-RESULT.
главное не забыть запятую между ними.
Также в программе отметились 4 математических функции:
Сложение ADD WS-A TO WS-B GIVING WS-RESULT.
Вычитание SUBTRACT WS-A FROM WS-B GIVING WS-RESULT.
Умножение MULTIPLY WS-A BY WS-B GIVING WS-RESULT.
Деление DIVIDE WS-B BY WS-A GIVING WS-RESULT.
Построены они по одному принципу.
значение1 TO/FROM/BY значение2 GIVING переменная.
В качестве значений могут выступать как переменные, так и числа напрямую, например,
ADD 10 TO 20 GIVING WS-RESULT.
Прибавят 10 к 20 и запишут результат (30) в WS-RESULT.
В случае, если GIVING и последующее имя переменной опускается, то результат запишется в переменную идущую ПОСЛЕ TO, FROM, BY – в нашем случае это будет WS-B (но WS-A в случае с DIVIDE).
Маленькое, но важное примечание, есть и немного другие формы записи, например:
ADD 1 2 3 TO WS-B – соответственно вначале сложит 1+2+3, а потом приплюсует это к значению WS-B и запишет результат в WS-B.
Можно опустить и TO – ADD 1 WS-A 2 WS-B сложит все эти значения и запишет результат в WS-B. Несколько переменных можно указать и после TO (к каждой из переменных после TO будут прибавлены значения до TO и результат записан в соответствующую переменную) и после GIVING, тогда в каждую из них будет записан результат. Аналогично можно оперировать и с SUBTRACT.
НО в случае с MULTIPLY и DIVIDE указание нескольких переменных возможно только после GIVING (и то это нужно уточнять для каждого компилятора отдельно).
Помимо этого у DIVIDE есть и вторая форма записи.
DIVIDE WS-A INTO WS-B GIVING WS-C со сменой BY на INTO меняется и порядок переменных, какую именно форму использовать остается выбор за пользователем. Укажу лишь, что:
DIVIDE WS-A INTO WS-B это WS-B / WS-A = WS-B
DIVIDE WS-B BY WS-A GIVING WS-RESULT
это WS-B / WS-A = WS-RESULT
ЭТО ВАЖНО! Вариант с BY НЕ БУДЕТ работать без GIVING. Программа просто не скомпилируется из-за ошибки.
Ну и напоследок маленький “подарок” — наверняка читатель уже задался вопросом “а как же присвоить значение переменной?”. С помощью MOVE
MOVE 10 TO WS-A
или MOVE WS-A TO WS-B
или даже MOVE 10 TO WS-A WS-B
ЭТО ВАЖНО! MOVE принимает несколько переменных только на “выходе”, т.е. после TO.
P.S. И наверняка вас удивляют цифры, которые мы получили на выводе и количество нулей в них? Это мы рассмотрим в следующей статье.
Воронцов “nerfur” Вячеслав. 2011.
ВАЖНЫЙ UPDATE! К сожалению забыл указать одно важное ключевое слово для DIVIDE.
DIVIDE WS-B BY WS-A GIVING WS-RESULT REMINDER
Используя REMAINDER мы указываем переменную в которую запишется ОСТАТОК от деления.
Источник
