We describe some of the methods inside the AME main loop that is shown in Figure 2-13 on  page 197: If defined applications are found in the  .xml  file, then some memory data structures, which  are called  maps , are populated or updated with configuration and status details about  each found application as follows:  After reaching this point, the thread returns from  doXML()  and calls  doLaunch() . For each app in the app map, check the state and decide whether the mon, stop, or start  script must be started. If yes, start it and update the maps. Compute the time of the  timeout  and  update map  entries. After reaching this point, the thread returns from  doLaunch()  and calls  doNonBlockingWait() . For each app, look for children processes (started scripts that are not marked as returned  yet) and check whether they exited or not. For those that returned, update the states. For each app, if a timeout condition is ascertained on the current running script, the  blocking script is killed and the application status updates. Similarly, putting together all noticed state transitions of our test application in the presented  scenarios, we come up with the state machine diagram in Figure 2-14. 198  Implementing IBM VM Recovery Manager for IBM Power Systems Figure 2-14 Application state machine diagram GLYPH<SM590000> doInspectForTimeout() GLYPH<SM590000> doNonBlockingWait() GLYPH<SM590000> doLaunch() – If entries exist, then they are updated as  derived from the counterpart attributes that  are retrieved from the  .xml  file in case they are different.  – If no entries exist in the memory maps for an application, then they are created.  GLYPH<SM590000> doXML() At startup, the AME thread runs the  doXML()  method. The  .xml  config file is parsed for  defined applications. If no applications are defined, the thread goes to sleep from which it  can return by receiving a sync notification from  ksysvmmgr . In such a situation, it parses the  .xml  file again and looks for defined applications.