Что может вызвать транзакцию CICS для записи из выделенной памяти CICS?
Я использую CICS в программе Cobol и заметил, что иногда данные записываются из памяти CICS. Это приводит к повреждению данных и остановке моего приложения. Я не знаю, где он добавляется, поэтому я создаю парсер для анализа моего кода Cobol на предмет возможного повреждения в COMMAREA, используемого CICS. Сейчас я проверил следующие утверждения:
EXEC CICS XCTL
EXEC CICS LINK
EXEC CICS RETURN TRANSID
Для каждого я проверяю, отправлена ли длина (объявлена в LENGTH параметр) не больше отправленного COMMAREA, Тогда я проверяю, если DFHCOMMAREA в принимающей программе не больше отправленной COMMAREA (согласно этому документу http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom.ibm.cics.ts31.doc%2Fdfhp3%2Fdfhp37t.htm):
Область принимаемых данных не обязательно должна быть той же длины, что и исходная область связи; если доступ требуется только к первой части данных, новая область данных может быть короче. Однако он не должен превышать длину передаваемой области связи. Если это так, ваша транзакция может непреднамеренно попытаться прочитать данные за пределами области, которая была передана. Это может также перезаписать данные за пределами области, что может привести к прекращению работы CICS.
Теперь мне интересно, что еще нужно проанализировать, чтобы обнаружить перезапись памяти?
4 ответа
Когда программа CICS начинает перезаписывать всю память, она не только "перестает работать", но, возможно, также приводит к сбою в области CICS!
Если вы уверены, что LENGTH правильно установлен на LINKс и XCTLи что вы получаете COMMAREA в запись связи такого размера (EIBCALEN), тогда у вас должно быть все в порядке.
Вместо того, чтобы пытаться анализировать ваши программы на COBOL, я предлагаю вам включить опции проверки границ компилятора. Проблема, с которой вы сталкиваетесь, скорее всего, связана с индексированием или подпиской за пределы рабочей таблицы хранения. Попытка обнаружить этот класс программной ошибки посредством статического анализа, как правило, не очень эффективна.
Установка проверки границ должна обнаруживать ссылки на память вне диапазона, выдавать диагностическое сообщение в журнал, а затем и завершать работу вашей программы до того, как произойдет сбой во всем регионе CICS. Зарегистрированное сообщение должно указать вам исходную строку, где произошла ссылка за пределы.
Проверьте SSRANGE опция времени компиляции. Убедитесь, что он установлен, и что ваш регион CICS запускает программы с поддержкой LE с CHECK(ON),
Это должно выскочить за пределы памяти ссылки довольно быстро.
У NealB хорошая идея. Предлагаю вам также изучить параметры инициализации системы STGPROT и RENTPGM CICS.
Для проверки границ передачи данных всегда используйте transclusion, которое в COBOL называется COPYCODE или COPYBOOK. Передайте корневой элемент данных в copycode и скомпилируйте ту же версию в вызывающей и вызываемой программе. Этот COPYCODE является своего рода контрактом для вызываемой программы, поэтому рекомендуется заключить соглашение об именовании, связывающее их вместе. Чтобы убедиться, что они синхронизированы, всякий раз, когда вы меняете COPYCODE, перекомпилируйте все программы, которые ссылаются на него.
Кроме того, использование SSRANGE отлично (но кто-то уже упоминал об этом).
Поскольку вы используете Micro Focus COBOL, вы можете установить переменную memory_strategy (или API CBL_MEM_STRATEGY), чтобы помочь вам анализировать, где происходит ошибка, позволяя среде выполнения защищать память различными способами.
Память также может быть проверена с помощью вызова "CBL_MEM_VALIDATE".
Другая вещь, которую можно сделать, это использовать поддержку трассировки... lookup CTF (Consolidated Tracing Facility). Это даст вам представление о том, где вы кодируете во время ошибки.
Некоторые рекомендации, которые помогут вам;
http://kb.microfocus.com/display/4/kb/article.aspx?aid=31645