Re: symbolic link to XA tables?

On 15-Jun-2010 12:39, Dean Eggert wrote:

I have a Crystal Reports server set up to report on my XA data
which has been working pretty good. Currently, I'm in the
process of updating XA to 7.8 from 7.7 and need to change the XA
library names to accommodate the new version. Unfortunately, the
Crystal ODBC driver looks for the XA tables in the old LIB name
(ex: AMFLIBA). It's a pain to have to change the ODBC drivers on
the PC clients and then have to change the LIB references for the
Crystal reports. The ODBC drivers are bad enough, but to have to
migrate all of the Crystal report data source over to new 7.8 LIB
names and then republish the changed reports to the Crystal
Server is even worse.

I was hoping to be able to use ADDLNK to create a symbolic link
in QSYS to point to AMFLIBA (ex: CRXA -> AMFLIBA). With a
symbolic link, I could repoint the link to the new XA LIB name.
Evidently, that does not work outside of the IFS. I asked IBM
and they were no help whatsoever. I'm looking to also update to
XA 9 next spring and having to do all of the references over
again is kind of disheartening.

Any suggestions for this problem would be greatly appreciated.

Is there a requirement to fully qualify the references in the first place? Can the *SYS naming or the CURRENT SCHEMA support of the SQL be utilized along with unqualified TABLE\VIEW references to access the appropriate data?

I suppose utilizing the appropriate exit point, the incoming statement could be revised with something like the pseudo-coded request to:
incoming_statement=AMFLIBAtoAMFNewLib(incoming_statement);

Similarly for DML, an appropriate exit point could effect OVRDBF for the various file names, which redirect to either the new library name but with the same file name or perhaps to the library name *LIBL for the same file name [if the library list is also adjusted appropriately].

FWiW:

The database features are implemented using the native file system, and the catalogs for /long name/ support. The /QSYS.LIB File System defines the map to the original\native portion of the Integrated File System, but that is of no consequence to the database, since its implementation effectively knows nothing of [thus does not attempt to locate objects using] the /QSYS.LIB file system.

And, the ODBC is for database access, so a means via the database is required to redirect the database requests. To redirect to an alternate database table [or member], there is the SQL ALIAS or the DDM file; the former is implemented via the latter, but only the former can be referenced in an SQL DML statement. Since ODBC access is SQL database access, an SQL ALIAS should probably suffice to replace existing file names. However the /short name/ must be unique in the library [unique across all *FILE objects], so having both an ALIAS and the original PF\TABLE or LF\VIEW coexist in the original library name is not possible for the short name.

Regards, Chuck