unicode problem for offset and length

[Former Member]

Dear Experts,

I am currently working on unicode program where I am getting a error from transaction UCCHECK.

I have set up a offset length in the program which is not getting accepted for unicode check.

My coding is :

LOOP AT T_KEPH.

    V_KEPH-ANZ = 1.
    OFF1 = 0.
    LEN1 = 7.
DO 40 TIMES.
      T_KEPH_AUSG-WAERS = T_KEPH-WAERS.
      V_ANZ-CHAR = V_KEPH-ANZ.
      ASSIGN: T_KEPH-KST001+OFF1(LEN1) TO <FS> TYPE 'P'.
      V_KEPH-KST =  <FS>.

Overhere the assign statement is getting an error as

The system cannot perform a static check on the validity of the offset/ length entries for operand "T_KEPH-KST001+OFF1(LEN1)". They will be checked at runtime.

Kindly suggest solution.

Thanks and Regrds,

Nikhil.

[SimoneMilesi]

Try

ASSIGN: (T_KEPH-KST001+OFF1(LEN1))*TO <FS> TYPE 'P'.

or

ASSIGN: (T_KEPH-KST001+OFF1(LEN1)) TO <FS>.

[Former Member]

Hi Simone,

Not possible since dynamic field specification not allowed in unicode program.

Let me know if there is any other solution.

Thanks,

Nikhil.

[Former Member]

Hello Experts,

Can you provide any other suggestions which can overcome this error.

let me know if there is any other possibility other than exception.

Thanks and Regrds,

Nikhil.

[Former Member]

Hi Nikhil,

Lots of different possibilities. One is to utilize the [ASSIGN COMPONENT comp OF STRUCTURE|http://help.sap.com/abapdocu_70/en/ABAPASSIGN_MEM_AREA_DYNAMIC_DOBJ.htm#!ABAP_ALTERNATIVE_4@4@] statement. Since it seems that you basically want to iterate over all fields KST0<index> of KEPF, below is some sample coding:

  DATA:
    t_keph TYPE STANDARD TABLE OF keph,
    l_ind TYPE numc3,
    l_field TYPE fieldname,
    l_keph TYPE keph.

  LOOP AT t_keph ASSIGNING <l_keph>.

    DO 40 TIMES.
      l_ind = sy-index.
      CONCATENATE 'KST' l_ind INTO l_field.
      ASSIGN COMPONENT l_field OF STRUCTURE <l_keph> TO <l_kst_ind>.
      IF sy-subrc = 0.
        " Now you have in field symbol <l_kst_ind> the field KST001,
        " KST002, KST003 and so on...
      ENDIF.
    ENDDO.

  ENDLOOP.

Cheers, harald

[Former Member]

Hi Herald,

I tried your sample coding in my program but still I get a warning message like

>The system cannot perform a static check on the validity of the offset/ length entries for operand "<L_KST_IND>+OFF1(LEN1)". They will be checked at runtime.

In transaction UCCHECK.

Is there any other way or this part of coding is accepted in unicode compatible system.

Regrds,

Nikhil.

Edited by: Rob Burbank on Mar 19, 2010 4:05 PM

[Former Member]

Hi Nikhil,

I think you misunderstood my coding. With the version that I gave you, there's no need to specify any offset. Within the loop the field symbol <l_kst_ind> will be assigned to the fields of structure KEPH-KST001, KST002 and so on.

Run the coding in debugger and you'll see what I mean. Just try to do whatever you'd do with KST<number> fields with the field symbol <l_kst_ind>.

Cheers, harald

[Former Member]

Hi Harald,

Can you give me sample example where there is offset and length used in unicode programs for a better understanding.

Thanks and Regrds,

Nikhil.

[Former Member]

Hi Nikhil,

In Unicode programs you really must not use offsets for accessing structures (though in theory you could do that if there's only character-type fields up to the offset/length combination). Here's the explanation in the [online help|http://help.sap.com/saphelp_nw04/Helpdata/EN/79/c55470b3dc11d5993800508b6b8b11/frameset.htm] and here's the corresponding link in the [ABAP documentation|http://help.sap.com/abapdocu_70/en/ABENUNICODE_OFFSET_LENGTH.htm].

As the help states, there's no good reason to use offset and length. It does make sense if you're talking about a single string (or xstring), but when using structures you should always access the individual components directly (e.g. one possibility via dynamic programming I've shown you above).

Cheers, harald

[Former Member]

Hi Harald,

Thank you so much for your inputs in Offsets and length in unicode programs.

I guess I need to built up the offset and length like the sample coding you have done.

Thanks and Regrds,

Nikhil.

[Former Member]

Hallo Harald,

I am still trying to work on this problem, I have built an example program with offset and length:

DATA text2 TYPE c LENGTH 10 VALUE '0123456789'.

FIELD-SYMBOLS: <char> TYPE c.
              
DATA: off2 TYPE i,
      len2 type i.

DO 10 TIMES.
  off2 = sy-index - 1.
*  off2 = 1.
  len2 = 1.
  ASSIGN text2+off2(len2) TO <char>.
  WRITE / <char>.
ENDDO.

I am getting an output with it but when I check in tcode UCCHECK me getting a error message:

>The system cannot perform a static check on the validity of the offset/ length entries for operand "TEXT2+OFF2(LEN2)". They will be checked at runtime.

Thanks and Regrds,

Nikhil.

Edited by: Rob Burbank on Mar 19, 2010 4:08 PM

[Former Member]

Hi Nikhil,

Are you running UCCHECK with the option <i>Display lines that cannot be analyzed statically</i> (check also the documentation for transaction UCCHECK). The message is quite reasonable: You're using a dynamic offset and length specification, which are only filled at runtime. It's impossible to analyze this dynamic behavior in general for all possible cases using just static code analysis. I.e. in your specific case in theory it would still be possible to figure out offset and length, but for a static analysis, this gets at some point impossible, because only at runtime you will know what values the fields have.

Thus a static check is not always complete and cannot necessarily determine if the program won't create any problems when running. It's just a good tool to check for certain error categories that can be determined that way. As also specified in the documentation of UCCHECK, part of an analysis is to actually test the programs by executing them (as some errors can only be detected at runtime).

It's an old problem, essentially it's virtually impossible to prove the absence of bugs. The best you can do is run your static code checks, create test cases for all possible scenarios (which is for reasonably complex programs not feasible) and check the results.

Cheers, harald

[kesavadas_thekkillath]

Hi ,

During the static check only the syntax is checked.

This is a dynamic check which states the possibility of error during the runtime.

I think handiling the exception will hide this warning.

[Former Member]

Hi Nikhil,

You can try this.

data:lv_KST001 type KST001.
LOOP AT T_KEPH.
 
    V_KEPH-ANZ = 1.
    OFF1 = 0.
    LEN1 = 7.
DO 40 TIMES.
      T_KEPH_AUSG-WAERS = T_KEPH-WAERS.
      V_ANZ-CHAR = V_KEPH-ANZ.

lv_KST001  = T_KEPH-KST001+OFF1(LEN1).

      ASSIGN: lv_KST001 TO <FS> TYPE 'P'.
      V_KEPH-KST =  <FS>.

Edited by: pravin s. on Mar 15, 2010 12:12 PM

[Former Member]

Hi Pravin.

No it does not work it does not take a sub-field

lv_KST001 = T_KEPH-KST001+OFF1(LEN1).

Overhere is an error.

Field type p does not permit a sub-field access.

Regrds,

Nikhil.

[Former Member]

Hi Harald,

Well I was just going through the documentation of UCCHECK transaction and when I disable check box for

Display lines that cannot be analyzed statically I get no unicode errors found.

Do you mean we can just neglect this error when we are working on offset and length for unicode programs.

Thnks and Regrds,

Nikhil

[Former Member]

Hi Nikhil,

Do you mean we can just neglect this error when we are working on offset and length for unicode programs.

Please check again my previous posting. Let me try again, since it seems unclear, even though the message is simple: Static code checks cannot detect all problems, you will have to do runtime testing (Unit tests, integration tests, etc.). So if UCCHECK tells you that there's a line that cannot be statically analyzed (with option checked), then it basically means that the statement might be problematic, but the static code analysis cannot tell. So at that point you can use your ABAP skills to check if the statement is ok or not and if the logic is too complex, you will have to rely on runtime tests.

Of course you basically have to test all programs, no matter if UCCHECK complains or not, but in those special cases where UCCHECK marks certain statements, you should also take a careful look at the coding and see if there's anything wrong (e.g. byte mode versus character mode) and possibly use information about the code internals to construct your test cases (if you use [white box testing|http://en.wikipedia.org/wiki/White-box_testing]). In theory you could have a program that worked fine before an upgrade, which is still syntactically correct after an upgrade, but the program produces the wrong result from functional perspective...

Consider static code checks as one tool in your toolbox for detecting possible problems, but not as the answer to everything...

Cheers, harald

[Former Member]

Hi Harald,

Me still working on this issue, now I am getting a dump since P types are not accepted when I assign field-symbols how can I avoid this.

here is my coding:

FIELD-SYMBOLS: <L_KEPH> TYPE ANY,
               <l_kst_ind> TYPE ANY.
DATA:
    t_keph TYPE STANDARD TABLE OF keph,
    l_ind TYPE numc3,
    l_field TYPE fieldname,
    l_keph TYPE keph.

TABLES: KEPH.

DATA: ITAB1 LIKE KEPH OCCURS 0 WITH HEADER LINE.
DATA: OFF10 TYPE I,
      LEN10 TYPE I.

SELECTION-SCREEN: BEGIN OF BLOCK B1 WITH FRAME TITLE A1.
SELECT-OPTIONS: S_KALNR FOR KEPH-KALNR.
SELECT-OPTIONS: S_KALKA FOR KEPH-KALKA.
SELECT-OPTIONS: S_BZOBJ FOR KEPH-BZOBJ.
SELECTION-SCREEN: END OF BLOCK B1.

START-OF-SELECTION.

SELECT * FROM KEPH INTO CORRESPONDING FIELDS OF TABLE ITAB1
                                 WHERE KALNR IN S_KALNR
                                   AND KALKA IN S_KALKA
                                   AND BZOBJ IN S_BZOBJ.


  LOOP AT ITAB1. "ASSIGNING <l_keph>.

   OFF10 = 0.
    LEN10 = 7.
    DO 40 TIMES.
    ASSIGN: itab1-KST001+off10(len10) TO <L_KEPH>. "TYPE 'P'.
 WRITE: <l_kEPH>.
    ENDDO.
  ENDLOOP.
  WRITE: ITAB1-KALNR,ITAB1-KALKA, itab1-KST001.

How can I avoid the dump here..

Thnks and Regrds,

Nikhil.

[Former Member]

Hi Nikhil,

Looks like my message is not coming across, maybe somebody else should try to comment...

Let me try one more time though: Don't use offsets for accessing fields of structures; instead use the sample coding that I posted above, e.g. you could add a WRITE <l_kst_ind>. to my version and you'd see the contents of the individual fields.

Cheers, harald

[Former Member]

Hi Harald,

I got your message but my issue was that we had used a offset and length in a program. We are doing an upgradation, and we want to retain the original coding, but as you know KST001 is a P type and we get a dump hence finding a solution for it.

What I have done is I have moved this field into variable of type C and its working now.

Thnks and Regrds,

Nikhil.

[Former Member]

not answered yet

[Former Member]

not answered yet

[Former Member]

answered