Какой-то способ обеспечить целостность данных без компиляции RPG с проверкой на уровне файлов?

Question

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

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

Если мы скомпилируем без проверки уровня , то, если программа RPG использует не-наделенных таблиц, и мы удаляем соответствующий столбец из одной из этих таблиц, затем программа RPG может вставить в таблицу, не занесенную в журнал, а затем не может быть вставлена ​​во вторую (измененную) таблицу, оставляя таким образом потерянные данные (поскольку мы не можем использоватьтранзакции, поскольку таблицы не регистрируются).

Нам не нужно ничего перекомпилировать при добавлении столбца (или увеличении размера столбца и т. д.), но без риска целостности данных.

Есть ли способ, которым мы могли бы достичь этого?

Answer 1

Что нам нужно, так это то, что вам не нужно ничего перекомпилировать, просто добавляя столбец (или увеличивая размер столбца и т. Д.), - но не рискуя целостностью данных.

Добавление столбцаэто просто, изменить размер - это другая история ...

Вам нужен слой, который отделяет ваши программы RPG от физического макета данных.

Просто сделайте две вещи

1. Определите все LF с явным форматом
2. У всех ваших программ RPG есть доступ через LF вместо доступа через PF.

, чтобы вы могли иметь

A* My Physical file
A                                      UNIQUE  
A          R MYPFR                     
A            MYKEY          3A         COLHDG('Key Field')
A            FLD1          10A         COLHDG('field 1')
A            FLD2          15A         COLHDG('field 2')
A            FLD3          20A         COLHDG('field 3')
A          K MYKEY

В вашей логике явно перечислите включенные поля ...

A                                      UNIQUE  
A          R MYLFR                     PFILE(MYPF)
A            MYKEY          
A            FLD1          
A            FLD2          
A            FLD3          
A          K FLD1

То, что вы не хотите хотите иметь, - это LF, автоматически использующий формат PF.

A                                      UNIQUE  
A          R MYLFR                     PFILE(MYPF)
A          K FLD1

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

Вы можете определить новый LF, включающий новый столбецдля использования любыми RPG-программами, которым необходим доступ к новому столбцу.

да, со временем у вас будет больше логики.Но пока «новая» логика использует тот же ключ, что и существующий, она не требует никаких ресурсов, кроме нескольких байт дискового пространства.Поскольку «новая» логика будет использовать существующий путь доступа.А сохранение / поддержание пути доступа - вот что потребляет ресурсы в i.

Переход к этой настройке также не так уж и сложен.

1. Создайте новый PF с новым именем
2. Создайте новый LF с существующим именем PF
3. обновите существующий LF, чтобы он указывал на новый PF и явноперечислить столбцы.

Фактически вы можете использовать SQL вместо DDS для шага 1, это позволяет вам использовать некоторые из новых функций только для SQL базы данных.

IBM Redbook Модернизация приложений IBM i от базы данных до пользовательского интерфейса и всего, что между детализирует подход.

Но идея о том, чтобы приложения работали через LF-уровень, существует очень долго.

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