Чтение JCL начинается с порядка выполнения

JCL становится понятным, когда вы перестаете считать его программой и начинаете видеть в нем последовательную запись графа управления. Исходный текст называет программы, предоставляет ресурсы и задает условия, но фактическое выполнение определяют сразу несколько систем: конвертер раскрывает процедуры, каталог разрешает имена наборов данных, JES и инициатор задают контекст задания, планировщик может подставлять символы, а оператор может перезапустить задание с середины. Если читать только видимые карточки, легко нарисовать убедительную, но неверную схему выполнения.

У первого прохода одна цель: восстановить упорядоченные шаги, данные, которые каждый шаг читает и записывает, и условия, способные его пропустить. Детали синтаксиса понадобятся позже. Я видел, как команды полдня разбирали столбцы и запятые, не замечая, что каталогизированная процедура добавляет шесть шагов, а планировщик выбирает вчерашнее поколение. Сначала разберитесь в поведении, затем подтвердите выводы синтаксисом.

Элемент JCL задает граф управления, а не сценарий

Задание обычно содержит оператор JOB, за которым идут операторы EXEC и относящиеся к ним операторы DD. На верхнем уровне порядок действительно последовательный: если шаг не пропущен, не произошла ошибка, перезапуск или аварийное завершение, JES передает шаги инициатору по порядку. Но открытый элемент библиотеки может содержать лишь часть графа. EXEC способен вызвать каталогизированную или встроенную процедуру, JCLLIB меняет места поиска процедур, а INCLUDE добавляет операторы до начала выполнения.

Разделяйте четыре фазы. На вводе JES читает задание и применяет правила ввода. При конвертации система проверяет JCL, раскрывает процедуры и подставляет символы. При выделении ресурсов z/OS находит или создает нужные шагу наборы данных и устройства. При выполнении запускается выбранная программа, которая возвращает код или аварийно завершается. Обработка вывода и очистка идут вокруг этого потока, но не превращают JCL в прикладную логику.

Это различие объясняет частую загадку: задание может завершиться ошибкой до запуска первой программы. Отсутствующая процедура, неразрешенный символический параметр, повторяющееся имя шага, неверный DD или недоступный набор данных вызывают ошибку JCL на этапе конвертации либо выделения ресурсов. Не называйте каждое красное задание сбоем приложения. Сначала выясните, получила ли управление хоть одна программа. Ответ есть в сообщениях JES и журнале задания.

До разбора операндов набросайте граф. Создайте узел для каждого раскрытого EXEC, сплошную стрелку для обычной последовательности, пунктирную для каждого условия и ребра данных для именованных наборов между производителями и потребителями. Отметьте три вида состояния, которые не являются обычными файлами: символы после конвертации, состояние каталога при выделении ресурсов и коды возврата при выполнении. Такая схема быстро обнаруживает недостающие доказательства.

Порядок в исходном тексте по-прежнему важен, но отвечает лишь на один вопрос: в какой очередности пошли бы допустимые шаги? Он не показывает, допустимы ли они, во что раскрывается процедура, какое физическое поколение выбирает относительное имя GDG и откуда начинается перезапуск. Элемент библиотеки служит входом для запуска, а не его протоколом.

Операторы EXEC определяют единицы работы

Каждый EXEC создает шаг, а операнд указывает, запускает ли шаг программу напрямую или вызывает процедуру. EXEC PGM=IEFBR14 называет программу. EXEC PROC=DAILY или короткая форма EXEC DAILY вызывает процедуру. Имя слева от EXEC служит устойчивой ссылкой для условий, переопределений, перезапусков и сообщений. Запишите его точно.

Начнем с небольшого примера:

//BILLING  JOB (ACCT),'DAILY BILL',CLASS=A,MSGCLASS=X
//EXTRACT  EXEC PGM=EXTBILL,PARM='DAILY'
//INPUT    DD DSN=APP.CUST.MASTER,DISP=SHR
//OUT      DD DSN=APP.BILL.WORK(+1),DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(20,10)),UNIT=SYSDA
//SORT     EXEC PROC=SORTBILL,INDSN=APP.BILL.WORK(+1)
//LOAD     EXEC PGM=LOADBILL,COND=(0,NE,SORT)
//IN       DD DSN=APP.BILL.SORTED(+1),DISP=SHR

Видимая последовательность состоит из EXTRACT, SORT и LOAD. Это еще не план выполнения. SORTBILL может раскрыться в несколько шагов процедуры. Имя SORT обозначает вызывающий шаг, а сообщения и ссылки на условия внутри процедуры используют составные имена вроде SORT.COPY. У LOAD есть условие, способное его пропустить. Оба относительных имени поколений требуют контекста каталога.

Читайте EXEC в таком порядке: имя шага, PGM или процедура, управление условиями, ограничения региона или времени при их наличии, текст параметра для программы. Не принимайте PARM за логику JCL. JCL только передает текст; смысл PARM='DAILY' определяет контракт программы. То же относится к SYSIN. Его содержимое часто похоже на другой язык, потому что это и есть другой язык, предназначенный для утилиты, средства работы с базой, компилятора или внутренней программы.

Процедура создает два пространства имен. У вызывающего задания есть внешнее имя шага, у процедуры есть внутренние имена. В сообщениях, переопределениях и синтаксисе перезапуска встречаются составные формы. В развернутой таблице присвойте каждому шагу имя вроде SORT.COPY и сохраните рядом исходный текст процедуры. Иначе STEP1 из двух процедур будет выглядеть как один шаг.

Программы также могут динамически выделять данные через SVC 99 или библиотечную обертку. Такие выделения не появятся среди DD в поданном JCL. Если программа открывает необъяснимый набор, изучите сообщения, трассировку выделения, исходный текст или конфигурацию времени выполнения, прежде чем решать, что DD отсутствует. JCL объявляет значительную часть среды, но не обязательно всю.

Операторы DD связывают имена программы с ресурсами

Оператор DD относится к предыдущему EXEC до начала следующего EXEC. Имя слева обычно совпадает с именем, которое открывает программа; операнды описывают ресурс и его жизненный цикл. Читайте //INPUT DD DSN=APP.CUST.MASTER,DISP=SHR так: на этом шаге связать программное имя INPUT с данным каталогизированным набором и ожидать совместный доступ. INPUT не является переменной, сохраняющейся между шагами. Другой шаг может определить собственный INPUT с иным смыслом.

Разделите DD на пять практических групп: каталогизированный набор, новый набор, временный набор, встроенные данные и системный вывод. DSN= называет набор данных. DD * и DD DATA вводят записи прямо в задание. SYSOUT=* отправляет вывод в класс вывода задания. DUMMY заставляет многие методы доступа считать ввод пустым или отбрасывать вывод. Отсутствующий DD может быть намеренным, если программа выделяет его динамически или считает необязательным. Сверьтесь с контрактом программы.

У DISP до трех частей: состояние при старте шага, действие после нормального завершения и действие после аварийного завершения. DISP=(NEW,CATLG,DELETE) запрашивает новый набор, каталогизирует его после нормального конца и удаляет после аварийного. DISP=SHR запрашивает существующий набор для совместного доступа. OLD обычно требует исключительного контроля, а MOD позиционирует набор для дополнения и имеет правила создания, которые стоит проверить в руководстве IBM. DISP описывает выделение и дальнейшую судьбу, а не деловой успех. Программа может нормально вернуть 8, и нормальное действие DISP все равно будет применено, поскольку abend не произошел.

Временные имена начинаются с && и обычно существуют до конца задания. Передача такого имени от производящего шага потребляющему создает явное ребро данных, хотя каталог его не видит. И наоборот, похожие постоянные DSN не доказывают связь. Оба может предоставить планировщик, либо вход создало предыдущее задание.

Конкатенация тоже обманывает при беглом просмотре. Последовательные DD могут образовать единый логический вход, если последующие операторы опускают ddname. Библиотеки в STEPLIB или JOBLIB ищутся по порядку, поэтому побеждает первый подходящий загрузочный модуль. Входные конкатенации поступают последовательно, но совместимость зависит от метода доступа и атрибутов набора. Записывайте конкатенацию как одну упорядоченную связь.

Переопределения способны заменить или добавить DD внутри процедуры. //SORT.COPYIN DD DSN=APP.SPECIAL.INPUT,DISP=SHR может указывать на COPYIN шага COPY в процедуре, вызванной шагом SORT. Тогда одна процедура неверно описывает запуск, а в вызывающем элементе виден будто бы бесхозный DD. Честную картину дает только раскрытие.

Справочник IBM z/OS JCL определяет операнды, но не сообщает, нужен ли вашей программе конкретный ddname и какие записи она ожидает в SYSIN. Для этого найдите описание интерфейса программы или изучите ее OPEN и динамическое выделение. JCL объясняет связь, программа объясняет контракт. Если смешать эти понятия, миграция сохранит имена файлов, но сломает поведение.

Раскрытие процедур показывает отсутствующий исходный текст

Определить порядок выполнения можно только после раскрытия всех процедур и групп INCLUDE с теми же библиотеками и символами, что использовались при запуске. Каталогизированная процедура представляет повторно используемый JCL в библиотеке процедур. Встроенная процедура находится между PROC и PEND в поданном задании. Обе могут содержать EXEC, DD, символические параметры и вложенные вызовы в пределах системных ограничений.

Развернутый листинг в выводе JES обычно надежнее поиска по репозиторию, поскольку фиксирует результат конвертации конкретной подачи. Найдите листинг JCL, часто JESJCL, и сообщения JESYSMSG и JESMSGLG. Локальные настройки меняют хранение и отображение spool. Если листинг расходится с Git, сначала проверьте, не подал ли планировщик сгенерированный элемент и не выбрал ли другую PROCLIB.

Символические параметры выглядят, например, как &INDSN.. Точка завершает имя символа и может исчезнуть при подстановке. Значения по умолчанию находятся в PROC, вызывающая сторона переопределяет их в EXEC, SET назначает значения, а планировщик может выполнить замену еще до чтения текста JES. Сохраняйте выражение и разрешенное значение. Только значение не позволяет предсказать следующий запуск; только исходник не позволяет объяснить наблюдаемый.

JCLLIB и локальные конкатенации процедур управляют поиском. В двух библиотеках может находиться элемент с одинаковым именем, а порядок поиска решает, какой будет раскрыт. Это похоже на выбор версии зависимости, только версия зашифрована в порядке библиотек, а не в манифесте. Запишите имя элемента, библиотеку, доступный уровень изменения и раскрытые операторы.

Переопределения применяются после определения повторно используемой процедуры. Они меняют параметры EXEC, заменяют или отменяют DD и добавляют связи. Короткий синтаксис способен спрятать серьезное изменение поведения. Отмечайте каждое переопределенное поле на плоском графе и указывайте оба исходных места.

Не вставляйте текст процедур вручную в задание и не считайте анализ завершенным. При такой работе легко пропустить вложенные вызовы, границы символов, приоритет библиотек и переопределения. Возьмите результат конвертации записанного запуска за основу, затем восстановите, как конвертер его получил. Во многих организациях для проверки синтаксиса применяют TYPRUN=SCAN, но точный эффект зависит от местных правил JES. Scan проверяет поданный JCL, а не данные приложения и последующее поведение.

Имена GDG разрешаются по меняющемуся состоянию каталога

Generation data group представляет запись каталога, которая управляет последовательностью наборов поколений. К базе вроде APP.BILL.WORK обращаются по абсолютному имени поколения или относительному номеру: (0) означает текущее поколение, (-1) предыдущее, а (+1) обычно новое. Относительная форма удобна для эксплуатации, но неполна для анализа, потому что физическое имя зависит от состояния каталога.

Если шаг создает APP.BILL.WORK(+1) со статусом NEW, а следующие шаги читают то же относительное поколение, задание передает новый набор дальше без жестко заданного GxxxxVyy. Покажите на графе относительную ссылку и наблюдавшееся абсолютное имя. Никогда не заменяйте все ссылки тем, что (0) означает сегодня. Каталог мог с тех пор продвинуться.

Сложный сбой возникает, когда пропущенный или упавший производитель предшествует потребителю. Допустим, EXTRACT выделяет WORK(+1), аварийно завершается и срабатывает DELETE. SORT не получает допустимое новое поколение. В зависимости от условий и момента выделения он будет пропущен, упадет при выделении или увидит иное состояние каталога. Поздний перезапуск только SORT может превратить (+1) в новое выделение вместо ожидаемого результата. Относительная запись сама по себе не хранит происхождение.

Другая ловушка находится между заданиями. Планировщик может запустить JOB A для создания поколения, а JOB B для чтения (0). Зависимость отсутствует в обоих элементах JCL. Если JOB B стартует рано или оператор повторит JOB A, (0) может выбрать другое поколение. План планировщика, история каталога и временные метки являются частью программы. Один репозиторий не доказывает, какие записи читал JOB B.

Создайте журнал GDG для запуска со столбцами: шаг, DD, относительная ссылка, disposition, разрешенный абсолютный DSN, действие каталога и наблюдаемый результат. Заполняйте его по сообщениям выделения и данным каталога, а не по догадкам. Для сбоя отметьте, завершилось ли выделение и какое действие disposition состоялось. Такой журнал обычно отвечает, переиспользует ли перезапуск данные или создаст другое поколение.

Документация IBM различает базу GDG, ее модель и правила лимита, а также отдельные наборы поколений. Сохраняйте это различие. Удаление или декаталогизация одного поколения не меняет базу, а выход поколения за лимит не означает немедленное стирание с тома. Для понимания программы достаточно правила: относительное имя GDG является запросом к каталогу в контексте запуска, а не постоянным именем файла.

Коды условий пропускают шаги по результатам предыдущих

Нормально завершившаяся программа возвращает код, который в выводе часто обозначен RC или CC. JCL может использовать его для решения о запуске следующего шага. Код abend отличается от нормального возврата, а ошибка выделения или конвертации может не допустить появления программного кода вообще. Ведите RC, системный abend, пользовательский abend и ошибку JCL в отдельных столбцах. Сведение к успеху и неудаче уничтожает сведения, необходимые для восстановления условий.

Старый параметр COND читается как проверка для пропуска. В COND=(0,NE,SORT) система сравнивает литерал 0 с RC шага SORT через NE. Если 0 не равен RC, проверка истинна и текущий шаг пропускается. Обычными словами, LOAD запускается только при SORT RC 0. Инженеры часто меняют смысл на обратный, поскольку принимают COND за условие запуска. Перед каждым COND мысленно пишите «пропустить, если», затем переводите сравнение.

Несколько примеров показывают инверсию:

• COND=(4,LT,COMPILE) означает пропустить, если 4 меньше RC шага COMPILE, поэтому значения выше 4 подавляют шаг.
• COND=(0,EQ,CHECK) означает пропустить, если CHECK вернул 0.
• COND=EVEN позволяет рассмотреть шаг даже после предыдущего abend с учетом остальных правил.
• COND=ONLY выполняет шаг только после предыдущего abend, также с учетом полного контекста.

Современный JCL поддерживает IF, THEN, ELSE и ENDIF, которые читаются ближе к прикладной логике. Выражения могут ссылаться на составные имена кодов возврата и состояние abend. Это по-прежнему управление вокруг шагов, а не внутри программ. Вложенность и квалификация процедур могут растянуть блок IF за пределы экрана, поэтому обозначьте его границы на раскрытой схеме.

COND уровня задания и шага взаимодействуют со сбоями, а условия процедуры может переопределить вызывающая сторона. Не сводите их к одной зеленой стрелке. Для каждого шага запишите выражение допустимости на основе прежних результатов и вычислите его для фактического запуска. Так вы разделите возможные маршруты и действительно пройденный.

Смысл кода возврата задает программа. RC 4 часто означает предупреждение у утилит IBM, но внутренняя программа может определить его иначе. Некоторые планировщики считают диапазон успешным, хотя следующий COND различает 0 и 4. Отдельно фиксируйте три правила: что сообщает программа, что пропускает JCL и что считает успехом планировщик. Один индикатор не передает все три.

Перезапуск меняет начало, не меняя элемент

Перезапущенное задание не обязано начинаться с первого EXEC. Запрос может назвать шаг задания или внутренний шаг процедуры, а местное средство или планировщик может сформировать фактический запрос. Элемент остается побайтно прежним, хотя запуск начинается с середины. Поэтому схема без идентификатора запуска и метаданных перезапуска остается предварительной.

Безопасность перезапуска зависит от состояния данных, а не только от порядка. Предыдущие шаги могли каталогизировать результаты, изменить базу, напечатать записи, отправить сообщения или подтвердить контрольные точки. Старт с STEP5 не отменяет эти эффекты. С другой стороны, аварийное действие DISP могло удалить нужный STEP5 набор. Перед одобрением перечислите все прежние побочные эффекты и все входы целевого шага.

Перезапуск по контрольной точке внутри программы отличается от перезапуска шага JCL. Утилита может продолжить внутри одного шага, а JES возвращается на границе EXEC. Доказательства и правила восстановления различны. Если оператор говорит, что перезапустил задание, запросите точный механизм, цель и идентификаторы.

Планировщики добавляют еще один невидимый слой. Они рассчитывают даты, выбирают элементы, подставляют SET, создают зависимости, удерживают задания до получения ресурсов и классифицируют коды возврата. Все это может отсутствовать в хранимом JCL. Предыдущее задание может быть настоящим производителем DSN для первого видимого шага. Календарное правило способно выбрать другую процедуру при закрытии месяца. Получите определение планировщика и запись подачи вместе с выводом spool.

Внешнее состояние меняет даже аккуратный повторный запуск. Текущее поколение GDG может продвинуться, входные файлы замениться, таблицы измениться, а поиск по библиотекам найти новую версию программы. Повтор доказывает текущее поведение при текущем состоянии. Он воспроизводит исходный запуск, только если сохранены его входы, разрешения каталога, двоичные файлы, символы и элементы управления.

Операторы также вводят команды и отвечают на запросы выделения либо устройства. Такие действия редко попадают в репозиторий. Журнал задания, журналы автоматизации и заявка эксплуатации могут содержать недостающее ребро. Если шаг ожидал монтирования ленты или был отменен по тайм-ауту, исходный текст не объяснит длительность и итоговый статус.

Spool содержит доказательства, а не шум

Быстрее всего понять унаследованный пакетный процесс можно, сопоставив исходный текст с одним успешным набором spool и одним характерным сбоем. Исходник показывает предполагаемые возможности. Spool показывает конвертацию, выделение, программные сообщения, возвраты и путь одной фактической подачи. Они не заменяют друг друга.

Начните с имени задания, job ID, системы, времени подачи, заказа или run ID планировщика и признака перезапуска. Затем соберите преобразованный листинг JCL, сообщения JES и системы, а также прикладной SYSOUT. Часто встречаются имена JESJCL, JESMSGLG и JESYSMSG, но местные правила различаются. Сохраните сырой материал до очистки spool.

Читайте в хронологическом порядке и помечайте фазы. Сообщения конвертера объясняют символы и синтаксис. Сообщения выделения сопоставляют DD с наборами и томами. Сообщения завершения называют программу, возврат и abend. Прикладные сообщения объясняют деловые счетчики и решения утилит. Из-за буферизации время может вводить в заблуждение, поэтому учитывайте также идентичность шага и сообщения.

Для каждого раскрытого шага запишите наблюдаемую строку:

SORT.COPY | PGM=SORT | ran=yes | RC=0004 | abend=none
  COPYIN  -> APP.BILL.WORK.G0123V00      DISP=SHR
  COPYOUT -> APP.BILL.SORTED.G0098V00   DISP=(NEW,CATLG,DELETE)
  gate    -> eligible after EXTRACT RC=0000

Формат намеренно скучен. Его удобно сравнивать, и он заставляет показывать неизвестное. Если абсолютный DSN отсутствует, напишите «неизвестно» и назовите нужное доказательство. Не подставляйте молча текущее значение каталога.

Сравните успешный и неудачный запуски по раскрытому имени шага, программе, DSN, символам, условиям и результатам. Первое отличие часто важнее последнего abend. Другое входное поколение способно вызвать позднюю проверку; измененная STEPLIB может загрузить иной программный код; предупреждающий RC может пропустить очистку и испортить следующий запуск.

Удаляйте учетные данные и регулируемые сведения до переноса spool в общие инженерные системы. JCL и SYSOUT могут содержать поля счетов, токены в PARM, управляющие операторы базы или полные деловые записи. Относитесь к spool как к производственному доказательству. При изолированном анализе держите доказательства и инструменты внутри периметра клиента.

Таблица трассировки превращает раскопки в проверяемую работу

Таблица должна позволить другому инженеру оспорить модель без перечитывания всего spool. Используйте строку на каждый раскрытый EXEC в фактическом порядке. Минимальные столбцы: составное имя шага, программа, источник процедуры, разрешенные символы, входные и выходные DD, правило допустимости, наблюдаемый RC или abend и последствия перезапуска. Добавляйте найденные динамические выделения.

Для реального задания соблюдайте такую последовательность:

1. Зафиксируйте исходник, запись планировщика, раскрытый JCL, spool и разрешения каталога одного запуска под общим run ID.
2. Раскройте процедуры и INCLUDE, разрешите символы и присвойте каждому EXEC составное имя.
3. Привяжите DD и упорядоченные конкатенации к шагам, затем разрешите GDG в абсолютные имена наблюдавшегося запуска.
4. Переведите каждый COND или IF в правило допустимости и вычислите его по записанным результатам.
5. Отметьте реальную точку старта, пропущенные шаги, динамические выделения, действия оператора и эффекты, важные для перезапуска.

Проверяйте таблицу в двух направлениях. Сверху вниз подтверждайте поток управления. Для каждого набора идите от производителя к потребителям и подтверждайте происхождение. Файл без производителя может быть внешним потоком, зависимостью планировщика или старым состоянием. Вывод без потребителя может быть отчетом, обменным артефактом или лишней работой. Не удаляйте его до понимания эксплуатации и хранения.

Отделяйте факты от гипотез. SORT.COPY returned 4 является фактом из spool. RC 4 means duplicate records остается гипотезой, пока управляющие операторы и сообщения SORT ее не докажут. Разрешение APP.BILL.WORK(+1) в G0123V00 является историческим доказательством. Утверждение, что перезапуск выберет то же имя, требует анализа каталога и перезапуска. Такая дисциплина не позволяет правдоподобной истории стать спецификацией.

Таблица также показывает границу миграции. Программы, условия JCL, зависимости планировщика, поведение каталога и действия операторов вместе образуют пакетную систему. Перевод COBOL без окружающего JCL сохраняет только самый заметный компонент. Современному сервису нужны явная оркестрация, устойчивая идентичность данных, правила повторов и наблюдаемые результаты, совпадающие со старым поведением там, где от него зависят потребители.

CodeHero читает все дерево COBOL и JCL вместе, а затем проверяет переписанную систему по записанному производственному трафику с помощью стенда проверки паритета. Построчный перенос не восстановит поведение, которое находилось в выборе процедур, связях DD, состоянии GDG и практике перезапуска.

Модернизация должна сделать скрытый порядок явным

Безопасная модернизация не повторяет каждый оператор JCL в новом синтаксисе. Она сохраняет наблюдаемое поведение и превращает неявные зависимости в именованные, проверяемые контракты. Временный набор может стать объектом или промежуточной таблицей, передача GDG неизменяемым артефактом запуска, условие COND явным переходом состояния. Целевая архитектура может меняться, но тесты паритета должны покрывать поведение, от которого зависят системы и операторы.

Начинайте спецификацию с записанных запусков, а не со схемы по памяти. Выберите нормальные запуски, пути с предупреждениями, падения производителя, ошибки выделения и перезапуски. Запишите идентичность входов, раскрытые шаги, выходы, классификацию возвратов и внешние эффекты. Производственный трафик полезен как доказательство, если включает сообщения и обмены, определяющие поведение, но работать с ним нужно по правилам безопасности клиента.

Не переносите случайные странности вслепую. Одно поведение задано контрактом, другое поддерживает эксплуатацию, третье оказалось незамеченным дефектом. Выясните, какие потребители зависят от детали, и напишите тест, называющий принятое решение. Если новая система намеренно меняет правило, зафиксируйте одобренное отличие, а не ослабляйте сравнение до успешного результата.

Изолированное выполнение может требоваться, если исходники, spool или производственные записи нельзя выносить за периметр клиента. Такое требование относится к развертыванию и обработке данных; оно не означает наличия сертификации соответствия. Разделяйте эти утверждения при архитектурной проверке и закупке.

Достоверный план переключения отвечает на конкретные вопросы: какая новая операция соответствует каждому старому шагу, как закрепляется идентичность входа, как повторы избегают двойных эффектов, как отображаются предупреждения, как продолжается частичный запуск и какое доказательство подтверждает паритет. Если команда не может ответить, она еще не дочитала JCL. Дополнительное изучение синтаксиса не закроет пробел. Полностью восстановите один запуск, включая все, чего не было в элементе, и пакетный процесс перестанет казаться загадочным.