I have two method: METHOD_A() and METHOD_B().
In METHOD_A() I use another method METHOD_A_A which returns me an internal table et_entityset with some data.
I want to export et_entityset to memory and import it from memory in METHOD_B(), but when I import et_entityset it's always blank.
My minimal reproducible example:
In method METHOD_A():
DATA et_entityset TYPE some_type.
lo_camp->METHOD_A_A(
EXPORTING
it_order = SOMETHING
IMPORTING
et_entityset = et_entityset
).
IF et_entityset IS NOT INITIAL.
EXPORT lt_mem_content FROM et_entityset TO MEMORY ID 'lt_memory_content'.
ENDIF.
In METHOD_B():
DATA lt_mem_content TYPE some_type.
IMPORT lt_mem_content TO lt_mem_content FROM MEMORY ID 'lt_memory_content'.
READ TABLE lt_mem_content INTO DATA(ls_mem_content) INDEX 1.
DATA(lv_content_id) = ls_mem_content-id.
Export to memory / Import to memory is valid only within a session.
So assuming you have not made a typo / upper lowercase error with the export and memory commands, then I can only assume you are no longer with the call sequence within a session.
Eg new calls to stateless services, new rfc calls not reusing a session .
A cross Workprocess cross session option.
Export ... to SHARED BUFFER
HOWEVER, there is NO guarantee the value will be there, as there is an automatic free as required algorithm that will discard entries to make room for new entries.
So if you plan to use this, make sure sufficient memory is allocated to the shared memory buffer. in AL12 you can monitor the entries.
The "ABAP memory", which is used by Export to memory and Import to memory, is accessible only by programs running in the same "ABAP session" (explanation of different types of memories and types of sessions in ABAP-based systems).
Two programs may run in the same ABAP session if they call each other, directly or indirectly, via statements like SUBMIT, CALL TRANSACTION, procedure call, etc.
For example:
If there are two HTTP calls, that will be two different ABAP sessions. There is one exception for BSP, which is an old SAP technology, there is a "stateful" flag at BSP level which retains and reuses the ABAP sessions.
If a user logs in once (one user session), and opens a new window (Ctrl+N), all programs executed in that window run in a second "ABAP session", i.e. two programs running in each session cannot communicate via the "ABAP memory".
Example to make two programs exchange some data via the ABAP memory:
REPORT zprogram1.
DATA variable TYPE string.
EXPORT memory_name_1 = `A` TO MEMORY ID 'my Z memory 1'.
SUBMIT zprogram2 AND RETURN.
IMPORT memory_name_2 = variable FROM MEMORY ID 'my Z memory 2'.
ASSERT variable = `AB`. " <=== proof that data was transferred via ABAP memory
REPORT zprogram2.
DATA variable TYPE string.
IMPORT memory_name_1 = variable FROM MEMORY ID 'my Z memory 1'.
variable = variable && `B`.
EXPORT memory_name_2 = variable TO MEMORY ID 'my Z memory 2'.
PS: an "ABAP session" may be better known as the old name "external session".
Related
Hi I am new to solidity and I am wondering why we use the keyword memory when declaring a function, what happens if we choose not to use it? For example
function createObject(string _name, uint _dna) public {
object.push(Object(_name, _dna));
}
instead of
function createObject(string memory _name, uint _dna) public {
object.push(Object(_name, _dna));
if you don't write it, easily it will give error
Without the memory keyword, Solidity tries to declare variables in storage.
Much like RAM, Memory in Solidity is a temporary place to store data whereas Storage holds data between function calls. The Solidity Smart Contract can use any amount of memory during the execution but once the execution stops, the Memory is completely wiped off for the next execution. Whereas Storage on the other hand is persistent, each execution of the Smart contract has access to the data previously stored on the storage area.
That is, the structure of storage is set in stone at the time of contract creation based on your contract-level variable declarations and cannot be changed by future method calls. BUT -- the contents of that storage can be changed with sendTransaction calls. Such calls change “state” which is why contract-level variables are called “state variables”. So a variable uint8 storagevar; declared at the contract level can be changed to any valid value of uint8 (0-255) but that “slot” for a value of type uint8 will always be there.
If you declare variables in functions without the memory keyword, then solidity will try to use the storage structure, which currently compiles, but can produce unexpected results. memory tells solidity to create a chunk of space for the variable at method runtime, guaranteeing its size and structure for future use in that method.
memory cannot be used at the contract level. Only in methods.
The memory keyword tells Solidity to store the parameter in a certain place which allows you to change that parameter inside the function itself. Pretty much like RAM.
Calldata is the same but the parameter is immutable. It's better to use that if you don't plan on changing the parameter inside the function because it's more efficient.
Storage tells Solidity that the value is in the state of the smart contract. It's also more efficient than memory if the parameter is indeed in the state.
You can get more information about the difference between these 3 keywords in this article
Is it possible to run the simulation for a certain amount of ticks, and then read the value of selected statistics from the Python config script?
Edit: a patch has been submitted at: https://gem5-review.googlesource.com/c/public/gem5/+/33176
As of 3ca404da175a66e0b958165ad75eb5f54cb5e772 it does not seem possible, but it is likely easy to implement.
We already have a loop that goes over all stats in the Python under src/python/m5/stats/__init__.py, so there are python stat objects fully exposed and iterated, but the actual stat value appears not exposed to them, only the stat name:
def _dump_to_visitor(visitor, root=None):
# Legacy stats
if root is None:
for stat in stats_list:
stat.visit(visitor)
# New stats
def dump_group(group):
for stat in group.getStats():
stat.visit(visitor)
The visit method then leads the value to be written out to the stat file, but the Python does not do it.
However, visit is already a pybind11 Python C++ extension defined at src/python/pybind11/stats.cc:
py::class_<Stats::Info, std::unique_ptr<Stats::Info, py::nodelete>>(
m, "Info")
.def("visit", &Stats::Info::visit)
;
so you would likely need to expose the value there.
One annoyance is that each stat type that derives from Stats::Info has a different data representation, e.g. scalars return a double:
class ScalarInfo : public Info
{
public:
virtual Counter value() const = 0;
but vectors an std::vector:
class VectorInfo : public Info
{
public:
virtual const VCounter &value() const = 0;
and so there is no base value() method due to the different return types, you'd juts need to expose one per base class.
TODO I couldn't see the value() method on the Python still, likely because they were still objects of the base class, needs more investigating.
You can use variation of the gem5-stat-summarizer. gem5-stat-summarizer is used to extract selected gem5 statistics to a csv file when you have multiple stats.txt files
I have a test plan that looks like
Test plan
Jsr223 sampler
{
def lst = [100 elements];
vars.putObject("lst",lst);
}
loop controller(100 times)
{
Http request
preprocessor
{
lst = vars.getObject("lst");
}
}
Now does the lst in preprocessor uses the same memory of lst in jsr223 sampler or it creates its new memory and uses.
Q2) Another question is, does the lst memory in preprocessor gets cleared for every iteration or does it created new memory for each iteration.
In your setup you always refer to the same object which lives in JMeterVariables class instance, it neither allocates new portion of memory nor frees it during new iterations.
However be aware that each JMeter thread (virtual user) will have this object in its local storage so for 1 thread you will have 1 instance, for 2 threads - 2 instances.
So if you have > 1 thread and use the same object across all threads - it's better to use props instead of vars, as per documentation:
Properties are not the same as variables. Variables are local to a thread; properties are common to all threads
If you want to clear the object manually use vars.remove() function where needed like:
vars.remove('lst')
In order to reduce memory consumption you might consider putting your objects into a CSV file and go for CSV Data Set Config which doesn't load the full file into memory and has flexible sharing options of the values across the threads.
The CiA 301 CANopen protocol specification defines two objects that a device may implement to save and restore parameters:
Object 1010h - Store Parameters
When a device implements this object, the CANopen master writes the value "save" to one of the subentries of the object to cause the corresponding set of parameters to be written to non-volatile memory.
Object 1011h - Restore Default Parameters
When a device implements this object, the CANopen master writes the value "load" to one of the subentries of the object to restore the corresponding default parameters to be restored.
Device Reset
The CiA 301 specification says that "default values shall be set valid after the CANopen device is reset" - by way of a power cycle, NMT reset node (sub-index 01h to 7Fh) or NMT reset communication (sub-index 02h).
What are 'the default values'?
Does "the default values" mean:
The values set by the Store Parameters object? In which case, how can the device be reset to the original factory default settings?
The original factory default settings? If so, when should the saved parameters be restored?
A combination of the above, whereby the factory default settings are restored by a device reset, and the Store Parameters values are restored by the Restore Default Parameters object?
Some other definition?
I understand the mechanisms for reading from the objects to obtain the device capabilities and writing the guard pattern to them to trigger the required action. I also know which values to save and which subsets to save for the different sub-indeces.
The thing I do not understand is when should the factory default values be used (if at all) rather than the saved values, and vice versa?
Object 1010h - Store Parameters
This does exactly what you'd expect: it causes the specified parameters to be stored.
Object 1011h - Restore Default Parameters
This causes and parameters that were previously saved by the Store Parameters to be no longer saved so that the original default values are used when the device resets. It is not equivalent to 'Load Parameters' (there is no such object), as this operation occurs automatically when the device resets, rather it could be thought of as 'Delete Stored Parameters'.
Summary
Object 1010h causes parameters to be saved.
Object 1011h causes saved parameters to be deleted.
On reset, parameters will be loaded from their saved values, if they have been stored, or set to their default values if the default values have been restored.
How do I call the SAP report (for example RSPARAM) with help JCo?
What RFC may be used to remotely call SA38 transaction with RSPARAM (e.t.c.) as parameter and then return results for later work ?
RFC is for calling function modules, not programs. It's possible to use some generic function module to start a report, but since you'll usually want to process the results of the program and the program does not know that it was meant to deliver its results in a machine-readable way, you probably won't get too far this was. What exactly are you trying to do?
With the nearly infinite possible results of calling a transaction, i don't think there is a RFC to execute such an operation and return a result. What would be the result in case of an ALV display, or if the program then wait for some interactions ?
You can display a transaction in SAP portal using transactions Iviews. You're then using the portal page as a HTMLGui for your transaction.
also, some FM can sometime be used to perform operations instead of a full program (ie HR_INFOTYPE_OPERATION instead of pa30).
regards
Guillaume
Edition : since you want the result of RRSPARAM, you could encapsulate the "important" part (form SHOW_ACTUAL_PAR_VALUES_ALV) in a module function accessible by RFC, and returning a table of CST_RSPFPAR_ALV (ie the same structure that is displayed in the report)
regards
If You don't find a function to call, just create one by yourself. Tag it as callable from outside via RFC and in the coding, perform such things as "submit report xyz with param1 = value1 ... and return ... exporting list to memory". Then you can even return list output from this. Define the interface of the freshly created function module as you need (that means, report name as input, list output as a table of strings, e.g.). Attention, there is of course a big security risk, having an remote function accepting variable reportnames. But I am sure You know :-)