Теперь мне нужно найти конкретную запись в журнале с помощью программы CL. Я использую для поиска способ, которым DSPJRNE помещает записи журнала в выходной файл, а затем использует OPNQRYF для фильтрации нужного. Файл имеет уникальный ключ, поэтому я планирую сравнить данные записи журнала с ключом. Проблема в том, что один из ключей является упакованным десятичным числом, поэтому в записи журнала он обрабатывается как шестнадцатеричный код символов и отображается как некоторые странные символы. Итак, чтобы сравнить строки, мне нужно преобразовать упакованный десятичный ключ в соответствующие символы. Как этого добиться в CL? Если использование CL невозможно, что насчет RPG?
Учитывая шестнадцатеричный код символа, как преобразовать его в соответствующий символ в программе CL?
Ответы (2)
Чтобы ответить на ваш непосредственный вопрос, инструкция CVTCH MI преобразует шестнадцатеричный формат в char, но я бы не пошел по этому пути; ни в CL, ни в RPG. Скорее, я последовал бы совету Джеймса, сделав несколько дополнительных шагов.
DSPJRNE OUTFILE(QTEMP/DSPJRNE)
QRY input file DSPJRNE, output file QRYJRNE, select only JOESD
CRTDUPOBJ PRODUCTION_FILE QTEMP/JRNF DATA(*NO)
CPYF QRYJRNE JRNF FMTOPT(*NOCHK)
Это даст вам внешне описанный файл с тем же макетом, что и ваш рабочий файл. Вы можете запросить это и т. Д.
person
Buck Calabro
schedule
29.05.2012
У Дитера Бендера есть инструмент, который сделает это за вас: bender-dv.de/index.html < / а>
- person Buck Calabro; 29.05.2012
Почему не рекомендуется использовать CVTCH MI? Действительно ли прямая копия записи журнала в производственный файл правильно выравнивает данные по полям?
- person God_of_Thunder; 29.05.2012
Что вы будете делать с записью, когда найдете ее? Распечатать отчет об обновленных записях? Что делать, если вы не найдете его по ключу, и вам нужно посмотреть другие столбцы? На мой взгляд, иметь его во внешнем файле более гибко, чем поиск методом грубой силы по столбцу и CVTCH. Что касается CPYF, да, он точно выровняет поля. Не используйте CPYF для вашего производственного файла !!!!! CPYF в дубликат.
- person Buck Calabro; 29.05.2012
Попробуйте решение Джеймса. Это очень похоже на ANZJRN Дитера.
- person Buck Calabro; 29.05.2012
Поскольку я знаю ключ записи в файле, я не должен его пропустить. Требуется исходное значение этой записи, но из-за логики текущей программы оно не сохраняется и не перезаписывается последующими обновлениями, поэтому мне нужно найти его из записи журнала. В любом случае, я попробовал ваш способ сегодня, и это сработало. Это все, что мне нужно.
- person God_of_Thunder; 30.05.2012
Если вы извлекаете записи журнала для определенного файла, вы можете сбросить их во внешне описанный файл с умным использованием SQL:
CREATE TABLE QTEMP/QADSPJRN LIKE QSYS/QADSPJRN
ALTER TABLE QTEMP/QADSPJRN DROP COLUMN JOESD
CREATE TABLE QTEMP/DSPJRNE AS (SELECT * FROM QTEMP/QADSPJRN, FILE-LIB/FILE)
WITH NO DATA
DSPJRNE ... OUTPUT(*OUTFILE) OUTFILFMT(*TYPE1) OUTFILE(QTEMP/DSPJRNE)
ENDDTALEN(*CALC)
person
James Allman
schedule
29.05.2012
Что ж, я уже знал, как сбрасывать все записи в файл. Проблема в том, как найти именно ту запись, которую я ищу.
- person God_of_Thunder; 29.05.2012
Может я не понимаю вопроса. Как только вы помещаете журнал во внешне описанный файл, остается лишь выполнить запрос, основанный на поле / значении, которое вы ищете. Накладывая буфер записи на внешние описания, все преобразования выполняются за вас.
- person James Allman; 29.05.2012
Джеймс, я думаю, он хочет разобрать упакованные поля внутри JOESD.
- person Buck Calabro; 29.05.2012
Ты понял мою точку зрения, Бак. Извините, что мой вопрос может немного сбить с толку. Записи в журнале - это всего лишь предыстория.
- person God_of_Thunder; 29.05.2012
@BuckCalabro Мои шаги накладывают поле JOESD поверх внешних описаний исходного файла, поэтому я распаковываю двоичный / упакованный / и т. Д.
- person James Allman; 29.05.2012
Теперь я это понимаю. Пропущено неявное соединение. Очень хорошо.
- person Buck Calabro; 29.05.2012
