Definitely sounds like commitment control. Either set commitment control to *NONE or start journaling on the table and issue a COMMIT or the table create will be rolled back
Thanks,
Tommy Holden
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Justin Taylor
Sent: Friday, September 7, 2018 8:44 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Is the table created or not?
QTEMP? Commitment control? Those are about the only things that come to mind.
-----Original Message-----
From: John Yeung [mailto:gallium.arsenide@xxxxxxxxx]
Sent: Thursday, September 06, 2018 5:55 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Is the table created or not?
I am at my wits' end. Within a large application, I've got some SQL which creates a table (which will be used for output later) by selecting columns from another table (which serves as a kind of data dictionary of all possible columns).
This has been working for years, and now when I make some changes to the application, it doesn't work anymore.
We don't have journaling, so the SQL always gives me
SQLState: 01567, Error code: 7905
Table MYFILE in MYLIB created but was not journaled.
But that has always been the case; the application would simply carry on despite the lack of journaling, and make use of MYLIB/MYFILE just fine.
However, with my recent changes, the table doesn't even seem to be created. I get the same message (that it's created but not journaled), yet the table's not there.
Maybe more precisely, the *file* is not there. Immediately after attempting to create the table, I check for existence of the file object, and the result is negative. But I can still query the table with SQL to get a row count (which will be zero). A table that doesn't exist shouldn't be able to be queried at all.
I know I haven't given many details and no code at all, but it's in iSeriesPython. I guess I'm mainly wondering if anyone's ever encountered anything like this before, or has any ideas of what to look for.
Oh, I should mention that when I pull the suspect code out of the application and into a testing stub, or into STRSQL, it works fine.
And as I said, it's still working in the current version of the application, just not in my new, modified version.
John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fmidrange-l&data=02%7C01%7CTommy.Holden%40tmcat.com%7Cb94760f5013a4402aa5a08d614c80716%7C7bedfe4f5ee143529ded95e9c966aa39%7C0%7C0%7C636719246675123738&sdata=0a8qryWgG4Atp0wXQNg%2FCzUeFegpXLgjV%2BIm2s%2BIoMk%3D&reserved=0
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fmidrange-l&data=02%7C01%7CTommy.Holden%40tmcat.com%7Cb94760f5013a4402aa5a08d614c80716%7C7bedfe4f5ee143529ded95e9c966aa39%7C0%7C0%7C636719246675123738&sdata=0awVo13KV6Cy%2F4J%2FNNCUw237z1tjZlxkqQ2tn9DlfR8%3D&reserved=0.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Famzn.to%2F2dEadiD&data=02%7C01%7CTommy.Holden%40tmcat.com%7Cb94760f5013a4402aa5a08d614c80716%7C7bedfe4f5ee143529ded95e9c966aa39%7C0%7C0%7C636719246675123738&sdata=n9rzqFqzXw4u%2FqvwXQFEBMPecrJ4Byu2Wj%2FQmSBOjuk%3D&reserved=0
midrange.com
