Quite a few of our customers are running systems, that are mirrored using a high availability system like e.g. MIMIX or iTera. The usual questions for InterForm400 in relation to such systems are these:

a) What files (or objects) should we including in the mirroring?
Answer: The important files in InterForm400 are the files that are normally included in the journal, but you could simply mirror all objects in library APF3812. Remember that if you are using journaling for this, the journaling MUST use IMAGES(*BOTH) (parameter on STRJRNPF). This is necessary because InterForm400 is using the journal to roll back changes if necessary.
 
In older versions of InterForm400 we emphasized that it was important NOT to mirror the data area: apf3812/apfconfig, as it contains the license code and it must be different on the two machines, but with the 2008 (and newer) versions of InterForm400 you can now maintain up to 4 license codes via the same license screen. You now insert both license codes in the same screen and let the mirroring copy the changes onto the other machine. So now you should even mirror this object as well!

You should also mirror the directories /apf3812home and /apf3812mail and subdirectories EXCEPT: /apf3812home/temp and /apf3812mail/PDFtemp. These temp directories contains temporary work files and slow mirroring of these temp directories can actually cause a problem in InterForm400.

b) Problem during upgrading
A call that I have often had regarding such HA systems is this:

--------------------------------------------------------------------------------------------------------------------
We are trying to upgrade InterForm400, but the upgrade stop with this message:
Library APF3812 cannot be renamed APF3812OLD.                                                     
Library APF3812 is in use.                       
Press F10 to view object locks for the library.  
Press Enter to retry.                            
When we press F10 no object locks are to be seen, so what is the problem??
--------------------------------------------------------------------------------------------------------------------

Answer: The problem is, that InterForm400 during the upgrade have tried to end all journaling, save the journal and journal receiver and delete the journal and journal receiver, but was not able to delete them. You can see the reason in the joblog:

Cannot delete journal APFJRN in APF3812.  Details:

Additional Message Information                        

Message ID . . . . . . :   CPF7021       Severity . . . . . . . :   40        
Message type . . . . . :   Escape                                             
Date sent  . . . . . . :   16/11/09      Time sent  . . . . . . :   12:11:09  

Message . . . . :   Cannot delete journal APFJRN in APF3812.                  
Cause . . . . . :   Journal APFJRN in library APF3812 cannot be deleted       

  because either objects are being journaled to journal APFJRN or commitment  
  control is active for some job on the system and journal APFJRN controls the
  commitment control environment.                                             

Recovery  . . . :   End journaling for all objects being journaled to journal 

  APFJRN in library APF3812 using one or more of the following:               
    -- End Journal Access Paths (ENDJRNAP)                                    
    -- End Journaling Physical File Changes (ENDJRNPF)                        
    -- End Journal (ENDJRN)                                                   
    -- End Journal Object (ENDJRNOBJ)                                         
    -- End Journal Library (ENDJRNLIB)                                        
                                                                       More...
Press Enter to continue.                                                      

F3=Exit   F6=Print   F9=Display message details   F12=Cancel                  

F21=Select assistance level

This is the core problem: Someone have chosen to add journaling of other objects than files thus creating this problem. You can use this command in order to find out exactly which objects that are still journaled:

WRKJRNA JRN(APF3812/APFJRN)

Now press: F19=Display journaled objects and select e.g. option '30. All object types' to go through all object types that may be journaled. You should be able to find that e.g. data areas or stream files / directories in the IFS are journaled. You will need to end this journaling with the appropiate command e.g. ENDJRNOBJ or ENDJRN.

If you are using a remote journal you can also check for any active remote journals via WRKJRNA and F16.

When journaling has ended you can retry the renaming with Enter on the installation job (if you have kept it active while fixing the journal problem). You will need manually to start journaling again of the additional objects after the upgrade has finished.

The scenario above will happen if someone have added extra objects to be journaled into the default journal (APFJRN in library APF3812) or another journal inside the APF3812 library. If the customer is using a journal inside another library it will work better, but the objects in the old library (APF3812OLD) are then also journaled after the upgrade.

c) The right way to upgrade a mirrored machine
So above a couple of issues regarding such mirrored setups are addressed. What would be the best way to upgrade InterForm400 in such a setup you may ask.

Before you start out, you will need to make sure, that it is OK to temporarily end journaling as mentioned above and end the subsystem. You can chose to let InterForm400 end most of the journaling and end whatever is missing yourself. If you want to be 100% sure that the upgrade will run through, you can also end the Auto_Form subsystem and end journaling and see if you can rename the apf3812 library. If yes the upgrade should run fine.

To update the remote (mirroring) machine you do the same upgrade here (if possible). If not possible you could save and restore the APF3812 library and the directories /apf3812home and /apf3812mail, but there might be other changes in an upgrade (A new release could  e.g. include other objects e.g. a new user profile or simular).

d) Check the data queues on the remote machine
One thing I have seen on at least one mirrored setup was, that somone had forgot to link data queues with the output queues on the remote machine. That meant, that Auto_Form would not react to any new spooled files. If possible you can check if these data queues exist, and if they are added to all the output queues, that are monitored by InterForm400.

The data queues are normally named the same as the output queue, that they are used for and placed in the same library. Via wrkoutqd you can check if a data queue is connected to the specific output queue:

Work with Output Queue Description

Queue:   PRT01_IN     Library:   QUSRSYS               

Status:                                                

  Writer active  . . . . . . . . . . . :   N           

  Writer name(s) if active . . . . . . :               

  Output queue held  . . . . . . . . . :   N           

Maximum spooled file size:                             

  Number of pages  . . . . . . . . . . :   *NONE       

  Starting time  . . . . . . . . . . . :               

  Ending time  . . . . . . . . . . . . :               

Writers to autostart . . . . . . . . . :   *NONE       

Display any file . . . . . . . . . . . :   *NO         

Job separators . . . . . . . . . . . . :   0           

Operator controlled  . . . . . . . . . :   *YES        

Order of files on queue  . . . . . . . :   *FIFO       

Data queue . . . . . . . . . . . . . . :   PRT01_IN  

  Library  . . . . . . . . . . . . . . :     QUSRSYS

If there is no data queue attached you can create and add it either via the InterForm400 menu simply by editing the output queue with option 2=Change or you can add it via CHGOUTQ of course.