Skip to Content
author's profile photo Former Member
Former Member

JCO.Server programming, Question about the offset value in the addInfo meth

Hi all,

I;m working on a JCO.Server programming,

In the code there're complex nested structures.

I almost done the job, but now there comes a fatal problem.

Because of my wrong offset definition, each caller can enforce to crash my running server! It doesn't work.

from the trace file, I find somthing like:

*>RfcInstallStrucure2: field 2 (TAGE, t:8, l:4) offset 90 too small (at least 92 expected)

*>RfcInstallStrucure2: field 13 (KKURS, t:8, l:4) offset 74 too small (at least 76 expected)

*>RfcInstallStrucure2: field 10 (FKIMG, t:7, l:8) offset 167 too small (at least 168 expected)

*>RfcInstallStrucure2: field 7 (KPEIN, t:8, l:4) offset 81 too small (at least 84 expected)

*>RfcInstallStrucure2: field 17 (KUMZA, t:8, l:4) offset 97 too small (at least 100 expected)

*>RfcInstallStrucure2: field 6 (FKIMG_VG2, t:7, l:8) offset 62 too small (at least 64 expected)

*>RfcInstallStrucure2: field 7 (TOLER_FROM, t:7, l:8) offset 146 too small (at least 152 expected)

*>RfcInstallStrucure2: field 10 (TOLER_FROM, t:7, l:8) offset 178 too small (at least 184 expected)

& have a look at Example5, I also can not explain the offset value definition

JCO.MetaData smeta = new JCO.MetaData("RFCTEST");

smeta.addInfo("RFCFLOAT", JCO.TYPE_FLOAT, 8, 0, 0);

smeta.addInfo("RFCCHAR1", JCO.TYPE_CHAR, 1, 8, 0);

smeta.addInfo("RFCINT2", JCO.TYPE_INT2, 2, 10, 0);

smeta.addInfo("RFCINT1", JCO.TYPE_INT1, 1, 12, 0);

smeta.addInfo("RFCICHAR4", JCO.TYPE_CHAR, 4, 13, 0);

smeta.addInfo("RFCINT4", JCO.TYPE_INT, 4, 20, 0);

smeta.addInfo("RFCHEX3", JCO.TYPE_BYTE, 3, 24, 0);

smeta.addInfo("RFCCHAR2", JCO.TYPE_CHAR, 2, 27, 0);

smeta.addInfo("RFCTIME", JCO.TYPE_TIME, 6, 29, 0);

smeta.addInfo("RFRDATE", JCO.TYPE_DATE, 8, 35, 0);

smeta.addInfo("RFCDATA1", JCO.TYPE_CHAR, 50,43, 0);

smeta.addInfo("RFCDATA2", JCO.TYPE_CHAR, 50,93, 0);

addInfo(String name, int type, int length, int offset, int decimal)

from Example5's segment,

if RFCFLOAT start from 0 with length 8, RFCCHAR1 start from 8 with length 1 is ok, how come RFCINT2 start from 10, not 9?

the same thing appears again with this:

smeta.addInfo("RFCICHAR4", JCO.TYPE_CHAR, 4, 13, 0);

smeta.addInfo("RFCINT4", JCO.TYPE_INT, 4, 20, 0);

why RFCINT4 start from 20, not 17

how to calc all these offset values, there must be some rules, maybe depends on TYPE, if there's number in decimal value(>0), will it affect offset value?

This problem is urgent, please help.

Add a comment
10|10000 characters needed characters exceeded

Related questions

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Jan 10, 2007 at 04:01 PM


    Good question. The offset depends on the definition in ABAP dictionary. If you look at the definition of field RFCCHAR1 you will see that it has a length of 1. Ok, cause it is based on CHAR with a length of 1. But there is a flag set, that indicates, that the field is lowercase in case of inputs. With this information the field grows now to a length of 2 and so the offset of the next field also growths.

    To get the right offset, lenght, type and so on, you could use FB DDIF_FIELDINFO_GET. Call this FB in Java to get the information of the used structure. With this information you wont run in any trouble later cause you have the right information of the structure/field definition.



    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.