The following is a list of frequently asked questions about iFileAudit. If you have a question that is not covered here, ask us via and we'll answer your question.
Yes: To change the port number used, there are two places where it need to be updated. First, run the HTTP Admin utility on your IBM i system. You can access it with the following URL: http://nn.nn.nn.nn:2001/HTTPAdmin changing the nn.nn.nn.nn to your system's IP address. After you sign in, click on the "Manage" tab and then the "HTTP Servers" tab. In the "Server:" selection box, find the "KISCOIFA - Apache" server. If the server shows as active, stop it before making the change.
Once the server has stopped, then click on the "General Server Configuration" option under "Server Properties" in the left-hand panel of options. On the General Settings tab, you will see where the "Server IP addresses and post to listen on" is located. Add a new entry for the port number that you want to use, click on the "Add" button under this area and enter just the port number on the next panel. Click on OK. If you want to remove the 8080 port, select it and use the "remove" option.
At this point, the server instance can be restarted. Now when you access the iFileAudit Bluescape, just use the new port number in the URL to access the logon process - http://nn.nn.nn.nn:9090/ifalogon.htm. In this case, the new port number is 9090.
This is a security issue. The browser interface runs from the QTMHHTTP system user profile. If you want to use the Analyze File option from the browser interface, this profile will need to be authorized as an Administrator for iFileAudit. You can do this using option 8 on the INSTALL menu. Before you make this change, make sure that the profile has its password set to *NONE. This will prevent it from being used maliciously to make changes to the iFileAudit configuration.
To change this feature setting for a file that is already registered and active you must follow this sequence of steps:
At this point, all file open and close operations will be tracked for the file.
Yes. iFileAudit will track the entire contents of fields up to a maximum length of 256 characters. If you have a field in a database file that is longer than 256 characters, iFileAudit will only track the first 256 characters of the field.
If iFileAudit has never been installed on your DR system, then you can activate the software without needing a special authorization code from Kisco. After the FILAUD library has been loaded, go to the INSTALL menu and run option #1. This will start a 30 day trial on your backup system which should be sufficient for your DR test.
After this has been done, run option #2 and the software should show as installed on trial with an expiration date more than one month in the future. If this is not the case, then contact Kisco to obtain a temporary code. Send a screen shot of the display from option #2 on the INSTALL menu.
If you are concerned that the above may not work correctly, provide Kisco with the serial number and partition number for your DR test system in advance and a temporary code will be provided in advance.
In a word - YES!
Please be sure to read this entire article before you start your planning for a DR system. If you have specific questions, don't hesitate to contact us.
First, if you want to be able to fail over to your DR system, then iFileAudit must be licensed on that system. Contact Kisco Information Systems to make these arrangements. If you do not want an active license on your DR system, you can always contact Kisco for a temporary passcode to use the software for a short duration during an emergency, but the temporary code may not be immediately available and you should plan accordingly.
Once the licensing issue has been resolved, there are additional considerations. Kisco recommends that you exclude all objects from replication in the FILAUD library with the following exceptions:
All other objects in the FILAUD library should be excluded from replication and the software base on your DR system should be directly maintained using Kisco upgrades or Kisco issued PTFs.
Also, you should consider the objectives of iFileAudit. The software is intended to capture database file changes. In a replication environment, these changes will be captured on your source system by iFileAudit. Then, your replication software will copy the changes to your backup system where iFileAudit could end up duplicating the results. Because of this, it is recommended that if you have an active license on your DR system, then you keep the files registered in iFileAudit as *INACTIVE. To avoid having them automatically activated, you should exclude the database *FILE object in the FILAUD library named FILAUDA. During a failover, you will need to wait until the backup system is active, and then add a step in your failover process to activate the files in question. This may also mean that if you add files to those that are being monitored in iFileAudit, then you will also have to add them on your backup system.
When the active status is flagged in yellow on this display, it means that the journal reference for the registered file has been removed and the file is no longer being journaled. When this happens, iFileAudit can no longer track changes on the file.
To correct for this situation, use the Journal Reset option on the file. This is option 9. When you use this option, the journal status will be reset and file update tracking will resume as of the point in time when the option 9 is selected.
The journal status can be changed if a file is updated by a third party software update or if the file is recompiled to add or delete fields to it. If you have files that are regularly updated in this way, you should make it a practice to check the iFileAudit registrations after each such update so that tracking can be kept current.
Yes. Once you become more experienced with journaling and journals, you may decide that you want to change the way the journals are stored and processed by iFileAudit. You can change the journal that is used by following this specific sequence:
When this switch is made, the journal entries showing that journaling was stopped will not appear in the file history stream stored in iFileAudit. You will, however, see journal entries stored showing that journaling was started and this will be your confirmation that the change was made.
Note: The above procedure will not work if your Journal Setup is showing as code U (User controlled). If this is the case, you can use the following procedure to make a journal change for a file with a user controlled journal:
At this point, iFileAudit will recognize the new journal and journal library and will continue to work without loosing any history information.
Yes. Most customers with files that are already being journaled have some form of High Availability (HA) software installed on their system. If this is the case, then when the journaling was started, it was done so with only the "after" record images being captured. Before making a change for this, we strongly recommend that you check with your HA software vendor to make sure that their software will still work correctly once you have changed the journaling to capture both "before" and "after" record images.
To make this change, just use the CHGJRNOBJ command as follows for each file where you want to change the configuration for iFileAudit:
CHGJRNOBJ OBJ((mylib/myfile *FILE)) ATR(*IMAGES) IMAGES(*BOTH)
When this has been done, then you will have to remove the current file registration for the file in question in iFileAudit (option #1 on the MASTER menu) and then re-register the file as a new registration. This will force iFileAudit to then recognize the proper journal registration information and it will then start showing both before and after file information.
Yes, an No. iFileAudit will track the changes just fine. The problem is the way most utilities work with source files. For example, IBM PDM utility makes a complete copy of a source file when it is being updated. When the update is done, the entire file contents are replaced. In the iFileAudit product, this ends up yielding a lot of update activity and none of it is very meaningful for anyone attempting to track individual source statement changes. We generally recommend that iFileAudit not be used for this purpose.
This can be done by adding the STRIFAQ command to your startup program as specified in system value QSTRUPPGM. Add the following command to this program:
FILAUD/STRIFAQ STRTYPE(*DEFER) STIME(2000) ITIME(1440)
In this example, the Automatic Analysis will run at 8pm once a day. See the documentation for more details on how the parameters should be set for your installation. Please note that you should not add this to your startup program until iFileAudit has been permanently installed on your system.
Yes - If you have never used journaling and are concerned about possible overhead and performance, then there are tools available from IBM to help you estimate the effect on your system.
Link to here at an IBM site. At this page, you will find a section on Journal Sizing and Planning Tool (Pseudo Journal) that includes downloadable code, installation instructions and a tutorial on how to use the tools. This can be used on your system to get an estimate on overhead and disk use for the file or files that you want to journal. Remember, iFileAudit runs with both before and after images enabled, this will affect how you interpret the results.
Yes - iFileAudit provides OS-style commands to easily register multiple files within a library.
No - The current version does not work with PC type files stored in the IFS.
Yes! If a journal is already active for a file when it is registered to iFileAudit, the software will use the existing journal information.
iFileAudit works on any physical file (PF). For best results, the file should be DDS described. Internally (non-DDS) described files will still work but the field interpretations will be incorrect. Also, while iFileAudit will work on Source Physical Files, it is of dubious value with these files because of the way the OS processes those files when they are updated.