IBM i Global

 View Only
  • 1.  ObjectConnect over TCP/IP

    InnerCircle
    Posted Tue July 26, 2022 10:08 AM
    Edited by Kristen Park Wed July 27, 2022 10:01 AM

    We want to setup ObjectConnect over (secure) TCP/IP
    (we have it already running with SNA over TCP/IP).

    The IBM i documentation is very limited en certain HTTP links are dead. 
    (For example click on the link 'ObjectConnect Server' in step 1)

    Does anyone has an step by step manual or link to configure this?

    Setting up your system to use ObjectConnect

    Ibm remove preview
    Setting up your system to use ObjectConnect
    After you have installed ObjectConnect, you must set up your systems to run ObjectConnect. You perform some tasks only once. You perform other tasks regularly to prepare for ObjectConnect commands.
    View this on Ibm >





    ------------------------------
    H Haken
    Pantheon Automatisering B.V.
    Netherlands
    ------------------------------


  • 2.  RE: ObjectConnect over TCP/IP

    Posted Tue July 26, 2022 08:20 PM
    Edited by Satid Singkorapoom Tue July 26, 2022 08:23 PM
    Dear Heye

    If you Google with "ibm i objectconnect tcp", you will find the following IBM Support Information that guides you through the setup steps you need : https://www.ibm.com/support/pages/object-connect-now-runs-over-tcpip-server-strtcpsvrobjc



    ------------------------------
    Right action is better than knowledge; but in order to do what is right, we must know what is right.
    -- Charlemagne

    Satid Singkorapoom
    ------------------------------



  • 3.  RE: ObjectConnect over TCP/IP

    Posted Wed July 27, 2022 01:53 AM
    > ... it is strongly suggested you assign a certificate ...
    Above sentence is somewhat misleading because it is necessary to assign a certificate.

    One of my customer decided to stay with EE because it is much easier to configure and they use ObjectConnect on secured N/W.

    ------------------------------
    Hideyuki Yahagi @ Japan
    ------------------------------



  • 4.  RE: ObjectConnect over TCP/IP

    Posted Wed July 27, 2022 11:41 PM
    Edited by Satid Singkorapoom Thu July 28, 2022 01:43 AM
    Using EE rather than native TCP/IP has a disadvantage of under-the-cover performance overhead in the data communication part (due to longer SW path length from EE to TCP/IP) of SAVRST operations.  The larger the amount of data involved, the more the accumulated overhead and therefore the longer the time it takes to run each SAVRST.... operation.  If SAVRST operations involve quite a large amount of data being transferred and the fastest operation is needed, using native TCP/IP support potentially delivers a better overall run-time due to shorter SW path length (No EE layer).   In many of my customers, I see that using self-signed certificates has been the most popular approach they adopt for their "internal" operations and SAVRST is mostly internal type.

    ------------------------------
    Right action is better than knowledge; but in order to do what is right, we must know what is right.
    -- Charlemagne

    Satid Singkorapoom
    ------------------------------



  • 5.  RE: ObjectConnect over TCP/IP

    Posted Fri July 29, 2022 02:12 AM
    Hallo Heye,

    After recently upgrading to IBM i 7.4 and finally getting around to configuring ObjectConnect over IP, one helpful source of information I found is  PDF file for ObjectConnect .
    Granted I found that this PDF is currently only available from IBM i 7.5 Documentation, but is still relevant.

    In the end we found the process to configure ObjectConnect over IP straightforward, even with having to assign a certificate to the ObjectConnect Server. We used a company generated certificate but the process to import and then assign was easy.  
    If you follow the steps as per the link in Satid's post, you should find it is not difficult. 

    Couple of points:
    - When you run the command CHGOBJC to create the ObjectConnect server and user profile QOBJC, it creates the file QUSRSYS/QATMOBJC which is the ObjectConnect config file. 
    One thing I am trying to find more info on are the parameters DCSENDSIZE and DCRECVSIZE which default to 262144 (256K) and 8388608 (8MB) respectively.          
    @Satid, do you have any information on the relevance of these two parameters please?

    - We have also configured Virtual Ethernet for the use of SAVRST* commands between LPARs on the same Power9 server. But using Virtual Ethernet we found the transmission speed quite slow, at around 199Mb/sec. But using FTP we got just over 900 Mb/sec.  
    More experimenting required. IBM does state however that ObjectConnect is not a "performance enhancement product". See ObjectConnect/400 - Troubleshooting Mini-Guide

    Regards,
    Jozsef




    ------------------------------
    Jozsef Torok @ New Zealand
    ------------------------------



  • 6.  RE: ObjectConnect over TCP/IP

    Posted Fri July 29, 2022 03:49 AM
    Edited by 英幸 矢作 Fri July 29, 2022 03:50 AM
    > But using Virtual Ethernet we found the transmission speed quite slow, at around 199Mb/sec. But using FTP we got just over 900 Mb/sec. 

    Have you tried Jumbo-Frame?

    Specifying 8,996 for MTU (frame size) slightly improved FTP throughput for stream files (virtual Ethernet on IBM i 7.1).
    ** Notes ** It is recommended to use a smaller MTU (1,496) when transferring SAVF via FTP, as it took twice as long with Jumbo-Frame.

    In other words, throughput depends on the transfer protocol and network configuration.
    You may try Jumbo-Frame for ObjectConnect, which transfers data in 32K block units.



    ------------------------------
    Hideyuki Yahagi @ Japan
    ------------------------------



  • 7.  RE: ObjectConnect over TCP/IP

    Posted Fri July 29, 2022 09:31 AM
    Edited by Satid Singkorapoom Fri July 29, 2022 09:44 AM
    Dear Jozsef

    I cannot find any information about QATMOBJC config file and I do not think you will gain a benefit in trying to understand if you can tweak it for a purpose (performance related, I assume). 

    As for your comment on data transfer speed of 199Mb/sec  VS 900Mb/sec, did you use SAVRST... command to see the lower speed (calculated manually) while you used FTP to manually send just the save file image (of the same set of objects used by SAVRST) over the same virtual ethernet and saw faster speed (as reported by FTP message)?  

    If this is the case, I hope you realize from the troubleshooting mini-guide that SAVRST.. sends all the data blocks (one by one) of the source object(s) to the target LPAR without using any save file at all. I see that there is no meaningful point to compare SAVRST... operation's speed against FTP of save file image over the same communication link because they do not employ the same data transfer method, not to mention that SAVRST performs a complete end-to-end operation while FTP does not.  You should trust that both methods should get the same data transfer speed over the exact same link - as far as data transfer part goes.   The value of Opticonnect is that it helps reduce the user's burden of having to write a program to do this end-to-end operation by providing just a single command to do this.  

    If this is not the case, please explain more on why you try to compare SAVRST against FTP. 

    As for the indication in the mini-guide that Opticonnect is not a performance enhancement product, this statement was made in a past context that had nothing to do with comparing between SNA version against the new TCP/IP one.    In fact, I see that if you are interested and have time, you can compare the performance of SAVRST between the SNA version against the TCP one. Be sure to try different data sizes to check the different in their performance. 

    ------------------------------
    Right action is better than knowledge; but in order to do what is right, we must know what is right.
    -- Charlemagne

    Satid Singkorapoom
    ------------------------------