Wednesday used to be my favorite day when I was a child. No school and a nice trip via the Buttes Chaumont gardens in Paris to my grandmother's flat to enjoy a lovely lunch. These days are long gone, and Wednesday has become a nightmare day. This is the day my company installs new software and upgrades, and things are not always as straightforward as we would like. About a month ago, I installed a new version of a program in which embedded SQL had substituted old-fashioned RPG to retrieve records. No problems doing that. It was later, when we received a visit from people at operations, that we learned interactive programs were falling over unexpectedly. Operations asked us whether we had installed anything related to these programs. We had not, but we figured out that a program was falling over with a level check error. Spooky we thought. Neither program nor display file had changed. Library lists were the same as before. So, why was this happening?
To ensure compatibility between files and programs, file record formats have an identifier. The quickest way to see them is by using the command DSPFD asking for RCDFMT information. When a module or program is compiled, a snapshot of concerned identifiers is taken and stored inside the module or program definition. You may view the snapshot by doing a DSPPGMREF. When a file is opened by a program, a check is made to ensure the current file record format identifier is the same as the snapshot contained in the program. If they disagree, an error is issued, unless the file is set or overridden to ignore such check. To override a file in such a way, you would do OVRDBF File LVLCHK(*NO).
As I said earlier, no change had occurred and yet a level check was happening. A closer look revealed something unsettling: A DSPFD on the display file showed that one of the identifiers had changed. Such identifiers are made of hexadecimal characters, and yet a had replaced one of the characters. This happened while the
To continue reading for free, register below or login
To read more you must become a member of Search400.com
file was held by dozens of users, and without leaving a trace in the object auditing. We could not recompile the file or move it and replace it with a "clean" version and had to get all users out of the system. We recompiled the program and saw that the snapshot for this format now incorporated a . The recompile worked and users were allowed back in. The same problem happened three more times. In one case, a Z replaced a character in an identifier, and in another one, the name of a subfile control format was corrupted. We managed to correct the problem by setting off the level checking for one display file and copying a clean version of the last file in QUSRSYS. By noon on Thursday, we were keeping our fingers crossed that this would not happen again. And we were delighted this had not happened to database files.
We made a quick call to IBM and ordered large PTFs. And surprise, surprise, they concerned SQL. This new program I'd introduced apparently managed to modify the display file sub-headers, and these PTFs would make sure that wouldn't happen again. The header of an object stores information such as the object name, its library, and who owns it. In the case of files, a sub-header is added that contains format names and their identifiers. That it was modified following a SQL problem seems extraordinary, but it is yet again an example of why one must keep up to date with PTFs.
I once heard of a bank that would not install PTFs, including HIPER PTFs, on its system until they had spent three or six months on a test machine. When you see what PTFs can correct, this is frightening. Our incident was relatively minor, but other PTFs cover more damaging problems. Without some PTFs, SQL might return wrong sets of records, RPG. Calculations might go wrong, data might be corrupted on disks, or expensive tape units might have to be replaced seven times in a month. (The latter happened to me at a previous company!)
The AS/400 is a great machine. Keep it this way. Keep it up to date.
Pascal Jacquemain is an analyst/programmer at Gulliver Travel in London. In addition, he has worked as an AS/400 instructor.
