Re:invalid partial field access: negative offset

[Former Member]

Hi,

iam getting error invalid partial field access: negative offset, what is this mean

[Former Member]

Check if u are giving the offset value properly...i mean like field + 0(10)...

[Former Member]

negative off set not allowed

Access Using Offset and Length Specifications

Offset and length specifications are generally critical since the length of each character is platform-dependent. As a result, it is initially unclear as to whether the byte unit or the character unit is referred to in mixed structures. This forced us to put in place certain considerable restrictions. However, access using offset or length specifications is still possible to the degree described in the following. The tasks subject to this rule include accessing single fields and structures, passing parameters to subroutines and working with field symbols.

Single field access

Offset- or length-based access is supported for character-type single fields, strings and single fields of types X and XSTRING. For character-type fields and fields of type STRING, offset and length are interpreted on a character-by-character basis. Only for types X and XSTRING, the values for offset and length are interpreted in bytes.

Structure access

Offset- or length-based access to structured fields is a programming technique that should be avoided. This access type results in errors if both character and non-character-type components exist in the area identified by offset and length.

Offset- or length-based access to structures is only permitted in a UP if the structures are flat and the offset/length specification includes only character-type fields from the beginning of the structure. The example below shows a structure with character-type and non-character-type fields. Its definition in the ABAP program and the resulting assignment in the main memory is as follows:

BEGIN OF STRUC,

a(3) TYPE C, "Length: 3 characters

b(4) TYPE N, "Length: 4 characters

c TYPE D, "Length: 8 characters

d TYPE T, "Length: 6 characters

e TYPE F, "Length: 8 bytes

f(26) TYPE C, "Length: 28 characters

g(4) TYPE X, "Length: 2 bytes

END OF STRUC.

Internally, the fragment view contains four fragments. Offset- or length-based access in this case is only possible in the first fragment. Statements like struc(21) or struc7(14) are accepted by the ABAP interpreter and treated like a single field of type C. By contrast, struc57(2) access is now only allowed in an NUP. If offset-/length-based access to a structure is permitted, both the offset and length specifications are generally interpreted as characters in a UP.

Passing parameters to subroutines

Up to now, parameter passing with PERFORM has allowed you to use cross-field offset and length specifications. In future, this will no longer be allowed in a UP. In a UP, offset and length-based access beyond field boundaries returns a syntax or runtime error. For example, access types c15 or c5(10) would trigger such an error for a ten-digit C field c.

If only an offset but no length is specified for a parameter, the entire length of the field instead of the remaining length was previously used for access. As a result, parameter specifications are cross-field if you use only an offset, and therefore trigger a syntax error in a UP. PERFORM test USING c+5 is consequently not permitted.

In addition, in a UP, you can continue to specify the remaining length starting from the offset off for parameters using the form field+off(*).

Ranges for offset and length access when using field symbols

A UP ensures that offset- or length-based access with ASSIGN is only permitted within a predefined range. Normally, this range corresponds to the field boundaries in case of elementary fields or, in case of flat structures, to the purely character-type starting fragment. Using a special RANGE addition for ASSIGN, you can expand the range beyond these boundaries.

Field symbols are assigned a range allowed for offset/length specifications. If the source of an ASSIGN statement is specified using a field symbol, the target field symbol adopts the range of the source. If not explicitly specified otherwise, the RANGE is determined as follows:

ASSIGN feld TO <f>.

In a UP, the field boundaries of field are assigned to <fs> as the range, where field is no field symbol.

ASSIGN <g> TO <f>.

<fs2> adopts the range of <fs1>.

ASSIGN elfeld+off(len) TO <f>.

In a UP, the field boundaries of the elementary field elfield are assigned to <fs> as the range.

ASSIGN <elfld>+off(len) TO <f>.

<fs> adopts the range of the elementary field <elfield>.

ASSIGN struc+off(len) TO <f>.

ASSIGN <struc>+off(len) TO <f>.

In a UP, the purely character-type starting section of the flat structures struc or <struc> determines the range boundaries.

If the assignment to the field symbol is not possible because the offset or length specification exceeds the range permitted, the field symbol is set to UNASSIGNED in a UP. Other checks such as type or alignment checks return a runtime error in a UP. As a rule, offset and length specifications are counted in characters for data types C, N, D, and T as well as for flat structures, and in bytes in all other cases.

Offset without length specification when using field symbols

Up to now, ASSIGN field+off TO <fs> has shown the special behavior that the field length instead of the remaining length of field was used if only an offset but not length was specified. Since an ASSIGN with a cross-field offset is therefore problematic under Unicode, you must observe the following rules:

As previously, the field length of field is used as the length. Using ASSIGN field+off(*)... you can explicitly specify the remaining length.

ASSIGN <fs1>+off TO <fs2> is only permitted if the runtime type of <fs1> is flat and elementary, that is, C, N, D, T (offset in characters), or X (offset in bytes).

ASSIGN field+off TO <fs2> is generally forbidden from a syntactical point of view since any offset <> 0 would cause the range to be exceeded. Exceptions are cases in which a RANGE addition is used.

These rules enable you also in future to pass a field symbol through an elementary field using ASSIGN <fs>+n TO <fs>, as it is the case in a loop, for example.

Processing Sections of Strings

You can address a section of a string in any statement in which non-numeric elementary ABAP types or structures that do not contain internal tables occur using the following syntax:

<f>[+<o>][(<l>)]

By specifying an offset <o> and a length (<l>) directly after the field name <f>, you can address the part of the field starting at position <o>1 with length <l> as though it were an independent data object. The data type and length of the string section are as follows:

Original field

Section

Data type

Data type

Length

C

C

<l>

D

N

<l>

N

N

<l>

T

N

<l>

X

X

<l>

Structure

C

<l>

If you do not specify the length <l>, you address the section of the field from <o> to the end of the field. If the offset and length combination that you specify leads to an invalid section of the field (for example, exceeding the length of the original field), a syntax or runtime error occurs. You cannot use offset and length to address a literal or a text symbol.

You should take particular care when addressing components of structures. To ensure the correct platform-specific alignment of type I and F components, they may contain filler fields, whose lengths you need to consider when calculating the correct offset. Furthermore, SAP plans to convert the internal representation of character types to UNICODE, in which one character will no longer occupy one byte, but instead two or four. Although offset and length specifications can work for character fields (types C, D, N, and T) or for hexadecimal fields (type X), incompatible changes may occur in structures containing a mixture of numeric, character, and hexadecimal fields. SAP therefore recommends that you do not use offset and length to address components of structures.

In nearly all cases, you must specify offset <o> and length <l> as numeric literals without a preceding sign. You may specify them dynamically in the following cases:

When assigning values using MOVE or the assignment operator

When assigning values with WRITE TO

When assigning field symbols using ASSIGN.

When passing actual parameters to subroutines in the PERFORM statement.

DATA TIME TYPE T VALUE '172545'.

WRITE TIME.

WRITE / TIME+2(2).

CLEAR TIME+2(4).

WRITE / TIME.

The output appears as follows:

172545

25

170000

First, the minutes are selected by specifying an offset in the WRITE statement. Then, the minutes and seconds are set to their initial values by specifying an offset in the clear statement.

Offset and Length Specifications in the MOVE Statement

For the MOVE statement, the syntax for specifying offset and length is as follows:

MOVE <f1>[<o1>][(<l1>)] TO <f2>[<o2>][(<l2>)].

Or, when you use the assignment operator:

<f2>[<o2>][(<l2>)] = <f1>[<o1>][(<l1>)].

The contents of the part of the field <f1> which begins at position <o1>1 and has a length of <l1> are assigned to field <f2>, where they overwrite the section which begins at position <o2>1 and has a length of <l2>.

In the MOVE statement, all offset and length specifications can be variables. This also applies to statements with the assignment operator, as long as these can also be written as MOVE statements. In statements where no field name is specified after the assignment operator, (for example, in Numeric Operations), all offset and length specifications must be unsigned number literals.

SAP recommends that you assign values with offset and length specifications only between non-numeric fields. With numeric fields, the results can be meaningless.

DATA: F1(8) VALUE 'ABCDEFGH',

F2(20) VALUE '12345678901234567890'.

F26(5) = F13(5).

In this example, the assignment operator functions as follows:

DATA: F1(8) VALUE 'ABCDEFGH',

F2(8).

DATA: O TYPE I VALUE 2,

L TYPE I VALUE 4.

MOVE F1 TO F2. WRITE F2.

MOVE F1+O(L) TO F2. WRITE / F2.

MOVE F1 TO F2+O(L). WRITE / F2.

CLEAR F2.

MOVE F1 TO F2+O(L). WRITE / F2.

MOVE F1O(L) TO F2O(L). WRITE / F2.

This produces the following output:

ABCDEFGH

CDEF

CDABCD

ABCD

CDEF

First, the contents of F1 are assigned to F2 without offset specifications. Then, the same happens for F1 with offset and length specification. The next three MOVE statements overwrite the contents of F2 with offset 2. Note that F2 is filled with spaces on the right, in accordance with the conversion rule for source type C.

Offset and Length Specifications in the WRITE TO Statement

For the WRITE TO statement, the syntax for specifying offset and length is as follows:

WRITE <f1>[<o1>][(<l1>)] TO <f2>[<o2>][(<l2>)].

The contents of the part of the field <f1> which begins at position <o1>1 and has a length of <l1> are converted to a character field and assigned to field <f2>, where they overwrite the section which begins at position <o2>1 and has a length of <l2>.

In the WRITE TO statement, the offset and length specifications of the target field can be variables. The offset and length of the target field must be numeric literals without a preceding sign.

DATA: STRING(20),

NUMBER(8) TYPE C VALUE '123456',

OFFSET TYPE I VALUE 8,

LENGTH TYPE I VALUE 12.

WRITE NUMBER(6) TO STRING+OFFSET(LENGTH) LEFT-JUSTIFIED.

WRITE: / STRING.

CLEAR STRING.

WRITE NUMBER(6) TO STRING+OFFSET(LENGTH) CENTERED.

WRITE: / STRING.

CLEAR STRING.

WRITE NUMBER TO STRING+OFFSET(LENGTH) RIGHT-JUSTIFIED.

WRITE: / STRING.

CLEAR STRING.

This produces the following output:

123456

123456

123456

The first six characters of the field NUMBER are written left-justified, centered, and right-justified into the last 12 characters of the field STRING.

[Former Member]

Hi Sravanthi,

Can you paste your code. You must be accessing a field with invalid offset.

Regards,

Atish

[Former Member]

Hi,

DATA: LV_NUM type n,

LV_STRING(40) ,

( consider)

(US_ROLES-AGR_NAME = Z:MM-PUREQ-APPR-UTAC-1000-R)

LV_STRING = US_ROLES-AGR_NAME.

LV_NUM = STRLEN( LV_STRING ).

LV_NUM = LV_NUM - 1.

LV_LAST_LETTER = LV_STRING+LV_NUM(1).

IF LV_LAST_LETTER = 'R'.

v_opt = 'YES'.

ELSE.

v_opt = 'NO'.

ENDIF.

IF I SEE IN DEBUGGING MODE THE VALUES are

LV_NUM = 8 -

---

> lv_num should take length = 28

LV_NUM = LV_NUM - 1( 8-1 = 7)

if i change LV_NUM type n to LV_NUM type i , the output is coming correctly if i execute for one user but if i execute for more users iam getiing invalid partial field access: negative offset

is the above logic correct , in that roles if the last lettr is 'R' then v_opt ='Yes' otherwise 'NO'

[Former Member]

here is the bug you have declared DATA: LV_NUM type n, so by default it is of length 1 and it is taking 8 instead of 28. correct declaration is

DATA: LV_NUM(2) type n,

regards

shiba dutta

[Former Member]

Hi,

Change this piece of code and try.

<b>DATA: LV_NUM(2) type n.</b>

Regards,

Atish