Author Topic: Merge existing AIX library server into an existing z/OS library server  (Read 4396 times)

Benny N. Ormson

  • Jr. Member
  • **
  • Posts: 20
    • View Profile
I may have the need to merge an existing AIX library server into an existing z/OS library server.  The idea is to leave the existing AIX object servers in place and reference those objects from the z/OS library server.  If you have any knowledge on how this might be done I would appreciate hearing your thoughts.
Benny N. Ormson
OnDemand Architect

Steve C

  • Guest
Re: Merge existing AIX library server into an existing z/OS library server
« Reply #1 on: October 24, 2006, 09:42:20 AM »
I've migrated a full ODv7 system from AIX to z/OS Object and Lib server  (Plus Java and C application code).

If just doing the lib part then it is relatively straight forward - however any BIGINTs in UDB on AIX will need to be cast/converted to INTs on z/OS.
(We had this in our application code, I cannot remember if we had this in the ODv7 code.
We attempted to move the tables initially via Db2 connect, but the volume of the largest tables tended to cause problems with resource limits.
In the end we unloaded via utilities (run as part of unix scripts); FTPd (driven by jobs from the mainframe) then loaded via Db2 load utilities.
Ocopy was used to transfer the data from the USS side of the world to z/OS.
The unload needed to be in an 'externalised' text  format to allow correct conversion during the FTP. This however means that you need
to take care of the load cards to match on the z/OS side (can be generated by doing an unload on the target system).
In doing this I remember we made the error of having leading and trailing spaces on some of our DOC_NAMEs and so these needed to be trimmed.

If you drag and drop the SG,AG,APP definitions (etc) in the admin client then no need to transport this data via FTP, and then also no conflict with
AG IDs in the meta info.
In the ARSGEG table you will need to still copy / create the references to the index tables to be loaded and also need to create these index tables
with the correct name. But this is really peanuts.

One point that bit us a year or 2 down the line was the move to Db2v8 on z/OS. With the ODBC driver there are additional codes which identify
when there has been possible code page conversion errors (between a DB2 system in cp500 and an Odv7 server in cp1047).
The cuase for us was German ?,? etc in description text in the APP and AG. The ODBC driver reported these as possible errors and ODv7
did not know (at the time, maybe 7.1.6.2 knows better) what to do with these codes and so treated them as errors.
This will hit even if you are not in full function mode.
So long as you do not have these funny characters then you should be ok. Even in the admin tables it is not so traggic as it is easy to update with
queries and once done then you can forget it.
You have more issues if you have funny characters in the key values in an index table. We used REXX utilities in the case large volues of data needed
to be corrected before doing the loads.




Also we had to include an additional steplib to help the server identify the correct code page to use. This is some speciallity of C that if this is not specified then this can cause problems.
But I suspect you may hit this issue if you start on z/OS, not just migrate. Just to say, this did seem to cause us strange errors in code page conversion.

XXSTEPNAME EXEC PGM=ARSSOCKD,PARM=('NAME arssockd'),
XX           REGION=0M,TIME=NOLIMIT                 
XXSTEPLIB  DD DISP=SHR,DSN=SYS5.DB2.SDSNEXIT.DB20   

DSN=SYS5.DB2.SDSNEXIT.DB20   contains members:-
   DSNHDECP
   DSNHMCID



Hope the above ramble is of use