PERFORM_PARAMETER_TOO_SHORT

Hi All,
Can any one tell me why/when this short dump occurs PERFORM_PARAMETER_TOO_SHORT. Please revert as soon as possible. It's urgent.
Thanks
kannan

Hi,
Check the number of parameters in the perform statement and in the form statement..
Are you using user command for ALV..The following should be structure..
FORM user_command USING ucomm LIKE sy-ucomm
                        selfield TYPE slis_selfield.
For setting Gui status in a custom form..use the following interface..
FORM set_pf_status USING  extab TYPE slis_t_extab.
Thanks,
Naren

Similar Messages

  • PERFORM_PARAMETER_TOO_SHORT Short Dump

    Hi All,
    I have created a generic datasource using an Infoset Query.
    The code written in the Infoset Query has no errors and it executes successfully.
    But, when i try to execute the datasource in RSA3, i get a dump with the runtime error PERFORM_PARAMETER_TOO_SHORT.
    I am attaching the whole dump below. Kindly help me solve this issue.
    Runtime Errors         PERFORM_PARAMETER_TOO_SHORT
    Exceptn                CX_SY_DYN_CALL_ILLEGAL_TYPE
    Date and Time          20.03.2009 17:53:04
    ShrtText
         Actual parameter too short when passing parameter in PERFORM.
    What happened?
         Error in ABAP application program.
         The current ABAP program "SAPLAQBWEXR" had to be terminated because one of the
         statements could not be executed.
         This is probably due to an error in the ABAP program.
    Error analysis
         An exception occurred. This exception is dealt with in more detail below
         . The exception, which is assigned to the class 'CX_SY_DYN_CALL_ILLEGAL_TYPE',
          was neither
         caught nor passed along using a RAISING clause, in the procedure
          "AQBW_GET_DATA" "(FUNCTION)"
         Since the caller of the procedure could not have expected this exception
          to occur, the running program was terminated.
         The reason for the exception is:
         The field which is supposed to receive a structured parameter is
         shorter than the structure of the parameter. This is not supported.
         This is parameter no. 2 of the FORM "%GET_DATA" in the program
          "AQZZSYSTBWGENER0SY000000000096".
        The actual parameter is 40 bytes long, the formal parameter 110 bytes.
    Missing RAISING Clause in Interface
        Program                                 SAPLAQBWEXR
        Include                                 LAQBWEXR$02
        Row                                     5
        Module type                             (FUNCTION)
        Module Name                             AQBW_GET_DATA
    Trigger Location of Exception
        Program                                 SAPLAQBWEXR
        Include                                 LAQBWEXRU02
        Row                                     273
        Module type                             (FUNCTION)
        Module Name                             AQBW_GET_DATA
    Source Code Extract
    Line  SourceCde
      243          OTHERS                      = 5
      244              .
      245       if sy-subrc = 0.
      246         E_T_DATA[] = <l_dtab>.
      247       elseif sy-subrc = 4. 248 * alle Daten gelesen -> Schluss
    249         raise no_more_data.
    250       else.
    251         LOG_WRITE 'E'              "message type
    252                            SY-MSGID         "message class
    253                            SY-MSGNO         "message number
    254                            SY-MSGV1         "message variable 1
    255                            SY-MSGV2.        "message variable 2
    256         RAISE ERROR_PASSED_TO_MESS_HANDLER.
    257       ENDIF.
    258     else.
    259 * alte Version, dieser Zweig wird auch bei ersten Durchlauf ausgeführt
    260       IF L_TABIX_FROM > L_TABIX_MAX.
    261         RAISE NO_MORE_DATA.
    262       ENDIF.
    263       L_TABIX_TO = L_TABIX_FROM + G_S_INTERFACE-MAXSIZE - 1.
    264       IF L_TABIX_TO > L_TABIX_MAX.
    265         L_TABIX_TO = L_TABIX_MAX.
    266       ENDIF.
    267       CLEAR: E_T_DATA, E_T_DATA[].
    268
    269       PERFORM %GET_DATA IN PROGRAM (L_REPID) TABLES E_T_DATA
    270                                               USING L_TABIX_FROM
    271                                                     L_TABIX_TO.
    272     endif.
    >>>>     L_TABIX_FROM = L_TABIX_TO + 1.
    274
    275     G_COUNTER_DATAPAKID = G_COUNTER_DATAPAKID + 1.
    276
    277
    278   ENDIF.              "Initialization mode or data extraction ?
      279
      280 ENDFUNCTION.
    Edited by: Apeksha M. on Mar 20, 2009 1:35 PM

    I ran into the same problem.
    I solved it by regenerating the datasource in the source system using transaction RSO2. You do this by by entering the datasource, choose Change and then choose Save to regenerate the datasource. Choose Save again in the sybsequent dialog.
    In my case I also regenerated the Infosource on which the extractor was based.
    Kindest regards
    Thomas

  • Catching a runtime error

    Hi,
    A runtime error for overflow (type p) occurs with the following details:
    Runtime Errors         COMPUTE_BCD_OVERFLOW    
    Exception              CX_SY_ARITHMETIC_OVERFLOW
    Date and Time          06/12/2007 11:33:13     
    Instead of displaying the dump screen, i'd like to catch the runtime error and display a message instead. The following is the code that causes the error (onhand is too large):
          REQRMENT = FORECAST - ONHAND - OPENQTY.
    Please help,
    Points will be rewarded and all help will be greatly appreciated.
    Thanks,
    John

    According to help, these are the catchable exceptions for a form call:
    Catchable Exceptions
    CX_SY_PROGRAM_NOT_FOUND
    Cause: The specified program was not found.
    Runtime Error: LOAD_PROGRAM_NOT_FOUND
    Cause: The specified program cannot exist because the program name is longer than 40 characters.
    Runtime Error: PERFORM_PROGRAM_NAME_TOO_LONG
    CX_SY_DYN_CALL_ILLEGAL_FORM
    Cause: The specified subroutine was not found.
    Runtime Error: PERFORM_NOT_FOUND
    Cause: The specified index was too small.
    Runtime Error: PERFORM_INDEX_0
    Cause: The specified index was negative.
    Runtime Error: PERFORM_INDEX_NEGATIVE
    Cause: The specified index was too large.
    Runtime Error: PERFORM_INDEX_TOO_LARGE
    CX_SY_DYN_CALL_PARAM_MISSING
    Cause: The called FORM expects more parameters than were specified.
    Runtime Error: PERFORM_PARAMETER_MISSING
    CX_SY_DYN_CALL_PARAM_NOT_FOUND
    Cause: More parameters were specified than expected by FORM.
    Runtime Error: PERFORM_TOO_MANY_PARAMETERS
    CX_SY_DYN_CALL_ILLEGAL_TYPE
    Cause: In the parameter transfer using the addition STRUCTURE, the addressing offsets/> do not match in the current and target structures.
    Runtime Error: PERFORM_BASE_WRONG_ALIGNMENT
    Cause: The deep components contained in the current and target structures cannot be passed to each other. This error can only occur in parameter transfer using STRUCTURE.
    Runtime Error: PERFORM_CAST_DEEP_MISMATCH
    Cause: During the transfer of a generically defined type to the form, a type conflict occurred.
    Runtime Error: PERFORM_CONFLICT_GENERIC_TYPE
    Cause: The table type of the current parameter does not match the table type of the parameter defined in the form.
    Runtime Error: PERFORM_CONFLICT_TAB_TYPE
    Cause: The type of current parameter does not match the type of parameter defined in the form.
    Runtime Error: PERFORM_CONFLICT_TYPE
    Cause: The current parameter occupies less storage space than the target parameter defined in the form. This error occurs only with parameter specification using STRUCTURE.
    Runtime Error: PERFORM_PARAMETER_TOO_SHORT
    Cause: During parameter transfer with the addition STRUCTURE, the fragment views of the current and target parameters do not match. This error only occurs in Unicode programs in
    Runtime Error: PERFORM_CONFLICT_UC_STRUCT
    Cause:When the form is called, an internal table is expected as current parameter.
    Runtime Error: PERFORM_TABLE_REQUIRED
    Cause: A hash table was passed to a parameter defined using TABLES.
    Runtime Error: PERFORM_STD_TAB_REQUIRED

  • Form Routines

    Hi  ABAP Gurus,
                             i am new to abap.i Have some small doubts.please explain me some doubts.please do explain me in simple words dont send links.
    1. what is a FORM Routine?
    2. what is importing ,Exporting?
    3. what is the diff. b/w exporting & Returning?
    4.what is changing?
    5. what is returning ,receiving?
    6.what is PERFORM Statement?
    7.explain me about public,protected and private?
    note:please do explain me these with simple coding so that i can be familiar to know where to use them.

    Check this link -
    http://www.geocities.com/rmtiwari/Resources/Utilities/ABAPReference/ABAPReference.html
    PERFORM
    Variants:
    1. PERFORM form.
    2. PERFORM form IN PROGRAM prog.
    3. PERFORM n OF form1 form2 form3 ... .
    4. PERFORM n ON COMMIT.
    5. PERFORM n ON ROLLBACK.
    6. PERFORM form(prog).
    Variant 1
    PERFORM form.
    Extras:
    1. ... USING    p1 p2 p3 ... 2. ... CHANGING p1 p2 p3 ...
    3. ... TABLES   itab1 itab2 ...
    Effect
    Calls the subroutine form defined usng a FORM statement. After the subroutine has finished, processing continues after the PERFORM statement. The parameters of the subroutine are position parameters, and must be passed in the call according to the definition of the formal parameters in the corresponding FORM statement.
    Example
    PERFORM HELP_ME.
    FORM HELP_ME.
    ENDFORM.
    The PERFORM statement calls the subroutine HELP_ME.
    Note
    Non-Catchable Exceptions:
    PERFORM_PARAMETER_MISSING: The subroutine called has more parameters than you passed to it.
    PERFORM_TOO_MANY_PARAMETERS: You passed more parameters to the subroutine than it was expecting.
    PERFORM_CONFLICT_TYPE,
    PERFORM_CONFLICT_TAB_TYPE,
    PERFORM_STD_TAB_REQUIRED,
    PERFORM_CONFLICT_GENERIC_TYPE,
    PERFORM_BASE_WRONG_ALIGNMENT,
    PERFORM_PARAMETER_TOO_SHORT,
    PERFORM_CAST_DEEP_MISMATCH,
    PERFORM_TABLE_REQUIRED: The type of a parameter did not correspond to the type specified in the FORM statement.
    Addition 1
    ... USING    p1 p2 p3 ...
    Addition 2
    ... CHANGING p1 p2 p3 ...
    Effect
    These two additions have an identical function. However, you should always use the same addition as is used in the corresponding FORM definition (for documentary reasons).
    The statement passes the parameters p1 p2 p3 ... to the subroutine. A subroutine may have any number of parameters.
    The order in which you list the parameters is crucial. The first parameter in the PERFORM statement is passed to the first formal parameter in the FORM defintion, the second to the second, and so on.
    You can specify offset and length of a parameter as variables. If you use the addition ' ...USING p1+off(*)', the parameter p1 will be passed with the offset off, but the length will not exceed the total length of the field.
    Example
    DATA: NUMBER_I TYPE I VALUE 5,
          NUMBER_P TYPE P VALUE 4,
          BEGIN OF PERSON,
            NAME(10)      VALUE 'Paul',
            AGE TYPE I    VALUE 28,
          END   OF PERSON,
          ALPHA(10)       VALUE 'abcdefghij'.
    FIELD-SYMBOLS <POINTER> TYPE ANY.
    ASSIGN NUMBER_P TO <POINTER>.
    PERFORM CHANGE USING 1
                         NUMBER_I
                         NUMBER_P
                         <POINTER>
                         PERSON
                         ALPHA+NUMBER_I(<POINTER>).
    FORM CHANGE USING VALUE(PAR_1)
                      PAR_NUMBER_I
                      PAR_NUMBER_P
                      PAR_POINTER
                      PAR_PERSON STRUCTURE PERSON
                      PAR_PART_OF_ALPHA.
      ADD PAR_1 TO PAR_NUMBER_I.
      PAR_NUMBER_P = 0.
      PAR_PERSON-NAME+4(1) = ALPHA.
      PAR_PERSON-AGE = NUMBER_P + 25.
      ADD NUMBER_I TO PAR_POINTER.
      PAR_PART_OF_ALPHA = SPACE.
    ENDFORM.
    Field contents after the PERFORM statement:
    NUMBER_I    = 6
    NUMBER_P    = 6
    <POINTER>   = 6
    PERSON-NAME = 'Paula'
    PERSON-AGE  = 25
    ALPHA       = 'abcde    j'
    Notes
       1. If you want to pass the body of an internal table itab that has a header line, you must use the notation itab[] (see Data Objects). If you do not use the brackets, the header line of the tabel is passed.
       2. The field types and lengths of the parameters remain the same. If a parameter is changed within the subroutine, it will still have the changed value after the subroutine has finished. This does not apply to parameters passed using VALUE. werden.
       3. If you pass literals, they may not be changed unless you pass them to a formal parameter defined with USING VALUE.
    Addition 3
    ... TABLES itab1 itab2 ...
    Effect
    TABLES allows you to pass internal tables to a subroutine.
    Example
    TYPES: BEGIN OF ITAB_TYPE,
             TEXT(50),
             NUMBER TYPE I,
           END OF ITAB_TYPE.
    DATA:  ITAB TYPE STANDARD TABLE OF ITAB_TYPE WITH
                     NON-UNIQUE DEFAULT KEY INITIAL SIZE 100,
           BEGIN OF ITAB_LINE,
             TEXT(50),
             NUMBER TYPE I,
           END OF ITAB_LINE,
           STRUC like T005T.
    PERFORM DISPLAY TABLES ITAB
                    USING  STRUC.
    FORM DISPLAY TABLES PAR_ITAB STRUCTURE ITAB_LINE
                 USING  PAR      like      T005T.
      DATA: LOC_COMPARE LIKE PAR_ITAB-TEXT.
      WRITE: / PAR-LAND1, PAR-LANDX.
      LOOP AT PAR_ITAB WHERE TEXT = LOC_COMPARE.
      ENDLOOP.
    ENDFORM.
    Within the subroutine DISPLAY, you can use any internal table operation to work with the internal table that you passed to it.
    Note
    If you use TABLES, it must always be the first addition in a PERFORM statement.
    Variant 2
    PERFORM form IN PROGRAM prog.
    Extras:
    1. ... USING    p1 p2 p3 ... 2. ... CHANGING p1 p2 p3 ...
    3. ... TABLES   itab1 itab2 ...
    4. ... IF FOUND
    Passsing SY-REPID not allowed and Receiving SY-SUBRC not allowed.
    Effect
    This variant is similar to variant 2 (external perform). However, here you can specify the names of both the subroutine and the program in which it occurs dynamically at runtime. If you do this, you should place the variables form and prog in parentheses. The names in form and prog must be entered in uppercase, otherwise a runtime error occurs. If you do not specify any additions (such as USING) you do not need to specify the program after IN PROGRAM. In this case, the system looks for the subroutine in the current program.
    Example
    DATA: RNAME(30) VALUE 'WRITE_STATISTIC',   "Form and program
                                               "names must
          PNAME(8)  VALUE 'ZYX_STAT'.          "be written in
                                               "upper case
    PERFORM (RNAME)         IN PROGRAM ZYX_STAT.
    PERFORM WRITE_STATISTIC IN PROGRAM (PNAME).
    PERFORM (RNAME)         IN PROGRAM (PNAME).
    All three PERFORM statements have the same effect, that is, they call the subroutine 'WRITE_STATISTIC', which is defined in the program 'ZYX_STAT'.
    Notes
    Dynamic PERFORM statements require more CPU time, since the system has to locate the subroutine each time.
    Note
    Non-Catchable Exceptions:
    PERFORM_NOT_FOUND: Unable to find the specified subroutine.
    LOAD_PROGRAM_NOT_FOUND: Unable to find the specified main program.
    PERFORM_PROGRAM_NAME_TOO_LONG: The specified program cannot exist because the program name is longer than 40 characters.
    Addition 1
    ... USING p1 p2 p3 ...
    Effect
    See variant 1, addition 1.
    Addition 2
    ... CHANGING p1 p2 p3 ...
    Effect
    See variant 1, addition 2.
    Addition 3
    ... TABLES itab1 itab2 ...
    Effect
    See variant 1, addition 3.
    Addition 4
    ... IF FOUND
    Effect
    The system only calls the subroutine if it and its main program exist. If this is not the case, the statement is ignored.
    Variant 3
    PERFORM n OF form1 form2 form3 ... .
    Effect
    Calls the subroutine with the index n from the list of subroutines in the statement. At runtime, n must contain a value between 1 (first name) and the total number of subroutines listed in the PERFORM statement (last name). The list can contain up to 256 subroutines.
    Note
    Non-Catchable Exceptions:
    PERFORM_INDEX_0: The specified index was too small.
    PERFORM_INDEX_NEGATIVE: The specified index was negative.
    PERFORM_INDEX_TOO_LARGE: The specified index was too big.
    Variant 4
    PERFORM n ON COMMIT.
    Extras:
    1. ... LEVEL idx
    Effect
    Calls the specified subroutine at the next COMMIT WORK statement. This allows you to delay the subroutine until the logical transaction is finished. Even if you register the same subroutine more than once, it is only executed once. For further information, refer to COMMIT WORK. The ROLLBACK WORK statement deregisters all subroutines registered using this addition.
    Notes
       1. You cannot use USING or CHANGING with the ... ON COMMIT addition. If you need to pass data to the subroutine, you must place it in global variables or use the EXPORT ... TO MEMORYstatement.
       2. The PERFORM ... ON COMMIT statement can also be used during update. The corresponding subroutine is called at the end of the update task.
    Addition 1
    ... LEVEL idx
    Effect
    The LEVEL addition, followed by a field, determines the sequence in which the specified subroutines will be executed at the COMMIT WORK statement. The subroutines are called in ascending order of their level. If you do not use the LEVEL addition, the subroutine assumes the level zero. If two or more subroutines have the same level, they are executed in the sequence in which they are called in the program. You assign levels by defining constants in an include program. The level must have type I.
    Variant 5
    PERFORM n ON ROLLBACK.
    Effect
    The specified subroutine is executed if a ROLLBACK WORK occurs. This allows you, for example, to delete data, such as an internal table or data in memory, that was intended for use in PERFORM...ON COMMIT. If you register the same subroutine more than once, it will still only be executed once per ROLLBACK WORK.
    Notes
       1. Subroutines registered using PERFORM... ON COMMIT cannot have USING or CHANGING parameters. Any data you want to pass to them must be contained in global variables or buffered using EXPORT ... TO MEMORY.
       2. If you catch a type A message ( MESSAGE) using the EXCEPTIONS..ERROR_MESSAGE addition in the CALL FUNCTION statement, a ROLLBACK WORK occurs, in which the subroutines registered using PERFORM ... ON ROLLBACK are executed.
    Variant 6
    PERFORM form(prog).
    Extras:
    1. ... USING    p1 p2 p3 ... 2. ... CHANGING p1 p2 p3 ...
    3. ... TABLES   itab1 itab2 ...
    4. ... IF FOUND
    PERFORM form(prog) not allowed.
    Effect
    Calls the subroutine form defined in program prog ("external PERFORM").
    Notes
       1. You pass parameters to the external subroutine as described in variant 1.
       2. However, you can also do it using a shared data area ( DATA BEGIN OF COMMON PART).
       3. Please consult Data Area and Modularization Unit Organization documentation as well.
       4. You can use nested calls, including several different subroutines in different programs.
       5. When you call a subroutine that belongs to a program prog, prog is loaded into the PXA buffer (if it has not been loaded already). To minimize the possibility of memory problems, try not to use too many external subroutines from a large number of different programs.
    Hope this helps.
    ashish

Maybe you are looking for