Size of LUW's

Hi All,
Iam trying to findout the no.of records the delta generated in R/3, Iam checking in RSA7 its showing some 651 in Totals column, i know that 651 stands for no. of LUW, when iam trying to display data in that datasource delta, its asking me for
choose
Package _________ to _________
Data record ___ to ____
Extraction Parameters
Data pack size __________ ( 42283 default)
Max. no. records _________ (1000 default)
where are these default figures comin from.
when i ran it with those figures, its timing out with short dupms.
any help is appreciated ( of course w/ points)
Regards,
Robyn.

Are you getting a QRFC error? If so, you don't have security in R/3 for QRFC.
What is the error you are getting?
.smw

Similar Messages

OSS Notes Please

Dear Gurus,
Can anyone send me the following OSS notes if u have. 567747, 130253 and 417307. Your kind help will be definitely awarded.
My mail ID is [email protected]
Best Regards
Mohan Kumar
Message was edited by: mohan kumar

hi Mohan,
i think you will need to have access to oss yourself,
note 567747 is composite one that contains several notes.
sent to you mail ...
130253
Symptom
Uploading transaction data to BW takes too long
Other terms
Business Warehouse, data upload, batch upload, transaction data upload,
performance, runtime, data load, SPLIT_PARTITION_FAILED ORA00054
Reason and Prerequisites
Loading data from a mySAP system (for example, R/3) or from a file takes a very long time.
Solution
The following tips are a general check list to make the mass data upload to the Business Warehouse (BW) System as efficient as possible.
Tip 1:
Check the parameter settings of the database as described in composite Note 567745.
Check the basis parameter settings of the system.
Note 192658 Setting basis parameters for BW Systems
See the following composite notes:
Note 567747 Composite note BW 3.x performance: Extraction & loading
Note 567746 Composite note BW 3.x performance: Query & Web applications
Tip 2:
Import the latest BW Support Package and the latest kernel patch into your system.
Tip 3:
Before you upload the transaction data you should make sure that ALL relating master data has been loaded to your system. If no master has been loaded yet, the upload may take up to 100 percent longer because in this case, the system must retrieve master data IDs for the characteristic attributes and it must add new records to the master data tables.
Tip 4:
If possible, always use TRFC (PSA) as the transfer method instead of
IDocs. If you (have to) use IDocs, keep the number of data IDocs as low
as possible. We recommend an IDoc size of between 10000 (Informix) and 50000 (Oracle, MS SQL Server).
To upload from a file, set this value in Transaction RSCUSTV6.
To upload from an R/3 system, set this value in R/3 Customizing (SBIW -> General settings -> Control parameters for data transfer).
Tip 5:
If possible, load the data from a file on the application server and not from the client workstation as this reduces the network load. This also allows you to load in batch.
Tip 6:
If possible, use a fixed record length when you load data from a file (ASCII file). For a CSV file, the system only carries out the converison to a fixed record length during the loading process.
Tip 7:
When you load large data quantities from a file, we recommend that you split the file into several parts. We recommend using as many files of the same size as there are CPUs. You can then load these files simultaneously to the BW system in several requests. To do this, you require a fast RAID.
Tip 8:
When you load large quantities of data in InfoCubes, you should delete
the secodary indexes before the loading process and then recreate them afterwards if the following applies: The number of the records that are loaded is big in comparison to the number of records that already exist in the (uncompressed) F fact table. For non-transactional InfoCubes, you must delete the indexes to be able to carry out parallel loading.
Tip 9:
When you load large quantities of data in an InfoCube, the number range buffer should be increased for the dimensions that are likely to have a high number of data sets.
To do this, proceed as follows. Use function module RSD_CUBE_GET to find the object name of the dimension that is likely to have a high number of data sets.
Function module settings:
I_INFOCUBE = 'Infocube name'
I_OBJVERS = 'A'
I_BYPASS_BUFFER = 'X'
The numbers for the dimensions are then contained in table 'E_T_DIME', column 'NUMBRANR'. If you enter 'BID' before this number, you get the relevant number range (for example BID0000053).
You can use Transaction SNRO (-> ABAP/4 Workbench -> Development --> Other tools --> Number ranges) to display all number ranges for the dimensions used in BW if you enter BID*. You can use the object name that was determined beforehand to find the required number range.
By double-clicking this line, you get to the number range maintenance. Choose Edit -> Set-up buffering -> Main memory, to define the 'No. of numbers in buffer'.
Set this value to 500, for example. The size depends on the expected data quantity in the initial and in future (delta) uploads.
!! Never buffer the number range for the package dimension !!
Tip 10:
When you load large quantities of data, you should increase the number
range buffer for the info objects that are likely to have a high number of data sets. To do this, proceed as follows:
Use function module RSD_IOBJ_GET to find the number range name of the info object that is likely to have a high number of data sets.
Function module settings:
I_IOBJNM = 'Info object name'
I_OBJVERS = 'A'
I_BYPASS_BUFFER = 'X'
The number for the info object is in table 'E_S_VIOBJ', column 'NUMBRANR'. Enter 'BIM' in front of this number to get the required number range (for example BIM0000053).
Use Transaction SNRO (-> ABAP/4 Workbench -> Development --> Other tools --> Number ranges) to display all number ranges used for the info objects in BW by entering BIM*. By entering the object name determined beforehand you can find the desired number range.
By double-clicking this line you get to the number range object maintenance. Choose Edit -> Set-up buffering -> Main memory, to define the 'No. of numbers in buffer'.
Set this value to 500, for example. The size depends on the expected data quantity in the initial and in future (delta) uploads.
!! Never buffer the number range object for the characteristic 0REQUEST!!
417307
Symptom
Performance load is too high/not justifiable during data load.
Customizing settings via extractors IMG path (Transaction SBIW in the OLTP system; can be called directly in the OLTP or using Customizing, from the BW system) do not yield any considerable improvement or are not clear.
The settings in Table ROIDOCPRMS or in the Scheduler in the BW system are not taken into account by some extractors. How is the data package size defined for the data transfer to the BW? Are there application-specific features to determine the package size? If so, what are they?
Other terms
SBIW, general settings extractors, MAXSIZE, data volume, OLTP, service API, data package size, package size, performance
Reason and Prerequisites
The general formula is:
      Package size = MAXSIZE * 1000 / size of the transfer structure,
                    but not more than MAXLINES.
You can look up the transfer structure (extract structure) in Table ROOSOURCE in the active version of the DataSource and determine its size via SE11 (DDIC) -> Utilities -> Runtime object -> Table length.
The system default values of 10,000 or 100,000 are valid for the MAXSIZE and MAXLINES parameters (see the F1 help for the corresponding fields in ROIDOCPRMS). You can use the IMG Transaction SBIW (in the OLTP system) "Maintain General settings for extractors" to overwrite these parameters in Table ROIDOCPRMS on a system-specific basis. You also have the option of overriding these values in the scheduler (in the target BW system). However, in the Scheduler (InfoPackage) you can only reduce the MAXSIZE. The advantage of using the Scheduler to carry out maintenance is that the values are InfoSource-specific.
However, some extractors have their own flow logic which MAXSIZE does not load 1:1 from the ROIDOCPRMS.
This Note does not cover all SAP applications.
Solution
Application/DataSource               Standard settings or note
Generic extractor                     Standard (Example: Note 409641)
Delta Extraction via DeltaQueue       Standard as of PlugIn 2000.2
                                           Patch 3
LO-LIS                                 Standard
Logistic Cockpit SD                       Notes 419465 and 423118
Logistic Cockpit MM-IM:
Extraction 2LIS_03_UM                     Notes 537235 and 585750
Extraction 2LIS_03_BF                     Note 454267
           In general, the following applies to Logistic Cockpit Extraction: The package size set only serves as guideline value.
            Depending on the application, contents and structure of the documents, and the selection in the reconstruction program, the actual size of the transfer packages may differ considerably. That is not an error.
            For 'Queued Delta' update mode the package size of 9999 LUWs (=Logical Unit of Work, in this particular case documents or posting units per transaction are concerned) is set for LO Cockpit. However, if a transaction updated more than 10000 documents at once, the number 9999 would be invalid. This is because an update process cannot be split.
            In the case of a 'Direct Delta' update mode there is no package size for LUW bundling. In the DeltaQueue (RSA1) every LUW is updated individually.
           Also note the following:
                     If you want to transfer large data sets into the BW System, it is a good idea to carry out the statistical data setup and the subsequent data transfer in several sub-steps. In doing so, the selections for the statistical data setup and in the BW InfoPackage must correspond to each other. For performance reasons, we recommend using as few selection criteria as possible. You should avoid complex selections. After loading init delta with selection 1, the setup table has to be deleted and rebuilt with selection 2.
                     Bear the following in mind: The delta is loaded for the sum of all selections from the init deltas. Remember that the selections are made so that they do not impede the delta load, for example, if you have initialized the delta for the periods January 1st, 1999 to December 1st, 2000 and December 2nd, 2000 to August 1st, 2001 then you get a time interval from January 1st, 1999 to August 1st, 2001 in the BW. Documents from August 2nd, 2001 are no longer loaded.
CO-OM                                     Note 413992
PS                                        Standard or according
                                           to Note 413992
CO-PC                                     Standard
FI (0FI-AR/AP-3)                          First tables with open items(BSID for customers, BSIK for vendors) are read. The package size from the MAXISE field in Table ROIDOCPRMS is used in the extraction from these tables. If the packages are grouped together according to ROIDOCPRMS and a few data records still remain, these remaining records are transferred in one additional package.
After the open items are extracted, the system extracts from the table of cleared items (BSAD for customers, BSAK for vendors). In this extraction,the package size from the MAXSIZE field is adhered to.
FI (0FI-/AR/AP/-4 , new as of BW 30A) Like FI-AR/AP-3, but with one difference: if there are remaining records after the system reads the open items using the setting in the MAXSIZE field, they are not transferred in one extra package, but added to the first package of items read from the table of cleared items. For example, if 10 data packages with 15000 data records are extracted from Table BSID in accordance with ROIDOCPRMS, and 400 data records remain, the package size of the first data package from Table BSAD is 15400.
Both new and changed records are formatted in the following sequence in the delta transfer: 1) new BSIK/BSID records; 2) new BSAK/BSAD records; 3) changed BSIK/BSID records; 4) changed BSAK/BSAD records.
Package size 0FI_GL_4:
Prior to Note 534608 and the related notes, package size could vary considerably since the MAXLINES were applied to the document headers only. Then all documents lines for the document headers were read and transferred. As a result, the packages were 2 to 999 times as large as MAXLINES depending on the number of line items per document.
Note 534608 and the related notes changed the logic so that the MAXLINES is now also applied to the document lines. For each package, MAXLINES can be exceeded by up to 998 lines since a document is always transferred completely in one package. Smaller 'remaining packages' may also occur; for example if MAXLINES = 10000, and 10000 document headers with 21000 lines are selected, 2x10000 and the remainder of 1000 were were transferred in a separate package. Selection logic in 0FI_GL_4: Selection of the new FI documents via CPUDT -> the changed documents are then selected via Table BWFI_AEDAT. When changing the selection from new to changed documents, a package may occur which consists of the 'remainder' of the CPUDT selection and the first package of the BWFI_AEDAT selection. This package can then have a maximum size of 2 x MAXLINES.
FI-FM                                  Note 416669
EC-PCA                                 For the most part, the systemadheres to the standard settings but for technical reasons, packages packages smaller than the MAXSIZE or 7200 larger than the MAXSIZE may be omitted in Table ROIDOCPRMS
FI-SL                                  as in EC-PCA
PT                                     Standard (refer to Note
                                       397209)
PY                                     Standard
PA                                     Standard
RE                                     Standard
ISR-CAM (Category Management,
         new as of PlugIn 2001.1)     Standard
CO-PA                                  During the initialization and fullupdate in the profitability analysis, a join is always read from two tables (For details see Note 392635). To avoid terminations caused by Select statements that run for too long, access occurs with intervals for the object numbers (fixed size 10,000). New intervals are read until the package size requested by BW is reached. Therefore the size of the data package is always equal to or larger than the specification, but it can vary considerably.
Master data:
Business partner                       Standard
Product                                Standard
Customer                               Standard
Vendor                                 Standard
Plant                                  Standard
Material                               Standard
567747
Symptom
You want to improve the performance of the extraction and loading of your data into SAP BW 3.x.
Solution
This is a composite note that deals with performance-relevant topics in the area of extraction and loading.
If you encounter performance problems, ensure that the current Support Package has been imported.
This note is continually updated. You should therefore download a new version on a regular basis.
You will find further documents in the SAP Service Marketplace, alias bw under the folder "Performance".
Contents:
I.    Extraction from the OLTP
II.   Loading generally
III. Master data
IV.   Roll-Up/aggregate structure
V.    Compression
VI.   Hierarchies/attribute realignment run
VII. DataMart interface
VIII. ODS objects
IX.   Miscellaneous
I.    Extraction from the OLTP
Note 417307: extractor packet size: Collective note for applications
Note 505700: LBWE: New update methods from PI 2002.1
Note 398041: INFO: CO-OM/IM IM content (BW)
Note 190038: Composite note performance for InfoSource 0CO_PC_01 and
Note 436393: Performance improvement for filling the setup tables
Note 387964: CO delta extractors: poor performance for Deltainit
II.   Loading generally
Note 130253: Notes on uploading transaction data into BW
Note 555030: Deactivating BW-initiated DB statistics
Note 620361: Performance data loading/Admin. data target, many requests
III. Master data
Note 536223: Activating master data with navigation attributes
Note 421419: Parallel loading of master data (several requests)
IV.   Roll-Up/aggregate structure
Note 484536: Filling aggregates of large InfoCubes
Note 582529: Rollup of aggregates & indexes (again as of BW 3.0B Support Package 9)
V.    Compression
Note 375132: Performance optimization for InfoCube condensation
Note 583202: Change run and condensing
VI.   Hierarchies/attribute realignment run
Note 388069: Monitor for the change run
Note 176606: Apply Hierarchy/Attribute change ... long runtime
Note 534630: Parallel processing of the change run
Note 583202: Change run and condensing
VII. DataMart interface
Note 514907: Processing complex queries (DataMart, and so on)
Note 561961: Switching the use of the fact table view on/off
VIII. ODS objects
Note 565725: Optimizing the performance of ODS objects in BW 3.0B
IX.   Miscellaneous
Note 493980: Reorganizing master data attributes and master data texts
Note 729402: Performance when compiling and searching in the AWB

Error in RFC Adapter PI 7.10 maximum size of requests for one LUW

Hello all,
I have a big issue on our Development - SAP PI 7.10 System. If I try to push a RFC from a Client System
I get follow error messagei in the Runtime Workbench (RWB) back:
processing error to be caused by: com.sap.aii.adapter.rfc.core.server.RfcServerException: maximum size of requests for one LUW has been reached (1). handling of request for tRFC (TID: 0AA001B8712C49D35D4D06C2) not possible (server: RfcServer[PKG_R3_D07_600_RFC_SND]1)
But I don't know why. I checked follow OSS Notes:
730870 and 774705 w/o success. It will be nice somebody can help me.
Thanks
S. Kohler
P.S. We have the same scenario in our Quality SAP XI System and there works. I couldn't find any
differences between the Adapters. Is there a problem with the parameters ????

Hello Tarang Shah,
okay. Here again ( I thought I mentioned above):
in Q50 (SAP PI 7.10 System) we create a RFC Server with the program ID RFC_Q50.
in D64 (SAP PI 7.10 System) we vreate a RFC Server with the program ID RFC_D64
in D07 (SAP R/3 4.7 x110) we create a RFC Connection to D64 with the program ID RFC_D64.
The testconnection works well. I see in our Dev. SAP PI System (D64) that the connection works.
The problem is here, if you start in the application (System D07) the push, you get the error :
maximum size of requests for one LUW has been reac hed (1). handling of re
in Q50 (SAP R/3 4.7 x110) we create a RFC Connection to Q50 with the program ID RFC_Q50.
The testconnection in Q17 works well. Also the push from the application (System Q17.)
This means, the functionallity is okay on both sides (Q17 and D07) only the application sending
process from D07 makes trouble ( you see in Transaction SM 58 on Client Site, the error as I mentiond above and in SAP PI side.) It seems that SAP PI could't accept more as one LUWs
in the same time. Q50 (Q- System) accepted.
So, this is the reason in my point of view, that the problem isn't the connection, seems more
an paramter problem in D64 side. But I don't know which parameters. I checked the OSS Note 730870 and 774705 w/o success.
Thanks
S. Kohler

"maximum size of requests for one LUW has been reached"

Hi
In Rfc to jdbc scenario,
how can remove this error
"maximum size of requests for one LUW has been reached"
thanks

can u pls tell ,
while mapping the rfc wth jdbc request message,
where shud this "access" node be mapped
i mapped it wth the root element of rfc message type that contains the fields structure as the child elemnts in this case shud be fileds--is it right?
also the err now has changed to "Commit fault: com.sap.aii.af.rfc.afcommunication.rfcAFWException: senderA"
thanks

Error maximum size of requests for one LUW

Hi all,
My problem is:
In SAP ERP i call a function (ZQTC_NFE_CANCEL_XML_PI) that is implemented in SAP PI.
Follow below my source code of a call:
start----
DATA: gv_rfcdest TYPE rfcdest,
      gs_cancel_xml TYPE zqtc_cancel_xml_layout.
gv_rfcdest = 'SAPAVGXI'
CALL FUNCTION 'ZQTC_NFE_CANCEL_XML_PI' IN BACKGROUND TASK
   DESTINATION gv_rfcdest
   EXPORTING
     i_cancel_xml          = gs_cancel_xml
   EXCEPTIONS
     communication_failure = 1
     system_failure        = 2
     OTHERS                = 3.
IF sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
        WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
COMMIT WORK.
end----
When execute this function the error is "maximum size of requests for one LUW"
Attention
gs_cancel_xml is not big.
Can anyone help me please!

Hello,
RFC destination progid created in R/3 should be same in XI system either D or Q system
In your case check the RFC destination used and progid associated in that and make sure that the same progId exists in the system you want to receive data
Note : progID is key for receiving data so make sure only one is active at a time.(in your case required D or Q s id in other system change the progid)
Regards,
Phani

What is luw (logical unit of work)

pls tell me what is luw (logical unit of work)
what r the types of luw .
2 what ispurpose of code inspector and extended program check
pls expalin the diffrence b/w those two
3what are the candidate keys in db tables
4 what is the difference b/w occurs 1 and occurs 2 clauses
data : begin of itab occurs 0 .
data : itab type standard table of structure type initial size 1 with header line
pls tell diffrence between theese two statements
5can u pls tell what is the client in sap
pls tell answers to questions
pls dont give any websites addresses to see answers
6 what is the transaction from database point of view
7 what is the variant in alv reports
how do we use reuse_alv_grid_variant_get fun module in alvs

hi,
this gives complete idea
SAP LUW
Since, as a rule, an application program is processed by several work processes in succession, and every change of the work process is linked with an implicit database commit , an application program is not automatically linked with a single database LUW. This applies in particular to dialog-oriented applications, in which one database LUW is assigned to one dialog step.
To ensure the data consistency of application programs that are executed across different work processes, the application statements are not directly executed in an SAP LUW, rather, are first registered and then executed by a single work process, that is, in a single database LUW.
Two techniques are available for bundling the change statements in a database LUW:
Bundling via function modules (update)
Through the statement CALL FUNCTION...IN UPDATE TASK, an update function module is registered for subsequent execution in an update work process.
Bundling via function modules (transactional RFC)
Through the statement CALL FUNCTION... IN BACKGROUND TASK DESTINATION, a remote- compatible function module is registered for subsequent asynchronous execution via the RFC interface (transactional RFC ).
Bundling via subprograms
Through the statement PERFORM ... ON COMMIT, a subprogram is registered for subsequent execution in a different work process.
Statements for SAP LUWs
A SAP LUW is controlled via the Open SQL statements COMMIT WORK, ROLLBACK WORK and SET UPDATE TASK LOCAL.
Note
A function module can be classified either as an update function module or remote-compatible, but not both at the same time. The update helps realize SAP LUWs within an SAP System, while the transactional RFC creates LUWs in distributed systems.
COMMIT WORK
Variants:
1. COMMIT WORK [AND WAIT].
2. COMMIT CONNECTION con.
Effect
Terminates an SAP LUW and stores the changes.
Variant 1
COMMIT WORK [AND WAIT].
Effect
The statement COMMIT WORK completes the current SAP LUW and opens a new one, storing all change requests for the currenta SAP LUW in the process. In this case, COMMIT WORK performs the following actions:
It executes all subroutines registered using PERFORM ON COMMIT.
It triggers an internal event in Object Services that ensures the registration of changes in persistent objects as the last update function module, as well as the subsequent initialization of persistent object attributes.
It initiates the processing of all registered update function modules in the update work process.
This executes all high-priority update function modules registered using CALL FUNCTION ... IN UPDATE TASK in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating). If you specify the addition AND WAIT, however, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
If all high-priority update function modules are completed successfully, the statement executes the low-priority update function modules together in a common database LUW.
In parallel, it also executes the individual function modules registered using CALL FUNCTION ... IN BACKGROUND TASK DESTINATION in a separate database LUW for each destination.
It handles all SAP locks set in the current program according to the value of the formal parameter _SCOPE of the corresponding lock function modules.
It triggers a database commit that also terminates the current database LUW.
The completion of statement COMMIT WORK triggers the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE, where the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK.
If the statement COMMIT WORK is executed by calling special programs, be aware of the following:
In a program executed using batch input, or if you have called the program using the USING addition of the statement CALL TRANSACTION, COMMIT WORK terminates the batch input processing when using the corresponding settings.
In a program called using CALL DIALOG, COMMIT WORK initiates the processing of subroutines or updated function modules registered using PERFORM ... ON COMMIT and CALL FUNCTION ... IN UPDATE TASK. Therefore, it does not complete the current SAP LUW. The SAP LUW cannot be completed until you execute the COMMIT WORK statement in the calling program.
You cannot execute the COMMIT WORK statement during the updating procedure or during the execution of subroutines registered using PERFORM ... ON {COMMIT|ROLLBACK}.
System fields
sy-subrc Meaning
0 You have specified the AND WAIT addition, and the updating of the update function modules was successful.
4 You have specified the AND WAIT addition, and the updating of the update function modules was not successful.
The COMMIT WORK statement always sets sy-subrc to 0 if the AND WAIT addition is not specified.
Note
The COMMIT WORK statement closes all database cursors . Open SQL statements that access a database cursor later ( SELECT loop and FETCH) raise an exception that cannot be handled.
Variant 2
COMMIT CONNECTION con.
Note
This statement is for internal use only.
It cannot be used in application programs.
Effect
The COMMIT command is not executed on the standard database, but only on the secondary database connection specified by con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection. The source_text field must be of the type C or STRING.
On the specified secondary database connection, the database commit:
Closes all open database cursors (OPEN CURSOR)
Releases all database locks
Note
Note that the COMMIT CONNECTION DEFAULT statement unlike COMMIT WORK executes a pure database commit on the DEFAULT connection.
Exceptions
Non-Catchable Exceptions
Cause: COMMIT WORK is not possible in a FORM that was called using PERFORM ... ON COMMIT.
Runtime Error: COMMIT_IN_PERFORM_ON_COMMIT
Cause: COMMIT WORK is not allowed in the update.
Runtime Error: COMMIT_IN_POSTING
ROLLBACK WORK
Variants:
1. ROLLBACK WORK.
2. ROLLBACK CONNECTION con.
Effect
Terminates a SAP-LUW without storing the changes.
Variant 1
ROLLBACK WORK.
Effect
The statement ROLLBACK WORK closes the current SAP-LUW and opens a new one. In doing so, all change requests of the current SAP-LUW are canceled. To do this, ROLLBACK WORK carries out the following actions:
Executes all subprograms registered with PERFORM ON ROLLBACK.
Deletes all subprograms registered with PERFORM ON COMMIT.
Raises an internal exception in the Object Services that makes sure that the attributes of persistent objects are initialised.
Deletes all update function modules registered with CALL FUNCTION ...IN UPDATE TASK from the VBLOG and deletes all transactional remote Function Calls registered with CALL FUNCTION ... IN BACKGROUND TASK from ARFCSSTATE and from ARFCSDATA.
Removal of all SAP locks set in the current program in which the formal parameter _SCOPE of the lock function module was set to the value 2.
Triggers a database rollback, which also ends the current database-LUW.
After completion of the statement COMMIT WORK, the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE is raised, in which the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>ROLLBACK_WORK.
Variant 2
ROLLBACK CONNECTION con.
Note
This statement is for internal use only.
It cannot be used in application programs.
Effect
The ROLLBACK-statement is not executed on the standard database but only on the secondary database connection, specified through con. con is the name of the database connection as it was specified in table DBCON in column CON_NAME. The database connection con can also be specified dynamically in the form (source_text), in which the field source_text contains the name of the database connection. The field source_text must be of the type C or STRING.
Notes
As all opened database cursors on the respective database connections are closed at ROLLBACK, the attempt to continue a SELECT-loop after a ROLLBACK, leads to a runtime error. Due to the same reason, a FETCH after a ROLLBACK to the then closed cursor, leads to a runtime error. You have to make sure that cursors that are still open, are no longer used after ROLLBACK.
After execution of the statement ROLLBACK, SY-SUBRC is always equal to 0. It is not necessary to check if SY-SUBRC is unequal to 0 after ROLLBACK.
ROLLBACK must not be used during update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs, which were registered with PERFORM ... ON COMMIT resp. PERFORM ...ON ROLLBACK.
The statement ROLLBACK WORK is implicitly executed if a message of the type A is treated with the addition ERROR_MESSAGE when calling a function module with CALL FUNCTION.
Exceptions
Non-Catchable Exceptions
Cause: ROLLBACK WORK is not allowed within a FORM that is called with PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.
Runtime Error: ROLLBACK_IN_PERFORM_ON_COMMIT
Cause: ROLLBACK WORK is not allowed within an update.
Runtime Error: ROLLBACK_IN_POSTING
SET UPDATE TASK LOCAL
Syntax
SET UPDATE TASK LOCAL.
Effect
This statement specifies that the high-priority update function modules - registered during the current SAP LUW using CALL FUNCTION ... IN UPDATE TASK - are registered in the ABAP memory instead of the VBLOG database table. In addition, it specifies that the current work process and not the update work process run these modules during the current database LUW, when the COMMIT WORK statement is executed. This statement has no effect on low-priority update function modules.
At the beginning of every SAP LUW, the local update function is deactivated. If you wish to use it, you must reactivate it again before the first update function module is registered.
System fields
sy-subrc Meaning
0 The local update function is activated.
1 The local update function has not been activated, because the program has already registered at least one update function module for the normal updating procedure in the current SAP-LUW.
Notes
The local update function performs a synchronous update according to the COMMIT WORK statement, independent of the addition AND WAIT.
The occurrence of a database rollback during the local update affects all previous change requests.

RFC in background task LUW

Hello,
I've two RFC in user-exit. Both, using IN BACKGROUND TASK DESTINATION XI
When i execute the transaction, the user-exit is raising and i can see the follow error in SM58:
maximum size of requests for one LUW has been reached(1).
I've changing in the CC the parameter Maximum Conecction, however the error continue.
If i comment the second call function in the user-exit, the first call function is executed OK, the interface is right,
¿how can i do to execute two functions in the same LUW?
thanks

Hi,
>>¿how can i do to execute two functions in the same LUW?
you cannot - you need to do "commit work." after each RFC call
Regards,
Michal Krawczyk

Number of data records per logical unit of works (LUW)

When initialising opening stocks by default there are 5,000 data records per LUW. For our extract this works out to 204 LUW. Is there any optimium setting of number of LUW or data records per LUW? Thanks

Niten
See the below link
URGENT! - Data Packet Size
Assign points if has really helped you.
Regs
Gopi

Set idoc Packet Size to always be a single packet

Hi All,
WE20 config has a field for packet size. If I set it to 1, the system will create 1 packet/LUW for each idoc.
If I set it to two, it will wait until there are 2 idocs available and then create 1 packet/LUW for both idocs. however, if that second idoc is never created, the first idoc will never be sent.
Is there a way to specify that the system always send 1 packet/LUW for any number of idocs? So lets say today I created 10 idocs - the system would send that as 1 LUW. Tomorrow, I create 25 idocs, and the system would send that as 1 LUW.
I'm guessing the answer to this is NO, because the system will never know when to stop waiting for more idocs and send them to the receiving system already. The PI developers here are looking for a way to avoid implementing BPM, because they say it will cause performance issues. This was suggested as an alternative. As I said, I doubt it's possible, but I wanted to make certain before going back to them with that info.
Thanks,
Bryan

For some reason I was under the impression that RSEOUT00 wouldn't send the idocs unless the number had been reached, but I see that is not the case.
I always make things more complicated than they need to be.
Thanks!

On-line redu log file size reduce

Dear Experts,
Recently i have done HADR set-up, my DR server is on remote location,
and my network line is not very fast , my query is , can we reduce on log file size, which is currently 63.9921874995806 MB(by default) . because if we will reduce the size it may help to ship the log fast,
Kindly suggest the best,
Thanks
Sadiq

Hello,
if you are referring to the build-in DB2 HADR functionality, reducing the size of log files will not help.
HADR does not transfer complete log files but will replicate logging information of each single transaction constantly to the standby site.
Your network has to have enough bandwidth to support the average log generation rate. This is not related to the size of individual log files, but to how much logging information is generated per amount of time.
Kindly check the corresponding DB2 online documentation for HADR performance aspects
[High availability disaster recovery (HADR) performance|http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.ha.doc%2Fdoc%2Fc0021056.html]
But, to answer your initial question: The size of log files can be changed by modifying the LOGFILSIZ database configuration parameter. Probably it will not help in your case.
Edited by: Hans-Juergen Zeltwanger on Feb 20, 2012 2:49 PM
Edited by: Hans-Juergen Zeltwanger on Feb 20, 2012 2:50 PM

Downtime for Heterogeneous System Copy Export of Source DB2 LUW

Hello,
What is the downtime required for a heterogeneous system copy export of a source database on AIX with DB2 LUW? Here are the following details of the data itself:
DB size: 120 GB used of 240 GB.
Physical server: IBM Power5 quad-core 1.65GHz virtualized
RAM: 9.5GB

> What is the downtime required for a heterogeneous system copy export of a source database on AIX with DB2 LUW? Here are the following details of the data itself:
I suggest you just "try it out" as a test run. It's quite impossible to give estimates based on database sizes. It's possible to migrate roughly 1 TB/hour with appropriate hardware, mostly your harddisks will be the bottleneck.
There are also a number of other factors like number of R3load processes, table splitting or not, parallel export/import etc.
I highly suggest to run the migration a few times before you do the "live" migration.
Markus

Partiotning, pseudo delta, LUW

Hi gurus,
could you please tell me
how PSA partiotining done. need steps to do it. How is cube partioitning done .need steps.
what is pseudo delta and where is it done , please tell me the steps to do it
What is LUW abbriviation, and whai is its functionality in BW and R/3
thanks in advance
regards

Hi Chaudary,
PSA Partition will be done automatically also in the transaction RSCUSTV6 you could set Packet size and Partition size.
And you can partition InfoCubes using two characteristics calendar month (0CALMONTH) and fiscal year/period (0FISCPER). The special feature of the fiscal year/period characteristic (0FISCPER) being compounded with the fiscal year variant (0FISCVARNT) means that you have to use a special procedure when you partition an InfoCube using 0FISCPER.
You use partitioning to split the total dataset for an InfoCube into several, smaller, physically independent and redundancy-free units.
http://help.sap.com/saphelp_erp2005/helpdata/en/0a/cd6e3a30aac013e10000000a114084/frameset.htm
Partitioning infocube :
http://www.crmexpertonline.com/archive/Volume_01_(2005)/Issue_01_(October)/v1i1a1.cfm?session=
PPT:http://www.cs.utk.edu/~huangj/CS594S02/infovis.ppt
Hope The above two links (article and ppt) helps you to understand ..
Pseudo delta is used with generic extractors, to make a a generic extactor delta enabled ...In RSO2 after creating the datasource at the top of the screen you have "Generic delta" icon, click on this & in the following screen you need to select the field on which the delta is to be performed along with the type of delta i.e Numeric or time stamp or on 0calday.
Save the datasource & relicate it in the BW system.
A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirety or not at all. For the database system, it thus constitutes a unit.
LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.
An LUW begins
o each time you start a transaction
o when the database changes of the previous LUW have been confirmed (database commit) or
o when the database changes of the previous LUW have been cancelled (database rollback)
An LUW ends
o when the database changes have been confirmed (database commit) or
o when the database changes have been canceled (database rollback)
Points = thanks,
Regards
Message was edited by:
samara reddy

How do I find, at-a-glance, the sample size used in several music files?

How do I find, at-a-glance, the sample size used in several music files?
Of all the fields available in a FInder Search, "Sample Size" is not available. Finder does offer a "Bits per Sample" field, but it only recognized graphic files and not music files.
Running 10.8.5 on an iMac i5.
I did search through a couple of communities but came up empty.
Thank you,
Craig

C-squared,
There is no View Option to allow display of a column of sample size.
For WAV or Apple Lossless files, it is available on the Summary tab (one song at a time, as you know). For MP3 and AAC it is not available at all.
You can roughly infer it from the files that are larger than expected for their time.
99% of the music we use is at the CD standard of 16-bit, so I can guess that displaying it has never been a priority. However, if you want to make a suggestion to Apple, use this link:
http://www.apple.com/feedback/itunesapp.html

Edit scanning size

Hi. I downloaded AiO Remote app for my iPad. It has connected fine, but I was wondering if there is a way to alter the size of a document that I have scanned from my printer to my iPad. It did give me a size option which I thought would have been fine as it said A4, but when I later printed it from my iPad to the same printer, it was about 1/3rd the size of the A4 sheet of paper.
Thanks

Hi,
You have to select the size of the original, not the size of the glass.
Regards.
BH
**Click the KUDOS thumb up on the left to say 'Thanks'**
Make it easier for other people to find solutions by marking a Reply 'Accept as Solution' if it solves your problem.

Mixing memory module of different sizes in G5-8 slot machine

is there a problem with Mixing memory module of different sizes in G5-8 slot machine
I have 2gb on four slots with 512 memory chips
Can I upgrade my memory with 1gb chips in the remaining four slots.

Hi epospiech-
Yes you can.
Instructions here: Memory (DIMMs) Replacement Instructions
Luck-
-DaddyPaycheck

Size of LUW's

Similar Messages

Maybe you are looking for