Re: V7R1 SQL Testing Issue

[CRPence <CRPbottle@xxxxxxxxx>]

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