RCLRSC делает SRVPGM с F-spec сбоем - PullRequest
Новая
       8

RCLRSC делает SRVPGM с F-spec сбоем

0 голосов
/ 19 января 2019

Я первый, кто ввел SRVPGM в наше приложение.В моей SRVPGM я определил несколько необходимых файлов в глобальном масштабе, поскольку у нас около 50 000 транзакций в день, а подпроцедуры будут вызываться 10 раз для каждой транзакции.Хотя эти подпроцедуры используются совместно для пакетных заданий и промежуточных заданий, чтобы уменьшить блокировку файлов, я открываю файлы в соответствующем подпроцессе, если он не открыт (с% open), и закрываю файл в режиме заданий INTER перед возвратом из подпроцесса.

К сожалению, наша программа ввода пользовательского интерфейса - это OPM с RCLRSC.Я обнаружил, что каждый раз, когда я покидаю интерфейс и снова захожу, SRVPGM будет иметь проблему: в подпроцессе чтения файла% open возвращает 1, но когда цепочка / чтение файла, система выдает «Попытка обратиться ко всем или к частиобъект, который больше не существует.Я даже пытался снять проверку% open и direct open (e), проблема все еще сохраняется.

Я искал несколько статей, обсуждающих ту же проблему, но все еще не могу найти предпочтительное решение.

Наши существующие (> 1k) программы - это почти все * DFTACTGRP.

У нас есть несколько программ с RCLRSC, которые мой бюджет проекта не может покрыть усилия по изучению и удалению / замене RCLRSC..

В OVRDBF / OPNQRYF гораздо больше пгм, в которых не указана открытая область, поэтому я не могу просто изменить наши пгм на именованный ACTGRP.

Так что же я могу сделать дальше?рассматривать?Могут ли описанные ниже методы решить мою проблему (хотя я все еще тестирую их сейчас)

  1. Если я просто оставлю файлы открытыми до завершения задания INTER, поскольку наша SRVPGM только читает файлы?

  2. Если я определю 2 набора подпроцедур чтения файлов, один с файлами, определенными глобально для использования пакетных заданий, другой с файлами, определенными локально для заданий INTER?

  3. Отказаться от SRVPGM, просто связать модули с каждой вызывающей программой (около 70, все еще в состоянии управлять)?

1 Ответ

0 голосов
/ 24 января 2019

Использование RCLRSC с сервисными программами и процедурами ILE в лучшем случае проблематично.RCLRSC является строго инструментом OPM, существовавшим до появления групп активации, и на современных машинах влияет только на группу активации по умолчанию, но не полностью ее очищает и не завершает.RCLRSC закрывает только файлы и завершает программы, скомпилированные с помощью DFTACTYGRP (* YES).Если выбран DFTACTGRP (* NO), RCLRSC не трогает его.

Следующая проблема заключается в том, что вы не можете использовать подпроцедуры в программах, скомпилированных с DFTACTGRP (* YES).Это связано с тем, что IBM не хочет, чтобы процедуры ILE выполнялись в группе активации по умолчанию.Это можно сделать, но только если вы будете осторожны, и RCLRSC будет проблемой, как вы видели.Файлы закрыты, но объекты программы ILE не знают об этом, потому что группа активации не завершена и не очищена.Кроме того, принуждать процедуры ILE к выполнению в группе активации по умолчанию, указав ACTGRP (* CALLER), не рекомендуется, потому что вы не можете полностью закрыть группу активации по умолчанию без завершения задания.

Если ваш код OPMзагруженные командами RCLRSC, которые вы не можете исправить, тогда вам лучше избегать подпроцедур.Но лучший путь вперед - это работа по удалению команд RCLRSC.

...