Backups need not be a curse.

Brief: The new Save While Active option, available on several of the V2R2M0 system-supplied save commands, lets you save copies of objects while they are being used. There are two ways to use the Save While Active technique. Your selection must be based on the amount of effort that you are willing and able to put into a recovery situation, should that be necessary. This article describes Save While Active concepts and considerations that you should know before using it for your backups.

One of the most eagerly anticipated features of V2R2M0 of OS/400 is the Save While Active (SWA) option, added to most major save commands. With the SWA option, you can, in many cases, use objects as they are being saved. SWA is especially valuable for installations which require continuous availability of the computer system or where personnel are not present to perform saves during periods when the machine is inactive.

However, you cannot simply start using those additional parameters on your save commands. Before using SWA techniques, you must have a good understanding of how SWA works, what it is saving and what factors you must consider if you need to perform a recovery with the SWA media.

What SWA Does

SWA reduces or eliminates the amount of time that objects are unavailable to application programs during a save of the objects. In contrast, objects saved without SWA are either not available at all during a save or can be used as read-only objects. SWA is of particular interest when you need to save database files and other data type objects (such as data areas and user spaces). If there is a chance that the objects will be open for update during the time of the save, SWA processing can help you guarantee that related objects are saved in a "consistent" state with each other.

You can request SWA processing with parameters on these save commands: Save Library (SAVLIB), Save Object (SAVOBJ), Save Changed Objects (SAVCHGOBJ) and Save Document Library Object (SAVDLO). 1 shows the commands and command parameters used to request SWA processing. We'll explore the usage of each parameter later in the article.

You can request SWA processing with parameters on these save commands: Save Library (SAVLIB), Save Object (SAVOBJ), Save Changed Objects (SAVCHGOBJ) and Save Document Library Object (SAVDLO). Figure 1 shows the commands and command parameters used to request SWA processing. We'll explore the usage of each parameter later in the article.

The fundamental concept of SWA is the notion of a "checkpoint" for an object. A checkpoint is a map of the object taken at a point in time. The map directs the save to an image of the object which is saved. The image may be an exact copy of the object at the end of the save time or it may not, depending upon activities that take place on the object while its image is being saved.

Save Times

There are three distinct periods of time during a SWA save. Understanding what happens during these periods will help you determine how to use SWA processing and will also determine how you must proceed if you need to use the SWA media for recovery.

2 shows the time periods and describes what happens during each period. Most important is the save preprocessing time because during this time checkpoints are established and locks are applied to the objects being saved. Unless you are journaling files, applications that update the database should not be active during this time frame.

Figure 2 shows the time periods and describes what happens during each period. Most important is the save preprocessing time because during this time checkpoints are established and locks are applied to the objects being saved. Unless you are journaling files, applications that update the database should not be active during this time frame.

After checkpoints are taken, the objects can begin to be saved. This is the save processing time or save time. During this period, any changes made to the objects are handled according to the technique described in the sidebar on page 42.

Once the object is completely saved, there is no longer a need to maintain the checkpoint image. The image and the locks on the object are released. This is referred to as save post-processing time.

A Fundamental Decision

The most important decision that you must make regarding SWA processing is whether you will allow applications to be active during the time that a SWA save is taking place.

At first glance, that question seems to undermine the whole theory behind SWA saves. The obvious rejoinder, "Well, of course I will have applications active; is that not the purpose?" should not prevent you from understanding the consequences of that decision. The fact is, if you can possibly end any applications which change any of the objects that are to be saved during the save preprocessing time, then you can extract a great deal of benefit from SWA and enjoy the prospect of a relatively easy recovery using the SWA media, should that be necessary. Alternatively, if you cannot stop your applications during the save preprocessing time, then you must seriously consider journaling all database files saved with SWA, and determine how you can recover other objects that are not journaled.

Now, if you have to stop your applications in order to use SWA saves, what is the benefit of using SWA? Why not simply save objects as before? The answer is, once the checkpoints are established for the objects, you can start using them again, concurrent with the save of the objects. Establishing checkpoints takes much less time than actually saving the objects, so the amount of time that the objects are not available is decreased. If you can possibly work with the limitation of waiting until the checkpoints are taken, then the amount of effort required in a recovery situation will be significantly reduced.

The problem with using SWA with active applications is that the checkpoints may be established when the objects are not at an "application boundary." The problem is compounded if you are saving many active database files that are used together, but the files are not being used with commitment control. The checkpoint established for each file does not guarantee that the files are synchronized with each other. For example, a checkpoint for an order detail file may be taken in the middle of an order.

If the application was working with commitment control, the order detail file would either contain none of the detail lines for the order or would contain all of them, but not a partial set. It is not the function of the checkpoint to determine the state of any application using any of the objects that are being saved while active.

Two Types of Checkpoints

I stated earlier that SWA processing means that the system saves related objects in a consistent state with each other. As described above, the consistent state does not imply application consistency. Consistent, in this case, means that related objects are checkpointed and saved in such a manner that related objects can be restored to the same point that they were when any member of the group of related objects was checkpointed.

This is somewhat confusing. Essentially, it means that objects are checkpointed at a moment in time and that all objects could be restored to their relationships at that time. However, no logical checkpoint is established. The problem is compounded by the fact that you can select one of two methods for taking checkpoints. The first and simplest method is to take a checkpoint for all objects in the library that is to be saved. The second method is to tell the system to determine how to take checkpoints for the objects in the library.

You specify the first method by using SAVACT(*LIB). This parameter value means that you want all of the objects that are to be saved from a library to reach a common checkpoint. This is the recommended parameter value if you are saving database and nondatabase objects in the same library. Because taking the checkpoint implies that all of the objects were at a known state together, you can restore from the SWA media used with SAVACT(*LIB) and know that the relationship between all of the objects was restored.

The second method is to specify SAVACT(*SYSDFN). This means that you want the system to define how checkpoints are reached for objects that are saved. This method is not recommended unless all database files being saved are journaled. The system will reach one or more checkpoints, instead of the SAVACT(*LIB) requirement of reaching one checkpoint for all objects. With SAVACT(*SYSDFN), the system looks for relationships between database files and reaches checkpoints for those related files. This is called a database network.

A network is made up of physical files and related logical files, and physical files that are journaled to the same journal. Apart from originally creating the objects (physical and logical files and journals), you do nothing to create networks; they are a system construct used during SWA processing. As soon as all of the related objects in the network reach a checkpoint, those objects can be saved. The advantage of using SAVACT(*SYSDFN) is that the checkpoints can probably be established more quickly for database networks than if all of the objects in a library need to reach the common checkpoint together. The big disadvantage of this technique is that the "consistent state" established by the single checkpoint SAVACT(*LIB) is no longer guaranteed.

The SWA documentation is quite explicit about when SAVACT(*SYSDFN) should be used. If there are no applications making changes to the objects during the save preprocessing time, or if the only objects in the library are journaled database files, then the saved objects generated by the SWA can be used with relative ease in a restore situation. But if you use SAVACT(*SYSDFN) and neither of those conditions are met, you will have to plan for how you can resynchronize the objects after a restore (not an enviable project).

Other Parameters Used With SWA

There are two other parameters used to control SWA processing. The first, SAVACTWAIT, is used to indicate a time period to wait for objects to become available for checkpoint processing during SWA preprocessing time. The amount of wait time is specified in seconds, from 0 to 99999, with 120 seconds being the default. You can also specify *NOMAX, to indicate that there is no time limit.

Objects are not checkpointed until a lock of *SHRNUP (Shared, no update) or *SHRRD (Shared, allow read) is placed on the object. According to IBM, shared read is used for database files, data areas and a few other object types. The *SHRNUP lock ensures that no changes are made to the object during the checkpoint (save preprocessing). The *SHRNUP lock cannot be obtained if another job has a lock state of *EXCL (Exclusive), *EXCLRD (Exclusive, allow read) or *SHRUPD (Shared, allow update) on the object.

If the *SHRNUP lock cannot be obtained within the time limit set by the SAVACTWAIT value, the object cannot be checkpointed and is bypassed in the SWA process. If the *SHRNUP lock is obtained, the object is checkpointed, after which the lock is lowered to *SHRRD. The object is held in that lock state until the lock is released in the SWA post-processing time. While held in the *SHRRD lock state, the object cannot be deleted, renamed, moved to a different library (or folder) or have its ownership changed.

The other use of the SAVACTWAIT time is to check for database files that are open under commitment control. If the files are not at a commitment boundary within the specified period of time, SWA is ended for the library. Note that this penalty is much more severe than simply not saving the object; in this case, the entire SWA is ended. However, this is one of the reasons why commitment control is used-to ensure that all or none of the transactions are saved. Rather than saving some objects and not saving others in the same library because they are not at a commitment boundary, the system throws the problem back to you and demands that you resolve the situation before creating a save that may be unusable.

The last parameter used with the SWA processing is the SAVACT-MSGQ parameter. This parameter is used to specify the qualified name of a message queue where messages generated by the SWA process are to be sent. The values that you can specify include the default of *NONE (no notification messages are sent), *WRKSTN to send messages to the workstation message queue, or a message queue name (such as QSYSOPR). The messages that are sent include CPI3710, to notify you that checkpoint processing is complete for all objects in the library, and message CPI3711, indicating that checkpoint processing could not be completed for the library.

These messages take on importance when you use the recommended technique of halting applications for the SWA preprocessing time. If you receive message CPI3710, then you know that you can safely resume working with objects in the library. Receipt of message CPI3711 means that the system encountered some problem in establishing checkpoints. The problem could take the shape of applications with object allocations that prevent SWA preprocessing, or commitment control transactions that are not at a commitment boundary. You should take whatever steps are necessary to correct the problem and restart the SWA process.

Commitment Control

I have mentioned commitment control in relation to the SAVACTWAIT parameter. You should know about some additional considerations if you are using SWA with database files processed under commitment control. The first consideration is that none of these concerns are relevant if there are no applications active against the committed database files during the SWA preprocessing time. This is because the system is able to establish checkpoints easily and completely for all of the database files, since there is no competition for them. Remember that most of the work performed by the SWA process is done in the establishment of checkpoints for all of the objects that are to be saved. Once the checkpoints are established, the objects are available again.

If the objects are in use during the SWA preprocessing time, the system first checks to determine if there are any uncommitted transactions for any of the database files in a group that are reaching a checkpoint together. "Reaching a checkpoint together" can apply to all of the objects in the library (SAVACT(*LIB)) or to database networks (SAVACT(*SYSDFN)). Each uncommitted transaction causes message CPI8365 ("Save-while-active request requires commit or rollback for job x/x/x") to be sent to the QSYSOPR message queue after waiting approximately 30 seconds. The message is sent for each job. The message identifies the job and the fact that the job is not at a commitment boundary. If the messages are being monitored, either by the system operator or by a message monitoring program, then it may be possible to cause some action to have the job commit the transactions. For example, a data entry operator may be inadvertently delaying the closing of a transaction. That delay would cause the SWA checkpoint to be delayed and the CPI8365 message sent.

If the transaction is not completed within the number of seconds specified in SAVACTWAIT, the save processing is ended for the library. This implies that you should raise the time limit from the 120-second default for libraries when you know commitment control is in effect for database files being used during SWA preprocessing time. If you can manually or automatically intervene in the uncommitted transaction, you want to allow enough time for the transaction to be committed or rolled back, rather than having the system summarily cancel the SWA request.

One other consequence of using SWA with active database files under commitment control is that the jobs using the files can be delayed while the checkpoint is being established. Recall that the checkpoint processing can begin only when all of the jobs using the database file reach a commitment boundary. Once this occurs, the system starts the checkpoint process. Two factors dictate how long a job may have to wait: the amount of time spent waiting for other jobs to reach their commitment boundaries, and the size of the file (which determines how long it takes to establish a checkpoint, once the checkpoint can be taken). During the wait time, jobs are held at their last commitment boundary with a job status of Commit Wait (CMTW).

Recovery With SWA Media

If you have to recover a library, application or system with media produced by SWA, your task is not necessarily easier or more difficult than using media produced by non-SWA saves. If you are able to stop applications during the SWA preprocessing phase, then your recovery should be identical to a non-SWA recovery. However, if you are restoring from a SWA save when there were active jobs, you will probably have quite a job restoring your applications to application boundaries.

3 lists some of the possible scenarios you may encounter and briefly describes how you should use SWA processing and what to expect. As stated in the documentation for SWA, you determine the type of SWA you want to use based upon how much effort you are willing to put into recovering with the SWA media.

Figure 3 lists some of the possible scenarios you may encounter and briefly describes how you should use SWA processing and what to expect. As stated in the documentation for SWA, you determine the type of SWA you want to use based upon how much effort you are willing to put into recovering with the SWA media.

What you should note from the chart and from the preceding discussion is that you should not even consider using SAVACT(*SYSDFN) unless all of the database files being saved are being journaled. The reason for this strong precaution is that the checkpoints taken with SAVACT(*SYSDFN) are not necessarily consistent with each other, even within the same library. The checkpoints are only consistent within the database networks.

Always remember that the system cannot determine if or when your applications are at an application boundary. An application boundary is a point at which all of your related transactions are synchronized. For example, an application boundary in an order entry situation would mean that the entire order is entered, the inventory balances are updated to reflect the order, and the customer account records are in balance as a result of the order.

The application boundary means that you don't have to go through the laborious and error-prone exercise of reconstructing the transaction to get all of the files into agreement. Even if you are using commitment control, you have no guarantee of reaching an application boundary, but only a commitment boundary. (However, a properly implemented commitment control boundary would probably be an application boundary.) The simple fact is that if you are not willing or able to journal all of the database files that may be active during the SWA preprocessing time, you have no business running applications while using SWA to create save media.

If your installation has a mixture of database and nondatabase objects in a single library (Item A in 3), you have two possible SWA scenarios. For the simplest recovery, use SAVACT(*LIB) and halt applications during save preprocessing (until the checkpoint message is received). You should still realize substantial savings in system downtime because your objects will be available during the actual save process.

If your installation has a mixture of database and nondatabase objects in a single library (Item A in Figure 3), you have two possible SWA scenarios. For the simplest recovery, use SAVACT(*LIB) and halt applications during save preprocessing (until the checkpoint message is received). You should still realize substantial savings in system downtime because your objects will be available during the actual save process.

Alternatively, SAVACT(*SYSDFN) may result in a faster checkpoint. However, be aware that unless you halt all applications, recovery of objects other than journaled database files becomes far more complex with *SYSDFN. You will have to save, hope for the best and work out your recovery situation when it happens.

Item B (objects are in multiple libraries) is an unpleasant fact of life that may have no good solution. The problem is that checkpoints are reached on a library-by-library basis, regardless of how you specify the libraries on the save command. If you are able to halt applications for all of the libraries until the checkpoints are completed for all libraries, then at least the saved objects are at a "virtual" common checkpoint, if not a de facto one. The order in which libraries are saved can have a substantial effect on the amount of time you need to complete the checkpoints.

Item C represents a situation where you may start thinking about using SWA against active database files. If all of the files are journaled, you can specify SAVACT(*SYSDFN) and use the files even during preprocessing time. The reason for this is that you can use the journal entries in the associated journal receivers to force the database files to a certain known point. You can use either the Apply Journal Changes (APYJRNCHG) or Remove Journal Changes (RMVJRNCHG) command to bring your files up to date or back to a point. Note that files that are not journaled may require you to manually bring those files into synchronization with the files that were journaled.

Item D is probably the ideal case for a SWA usage. If all of the objects in the library are database files under commitment control, then the files are by definition being journaled. Ideally, you would also use SWA when applications are halted; but if that is not possible, the SWA function guarantees that the files are saved at a commitment boundary. You can use the journal entries to force the files to common application boundaries after a restore.

Item E is a more typical instance of an Item D installation, in that there may be objects other than database files saved with SWA. In this case, you have the benefit of database files saved under commitment control, but you must account for the other objects that may have been changed during SWA preprocessing. You might consider adding those other objects to the commitment cycle with the Add Commitment Resource (QTNADDCR) API, or plan for whatever other recovery steps would be required to synchronize them with the restored database files.

SWA Performance

There is no mystery to SWA performance; it is affected in the same manner as any other job that runs on your system. Because the very phrase "save while active" implies that you will be running the save while other jobs are active, it is obvious that the same considerations apply as for any other performance- related problem.

The documentation for SWA mentions some factors that you might consider and experiment with. The first is that the machine pool should be at least 600KB above the minimum machine pool size for your AS/400 model. When you first start using SWA, you should monitor paging within the machine pool. If the numbers are quite high, you should add storage to the machine pool immediately. Remember that a struggling machine pool can adversely affect every other job on your system.

Another memory-related recommendation is that the SWA job should be run in a memory pool of at least 4MB. This is another number that you should check when you try SWA. If the pool in which the job is run shows symptoms of extreme thrashing, then you should shift memory to that pool, either temporarily or permanently.

In addition to other jobs having an adverse effect on SWA performance, the SWA job can be detrimental to other jobs. Because of the batch-like processing of the SWA job, it should be run at a lower priority than other jobs, especially interactive and spooling jobs. The documentation also notes that performance is worse if many small objects are being saved, best if few large objects are being saved. This is similar to save commands without SWA, since the object save date and time information must still be updated for all of the saved objects.

SWA and Office

You can use SWA on the SAVDLO command to save folders and other Office objects. However, there are several things that you must keep in mind when saving active Office objects.

First, you cannot use SWA if STG(*DELETE) is specified on the same save command. Also, documents are not saved if the Reclaim Document Library Object (RCLDLO) command is running; folders are not saved if the Reorganize Document Library Object (RGZDLO) or RCL-DLO commands are being run.

Mail is forced to wait until checkpoint processing is complete.

The documentation describes how a document is updated, indicating that changes to a document are not made to the original version but to a work copy of the document. This means that if you open a document and then start a SWA save, the checkpoint is taken against the original copy of the document. Any changes that you make to the document prior to saving it are not saved. That is because SWA takes a checkpoint of the original copy of the document, which is not changed until you save the document in OfficeVision. This is in contrast to a user database application, where records are almost always updated in the database as the updates occur.

The documentation includes two additional concerns about SWA and Office. These include, without elaboration, the statements that "calendar items may be only partially added when checkpoint processing is complete, or in the case of a change operation the item may not be saved. The checkpoint processing will be done such that the data can be restored and used without errors." Also mentioned is a caution against performing directory updates until the checkpoint is complete for library QUSRSYS. The Work with Directories (WRKDIR), Work with Distribution List (WRKDSTL), Work with Directory Locations (WRKDIRLOC) and Start Office (STROFC) commands are mentioned as commands that should not be used until the checkpoint is reached.

Proceed With Caution

Save While Active may be a case of being careful about what you ask for-you might get it. It looks like IBM did a very thorough job of planning for and implementing this function. The concepts are flexible and easy to understand. As with anything you can do with a computer, there are numerous trade-offs that you make, depending upon your resources, requirements and the level of risk that you are willing to take.

One strong theme runs through the documentation about SWA. The very best SWA situation would occur if all of your files are journaled and used under commitment control where appropriate, and if you can halt any updating applications during the SWA preprocessing time. If your installation requires 100 percent availability, you will have to take special care to save your objects and journals, to account for the possibility of changes during the SWA preprocessing time.

On the other hand, if your installation already has a dedicated save time, you may want to check SWA processing to see if it reduces the amount of time that you must dedicate to the save. Since you already have dedicated time, you can run SWA without applications active during the preprocessing time. Once the objects have been checkpointed, you can start other applications. The resulting save will be the same as if the entire save was taken without SWA processing.

Reference

Advanced Backup and Recovery Guide (SC41-8079-01, CD ROM QBKA9101), Chapter 5: "Save-While-Active Function."

How SWA Works

To create the image of the object that will be saved, the system first determines the "pages" that are included in the object. A page is simply a fixed-length block of virtual storage that is swapped between auxiliary storage and main storage as needed. There is no correlation between a page and any other unit of measure that we would normally use to express our storage requirements. For example, records in a database file may require more than one page per record, or more than one record may be contained in a page. A1 illustrates how the page concept works.

To create the image of the object that will be saved, the system first determines the "pages" that are included in the object. A page is simply a fixed-length block of virtual storage that is swapped between auxiliary storage and main storage as needed. There is no correlation between a page and any other unit of measure that we would normally use to express our storage requirements. For example, records in a database file may require more than one page per record, or more than one record may be contained in a page. Figure A1 illustrates how the page concept works.

By using the concept of a page, the SWA implementation can be consistently used for any type of object. Rather than having one SWA technique for database files, another for user spaces, another for data areas and so on, the SWA process simply notes the pages that are included in the object at checkpoint time and monitors any changes to those pages.

After the checkpoint is established for the object, the object can be saved. While being saved, the object can be used for most other purposes. For instance, a database file can be opened and records read, added, changed or deleted. The file itself cannot be deleted during SWA save time. During the time that the object is being saved, changes to the object that affect any unsaved pages contained within the object are treated specially. First, SWA makes a copy of the page that is to be changed. Then the change is made to the page within the object. At the point where the save process is going to save that particular page, it saves the copy of the page instead. The result is that a version of the object is saved exactly as it was when the checkpoint was completed, and that the changes made to the object are stored in the current version of the object. The changes are not in the version of the object that is saved.

A2 shows how a database file is saved with SWA processing. An image of the file is made. When the system has noted all of the pages that comprise the file (A1), the file is at its checkpoint. If the file is then saved and there are no changes to the file while it is being saved, the system simply uses the checkpointed image to save the file. However, if a program changes any of the records in the file after the checkpoint is reached, the system copies the page or pages that will be changed prior to changing them, and saves those copies along with the other unchanged pages. As soon as all of the original pages are saved, the file is released from its checkpoint. Changes made after the checkpoint is released do not result in additional copies of pages being made, even though the save may still be in progress for other objects.

Figure A2 shows how a database file is saved with SWA processing. An image of the file is made. When the system has noted all of the pages that comprise the file (Figure A1), the file is at its checkpoint. If the file is then saved and there are no changes to the file while it is being saved, the system simply uses the checkpointed image to save the file. However, if a program changes any of the records in the file after the checkpoint is reached, the system copies the page or pages that will be changed prior to changing them, and saves those copies along with the other unchanged pages. As soon as all of the original pages are saved, the file is released from its checkpoint. Changes made after the checkpoint is released do not result in additional copies of pages being made, even though the save may still be in progress for other objects.

A First Look at Save While Active

Figure A1 Identify database file pages

 
  Figure A1: Identify Database File Pages 
 
  File (F1) = Page 58...Page 62 
 
  A First Look at Save While Active
 
 Figure A2  Saving a file with SWA
 
 
  Figure A2: Saving a database file with SWA 
 
  (Unable to reproduce graphic.) 
 
  A. Save Object command is issued with SWA request: 
     SAVOBJ OBJ(...) SAVACT(*LIB)... 
 
  B. Message CPI3710 is sent to the message queue specified in SAVACTMSGQ after 
     all checkpoints are reached. 
 
  C. File F1 (pages 58-62) is at its checkpoint. 
 
  D. Program P1 starts-it opens file F1 for update and changes some records. 
 
  E. Other programs can also make changes to file F1 or other checkpointed 
     files. The changes are noted and handled as in step D. 
 
  F. File F1 is saved as the checkpointed image of F1. This includes the image 
     taken at step C plus the copy of the original pages, as shown in step D. 
 
  A First Look at Save While Active
 
 Figure 1   Save commands that include SWA processing
 
 
  Figure 1: Save Commands That Include Save While Active Processing 
 
  Command                            Parameters 
                       ||------------------||--------------- 
                     SAVACT          SAVACTWAIT        SAVACTMSGQ 
 
  SAVLIB            *NO              0-99999           *NONE 
  SAVOBJ            *LIB             default 120       *WRKSTN 
  SAVCHGOBJ         *SYSDFN          *NOMAX            message queue 
 
  ------------------------------------------------------------------ 
 
  SAVDLO            *NO              0-99999           (not used) 
                    *YES             default 120 
                                     *NOMAX 
 
  A First Look at Save While Active
 
 Figure 2   Save While Active times
 
 
  Figure 2: Save While Active Times 
 
  Save Preprocessing 
    Determine objects to be saved 
    Lock object at *SHRNUP or *SHRRD based on object type 
    Take checkpoint image of object 
    Reduce object lock to *SHRRD 
 
  Save Processing 
    Save checkpoint image of object. Any changes made to object 
    during this time are not saved. 
 
  Save Post Processing 
    Checkpoint images of objects are released 
    Locks held on objects are released 
 
  A First Look at Save While Active
 
 Figure 3   Restore considerations for SWA saves
 
 
  Figure 3: Restore Considerations for SWA Saves 
 
  A. Some objects are not database files. 
 
    If SAVACT(*LIB) was used, restored objects within a library are consistent 
    with each other. However, the objects may not be at a common application 
    boundary. 
 
    SAVACT(*SYSDFN) should not be used unless all database files are journaled. 
 
  B. Objects are in multiple libraries. 
 
    Objects do not reach a common checkpoint. Recovery in this situation is 
    similar to recovering from an abnormal system end. 
 
  C. All objects are database files; some/all are journaled. 
 
    If ALL files are journaled, SAVACT(*SYSDFN) can be used. 
 
    Journal receivers should be saved immediately after SWA processing. This is 
    because the journal receivers contain journal entries for any changes made 
    to the files during the SWA save. 
 
    APYJRNCHG and/or RMVJRNCHG commands can be used to bring journaled database 
    files to application boundaries. 
 
  D. All objects are database files under commitment control. 
 
    If all files are in the same library, there are no special recovery 
    procedures required. The files are saved at the application boundary defined 
    by the commitment control cycle. 
 
    If files are in different libraries, APYJRNCHG and RMVJRNCHG commands can be 
    used to bring database files to consistent state. 
 
  E. Some objects are not database files, but all database files are under 
     commitment control in the same library. 
 
    Consider using Add Commitment Resource (QTNADDCR) API for nondatabase file 
    objects.