During my daily work with support I often see cases, where a customer has done updates to the operating system or InterForm400 objects, that caused a problem in InterForm400. I hope this can be used for inspiration of what NOT to do.

Here are a few examples:

· Changing default values for OS400 commands

This is a no-no as InterForm400 is not specifying all parameters for each CL command called, so if something like that is needed it might be a good idea to copy the commands and place the changed commands in a library, which is not included in the library list when running InterForm400 related jobs.

· Changing system values e.g. QCCSID

This is not directly InterForm400 related, but the result for one customer was (after changing QCCSID), that the emails could not be sent from InterForm400 as the @-sign was no longer recognized by the programs – as it was in a different code page than expected. Changing any system value is something you should think over twice before you do it.

· Deleting and updating objects in APF3812

We assume that all objects in the APF3812 library are untouched by the customer. A support case with strange problems turned out to be caused by a customer renaming a physical file and creating a new physical file with the same name as the original file – causing the logical files to point to the renamed file. Others have deleted the APF3812/APFSYS output queue and caused an InterForm400 stand still. They then recreated the output queue object, but was unaware that the output queue need to be connected to a data queue as all AFC monitored output queues need to be.

· Adding the APF3812 library to the system library list

This may sound like a good idea to avoid specifying the apf3812 library each time you want to use an InterForm400 command, but the problem will hit you when doing an InterForm400 upgrade: The APF3812 library is locked by all jobs and the only way to get around this is to specify APF3812 everywhere you are using InterForm400, remove APF3812 from the library list and then IPL the machine…

· Mirroring the machine

In principle mirroring is a good idea, but it can cause special challenges.. Mirroring the machine can cause a problem in two areas:

1) When adding journaling of the InterForm400 objects yourself. Here the customer has not noticed, that the InterForm400 journaling requires IMAGES(*BOTH) i.e. images of the record/status prior to and after an update is needed. When this is forgotten an error comes up when importing or saving in the designer stating that journaling is not active..

2) When doing an upgrade of InterForm400 it is necessary to end journaling of all objects in the APF3812 library. When running a mirrored machine all objects are mirror, which is not the case for a normal installation. So you need manually to end journaling for the extra objects and start journaling again after upgrading. This is also covered in the InterForm400 manual.

· Removing or disconnecting data queues

Auto Forms Control is monitoring output queues with the use of data queues, that are created in the same library as the output queue and named the same. This is required in order to be able ‘see’ new spooled files, when they arrive. In a couple of cases a customer had installed some software, which chose to remove the link between the output queues and the data queues and insert its own data queue instead – for all output queues on the machine..