Skip to main content

Uniface 9: any general solution for larger size parameters in 3gl interface ?

  • November 19, 2018
  • 6 replies
  • 0 views
Jan Cees Boogaard

any general solution for larger size parameters in 3gl interface ?

Author: gerd.vassen@gmx.net (gerdvassen)

hello everybody !

I am trying to create a callout 3GL interface (via activate), and in different places I am facing limitations of fixed size parameters due to the nature of how this is handled in Uniface.  I would like to have my functions work independently of the size of the parameters.  The parameters could take 100k or more, even if they most often just take some bytes (please do not ask me to rethink my design, I am looking for a general approach to an ever-returning problem :-)).
I can understand that on a lower level, those fixed packet sizes are necessary, but looking for instance at the UHTTP Uniface component, I can see that Uniface has also found a mechanism to solve this by repeated calls to READ_CONTENT until all the data is read (could probably be handled in a more programmer-friendly way by just doing this internally, but at least there is a way).

Does anybody have had similar or better, more generalized approaches for this issue that could be shared with the community ?

thank you

gerd

    6 replies

    Jan Cees Boogaard

    any general solution for larger size parameters in 3gl interface ?

    Author: gerd.vassen@gmx.net (gerdvassen)

    hello everybody !

    I am trying to create a callout 3GL interface (via activate), and in different places I am facing limitations of fixed size parameters due to the nature of how this is handled in Uniface.  I would like to have my functions work independently of the size of the parameters.  The parameters could take 100k or more, even if they most often just take some bytes (please do not ask me to rethink my design, I am looking for a general approach to an ever-returning problem :-)).
    I can understand that on a lower level, those fixed packet sizes are necessary, but looking for instance at the UHTTP Uniface component, I can see that Uniface has also found a mechanism to solve this by repeated calls to READ_CONTENT until all the data is read (could probably be handled in a more programmer-friendly way by just doing this internally, but at least there is a way).

    Does anybody have had similar or better, more generalized approaches for this issue that could be shared with the community ?

    thank you

    gerd

    Hi Gerd,

    AFAIK, the situation is caused that uniface can not pass a memory pointer to a routine directly,
    so they use buffers in between which in fact have some limits (whatever size it may be).

    SInce the very old days, the 3GL interface offers UFGET and UFGETC to read more from the field.
    But your 3GL has to handle that situation.

    For sure, you can ask CPWR to extend the size of each buffer, but this is only setting the limit to a higher value.

    Success, Uli

    P.S. I am not employed by CPWR, so please ...


    Author: ulrich-merkel (ulrichmerkel@web.de)
    Jan Cees Boogaard

    any general solution for larger size parameters in 3gl interface ?

    Author: gerd.vassen@gmx.net (gerdvassen)

    hello everybody !

    I am trying to create a callout 3GL interface (via activate), and in different places I am facing limitations of fixed size parameters due to the nature of how this is handled in Uniface.  I would like to have my functions work independently of the size of the parameters.  The parameters could take 100k or more, even if they most often just take some bytes (please do not ask me to rethink my design, I am looking for a general approach to an ever-returning problem :-)).
    I can understand that on a lower level, those fixed packet sizes are necessary, but looking for instance at the UHTTP Uniface component, I can see that Uniface has also found a mechanism to solve this by repeated calls to READ_CONTENT until all the data is read (could probably be handled in a more programmer-friendly way by just doing this internally, but at least there is a way).

    Does anybody have had similar or better, more generalized approaches for this issue that could be shared with the community ?

    thank you

    gerd

    hello Uli

    thanx for your reply.
    yes, I am already using UFGETC in some parts.  But  now I want to make a 3GL interface with activate, and here is also a size limitation, which Uniface solves itself by calling back and forth until no more data is left in the internal C buffers used by the the UHTTP component.  I was hoping to get a nice way to solve this generally, probably there is no elegant solution.  Would be nice if CPWR would do just this back and forth calling internally... 

    greetings,

    gerd


    Author: gerdvassen (gerd.vassen@gmx.net)
    Jan Cees Boogaard

    any general solution for larger size parameters in 3gl interface ?

    Author: gerd.vassen@gmx.net (gerdvassen)

    hello everybody !

    I am trying to create a callout 3GL interface (via activate), and in different places I am facing limitations of fixed size parameters due to the nature of how this is handled in Uniface.  I would like to have my functions work independently of the size of the parameters.  The parameters could take 100k or more, even if they most often just take some bytes (please do not ask me to rethink my design, I am looking for a general approach to an ever-returning problem :-)).
    I can understand that on a lower level, those fixed packet sizes are necessary, but looking for instance at the UHTTP Uniface component, I can see that Uniface has also found a mechanism to solve this by repeated calls to READ_CONTENT until all the data is read (could probably be handled in a more programmer-friendly way by just doing this internally, but at least there is a way).

    Does anybody have had similar or better, more generalized approaches for this issue that could be shared with the community ?

    thank you

    gerd

    Hello Gerd,

    What's the maximum amount of data you have to pass to a single parameter? You've mentioned in your initial email something about 100k or more, but that's well inside of the current limitation of the C Call-Out interface, which currently is 10240k (or 10M)! In case you have to pass bigger chunks of data between Uniface and some 3GL then there are certainly better and more efficient ways (like for example exchange the data via a database table or flat file).

    Hope this helps.

    Best regards,
    Daniel


    Author: diseli (daniel.iseli@uniface.com)
    Jan Cees Boogaard

    any general solution for larger size parameters in 3gl interface ?

    Author: gerd.vassen@gmx.net (gerdvassen)

    hello everybody !

    I am trying to create a callout 3GL interface (via activate), and in different places I am facing limitations of fixed size parameters due to the nature of how this is handled in Uniface.  I would like to have my functions work independently of the size of the parameters.  The parameters could take 100k or more, even if they most often just take some bytes (please do not ask me to rethink my design, I am looking for a general approach to an ever-returning problem :-)).
    I can understand that on a lower level, those fixed packet sizes are necessary, but looking for instance at the UHTTP Uniface component, I can see that Uniface has also found a mechanism to solve this by repeated calls to READ_CONTENT until all the data is read (could probably be handled in a more programmer-friendly way by just doing this internally, but at least there is a way).

    Does anybody have had similar or better, more generalized approaches for this issue that could be shared with the community ?

    thank you

    gerd

    hi Daniel

    oops you're right, I now also found it in the doc. I thought having read something about 8k limit,  but 100k is certainly more than enough.
    I'm sorry, my fault.

    Best greetings,

    gerd

     


    Author: gerdvassen (gerd.vassen@gmx.net)
    Jan Cees Boogaard

    any general solution for larger size parameters in 3gl interface ?

    Author: gerd.vassen@gmx.net (gerdvassen)

    hello everybody !

    I am trying to create a callout 3GL interface (via activate), and in different places I am facing limitations of fixed size parameters due to the nature of how this is handled in Uniface.  I would like to have my functions work independently of the size of the parameters.  The parameters could take 100k or more, even if they most often just take some bytes (please do not ask me to rethink my design, I am looking for a general approach to an ever-returning problem :-)).
    I can understand that on a lower level, those fixed packet sizes are necessary, but looking for instance at the UHTTP Uniface component, I can see that Uniface has also found a mechanism to solve this by repeated calls to READ_CONTENT until all the data is read (could probably be handled in a more programmer-friendly way by just doing this internally, but at least there is a way).

    Does anybody have had similar or better, more generalized approaches for this issue that could be shared with the community ?

    thank you

    gerd

    Hi Gerd

    I already had this problem too, and didn't want to penalize my 3GL interface with big parameter buffers, so I reused the Compuware's design of repeatidly call one function several times. Actually, this's simple to implement, cover most cases, and can be hidden with a simple service which does the tricky parts (calling the 3GL function until there's no more to read).

    I even made a standard interface (in my own .h files) to handle this, so now I just reuse this interface (a set of macros to deal with buffer positionning) each time a need a non fixed length string parameter.

    Regards,
    Richard


    Author: richard.gill (richard.gill@agfa.com)
    Jan Cees Boogaard

    any general solution for larger size parameters in 3gl interface ?

    Author: gerd.vassen@gmx.net (gerdvassen)

    hello everybody !

    I am trying to create a callout 3GL interface (via activate), and in different places I am facing limitations of fixed size parameters due to the nature of how this is handled in Uniface.  I would like to have my functions work independently of the size of the parameters.  The parameters could take 100k or more, even if they most often just take some bytes (please do not ask me to rethink my design, I am looking for a general approach to an ever-returning problem :-)).
    I can understand that on a lower level, those fixed packet sizes are necessary, but looking for instance at the UHTTP Uniface component, I can see that Uniface has also found a mechanism to solve this by repeated calls to READ_CONTENT until all the data is read (could probably be handled in a more programmer-friendly way by just doing this internally, but at least there is a way).

    Does anybody have had similar or better, more generalized approaches for this issue that could be shared with the community ?

    thank you

    gerd

    hello Richard

    thank you for your answer. I think I will do something in that direction too, I am not so happy with defining huge parameters if in most of the cases I use only smaller buffers and then will do a similar back and forth in case it is necessary.

    best greetings !

    gerd


    Author: gerdvassen (gerd.vassen@gmx.net)

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement