New CUM Level 8305 is giving me SQL Headaches
We recently upgraded to a new machine at OS Level V5R4 CUM 8305. Our old machine was also at V5R4 but the CUM level was only 8057. Ever since the upgrade, I have been having SQL Problems. My latest problem involves trying to update a QTEMP File that was built using CRTPF and specifying a record length. When my CLLE tries to update the temporary file, the system issues a message indicating the file is journaled and therefore the update action is invalid. I have commitment control set to *NONE on the RUNSQLSTM. To correct the issue I added a SET Statement to the SQL Source Member. (SET TRANSACTION ISOLATION LEVEL NO COMMIT) This also caused the CLLE to abort with a message indicating the Commit level was not at a break point.
I have been surfing the net in search of an answer, but have had no luck. Any suggestions or ideas would be greatly appreciated.
Software/Hardware used:
Software/Hardware used:
ASKED:
April 7, 2009 2:16 PM
UPDATED:
April 8, 2009 1:25 PM
Answer Wiki:
Hi,
My first thought goes to libraries and library lists - I'm sure I read somewhere that there were changes in how libraries and lists were handled with regard to SQL. Do you have the library name specified in your SQL statement? Is it possible that there is indeed a file with the same name in another library with journalling active?
Regards,
Martin Gilbert.
The SQL does have the Library Name specified for the File. I search the entire system looking for another file of the same name but found none. For now I gave in and Added a STRJRNPF statement for the file prior to applying the SQL to it. I hope to eventually find out however why the functionality changed. Thanks for you input Martin.
Frank Carpenter
To see all answers submitted to the Answer Wiki: View Answer History.
RSS - Discussions Help
Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
