Re: V7R1 SQL Testing Issue

On 02-Jun-2010 18:05, CRPence wrote:

On 02-Jun-2010 15:13, Richard Schoen wrote:

Getting an error creating long table names via SQL in V7R1.

Can someone try this SQL on V7R1 and let me know if it works for
them. I just applied CUM PTF's and still does not work.

Throws an SQL0901 error with CPF327E Internal error type 4204.
Works fine with short table name.

SQL statement:
create table QGPL/LONGNAME123456
(PageNumber dec(5, 0))

Here's the joblog info:
CPF327E - Alternative name for file LONGN00001 not allowed.

I can change my code to use 10 char file names, but this should
work with long file names.

Any feedback appreciated.

The status of the *DBXREF and its effect on SQL database file
/long name/ support is specific to your system\database.
That is, what transpires on any other system for the same
request is moot.

Perform RCLDBXREF with the option to /check or report/ *status*
about the /database cross-reference/ which are the basis for some
of the SQL catalogs. Presumably the /long name/ validity checking
for the QGPL library is not capable of being ensured for
uniqueness of the name due to some prior error. The rc4204 would
describe that error; I have not searched for an incident
describing that RC.

OK... /moot/ only with the exception of *horrible* defects like the following, for which it seems possibly, an attempt to create a duplicate long-name file into any library [i.e. SQL request to CREATE receives -601 or SQL0601 which logs the /normal/ condition symptom msgCPF327E rc2] then prohibits any future long-name file create requests into the same library:
http://www-01.ibm.com/support/docview.wss?uid=nas2fd863010e90edaee8625770c004ba294
http://www-01.ibm.com/support/docview.wss?uid=nas30c634ad2e556e4ba8625770c004cedf3

How such a defect could possibly exist in a base-release is unfathomable to me, if indeed it is in the base release and so blatantly FUBAR. And if with that highly negative effect, that its APAR would not then also be marked HIPer, would be mind-numbingly shocking. So anyhow, be sure the preventive R710 PTF SI39657 is applied before creating long-name TABLE [possibly INDEX, VIEW, and ALIAS as well?], possibly only when including CONSTRAINT PRIMARY KEY -- the APAR is [typically] lacking in specifics given for the problem origin, as well as failing to record the details for the message in symptom-string format or otherwise. Ughh.

The RCLDBXREF *CHECK request would report QGPL as being in-error for the scenario described in the APAR, after a prior CREATE TABLE encountered a valid condition of msgSQL0601; as any future request to CREATE TABLE ThatLib/AnyLongFileName would also fail. The recovery [which does not require restricted state nor the console] for a specific library being in-error is RCLDBXREF *FIX LIB(ThatLib) as described in the PTF cover letter.

Regards, Chuck