Logical file-to journal or not to journal
Last Post 06 Jan 2011 04:52 PM by Lynne Noll. 3 Replies.
AddThis - Bookmarking and Sharing Button Printer Friendly
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Bluemax86
New Member
New Member
Posts:54

--
05 Jan 2011 10:06 PM
We have an RPG program that was working fine in our QA environment, then suddenly it throws an error. When I looked at the joblog, the error was
Member PSARREL0 not journaled to journal *N
File PSARREL0 is a logical, when I displayed the logical via DSPFD command, it said the access path was journaled. But I could not see if the member was journaled. So I performed an ENDJRNAP and then a STRJRNAP. This seemed to fix the problem. But then I wondered why in the world I needed the access path journaled when the physical file was journaled. So I found Don Zimmerman's article and learned about "covert" logical journalling. So I then, just for grins, ended the journalling on the logical file again and tried the program. It worked fine without the logical file being specifically journaled. So my question is this - is there any problems with ending journaling on a logical file when a program encouters an error? I am assuming if you end journalling on the logical the system will continue it's covert operations when it feels like it needs to. Thanks
lostromich
Veteran Member
Veteran Member
Posts:1315

--
06 Jan 2011 12:07 PM Accepted Answer
I think the error message you got and STRJRNAP/ENJRNAP commands are not related. What you should do is to make sure PF is journalled using STRJRNPF command or compile program with COMMIT *NONE. Please double check if you are looking at correct PF in correct Library while doing the test.
Bluemax86
New Member
New Member
Posts:54

--
06 Jan 2011 01:53 PM Accepted Answer
The first thing I checked was the physical file and it is journaled and I do want the program to be compiled WITH commitment control, that's the whole point of having the physical journaled. If it was something else then shouldn't the error still occur after I stopped journalling on the logical??
Lynne Noll
Senior Member
Senior Member
Posts:6567

--
06 Jan 2011 04:52 PM Accepted Answer
I don't think the journalling of the access path has much to do with journaling the data and commit control. It is just so the system can keep track of changes that affect the access path so it can be recovered faster when the system goes down abnormally. I remember when bringing the machine back up took all day, because all the access paths were rebuilt from scratch. I am not sure if this message was the cause of the failure (RPG under commit control, especially RPG rather than SQL commit control has a lot of points of failure.) I think it is more likely that the member in the messaging is just the member that was convenient for the person composing the message at IBM to get (members of updatable logicals default to the name of the view), and you had an issue with the journalling in your QA environment. Which got fixed, maybe not by you.
You are not authorized to post a reply.

Acceptable Use Policy