При каких обстоятельствах OVRDBF будет вызывать сообщение об ошибке CPF5149?

В настоящее время я работаю над четырьмя программами CL и RLG. Стек вызовов выглядит следующим образом: A-> B-> C-> D, где A - это программа CL верхнего вызывающего абонента, а D - программа RPG нижнего вызываемого абонента. В программе A есть оператор OVRDBF с параметром SHARE (* YES) для файла, который используется в качестве вывода в программе D. Теперь я столкнулся с проблемой, заключающейся в том, что всякий раз, когда D пытается записать запись в этот файл, появляется сообщение об ошибке CPF5149. брошенный, говоря мне, что операция ввода-вывода недействительна. Если я прокомментирую этот оператор OVRDBF в программе A, тогда D сможет без проблем записать запись в файл. Так почему именно этот OVRDBF вызывает проблемы с вводом-выводом в программе RPG? Как это решить? Удаление его может быть не вариант.


person God_of_Thunder    schedule 25.06.2012    source источник


Ответы (1)


Параметр SHARE(*YES) для OVRDBF сохраняет путь к данным открытым. Если первая программа в стеке вызовов, открывающая файл, открывает его как доступный только для чтения, то он останется таким же для всех других программ.

Обычно SHARE(*YES) используется только тогда, когда вы хотите использовать OPNQRYF < / a> команда для фильтрации записей перед их передачей в другую программу.


ОБНОВЛЕНИЕ:

Открытые атрибуты программ B, C и D (в зависимости от того, какая из них откроет файл первой) в вашем примере будут управлять статусом открытия.

Если вы используете OPNQRYF, укажите параметр OPTION(*ALL), чтобы заставить его открыть путь к данным с полными атрибутами чтения / записи / обновления / удаления.


Информационный центр IBM i: совместное использование пути открытых данных

person James Allman    schedule 25.06.2012
comment
Только чтение? Вы имеете в виду вариант INHWRT (* YES)? В настоящее время он использует файл по умолчанию, поэтому я не уверен, открыт ли файл только для чтения. - person God_of_Thunder; 25.06.2012
comment
@God_of_Thunder Нет, я имею в виду спецификацию F или OPNF / OPNQRYF в первой программе в стеке вызовов, чтобы открыть файл. - person James Allman; 25.06.2012
comment
В CL нет OPENQRYF / OPNF. Любые связанные объявления спецификации F должны быть обновлены. - person God_of_Thunder; 25.06.2012
comment
@God_of_Thunder А как насчет статуса удаления? Каждая программа в стеке вызовов не может запрашивать больше атрибутов, чем первая программа, открывшая файл. Также проверьте журнал заданий на наличие диагностических сообщений, связанных с открытым путем к данным. - person James Allman; 25.06.2012
comment
Какой статус удаления? Я просто использую стандартную комбинацию UF A E в спецификации F. В журнале заданий отображается сообщение «Параметры открытия игнорируются». Это как-то связано с моей проблемой? - person God_of_Thunder; 25.06.2012
comment
Между прочим, программа B, которая является RPG, также обновляет тот же файл, но в спецификации F используется комбинация UF E, то есть опция добавления записи отсутствует. Как вы думаете, это может быть причиной проблемы? - person God_of_Thunder; 25.06.2012
comment
@God_of_Thunder Да, вот в чем проблема. - person James Allman; 25.06.2012
comment
Значит, тогда мне, возможно, придется изменить спецификацию F в программе B? Есть ли способ избежать этого? Я имею в виду, можно ли внести все изменения в программы C и D? Не хочу выкладывать изменения по всем программам. - person God_of_Thunder; 25.06.2012
comment
@God_of_Thunder Вы можете открыть файл в CL с помощью OPNDBF ... OPTION(*ALL). Просто не забудьте использовать CLOF в конце вашего CL, чтобы закрыть ODP. Или не используйте SHARE(*YES), если в этом нет необходимости. - person James Allman; 25.06.2012
comment
Только что решил сегодня проблему. Я изменил спецификацию F программы B, чтобы она позволяла добавлять записи в файл. Спасибо за вдохновение. - person God_of_Thunder; 26.06.2012