I am responsible for a legacy application deployed on an iSeries V7R3. The application is fairly high volume, 2 million or so transactions per month.

The database for this app spans multiple libraries and I am currently journaling each library individually. I've been looking on the web for suggestions as to whether this is the best approach or if a single journal for the application might be better or at least be just as efficient.

So far I haven't found any clear advice on this topic, with some advising separate journals for each physical file. Of course searching for anything about the iSeries brings back ancient results often with no mention of the OS version or date of the information.

I'm not experiencing any problems other than managing multiple journals is sometimes a pain.

1 Answer 1


Any files that are changed together, ie. could be changed in a single transaction, should be journaled to the same journal. But the don't have to be, it's just simpler that way.

Without knowing more about your application, it's hard to provide recommendations. I'd question the need to split the files between libraries.

I will say, in no way shape or form should you have a journal per file (table).

We have a mutli-tenet application with about 300 tenets/10,000 users per server. Each tenet has their own data library and we have only 4 journals per server, so about 75 data libraries per journal.

IBM's documentation says

When deciding how many journals to use and how to assign objects to journals, consider the following:

  • Using one journal (and journal receiver) is the simplest method for managing both daily operations and recovery. There is a limit of 10 000 000 objects that can be journaled to a single journal.
  • If using a single journal receiver causes a performance bottleneck, you can alleviate this by placing the journal receiver in a separate disk pool from the objects that you are journaling.
  • To simplify recovery, assign objects that are used together in the same application to the same journal.
  • If you are journaling database files, all the physical files underlying a logical file must be assigned to the same journal.
  • Files opened under the same commitment definition within a job can be journaled to different journals. In commitment control, each journal is considered a local location.
  • If your major applications have completely separate objects and backup schedules, separate journals for the applications may simplify operating procedures and recovery.
  • If you journal different objects for different reasons; such as recovery, auditing, or transferring transactions to another system; you may want to separate these functions into separate journals. However, you can assign an object to only one journal.
  • If the security of certain objects requires that you exclude their backup and recovery procedures from the procedures for other objects, assign them to a separate journal, if possible.
  • If you have basic disk pools with libraries, all objects assigned to a journal must be in the same disk pool as the journal. The journal receiver may be in a different disk pool. If you place a journal in a disk pool without libraries (non library disk pool), objects being journaled must be in the system disk pool. The journal receiver may be in either the system disk pool or the non library disk pool with the journal.
  • If you have independent disk pools, they must be library capable in order to journal objects on them. You cannot journal objects on User-Defined File System (UDFS) independent disk pools.
  • Thanks, just what I needed, a real-world case. I read the docs and the "performance bottlenecks" mentioned in the second bullet point scared me. I have zero control over the actual app, it is still actively developed and maintained by the vendor.
    – John Kuhns
    Feb 15, 2022 at 14:26
  • @JohnKuhns the performance bottle-neck in question comes from DASD transfer limits...doesn't matter if you have 1 journal or 10. Between read/write for the app and writes for the journal, you can run out of IOPS. In that case, it helps to dedicate the journal receivers to their own set of disks. Again 1 receiver or 10, doesn't matter. Approximately the same number of writes would be done.
    – Charles
    Feb 15, 2022 at 14:32
  • If your looking for a performance boost, and you have journaling turned on but your app is not using commitment control, take a look at turning on journal caching And here's an older article where a job went from taking 11+ hrs to only 1
    – Charles
    Feb 15, 2022 at 14:42
  • thanks again for the tips. With the 30+ individual journals we are not experiencing any kind of performance issues and disk performance even during nightly jobs is not reaching any kind of critical level, so I think I'm going to migrate to a single journal. Again, much thanks.
    – John Kuhns
    Feb 15, 2022 at 14:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.