Suppressing File IO using CL As400 command

user_450062 0
Viewed 83

I have recently been tasked by my organization with modifying a large program on our AS400 system. Since I have not worked with this part of the system before before, I wanted to run it through the debugger to get a handle on how it works - however I have been advised that running this program could cause unwanted database changes even in a dev environment.

Therefor I was hoping to use a CL command that suppresses file IO that I came across in training. Unfortunately, I have forgotten the name of it, no longer have access to my training resources and have been unable to find anything online. Does my description correspond to any known commands (or are there any others I might find useful in this situation)?

cl ibm-midrange io
3 Answers

the INHWRT parameter of the OVRDBF command is used, as the name implies, to inhibit writes, updates and deletes from being actually applied to the file. Beware that if trying to prevent updates of an entire application you have to apply the override to every file. And if the application writes to a table, then runs code that relies on that data being in the table, then that will not work either.

In practice, I have never seen INHWRT used in anything but a single purpose program.

user_54847370

I think the common way to handle this is by adjusting library lists so that instead of updating production files, you can update a copy in a different library. If the files are so badly organized that this cannot be done, you could make a list of all potentially affected files and override them to a QTEMP copy before the program starts. If the programs explicitly call for a file or table including the library name, this would let you control it by the file override mechanism, rather than by library.

Reading between the lines of the warnings you were given, I suspect that the developers do not trust the consistency in in file location or coding style to use either of these techniques. You really should read the code thoroughly to see if either of these techniques would work, or possibly make changes that allow them to work in order to test changes in a properly isolated manner.

user_31755620

If all your physical files are journaled with IMAGES(*BOTH) then every change made in the DB is logged and RMVJRNCHG can be used to get back to before the program started.

So you have to run STRJRNPF ... IMAGES(*BOTH) once

Before you call your program CHGJRN ... JRNRCV(*GEN), that will log changes in a new receiver

When you want to return to previous state you run RMVJRNCHG

But remember

  • If your app does RGZPFM or CLRPFM then you can't go back
  • It only works with dabase file, not with data area, nor other object, nor ifs files
  • You better be sure you have a backup that you can/know how to actually restore
  • You better be the only app active user
  • You better play with RMVJRNCHG before to understand how it works, and the messages it sends
user_121118210
Related