Results 1 to 7 of 7
  1. #1
    Join Date
    Mar 2004
    Location
    Spain
    Posts
    4

    Unhappy Unanswered: DB2 UDB unload problem

    I need to unload a DB2 UDB table (v8.1 ESE for AIX) in "raw" format (the same way a DB2 OS/390 does), that is: with the internal representation of the data, without any delimiter, header, tag or something more. The supported formats that appear in the manual only include: IXF, DEL and ASC formats, and no one of these formats are valid for us.

    Does exist any manner to do this without to build an external program?

    Thank you,

  2. #2
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650

    Re: DB2 UDB unload problem

    That is not possible AFAIK ....

    Cheers
    Sathyaram

    Originally posted by erguez
    I need to unload a DB2 UDB table (v8.1 ESE for AIX) in "raw" format (the same way a DB2 OS/390 does), that is: with the internal representation of the data, without any delimiter, header, tag or something more. The supported formats that appear in the manual only include: IXF, DEL and ASC formats, and no one of these formats are valid for us.

    Does exist any manner to do this without to build an external program?

    Thank you,
    Visit the new-look IDUG Website , register to gain access to the excellent content.

  3. #3
    Join Date
    Mar 2004
    Location
    Spain
    Posts
    4

    Unhappy

    Thank you for yor early response.

    I'm very surprised that nobody has the same problem, becasuse I think that always you have to process a DB unload programatically (C/C++, COBOL, Java, etc..) in a batch environment you prefer to have all the data in its internal representation; otherwise you have to transform all the data to its implicit representation to manage them.

    So, finally, the DB2 must to transform the data to make the unload file in the external representation and the program must to reverse this operation in order to use the data.... and this sounds very strange and non-performance to me.

  4. #4
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    I'm afraid, I can't make out what you are planning to do ...

    If you brief your requirement, someone here may be able to give you a suggestion

    Cheers
    Sathyaram
    Visit the new-look IDUG Website , register to gain access to the excellent content.

  5. #5
    Join Date
    Mar 2004
    Location
    Spain
    Posts
    4

    Unhappy

    Ok. You're right. This is a brief of my problem:

    I've got a lot of COBOL programs, in a mainframe platform, that are ready to batch process DB2 unload files. Batch processes are very time and resources consuming and always must be done with files, and not directly against the DBRM (... I think everybody knows what I talking about, and I think I don´t need to give more details...).

    These programs have a copy with the structure of the records of the output files; this copy could be the DCLGEN obtained for each table to download; this is an example:

    ************************************************** **
    * DCLGEN TABLE(XX.VCA4801_PARAMCAR)
    * LIBRARY(XX.PROGRAM.COPYS(CCA48010))
    * ACTION(REPLACE)
    * LANGUAGE(COBOL)
    * QUOTE
    ************************************************** **
    EXEC SQL DECLARE VCA4801_PARAMCAR TABLE
    ( DIEVISTA DECIMAL(4, 0) NOT NULL,
    DIECOBCL DECIMAL(4, 0) NOT NULL,
    INDINTDE CHAR(1) NOT NULL,
    DIERETEF INTEGER(4) NOT NULL,
    FECOVALI DATE NOT NULL,
    USUARIO CHAR(8) NOT NULL,
    TSULMOD TIMESTAMP NOT NULL
    ) END-EXEC.

    ************************************************** *****
    * COBOL DECLARATION FOR TABLE XX.VCA4801_PARAMCAR
    ************************************************** *****
    01 DCLVCA4801-PARAMCAR.
    10 DIEVISTA PIC S9(4)V USAGE COMP-3.
    10 DIECOBCL PIC S9(4)V USAGE COMP-3.
    10 INDINTDE PIC X(1).
    10 DIERETEF PIC S9(4)V USAGE COMP.
    10 FECOVALI PIC X(10).
    10 USUARIO PIC X(8).
    10 TSULMOD PIC X(26).
    ************************************************** ******

    In this case, the COBOL program expect records of 3+3+1+2+10+8+26=53 bytes length, without delimiters, headers, and with all the data in its internal form.

    So, the problem is that an IXF, ASC or DEL format must be transformed to acomplish the previous structure of fields (with another program, for example). Again, this would be a very time and resources consuming.... and what we are doing finally is a DB2 task!!!

    Another posibility is to make a dynamic SQL COBOL program to unload tables with the required structure... but in that case we are not using the DB2 utilities (EXPORT, HPU, IMPORT, LOAD) and the final result will be a bad designed, low performace, hard to update application.

    Well, I think that someone who have a programatically batch processing of an unload table might had the same problem, and I'm wondering how they solved it (I suppose IBM have a PTF, a workaround, or something like that...).

    Could someone help me? Every idea will be appreciated.

    Thanks in advance.

  6. #6
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    Is DDF Configured in your shop ?

    You can use cross-loader to extract data from Unix systems ... There is a limitation (32 K, I think) on the the width of each row ...

    I'm trying this out at the moment, and will post if I'm able to do this ...

    Cheers
    Sathyaram
    Visit the new-look IDUG Website , register to gain access to the excellent content.

  7. #7
    Join Date
    Mar 2004
    Location
    Spain
    Posts
    4

    Unhappy

    Sathyaram,

    Yes, we have DDF in our installation, but, wait a minute, the objetive of the project is to migrate all the OS/390 infraestructure to an AIX platform. This migration includes the movement of the DB2 and COBOL programs form the OS/390 to the new AIX platform.

    So, finally, we only have an AIX environment, with DB2 UDB and COBOL programs running in AIX. Unloads and execution of COBOL programs will occur in the AIX machine, and hopefully with the OS/390 server turned off.

    By now, we are developing the migration process, and doing the first tests with COBOL and DB2 in the new platform.

    Regards,

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •