• AS400 DB2 and IBM Integration Bus

    From Pasqualino Imbemba@21:1/5 to All on Fri Oct 16 08:25:33 2020
    Hi everyone,

    I have a DB2 on an AS400 system. The DB2 is structured via DDS paradigm.
    I need to connect to its data: I know I can use SQL via JDBC/JTOpen, but
    some of the tables are seralized in binary format.

    I was wondering if using the IBM Integration Bus (ESB) would be helpful
    in getting the desired CRUD access to those tables via REST or SOAP. I
    know this kind of transformation is natural of Enterprise Service Buses,
    but I'm concerned about the serialized tables (contained in a
    non-serialized one): Will deserialization come out of the box or is it necessary to apply some transformation logic?

    Thanks
    #pasquale

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jon.f.paris@gmail.com@21:1/5 to p.im...@gmail.com on Fri Oct 16 08:08:16 2020
    On Friday, October 16, 2020 at 2:25:37 AM UTC-4, p.im...@gmail.com wrote:
    Hi everyone,

    I have a DB2 on an AS400 system. The DB2 is structured via DDS paradigm.
    I need to connect to its data: I know I can use SQL via JDBC/JTOpen, but some of the tables are seralized in binary format.

    I was wondering if using the IBM Integration Bus (ESB) would be helpful
    in getting the desired CRUD access to those tables via REST or SOAP. I
    know this kind of transformation is natural of Enterprise Service Buses,
    but I'm concerned about the serialized tables (contained in a
    non-serialized one): Will deserialization come out of the box or is it necessary to apply some transformation logic?

    Thanks
    #pasquale
    What you are saying frankly makes no sense. Perhaps if you posted the DDS definition of the table we could offer suggestions. Alsop be nice to know what platform you are trying to access the data from.

    But simply put - any "file" on the IBM i (there hasn't been an AS/400 for about 20 years) is a table and can be accessed via SQL. There is within the capabilities of DDS nothing that I can think of that would equate to a "serialized table" which is why
    we need to see what you are talking about and also to know what you are trying to extract.

    Your task should be simple ...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pasqualino Imbemba@21:1/5 to All on Mon Oct 19 07:44:27 2020
    Am 16.10.20 um 17:08 schrieb jon.f...@gmail.com:

    #pasquale
    What you are saying frankly makes no sense. Perhaps if you posted the DDS definition of the table we could offer suggestions. Alsop be nice to know what platform you are trying to access the data from.

    This is the DDL of the table KL11. KL11FLD is the column that contains
    those other tables I need access to.

    Create Table KL11 (
    KL11SER CHAR(3)
    ,KL11TAB CHAR(8)
    ,KL11ELE CHAR(8)
    ,KL11ELS CHAR(4)
    ,KL11PRG NUMERIC(2)
    ,KL11DDS CHAR(8)
    ,KL11FLD VARCHAR(3807)
    );

    I do not know what kind of encoding it uses and which IBM i procedure is
    used to get those other tables stored. My question: Depending on this
    (IBM i) procedure, would an integration via IBM ESB automate
    encoding/decoding if I integrate via REST instead and leave
    serialization to the ESB?


    But simply put - any "file" on the IBM i (there hasn't been an AS/400 for about 20 years) is a table and can be accessed via SQL. There is within the capabilities of DDS nothing that I can think of that would equate to a "serialized table" which is why
    we need to see what you are talking about and also to know what you are trying to extract.

    Your task should be simple ...


    Yes, I know and accessed via JDBC to a DDS organized DB2 earlier. It's
    the first time I encounter such a serialization pattern. I was told this
    yields from the 80ies, where DBMS was limited in I/O access.

    Thanks
    #pasquale

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jon.f.paris@gmail.com@21:1/5 to p.im...@gmail.com on Tue Oct 20 07:01:32 2020
    On Monday, October 19, 2020 at 1:44:30 AM UTC-4, p.im...@gmail.com wrote:
    Am 16.10.20 um 17:08 schrieb jon.f...@gmail.com:
    #pasquale
    What you are saying frankly makes no sense. Perhaps if you posted the DDS definition of the table we could offer suggestions. Alsop be nice to know what platform you are trying to access the data from.
    This is the DDL of the table KL11. KL11FLD is the column that contains
    those other tables I need access to.

    Create Table KL11 (
    KL11SER CHAR(3)
    ,KL11TAB CHAR(8)
    ,KL11ELE CHAR(8)
    ,KL11ELS CHAR(4)
    ,KL11PRG NUMERIC(2)
    ,KL11DDS CHAR(8)
    ,KL11FLD VARCHAR(3807)
    );

    I do not know what kind of encoding it uses and which IBM i procedure is used to get those other tables stored. My question: Depending on this
    (IBM i) procedure, would an integration via IBM ESB automate encoding/decoding if I integrate via REST instead and leave
    serialization to the ESB?

    But simply put - any "file" on the IBM i (there hasn't been an AS/400 for about 20 years) is a table and can be accessed via SQL. There is within the capabilities of DDS nothing that I can think of that would equate to a "serialized table" which is
    why we need to see what you are talking about and also to know what you are trying to extract.

    Your task should be simple ...

    Yes, I know and accessed via JDBC to a DDS organized DB2 earlier. It's
    the first time I encounter such a serialization pattern. I was told this yields from the 80ies, where DBMS was limited in I/O access.

    Thanks
    #pasquale
    I sent this yesterday but it apparently didn't make it for some reason.

    Interesting.

    You need to look at the code that currently progresses the data.

    To my knowledge, which goes back to the 80s and before, there was never any "native" support for any such thing. In fact VarChar is (in those terms) a relatively new option that was not available in the 80s on the IBM i or its predecessors.

    So that leaves us with a number of possibilities. My best guess is that this may have originated on a mainframe and be a varchar representation of a varying length record. Ah! Is this a COBOL shop? If so that would explain it as this is how variable
    length records were implemented for COBOL. A number of fixed length columns followed by one huge varchar that contains a variable repeating number of a single column or structure.

    Either way you will need to have the original layout of the data which can only be obtained from program source unless you know roughly what is supposed to be in there and can work it out from the content.

    If you can get the code I will gladly help you make sense of it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)