What is being journaled in a library in iSeries

750 pts.
Tags:
AS 400
AS/400 journaling
iSeries
I have a large library on my iSeries and want to know all objects in the library that are being journaled. What is the command(s) I can use to accomplish this? I want to create an outfile, then write a short CL to end the journaling then start up journaling again, but in one journal in the library. Thank you.
0

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

Discuss This Question: 7  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TheRealRaven
    Start with this:
    DSPOBJD OBJ( libraryname/*ALL ) OBJTYPE( *ALL ) OUTPUT(*OUTFILE) ...
    The outfile fields ODJRST, ODJRNM and ODJRLB should tell you almost everything you need to know about what is and isn't journalled in that "libraryname". You might also review the object description of the library itself since the STRJRNLIB command can start journaling for all candidate objects at once.

    But before completing your last step, have you determined the performance impact of journaling all objects in a "large library" to a single journal? Are journal changes from multiple objects being recorded concurrently in multiple jobs?
    37,005 pointsBadges:
    report
  • ToddN2000
    Start with Ravens suggestion. My question is what is the purpose to stop then restart the journaling? Journaling must have been turned on for a reason and ending it opens the system up to an auditing nigtmare if you have to prove data changes were made.
    136,490 pointsBadges:
    report
  • Rrbond07
    Our Enterprise Architect wants to start using schemas. From my understanding using this improves performance on the system. However, one of our iSeries engineers, thinking he can accomplish the same thing wants to create a library journal. He wanted me to end journaling on all files in the library, then start journing up again on these objects in the single journal within the library. Using schemas, when creating it - creates the journal and other SQL object that can be used within the library. Once objects are placed within the schema they get journaled to the journal in that library. Files are not journaled outside it's library, but within it. So I have two people who want to accomplish performance improvement, but one not understanding, I think the way it is done or how it really works.
    750 pointsBadges:
    report
  • Splat
    Journaling adds overhead.

    In light of the benefits that's not a bad thing.
    12,915 pointsBadges:
    report
  • GregManzo
    Yes, journalling adds a bit of overhead, but it can improve performance because now the disk write becomes asynchronous. If you are worried about the performance impact, try putting the receivers in a dedicated pool so the heads don't need to move much.
    I'm with Todd, what was the design thinking behind the original journalling and will it break if you start journalling by library? Is commit control being used?
    2,970 pointsBadges:
    report
  • TheRealRaven
    As long as there is application downtime, it's unlikely to cause any audit problems. "Unlikely", but always possible if there's an unexpected issue with a life that crosses over the break between journals.

    Whatever programming does the journal changing, it should log old journal and new journal for each changed object. This log should be kept until after some sufficient length of time passes, weeks at least and probably months for some objects. The old journals should not be deleted either, though most old receivers can be as long as they're backed up. Old journals can be deleted after enough accounting periods have passed.

    Since journalling is already active, future performance issues will likely come from synchronous writes now being forced for multiple objects. Object #2 will now have to wait for journal writes to complete for object #1 before its app can continue, and so on for objects #3, #4, #5, etc. With separate journals, that's less of an issue.

    But journal caching might be an option (separately chargeable feature, reasonably priced if needed for most sites). Read the Journal management and system performance topic for intro to that and other tips.

    As far as performance goes, there are a number of other things that can/should be done before even thinking about journal performance. I'd think in terms of >5% of systems are well tuned, so there's likely plenty of room.
    37,005 pointsBadges:
    report
  • GregManzo
    If changing the journals programatically, you can avoid the risk by locking each object as you go. You need an *EXCL lock anyway so you might as well go: ALCOBJ, ENDJRNPF, STRJRNPF, DLCOBJ for each object as you process the lib.
    2,970 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: