According to a case I have opened the library QSBMJOBTRK does not get saved when doing a full system save.  Neither with *IBM nor *ALLUSR.  This was done with a somewhat recent PTF. S/R made this change at the request of the database team.

There are journal receivers in this library.  If you have a utility to delete saved receivers, well, that's going to have issues.  This is how I discovered this issue.

Hopefully the library is expendable.  I'll find out later this year when I do a system migration.

I'm being led to believe you can save the library individually.  But, like, who is going to know that a full system save is going to omit certain libraries?  I already know that IBM can flag IFS directories with Not to be saved and makes frequent use of that for directories containing expendable log files which often cause issues with locks during save while active.  Didn't know that IBM was going to start omitting libraries too.

As a side note for those using QSYS2.JOURNAL_RECEIVER_INFO:  SAVE_TIMESTAMP does not get updated for journal receivers in the *IBM type libraries for the same reason that object save date doesn't get updated on those objects in DSPOBJD.  Try to use STATUS and DETACH_TIMESTAMP as an alternative.

Hi Robert, 

What is the PTF you refer to? 

Your post prompted me to check on one of our IBM i 7.4 LPARs, our application test systems that we roll out new PTFs to first on a monthly basis. So pretty well up to date with the latest PTFs. 

We use Commvault for all our saves, and we ran a full system save on this LPAR on 14 June. Under the Commvault covers it still runs saves using SAVLIB *IBM as an example. Checking the *IBM save we see that QSBMJOBTRK was saved. And the object description for QSBMJOBTRK supports this. 

The help for SAVLIB *IBM certainly describes many exclusions, but QSBMJOBTRK is not on the list, assuming of course that the help text is up to date. 

Regards,

------------------------------
=====================
Jozsef Torok
Spark New Zealand Ltd
=====================

Original Message:
Sent: Fri June 20, 2025 03:10 PM
From: Robert Berendt
Subject: Library QSBMJOBTRK does not get saved.

According to a case I have opened the library QSBMJOBTRK does not get saved when doing a full system save.  Neither with *IBM nor *ALLUSR.  This was done with a somewhat recent PTF. S/R made this change at the request of the database team.

There are journal receivers in this library.  If you have a utility to delete saved receivers, well, that's going to have issues.  This is how I discovered this issue.

Hopefully the library is expendable.  I'll find out later this year when I do a system migration.

I'm being led to believe you can save the library individually.  But, like, who is going to know that a full system save is going to omit certain libraries?  I already know that IBM can flag IFS directories with Not to be saved and makes frequent use of that for directories containing expendable log files which often cause issues with locks during save while active.  Didn't know that IBM was going to start omitting libraries too.

As a side note for those using QSYS2.JOURNAL_RECEIVER_INFO:  SAVE_TIMESTAMP does not get updated for journal receivers in the *IBM type libraries for the same reason that object save date doesn't get updated on those objects in DSPOBJD.  Try to use STATUS and DETACH_TIMESTAMP as an alternative.

------------------------------
Robert Berendt IBMChampion
Business Systems Analyst, Lead
Dekko
Fort Wayne
------------------------------

According to a case I have opened the library QSBMJOBTRK does not get saved when doing a full system save.  Neither with *IBM nor *ALLUSR.  This was done with a somewhat recent PTF. S/R made this change at the request of the database team.

There are journal receivers in this library.  If you have a utility to delete saved receivers, well, that's going to have issues.  This is how I discovered this issue.

Hopefully the library is expendable.  I'll find out later this year when I do a system migration.

I'm being led to believe you can save the library individually.  But, like, who is going to know that a full system save is going to omit certain libraries?  I already know that IBM can flag IFS directories with Not to be saved and makes frequent use of that for directories containing expendable log files which often cause issues with locks during save while active.  Didn't know that IBM was going to start omitting libraries too.

As a side note for those using QSYS2.JOURNAL_RECEIVER_INFO:  SAVE_TIMESTAMP does not get updated for journal receivers in the *IBM type libraries for the same reason that object save date doesn't get updated on those objects in DSPOBJD.  Try to use STATUS and DETACH_TIMESTAMP as an alternative.

Whether this helps or not, the above is documented here -> https://www.ibm.com/docs/en/i/7.4.0?topic=procedure-submitted-job-tracker.  Based on this, it does look like your jobq info related to this would get restored

According to a case I have opened the library QSBMJOBTRK does not get saved when doing a full system save.  Neither with *IBM nor *ALLUSR.  This was done with a somewhat recent PTF. S/R made this change at the request of the database team.

There are journal receivers in this library.  If you have a utility to delete saved receivers, well, that's going to have issues.  This is how I discovered this issue.

Hopefully the library is expendable.  I'll find out later this year when I do a system migration.

I'm being led to believe you can save the library individually.  But, like, who is going to know that a full system save is going to omit certain libraries?  I already know that IBM can flag IFS directories with Not to be saved and makes frequent use of that for directories containing expendable log files which often cause issues with locks during save while active.  Didn't know that IBM was going to start omitting libraries too.

As a side note for those using QSYS2.JOURNAL_RECEIVER_INFO:  SAVE_TIMESTAMP does not get updated for journal receivers in the *IBM type libraries for the same reason that object save date doesn't get updated on those objects in DSPOBJD.  Try to use STATUS and DETACH_TIMESTAMP as an alternative.

That link just goes to the general 7.4 documentation.

Whether this helps or not, the above is documented here -> https://www.ibm.com/docs/en/i/7.4.0?topic=procedure-submitted-job-tracker.  Based on this, it does look like your jobq info related to this would get restored

According to a case I have opened the library QSBMJOBTRK does not get saved when doing a full system save.  Neither with *IBM nor *ALLUSR.  This was done with a somewhat recent PTF. S/R made this change at the request of the database team.

There are journal receivers in this library.  If you have a utility to delete saved receivers, well, that's going to have issues.  This is how I discovered this issue.

Hopefully the library is expendable.  I'll find out later this year when I do a system migration.

I'm being led to believe you can save the library individually.  But, like, who is going to know that a full system save is going to omit certain libraries?  I already know that IBM can flag IFS directories with Not to be saved and makes frequent use of that for directories containing expendable log files which often cause issues with locks during save while active.  Didn't know that IBM was going to start omitting libraries too.

As a side note for those using QSYS2.JOURNAL_RECEIVER_INFO:  SAVE_TIMESTAMP does not get updated for journal receivers in the *IBM type libraries for the same reason that object save date doesn't get updated on those objects in DSPOBJD.  Try to use STATUS and DETACH_TIMESTAMP as an alternative.

thanks..hate it when it does that...let's try the 7.5 version  - this should work Submitted Job Tracker - IBM Documentation

the same holds true for 7.4 though....

That link just goes to the general 7.4 documentation.

Whether this helps or not, the above is documented here -> https://www.ibm.com/docs/en/i/7.4.0?topic=procedure-submitted-job-tracker.  Based on this, it does look like your jobq info related to this would get restored

According to a case I have opened the library QSBMJOBTRK does not get saved when doing a full system save.  Neither with *IBM nor *ALLUSR.  This was done with a somewhat recent PTF. S/R made this change at the request of the database team.

There are journal receivers in this library.  If you have a utility to delete saved receivers, well, that's going to have issues.  This is how I discovered this issue.

Hopefully the library is expendable.  I'll find out later this year when I do a system migration.

I'm being led to believe you can save the library individually.  But, like, who is going to know that a full system save is going to omit certain libraries?  I already know that IBM can flag IFS directories with Not to be saved and makes frequent use of that for directories containing expendable log files which often cause issues with locks during save while active.  Didn't know that IBM was going to start omitting libraries too.

As a side note for those using QSYS2.JOURNAL_RECEIVER_INFO:  SAVE_TIMESTAMP does not get updated for journal receivers in the *IBM type libraries for the same reason that object save date doesn't get updated on those objects in DSPOBJD.  Try to use STATUS and DETACH_TIMESTAMP as an alternative.