In a customer object, I see the following ABAP code:
CLASS lcl_detail DEFINITION FINAL.
SET EXTENDED CHECK OFF.
PUBLIC SECTION.
[...]
ENDCLASS.
I've performed a syntax check on an SAP 7.40 system and it is fine. But if I check the 7.40 ABAP Keyword documentation of CLASS DEFINITION, it does not say that SET EXTENDED CHECK is allowed in this place. Also, I though there shouldn't be anything between the CLASS DEFINITION part and the first SECTION part.
Since the SET EXTENDED CHECK {ON|OFF} statement is used to activate/deactivate the complete check of the ABAP source code for all errors that can be detected statically, it can be put in any section of a program.
It is not used in program's execution. It's used when you run the extended program check (SLIN or ABAP Test Cockpit).
Related
For CALL METHOD - Static Method Call (Obsolete), the ABAP keyword documentation says: "If CALL METHOD is used for the standalone method call, no chained method calls are possible ..."
Nevertheless, the following happily executes on an 7.40 system. Isn't that an example of a standalone method call? Or else, what am I getting wrong?
REPORT ZUTEST3.
CLASS class_parent Definition.
PUBLIC Section.
METHODS m1 returning value(r) type ref to class_parent.
ENDCLASS.
CLASS class_parent Implementation.
Method m1.
create object r.
write / 'm1'.
EndMethod.
ENDCLASS.
start-of-selection.
data cl type ref to class_parent.
CREATE OBJECT cl.
CALL METHOD cl->m1( )->m1( ).
Edit: Disclaimer
We are writing a tool in Java that parses and transforms ABAP code. In particular, we have no intention to write new ABAP code. But instead, our tool has to handle all of ABAP, even obsolete statements and obscure syntax variants. Furthermore, I'd like to mention that I'm not an ABAP expert.
Addendum February 23rd, the right answer is given by Florian in the comments : "I reported the bug to the docu team and they answered that it has already been reported and they corrected it in the latest version. The new statement is: "With the second variant without round brackets, chained method calls are not possible and the operators NEW and CAST cannot be used.""
I let my original answer below (by the way, I think now that in CALL METHOD static_meth..., the term "standalone method call" refers to the part "static_meth", so it refers to the two groups of constructs, hence my answer is inexact and the one by SAP is 100% correct)
As I can see, the documentation says that the term "standalone method call" refers to these constructs (observe the use of parentheses), which are declared obsolete :
CALL METHOD method( ).
CALL METHOD method( 25 ).
CALL METHOD method( a = 1 ).
CALL METHOD method( EXPORTING a = 1 ).
CALL METHOD instance->method( ).
CALL METHOD class=>method( ).
etc.
The term ""standalone method call" doesn't refer to these constructs :
CALL METHOD method.
CALL METHOD method EXPORTING a = 1.
CALL METHOD instance->method.
CALL METHOD class=>method.
etc.
I guess that CALL METHOD cl->m1( ) belongs to the first group of constructs so there's an error in the documentation.
Probably a not is missing because it should apply to the second group of constructs (for instance, CALL METHOD method->method( ) is invalid).
Conclusion by me: you should read "If CALL METHOD is not used for the standalone method call, no chained method calls are possible ..."
Conclusion by Florian & SAP: In the comments below, Florian has asked the SAP support and indicates which exact sentence SAP should use in the next official release of the documentation
ADDENDUM (read it if you think wrongly that the documentation page is about "static methods", I hope I will make it clear that it's not).
The answers in this question prove that the documentation "CALL METHOD - Static Method Call (Obsolete)" is quite confusing.
The documentation title: here "static method call" means "static call of methods", not "call of static methods" (while at other places it could possibly have this meaning). If we could add parentheses in the written language, that would give these two possibilities, respectively :
static (method call) : static call of a method (whatever this method is of type "static" or "instance"; we could have a static call of an instance method)
(static method) call : call of a static method
Definitions :
static call : the class, interface or method names are "hardcoded" as symbols in the source code, not text literals, so that they are known by the compiler (for instance, CALL METHOD class=>method.). The opposite, a dynamic call, means that the names are passed through variables, which are only known at runtime (for instance, DATA classvar TYPE seoclsname VALUE 'CL_ABAP_TYPEDESCR'. CALL METHOD (classvar)=>(methodvar).) This other documentation page shows well that "static method call" is opposed to "dynamic method call", it never talks about "static and instance methods", only about "static method call" and "dynamic method call".
static method : a method being declared with CLASS-METHODS. For instance, a static call could be cl_ixml=>create( ), and a dynamic call could be DATA classvar TYPE seoclsname VALUE 'CL_IXML'. CALL METHOD (classvar)=>create.
Something in the documentation which confused me too, is the use of the term "static method" and examples based on static method only, because in fact the documentation page is about "static call", not static methods (instance methods could have been used) :
Syntax : CALL METHOD { static_meth( ) | static_meth( a ) | ... : what does mean "static_meth" here? In fact "static_meth" doesn't mean that it's a static method but it's any method in the context of a static method call. If you look at the documentation pages about "static calls" and "dynamic calls", you will see that the syntax is respectively static_meth( ) ... and CALL METHOD dynamic_meth ...
Example : a static method is again used in the three calls, all three of them having the same exact meaning but written with different syntaxes, to demonstrate that the first two calls are obsolete, and only the third one is recommended. In fact all three examples should have better used an instance method to avoid the confusion!
First of all, the method m1 is not static in your example and the quotation from the documentation has it that it is about a static method (CLASS-METHOD).
The only possible thing might be like in this example.
REPORT zutest3.
CLASS class_parent DEFINITION.
PUBLIC SECTION.
METHODS m1 RETURNING VALUE(r) TYPE REF TO class_parent.
CLASS-METHODS m1_static RETURNING VALUE(r) TYPE REF TO class_parent.
ENDCLASS.
CLASS class_parent IMPLEMENTATION.
METHOD m1.
CREATE OBJECT r.
WRITE / 'm1'.
ENDMETHOD.
METHOD m1_static.
CREATE OBJECT r.
WRITE / 'm2'.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
* this seems to be possible but no one sane calls a static method on an object reference
CALL METHOD class_parent=>m1_static( )->m1_static( ).
* the following two are not possible and will not compile either
* CALL METHOD class_parent=>m1_static( )=>m1_static( ).
* class_parent=>m1_static( )=>m1_static( ).
Second of all the CALL METHOD statement in this case is just a redundancy and its role is only informative.
Those two are equivalents
CALL METHOD cl->m1( ).
cl->m1( ).
analogically to for example this
DATA i TYPE i.
COMPUTE i = i + 1.
i = i + 1.
A bug in the docu. I reported it to the docu team and they answered that it has already been reported and they corrected it in the latest version.
The new statement is:
With the second variant without round brackets, chained method calls
are not possible and the operators NEW and CAST cannot be used.
We are writing a tool in Java that parses and transforms ABAP code. We therefore have no intention to write new ABAP code but our tool has to handle all of ABAP, even obsolete statements. Furthermore, I'm not an ABAP expert.
ABAP programs can use type groups, introduced by key word TYPE-POOL. Names of type groups have a maximal length of five (internally eight, if you count the prefix "% C"), their type code is TYPP. In the past, relying on these assumptions worked well for us.
Recently, we see ABAP programs with type code TYPP but with name longer than 5, e.g., 'OIA===========================P'. Furthermore, for each of those, there is another, empty object with same name but type code INCL. These new objects are referenced only if a regular type group is, too.
These new objects may be internal ones and irrelevant for us - I haven't seen any reference to them in the ABAP Keyword Documentation. On the other hand, they are confusing us because we see them.
Can someone explain to me the meaning of these objects and point me to some documentation?
Edit: Here examples from an EHP7 for SAP ERP 6.0 system
An example object. Entries in D010INC look fine:
The same object now using type pool mrm. Where do the additional includes come from?
These objects are introduced through inclusions, extensions and switched objects. To read along:
Check type pool MRM, type mrm_idoc_data_ers - that type contains a statement to include rmrm_idoc_data_ers_sbo. A similar include statement pulls rmrm_upd_arseg_nfm into mrm_upd_arseg. That explains the last two lines. Your parser should have caught that.
RMRM_IDOC_DATA_ERS_SBO contains an enhancement point named RMRM_IDOC_DATA_ERS_SBO_02 that belongs to an enhancement spot ES_RMRM_IDOC_DATA_ERS_SBO. Similarly, RMRM_UPD_ARSEG_NFM contains an enhancement point RMRM_UPD_ARSEG_NFM_01 that belongs to the enhancement spot ES_RMRM_UPD_ARSEG_NFM.
For ES_RMRM_IDOC_DATA_ERS_SBO, an enhancement implementation named ISAUTO_MRM_RMRM_IDOC_DATA_ERS exists. For ES_RMRM_UPD_ARSEG_NFM, an implementation named /NFM/MM_RMRM_UPD_ARSEG_NFM exists. That explains the references ending with =E
The implementation ISAUTO_MRM_RMRM_IDOC_DATA_ERS is located in the package ISAUTO_MRM. The implementation /NFM/MM_RMRM_UPD_ARSEG_NFM is located in the package /NFM/MM. That explains the references ending with =P. Obviously, these references are not generated for every package:
The package ISAUTO_MRM is controlled by the switch AM_ERS, the package /NFM/MM is controlled by the switch /NFM/MM. That explains the references ending in =S.
Ultimately, these references can be used to determine which programs need to be re-generated when the state of a switch is changed.
Suppose I have the following instantiation
first_mux_input=top.middle.down[i];
second_mux_input=top.middle.down[i+1];
assign down = (select[i])? first_mux_input:second_mux_input;
supposing there are a lot of muxes and their outputs go to the inputs to muxes that are placed below them.
I'm using the variable "down" before I define it. is this legal since verilog compiles all the lines subsequently and not by order(in this case)?
thanks
The assign statement is not a declaration. A declaration would be:
wire down;
If you never declare down such as this, it will be implicitly declared.
Section 6.10 of IEEE 1800-2012 states:
If an identifier appears on the left-hand side of a continuous assignment statement, and that identifier
has not been declared previously in the scope where the continuous assignment statement appears or
in any scope whose declarations can be directly referenced from the scope where the continuous
assignment statement appears (see 23.9), then an implicit scalar net of default net type shall be
assumed. See 10.3 for a discussion of continuous assignment statements.
and then:
See 22.8 for a discussion of control of the type for implicitly declared nets with the `default_nettype
compiler directive.
This (I believe) typically means a wire in Verilog and logic in SystemVerilog.
Now, as far as using the value before it is assigned, that's perfectly legal. As long as not declared after it is used or assigned.
It depends on your synthesizer. I have worked only with Xilinx. In my case Xilinx accepts this type definition for simulation. But for synthesis you need to define a wire/reg before instantiation.
I'm looking at the description of CALL - System Function Call in the SAP ABAP Keyword Definition. Such calls have the format CALL 'xxx' ID 'yyy' FIELD 'zzz'. The ABAP Keyword Definition does not mention that sy-subrc is set by calling a system function. But somehow, I suspect that it is.
Can I "trust" the Keyword Definition in such a case? (sy-subrc not mentioned => not set)
What would be a "good" example system function call to test it on an SAP system? (does not break/change anything, exists on all systems)
Note that I'm not an ABAP programmer and I usually handle third-party ABAP programs in Java as text / parse tree. I know that one usually should not call system functions, but the ABAP code I look at might have such calls. Furthermore, I'm not interested in the actual value a specific system call sets sy-subrc to, just in the fact whether system calls set/alter sy-subrc or not.
Well, as you are asking this question you are already aware this is NOT recommended approach to use direct SYSTEM calls. However, if you still want to use them...
By using CALL statement SAP kernel C-modules are called and without knowing the source we can not interpret the returning value confidently, either it's 0 or 1.
Despite there are examples (see line 230 of DYNP_VALUES_READ FM) where sy-subrc value is checked after system calls, nobody except SAP knows which value to check in certain case. Nor we.
Also there were reports (1, 2) about ambiguous meaning of these values during tests.
So the answer is NO, sy-subrc in this context brings no meaningful information.
P.S. Answering your questions:
No, you cannot interpret it that way. If something is not mentioned in ABAP Documentation then this not known for sure or not meaningful at all.
I cannot confirm this is good idea at all (to test system calls), but if you want you can try call SYSTEM function.
It calls arbitrary Unix command. For example, you can move files stored on your ABAP Server like this:
CALL 'SYSTEM'
ID 'COMMAND'
FIELD 'mv /usr/sap/temporary
/usr/sap/definite'.
Now this should be a safe call that works on any system:
DATA: dbserver TYPE char255.
CALL 'C_SAPGPARAM' ID 'NAME' FIELD 'SAPDBHOST'
ID 'VALUE' FIELD dbserver.
As you probably already know there are some exceptions that can occur. As for sy-subrc, when a command sets sy-subrc it is usually explicitly mentioned in the documentation including which values it can hold and their meaning. But don't quote me on that.
Simple (harmless) function modules are RH_GET_DATE_DAYNAME that requires the language and 10 character date (eg. 26.10.2016) as input fields and DATE_TO_DAY that only requires the 10 character date as input. The sy-subrc should be returned as 0 if a valid date is entered.
While modifying an existing program's CASE statement, I had to add a second block where some logic is repeated to set NetWeaver portal settings. This is done by setting values in a local variable, then assigning that variable to a Changing parameter. I copied over the code and did a Pretty Print, expecting to compiler to complain about the unknown variable. To my surprise however, this code actually compiles just fine:
CASE i_actionid.
WHEN 'DOMIGO'.
DATA: ls_portal_actions TYPE powl_follow_up_sty.
CLEAR ls_portal_actions.
ls_portal_actions-bo_system = 'SAP_ECC_Common'.
" [...]
c_portal_actions = ls_portal_actions.
WHEN 'EBELN'.
ls_portal_actions-bo_system = 'SAP_ECC_Common'.
" [...]
C_PORTAL_ACTIONS = ls_portal_actions.
ENDCASE.
As I have seen in every other programming language, the DATA: declaration in the first WHEN statement should be encapsulated and available only inside that switch block. Does SAP ignore this encapsulation to make that value available in the entire CASE statement? Is this documented anywhere?
Note that this code compiles just fine and double-clicking the local variable in the second switch takes me to the data declaration in the first. I have however not been able to test that this code executes properly as our testing environment is down.
In short you cannot do this. You will have the following scopes in an abap program within which to declare variables (from local to global):
Form routine: all variables between FORM and ENDFORM
Method: all variables between METHOD and ENDMETHOD
Class - all variables between CLASS and ENDCLASS but only in the CLASS DEFINITION section
Function module: all variables between FUNCTION and ENDFUNCTION
Program/global - anything not in one of the above is global in the current program including variables in PBO and PAI modules
Having the ability to define variables locally in a for loop or if is really useful but unfortunately not possible in ABAP. The closest you will come to publicly available documentation on this is on help.sap.com: Local Data in the Subroutine
As for the compile process do not assume that ABAP will optimize out any variables you do not use it won't, use the code inspector to find and remove them yourself. Since ABAP works the way it does I personally define all my variables at the start of a modularization unit and not inline with other code and have gone so far as to modify the pretty printer to move any inline definitions to the top of the current scope.
Your assumption that a CASE statement defines its own scope of variables in ABAP is simply wrong (and would be wrong for a number of other programming languages as well). It's a bad idea to litter your code with variable declarations because that makes it awfully hard to read and to maintain, but it is possible. The DATA statements - as well as many other declarative statements - are only evaluated at compile time and are completely ignored at runtime. You can find more information about the scopes in the online documentation.
The inline variable declarations are now possible with the newest version of SAP Netweaver. Here is the link to the documentation DATA - inline declaration. Here are also some guidelines of a good and bad usage of this new feature
Here is a quote from this site:
A declaration expression with the declaration operator DATA declares a variable var used as an operand in the current writer position. The declared variable is visible statically in the program from DATA(var) and is valid in the current context. The declaration is made when the program is compiled, regardless of whether the statement is actually executed.
Personally have not had time to check it out yet, because of lack of access to such system.