Fwd: Re: possible problem with OBJECT_STATISTICS

This is related to the PMR that Rob opened up about the long and short name should not match. I had asked Scott Forstie at IBM about it.

He told me that the original design was to find non-SQL objects, so the long name was not part of that. Below is what he told IBM Services, and Rob, you probably already have this - or may have posted it. I do have Scott's permission to post this in this forum.

Scott sees it as an enhancement and will talk about it in the next TR.

Enjoy!!
Vern

------------------------------------------------------------------------

/We have improved OBJECT_STATISTICS() such that the associated SQL name appears within OBJLONGNAME./

/PTF '5761SS1 V6R1M0 SI56082'/
/PTF '5770SS1 V7R2M0 SI56084'/
/PTF '5770SS1 V7R1M0 SI56083'/

/The customer needs to understand that OBJECT_STATISTICS() has been enhanced to derive the associated SQL long name through examination of the internals of the base object./
/We are not querying the various SQL catalogs to find the associated detail. Therefore, our implementation should perform well./

/Usage details:/
/OBJLONGNAME matches the behavior of DB2 for i catalogs, delimited names are returned without the delimiters. If the user wants to have a delimited name, they can wrapper OBJLONGNAME with the QSYS2.DELIMIT_NAME() function./
/For external routines, we return the routine name we find within the program or service program. Its possible, but unlikely, that this name won't match the detail found in the SYSROUTINE catalog./
/For external routines, if we find multiple routine names within the program or service program, we will return the name if all the names are identical (overloaded procedure or function). If the names differ, we return NULL./

/There are two cases where we continue to return NULL, because the SQL name is not stored within the base object. We will consider supporting these cases in a future release./

1. /SQL Triggers/
2. /External routines built over OPM programs/