Concurrent employment_URGENT

hi friends,
Plz tell me what is concurrent employment? How do we configure it in SAP systems and where and how can we see its impact?
Plz reply back....as this is really urgent for client implementation in india.
thanx
points are assured.

Hi Swarali,
In Concurent employement, an employee works in more than one personnel assignment with one enterprise or several affiliated enterprises. A concurrently employed person is represented in the system by assigning several personnel assignments to a central person (object CP). The central person is determined automatically by the system by internal number assignment. In addition, a unique external person ID is determined. The external person ID does not change with time (time constraint A).
You have to do the settings in IMG under Personnel Administration -> Customizing Procedures -> Settings for Concurrent Employment
There is wiki page on the same which will explain the CE concept.
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/erphcm/concurrent+employment&
Regards,
Sharadha

Similar Messages

  • How to submit a concurrent request from Discoverer report.

    I would like to know If any one has tried submitting a concurrent request from Discoverer Report?_
    This is no stupid question, but our team here finally decided with a solution to our long pending issues with few of the discoverer report. To Proceed further, we would like to know, how to submit a concurrent request from Discoverer report?
    We are looking for calling a package from the Disco admin by passing the parameters from the disco to the 6i report.
    All help us in this regards are much appreciated.
    Kindly help us in the same!
    Thanks
    Arun

    Thanks Rod for confirming the same.
    I will be trying the same today and will let you know if I succeed in doing it.
    If I can share the actual requirement with you, it goes like this.
    "I will be triggering the Oracle 6i standard AP Trail balance report through the Disco report. The standard report will be inserting the required data to one of my custom table. Once the concurrent program completes normal, my custom table will be having the required data to create the workbook specific to the current run of the concurrent program.
    The one problem which I think could happen is, How can I make my disco report to wait till the standard program to complete in normal so that my disco report can be generated with the data from custom table.
    Will the above requirement is possible If I follow the way you mention in the PDF or Could you suggest a better way for achieving the same.
    In short, my requirement is: The custom table(say XX_TABLE) will be populated with data when the standard 6i report is run and the disco admin will be making of the custom table (XX_TABLE) to generate the report.
    Please advice.
    Thanks
    Arun

  • Find the number of concurrent users in system at a given time

    Hi All,
    We have the ECC system in which we need to set up monitoring alert which should tell the following things.
    1.The  number of concurrent users looged  currently in the system.
    2. List of  transaction per hour or user activites with the counts
    I want to know whether we have any standard report , function module or tcode through which we can achive this.
    A quick response will be appreciated.
    Thanks in advance.
    Regards
    Santosh

    Dear Santosh,
    for concurrent users there is this monitor in RZ20:
       System Configuration
           Operation Mode Status
           Instance Status
           Concurrent Users
               Concurrent Users (all Clients)    2 Usrs, Green 15.05.2014 , 17:02:18
               Concurrent Users (Client 000)     1 Usrs, Green 15.05.2014 , 17:02:18
               Concurrent Users (Client 001)     1 Usrs, Green 15.05.2014 , 17:02:18
               Concurrent Users (Client 066)     0 Usrs, Green 15.05.2014 , 17:02:18
    This monitor is available under RZ20 --> SAP CCMS Monitor Templates --> System Configuration
    best regards,
    Alwina

  • Error in running a order import concurrent program

    Hi,
    Please tell me what type of error is this ,i am using user 'operations',and i have inserted data to the interface table successfully but while running the concurrent program ,i am getting this error.
    Cause: FDPSTP failed due to ORA-20100: File o0085033.tmp creation for FND_FILE failed.
    You will find more information on the cause of the error in request log.
    ORA-06512: at "APPS.FND_FILE", line 396
    ORA-06512

    Hi,
    Please see old threads as this error was discussed many times in the forum before.
    ORA-20100
    http://forums.oracle.com/forums/search.jspa?threadID=&q=ORA-20100&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
    Thanks,
    Hussein

  • Getting Error While Attaching Concurrent Program Output PDF file for POAPPRV Workflow

    Hi All,
    I am getting the below error when I am trying to attach concurrent program output to the PO Approval Notification.
    An Error occurred in the following Workflow.
    Item Type = POAPPRV
    Item Key = 1040589-528378
    User Key =945871
    Error Name = WF_ERROR
    Error Message = [WF_ERROR] ERROR_MESSAGE=3835: Error '-20002 - ORA-20002: [WFMLR_DOCUMENT_ERROR]' encountered during execution of Generate function 'WF_XML.Generate' for event 'oracle.apps.wf.notification.send'. ERROR_STACK=
    Wf_Notification.GetAttrblob(3604701, ZZ_PREVIOUS_PO_COMPARE, text/html)
    WF_XML.GetAttachment(3604701, text/html)
    WF_XML.GetAttachments(3604701, http://oraerp.am.corp.xxxx.com:8099/pls/DEV, 11283)
    WF_XML.GenerateDoc(oracle.apps.wf.notification.send, 3604701)
    WF_XML.Generate(oracle.apps.wf.notification.send, 3604701)
    WF_XML.Generate(oracle.apps.wf.notification.send, 3604701)
    Wf_Event.setMessage(oracle.apps.wf.notification.send, 3604701, WF_XML.Generate)
    Wf_Event.dispatch_internal()
    Error Stack =
    Activity ID = 190844
    Activity Label = AL_NOTIFY_APPROVER_PROCESS:ZZ_PO_PO_APPROVE_ATTCH
    Result Code = #MAIL
    Notification ID = 3604701
    There are several threads for this error however I cannot find any specific solution to the problem.
    Please find the code below -
        wf_engine.setitemattrdocument(itemtype=>itemtype,
                                      itemkey=> itemkey,
                                      aname=>'ZZ_PREVIOUS_PO_COMPARE',
                                      documentid =>'PLSQLBLOB:zz_po_reqapproval_init1.xx_notif_attachments/' || to_char(l_request_id_prev_po)||':'||to_char(l_document_num));
    -- here l_request_id_q_and_s is the request id of the program and l_document_num is the PO document number
    PROCEDURE xx_notif_attachments(p_request_id    IN VARCHAR2,
                                   p_document_num  IN VARCHAR2,
                                   p_document      IN OUT BLOB,
                                   p_document_type IN OUT VARCHAR2) IS
      v_lob_id          NUMBER;
      v_document_num    VARCHAR2(15);
      v_document_prefix VARCHAR2(100);
      v_file_name       VARCHAR2(500);
      v_file_on_os      BFILE;
      v_temp_lob        BLOB;
      v_dest_offset     NUMBER := 1;
      v_src_offset      NUMBER := 1;
      v_out_file_name   VARCHAR2(2000);
      v_conc_prog_name  VARCHAR2(500);
      v_conc_req_id     NUMBER;
      CURSOR get_output_file(p_concurrent_request_id NUMBER) IS
        SELECT cr.outfile_name, cp.concurrent_program_name
          FROM fnd_concurrent_requests cr, fnd_concurrent_programs_vl cp
         WHERE request_id = p_concurrent_request_id
           AND cp.concurrent_program_id = cr.concurrent_program_id;
    BEGIN
      --    set_debug_context('xx_notif_attach_procedure');
      v_conc_req_id  := to_number(substr(p_request_id,
                                         1,
                                         instr(p_request_id, ':') - 1));
      v_document_num := substr(p_request_id,
                               instr(p_request_id, ':') + 1,
                               length(p_request_id) - 2);
      OPEN get_output_file(v_conc_req_id);
      FETCH get_output_file
        INTO v_out_file_name, v_conc_prog_name;
      CLOSE get_output_file;
      v_out_file_name := substr(v_out_file_name,
                                instr(v_out_file_name, '/', -1) + 1);
      v_file_name     := to_char(v_document_num) || '-Previous_PO_Rev.pdf';
      utl_file.fcopy(src_location  => 'APPS_OUT_DIR',
                     src_filename  => v_out_file_name,
                     dest_location => 'PO_DATA_DIR',
                     dest_filename => v_file_name);
      --  v_lob_id := to_number(v_document_id);
      v_file_on_os := bfilename('PO_DATA_DIR', v_file_name);
      dbms_lob.createtemporary(v_temp_lob, cache => FALSE);
      dbms_lob.fileopen(v_file_on_os, dbms_lob.file_readonly);
      dbms_lob.loadblobfromfile(dest_lob    => v_temp_lob,
                                src_bfile   => v_file_on_os,
                                amount      => dbms_lob.getlength(v_file_on_os),
                                dest_offset => v_dest_offset,
                                src_offset  => v_src_offset);
      dbms_lob.fileclose(v_file_on_os);
      p_document_type := 'application/pdf;name=' || v_file_name;
      dbms_lob.copy(p_document, v_temp_lob, dbms_lob.getlength(v_temp_lob));
    EXCEPTION
      WHEN OTHERS THEN
        wf_core.CONTEXT('ZZ_PO_REQAPPROVAL_INIT1',
                        'xx_notif_attachments',
                        v_document_num,
                        p_request_id);
        RAISE;
    END xx_notif_attachments;
    Please help me find a to the above mentioned error.
    Thanks,
    Suvigya

    There are two ways to look at what error the PLSQLBLOB API is throwing.
    1) Call your PLSQLBLOB API GNE_PO_CREATE_FILE_ATTACHMENT.Gne_Create_File_Attachment directly from a PLSQL block and verify that it returns the BLOB data successfully.
    You could also call another WF API that in turn executes the PLSQLBLOB API internally. For example,
    <pre>
    declare
    l_document blob;
    l_doctype varchar2(240);
    l_aname varchar2(90);
    begin
    dbms_lob.CreateTemporary(l_document, true, dbms_lob.Session);
    -- 207046 - This is the notification id of your failed workflow
    -- PO_REPORT - Document type attribute
    -- 'text/html' - Content Type being generated for
    Wf_Notification.GetAttrBLOB(207046, 'PO_REPORT', 'text/html', l_document, l_doctype, l_aname);
    -- Print the size of the document here to verify it was fetched correctly
    end;
    </pre>
    2) Turn on log for SYSADMIN user with following attributes.
    Log Enabled = TRUE
    Log Level = ERROR
    Log Module = wf.plsql%
    Restart the Workflow Deferred Agent Listener and Workflow Notification Deferred Agent Listener and run your workflow process. Search for log messages written for above context and you can identify the error at wf.plsql.WF_XML.GetAttachment module with message starting as "Error when getting BLOB attachment ->"
    Hope this helps.
    Vijay

  • Error while submitting concurrent request

    Hi All,
    I am getting error while submitting this concurrent request (To handle deliver, RTR, RTV transactions)
    Error : app-fnd-00874: Routine FDFBDF found no rows in table FND_DESCRIPTIVE_FLEXS. Please contact your system administrator or support
    representative
    what is this error and how can i slove this problem?
    Thanks
    V.Arumugam

    Hi,
    We had same problem in GL while upgradation.
    Some flexfields were missing in the fnd descriptive flexfield.
    We could resolve later with help of metalink.
    Plz refer metalink note : Note:363117.1 and Note:290411.1
    Rgds,
    Arumugam S.

  • Error while running the concurrent program

    Hi All,
    We ran a concurrent program to create XML report which completed in warning.
    we got the following message in the log file.
    [091907_050229025][][EXCEPTION] java.io.IOException: Bad file descriptor
         at java.io.FileOutputStream.writeBytes(Native Method)
         at java.io.FileOutputStream.write(FileOutputStream.java:260)
         at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
         at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)
         at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
         at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
         at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
         at java.io.BufferedWriter.flush(BufferedWriter.java:236)
         at oracle.apps.xdo.dataengine.XMLPGEN.closeStream(XMLPGEN.java:804)
         at oracle.apps.xdo.dataengine.XMLPGEN.processXML(XMLPGEN.java:212)
         at oracle.apps.xdo.dataengine.XMLPGEN.writeXML(XMLPGEN.java:237)
         at oracle.apps.xdo.dataengine.DataProcessor.processData(DataProcessor.java:364)
         at oracle.apps.xdo.oa.util.DataTemplate.processData(DataTemplate.java:236)
         at oracle.apps.xdo.oa.cp.JCP4XDODataEngine.runProgram(JCP4XDODataEngine.java:293)
         at oracle.apps.fnd.cp.request.Run.main(Run.java:157)
    Please suggest us how to resolve this issue.
    Thanks in Advance

    did u check view xml in diagnostic tab after submitting the request.
    if ur xml file is generated(xml data file), then its a problem with your template.
    regards
    Ratnesh P

  • Error while running a concurrent program.

    Hi All,
    I have written a plsql procedure and registered it with apps. When i run the program it is giving
    FDPSTP failed due to ORA-20100: File l0137058.tmp creation for FND_FILE failed.
    You will find more information on the cause of the error in request log.
    I am not able to find out what is the problem with this. When i remove the FND_FILE.PUT_LINE statement from my code and execute it is executing properly without errors. Please suggest me what might be the problem. Also please suggest me where i can find this .tmp file or where i can find the request log.
    Thanks and Regards,
    Mahesh

    Mahesh,
    On the instance where this concurrent program fails to run, please verify the following:
    1) Make sure that APPLPTMP is set to a valid directory as shown above (Verify from the OS by issuing "echo $APPLPTMP" as applmgr user)
    2) Make sure that both the applmgr user and the database user "oracle" have read/write permissions on $APPLPTMP
    3) Make sure that APPLPTMP is the first entry in utl_file_dir (utl_file_dir is set in the init<SID>.ora file). To verify to what "utl_file_dir" is set:
    SQL> connect / as sysdba
    SQL> show parameter UTL_FILE_DIRPlease go through the first document referenced in my first reply (Note: 261693.1), it should be helpful.
    Regards,
    Hussein

  • Issue in Java concurrent program for Digital Signature Stamping

    Hi All,
    Im calling a Java concurrent program which does digital signature stamping on the PDF report generated.Program able to able to read the PDF file as input and also digital signature stored as file in the application but
    ends in error in create signature method , need help in this regard.
    Error:
    Parameter 0 is Request id of with out Digital signature file
    Parameter 1 is employee id of approver
    Parameter:0:99203256
    Parameter:1:1414603
    $$$$ start query fileinfo with callable statment
    programName>>>>>>>>BTPOPORPXML
    $$$$ Without digital Signature file Name $$$
    $/inst_top/finprod/apps/FINPROD_CPNQERPAAPZP10/logs/appl/conc/out/BTPOPORPXML_99203256_1.PDF
    PFX File Reading Start
    PFX File Reading Ends
    PFX File size is: 6460 Byte size is: 6460
    Elements present
    java.lang.NullPointerException
    at
    com.lowagie.text.pdf.PdfSignatureAppearance.getAppearance
    (Unknown Source)
    at
    com.lowagie.text.pdf.PdfSignatureAppearance.preClose
    (Unknown Source)
    at
    com.lowagie.text.pdf.PdfSignatureAppearance.preClose
    (Unknown Source)
    at com.lowagie.text.pdf.PdfStamper.close(Unknown
    Source)
    at
    btvl.oracle.apps.po.digsig.BTVLDigSign.runProgram
    (BTVLDigSign.java:151)
    at oracle.apps.fnd.cp.request.Run.main
    (Run.java:157)
    Edited by: 999033 on May 16, 2013 7:20 PM

    Hi Charls,
    I have successfully implemented at our end in 11i. Pl.try at your end.
    v_request_id := FND_REQUEST.SUBMIT_REQUEST (passed your arguments... );
    COMMIT;
    IF NVL( v_request_id , 0 ) = 0 THEN
    DBMS_OUTPUT.PUT_LINE( 'Item Assignment to Organization Program Not Submitted');
    p_status := 'FAILURE' ;
    p_err_msg := 'ERROR RAISED AFTER SUBMITTING THE IMPORT ITEM ORG.ASSIGNMENT CONCURRENT REQUEST ... ' ;          
    ELSE
    v_finished := FND_CONCURRENT.WAIT_FOR_REQUEST
    request_id => v_request_id,
    interval => 0,
    max_wait => 0,
    phase => v_phase,
    status => v_status,
    dev_phase => v_request_phase,
    dev_status => v_request_status,
    message => v_message
    LOOP
    EXIT WHEN ( UPPER(v_request_phase) = 'COMPLETE' OR v_phase = 'C');
    END LOOP;
    HTH                    
    Sanjay

  • Jump in Young GG (ParNew) times after CMS-concurrent-reset

    In one of our automated test scenarios following a CMS-concurrent-reset, young GC times dramatically increased. For instance, prior to the CMS reset, average young GC times average 0.15 seconds; after the CMS reset, times would spike to as high as 40 seconds. With our high-load scenario this does not happen. The difference in data load between these two tests is approximately 360:1.
    Usually when this occcurs, the young GC times would stay consistently high (between 30 and 40 seconds). However, in one of our most recent test runs, something else happened. Young GC times would spike and then over a period of time gradually decrease back down to tolerable levels (over a period of 3.5+ hours). The log snippet below illustrates this behavior.
    The application itself is a custom server built on Java 1.5.0_06 using Java 1.5.0_06erdist1. The hardware is a Dell PowerEdge 6800 running Windows 2003 Server 64-bit w/SP1. The server has 32GB of RAM, no swap file, and 8 logical CPU's (4 hyperthreaded Xeon processors). The system caches large amounts of data in a variety of strong, soft, and weak reference maps is using SleepyCat Software's DBJE for data storage.
    We're working on getting memory dumps, but right now, we're thinking it might have something to do with large arrays in the old generation either being reallocated, or references back to the young generation that could be causing this. There is a slight possibility that there is also a large object being allocated in the young generation, although this seems like it is less likely (the average data packet is less than 1K in this test scenario and most object allocations are usually less than 4K in size -- byte arrays usually).
    We're also looking at possibly testing with the latest 1.6 beta to see if the problem goes away, or at the very least we can profile the app when it gets into trouble without having to turn off CMS.
    Does anybody have any thoughts on what might be causing this, or has anyone else run into something similar before?
    The JVM Args used are:
    -server
    -Xms28G
    -Xmx28G
    -enableassertions
    -XX:-UsePerfData
    -XX:+PrintVMOptions
    -XX:-TraceClassUnloading
    -XX:+PrintGCDetails
    -XX:+PrintGCTimeStamps
    -verbose:gc
    -XX:MaxTenuringThreshold=0
    -XX:SurvivorRatio=20000
    -XX:+UseCMSCompactAtFullCollection
    -XX:CMSFullGCsBeforeCompaction=0
    -XX:+ParallelRefProcEnabled
    -XX:+CMSClassUnloadingEnabled
    -XX:+CMSPermGenSweepingEnabled
    -XX:+UseParNewGC
    -XX:+UseConcMarkSweepGC
    -XX:ParallelGCThreads=7
    -XX:NewSize=128M
    -XX:MaxNewSize=128M
    -XX:+CMSIncrementalMode
    -XX:+CMSIncrementalPacing
    -XX:CMSIncrementalDutyCycleMin=0
    -XX:CMSIncrementalDutyCycle=10
    -XX:CMSMarkStackSize=8M
    -XX:CMSMarkStackSizeMax=32M
    -XX:+UseLargePages
    -XX:+DisableExplicitGC
    64255.634: [GC 64255.634: [ParNew: 127304K->0K(131008K), 0.2955450 secs] 14370952K->14273019K(28671936K) icms_dc=0 , 0.2957102 secs]
    64270.829: [GC 64270.829: [ParNew: 130944K->0K(131008K), 0.2805740 secs] 14403963K->14286161K(28671936K) icms_dc=0 , 0.2807523 secs]
    64287.158: [GC 64287.158: [ParNew: 129676K->0K(131008K), 0.2908535 secs] 14415837K->14289089K(28671936K) icms_dc=0 , 0.2911033 secs]
    64297.966: [GC 64297.966: [ParNew: 130602K->0K(131008K), 0.2682085 secs] 14419692K->14311368K(28671936K) icms_dc=0 , 0.2683754 secs]
    64308.812: [GC 64308.812: [ParNew: 126613K->0K(131008K), 0.2965320 secs] 14437982K->14336914K(28671936K) icms_dc=0 , 0.2967070 secs]
    64319.249: [GC 64319.249: [ParNew: 128966K->0K(131008K), 0.2878087 secs] 14465880K->14364326K(28671936K) icms_dc=3 , 0.2879923 secs]
    64329.585: [GC [1 CMS-initial-mark: 14364326K(28540928K)] 14428075K(28671936K), 0.0367576 secs]
    64329.622: [CMS-concurrent-mark-start]
    64340.074: [GC 64340.074: [ParNew: 130758K->0K(131008K), 0.2824739 secs] 14495085K->14372339K(28671936K) icms_dc=3 , 0.2826438 secs]
    64341.411: [CMS-concurrent-mark: 0.873/11.789 secs]
    64341.411: [CMS-concurrent-preclean-start]
    64341.411: [CMS-concurrent-preclean: 0.000/0.000 secs]
    64341.557: [CMS-concurrent-abortable-preclean-start]
    64341.557: [CMS-concurrent-abortable-preclean: 0.000/0.000 secs]
    64350.684: [GC 64350.684: [ParNew: 130944K->0K(131008K), 0.2899810 secs] 14503283K->14395507K(28671936K) icms_dc=3 , 0.2901651 secs]
    64363.365: [GC 64363.365: [ParNew: 130944K->0K(131008K), 0.2975003 secs] 14526451K->14421343K(28671936K) icms_dc=3 , 0.2976791 secs]
    64372.076: [GC[YG occupancy: 83987 K (131008 K)]64372.076: [Rescan (parallel) , 0.0674530 secs]64372.144: [weak refs processing, 0.0308673 secs]64372.175: [class unloading[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor27]
    64372.182: [scrub symbol & string tables, 0.0083922 secs] [1 CMS-remark: 14421343K(28540928K)] 14505331K(28671936K), 0.1281897 secs]
    64372.206: [CMS-concurrent-sweep-start]
    64376.703: [GC 64376.703: [ParNew: 130944K->0K(131008K), 0.3150279 secs] 14552287K->14443248K(28671936K) icms_dc=3 , 0.3152040 secs]
    64393.182: [GC 64393.183: [ParNew: 130944K->0K(131008K), 0.2967053 secs] 14570664K->14441684K(28671936K) icms_dc=3 , 0.2968985 secs]
    64395.855: [CMS-concurrent-sweep: 2.118/23.650 secs]
    64395.856: [CMS-concurrent-reset-start]
    64396.202: [CMS-concurrent-reset: 0.346/0.346 secs]
    64404.846: [GC 64404.846: [ParNew: 130944K->0K(131008K), 11.8319372 secs] 452302K->326245K(28671936K) icms_dc=0 , 11.8321090 secs]
    64420.865: [GC 64420.865: [ParNew: 130944K->0K(131008K), 11.8750319 secs] 457189K->352203K(28671936K) icms_dc=0 , 11.8752811 secs]
    64435.536: [GC 64435.536: [ParNew: 130944K->0K(131008K), 11.8229769 secs] 483147K->374039K(28671936K) icms_dc=0 , 11.8231579 secs]
    64448.564: [GC 64448.564: [ParNew: 130944K->0K(131008K), 12.2692927 secs] 504983K->376605K(28671936K) icms_dc=0 , 12.2694811 secs]
    64462.276: [GC 64462.276: [ParNew: 130944K->0K(131008K), 12.0860714 secs] 507549K->401835K(28671936K) icms_dc=0 , 12.0862452 secs]
    64478.522: [GC 64478.522: [ParNew: 126250K->0K(131008K), 12.3507999 secs] 528085K->428168K(28671936K) icms_dc=0 , 12.3509812 secs]
    64492.047: [GC 64492.047: [ParNew: 130944K->0K(131008K), 11.7977262 secs] 559112K->450172K(28671936K) icms_dc=0 , 11.7979055 secs]
    64505.333: [GC 64505.333: [ParNew: 130944K->0K(131008K), 11.6679971 secs] 581116K->475511K(28671936K) icms_dc=0 , 11.6681951 secs]
    64523.377: [GC 64523.377: [ParNew: 130944K->0K(131008K), 12.1859479 secs] 606455K->496955K(28671936K) icms_dc=0 , 12.1861274 secs]
    64537.004: [GC 64537.004: [ParNew: 130944K->0K(131008K), 12.3909395 secs] 627899K->500863K(28671936K) icms_dc=0 , 12.3911184 secs]
    64550.836: [GC 64550.836: [ParNew: 130944K->0K(131008K), 13.3435750 secs] 631807K->522967K(28671936K) icms_dc=0 , 13.3437711 secs]
    64565.421: [GC 64565.421: [ParNew: 130943K->0K(131008K), 12.1759533 secs] 653910K->551883K(28671936K) icms_dc=0 , 12.1761337 secs]
    64578.968: [GC 64578.968: [ParNew: 129670K->0K(131008K), 11.7518116 secs] 681553K->565967K(28671936K) icms_dc=0 , 11.7519997 secs]
    64595.156: [GC 64595.156: [ParNew: 130944K->0K(131008K), 12.7430090 secs] 696911K->588549K(28671936K) icms_dc=0 , 12.7431996 secs]
    64609.154: [GC 64609.155: [ParNew: 127642K->0K(131008K), 13.4122057 secs] 716191K->613789K(28671936K) icms_dc=0 , 13.4123919 secs]
    64623.588: [GC 64623.588: [ParNew: 130934K->0K(131008K), 11.8692832 secs] 744723K->634958K(28671936K) icms_dc=0 , 11.8694631 secs]
    64636.690: [GC 64636.690: [ParNew: 130944K->0K(131008K), 12.2170544 secs] 765902K->640533K(28671936K) icms_dc=0 , 12.2172308 secs]
    64652.592: [GC 64652.592: [ParNew: 130153K->0K(131008K), 12.5039780 secs] 770687K->670050K(28671936K) icms_dc=0 , 12.5041652 secs]
    64665.798: [GC 64665.798: [ParNew: 130944K->0K(131008K), 11.8129872 secs] 800994K->683828K(28671936K) icms_dc=0 , 11.8131695 secs]
    64678.710: [GC 64678.710: [ParNew: 130944K->0K(131008K), 12.2518054 secs] 814772K->686723K(28671936K) icms_dc=0 , 12.2519837 secs]
    64692.491: [GC 64692.491: [ParNew: 128795K->0K(131008K), 12.4420712 secs] 815519K->711677K(28671936K) icms_dc=0 , 12.4422521 secs]
    64706.761: [GC 64706.761: [ParNew: 130944K->0K(131008K), 12.1215915 secs] 842621K->733167K(28671936K) icms_dc=0 , 12.1217708 secs]
    64720.486: [GC 64720.486: [ParNew: 130944K->0K(131008K), 12.4783432 secs] 864111K->736715K(28671936K) icms_dc=0 , 12.4785325 secs]
    64734.374: [GC 64734.374: [ParNew: 129901K->0K(131008K), 12.6808484 secs] 866617K->763351K(28671936K) icms_dc=0 , 12.6810264 secs]
    64748.544: [GC 64748.544: [ParNew: 130944K->0K(131008K), 13.0768090 secs] 894295K->772967K(28671936K) icms_dc=0 , 13.0769936 secs]
    64762.836: [GC 64762.836: [ParNew: 130944K->0K(131008K), 12.6763159 secs] 903911K->797964K(28671936K) icms_dc=0 , 12.6764964 secs]
    64777.255: [GC 64777.255: [ParNew: 125172K->0K(131008K), 11.3742001 secs] 923137K->823513K(28671936K) icms_dc=0 , 11.3743819 secs]
    64789.913: [GC 64789.913: [ParNew: 130944K->0K(131008K), 12.6647870 secs] 954457K->845201K(28671936K) icms_dc=0 , 12.6649700 secs]
    64803.944: [GC 64803.944: [ParNew: 127557K->0K(131008K), 12.4356678 secs] 972758K->870316K(28671936K) icms_dc=0 , 12.4358488 secs]
    64818.674: [GC 64818.674: [ParNew: 130944K->0K(131008K), 12.1313661 secs] 1001260K->895535K(28671936K) icms_dc=0 , 12.1315657 secs]
    64834.764: [GC 64834.764: [ParNew: 129555K->0K(131008K), 11.9518352 secs] 1025090K->925104K(28671936K) icms_dc=0 , 11.9520134 secs]
    64848.138: [GC 64848.138: [ParNew: 130944K->0K(131008K), 12.9124929 secs] 1056048K->939587K(28671936K) icms_dc=0 , 12.9127034 secs]
    64862.318: [GC 64862.318: [ParNew: 123806K->0K(131008K), 13.0569914 secs] 1063394K->964362K(28671936K) icms_dc=0 , 13.0571688 secs]
    64877.530: [GC 64877.530: [ParNew: 130944K->0K(131008K), 12.3056353 secs] 1095306K->986163K(28671936K) icms_dc=0 , 12.3058150 secs]
    64891.725: [GC 64891.725: [ParNew: 130944K->0K(131008K), 13.0376824 secs] 1117107K->1007903K(28671936K) icms_dc=0 , 13.0378846 secs]
    76591.355: [GC 76591.355: [ParNew: 130944K->0K(131008K), 0.2791594 secs] 15265232K->15138597K(28671936K) icms_dc=0 , 0.2793572 secs]
    76600.766: [GC 76600.766: [ParNew: 130944K->0K(131008K), 0.2752963 secs] 15269541K->15160685K(28671936K) icms_dc=0 , 0.2754887 secs]
    76611.557: [GC 76611.557: [ParNew: 130944K->0K(131008K), 0.2790154 secs] 15291629K->15165049K(28671936K) icms_dc=0 , 0.2792048 secs]
    76622.303: [GC 76622.303: [ParNew: 130944K->0K(131008K), 0.2849006 secs] 15295993K->15187817K(28671936K) icms_dc=0 , 0.2850920 secs]
    76632.887: [GC 76632.887: [ParNew: 130944K->0K(131008K), 0.2689896 secs] 15318761K->15213844K(28671936K) icms_dc=0 , 0.2693092 secs]
    76643.956: [GC 76643.956: [ParNew: 130879K->0K(131008K), 0.2662928 secs] 15344723K->15236015K(28671936K) icms_dc=0 , 0.2664782 secs]
    76656.379: [GC 76656.379: [ParNew: 130944K->0K(131008K), 0.2872218 secs] 15366959K->15242404K(28671936K) icms_dc=0 , 0.2874433 secs]
    76664.841: [GC 76664.841: [ParNew: 130868K->0K(131008K), 0.2931068 secs] 15373273K->15269283K(28671936K) icms_dc=0 , 0.2932965 secs]
    76677.732: [GC 76677.732: [ParNew: 130920K->0K(131008K), 0.2475306 secs] 15400203K->15276884K(28671936K) icms_dc=0 , 0.2477292 secs]
    76697.644: [GC 76697.644: [ParNew: 130944K->0K(131008K), 0.2879494 secs] 15407828K->15280611K(28671936K) icms_dc=0 , 0.2881359 secs]
    76707.426: [GC 76707.426: [ParNew: 130944K->0K(131008K), 0.2911420 secs] 15411555K->15285072K(28671936K) icms_dc=0 , 0.2913233 secs]
    76717.857: [GC 76717.857: [ParNew: 130944K->0K(131008K), 0.2701989 secs] 15416016K->15309374K(28671936K) icms_dc=0 , 0.2703928 secs]
    76728.560: [GC 76728.561: [ParNew: 130944K->0K(131008K), 0.2931724 secs] 15440318K->15333673K(28671936K) icms_dc=0 , 0.2933609 secs]
    76739.261: [GC 76739.262: [ParNew: 126315K->0K(131008K), 0.2973160 secs] 15459989K->15363224K(28671936K) icms_dc=0 , 0.2974960 secs]
    76749.705: [GC 76749.705: [ParNew: 127396K->0K(131008K), 0.2972422 secs] 15490620K->15382987K(28671936K) icms_dc=0 , 0.2975240 secs]
    76767.794: [GC 76767.794: [ParNew: 130944K->0K(131008K), 0.2838999 secs] 15513931K->15391591K(28671936K) icms_dc=0 , 0.2840901 secs]
    76773.076: [GC 76773.076: [ParNew: 130944K->0K(131008K), 0.2552678 secs] 15522535K->15393025K(28671936K) icms_dc=0 , 0.2554467 secs]
    76790.058: [GC 76790.058: [ParNew: 130860K->0K(131008K), 0.2934145 secs] 15523885K->15394843K(28671936K) icms_dc=0 , 0.2936080 secs]
    76802.396: [GC 76802.396: [ParNew: 130604K->0K(131008K), 0.2972303 secs] 15525447K->15397713K(28671936K) icms_dc=0 , 0.2974271 secs]
    76813.202: [GC 76813.202: [ParNew: 130169K->0K(131008K), 0.2880799 secs] 15527883K->15422970K(28671936K) icms_dc=0 , 0.2882746 secs]
    76823.896: [GC 76823.896: [ParNew: 129924K->0K(131008K), 0.2832927 secs] 15552894K->15452588K(28671936K) icms_dc=0 , 0.2834869 secs]
    76834.357: [GC 76834.358: [ParNew: 130767K->0K(131008K), 0.2764792 secs] 15583355K->15474140K(28671936K) icms_dc=0 , 0.2766770 secs]
    76855.497: [GC 76855.497: [ParNew: 130897K->0K(131008K), 0.2894657 secs] 15605037K->15488217K(28671936K) icms_dc=0 , 0.2896626 secs]
    76866.253: [GC 76866.253: [ParNew: 130944K->0K(131008K), 0.2999675 secs] 15619161K->15490659K(28671936K) icms_dc=0 , 0.3001493 secs]
    76879.530: [GC 76879.530: [ParNew: 130944K->0K(131008K), 0.2816982 secs] 15621603K->15493104K(28671936K) icms_dc=0 , 0.2818897 secs]
    76888.031: [GC 76888.031: [ParNew: 130944K->0K(131008K), 0.2760192 secs] 15624048K->15498672K(28671936K) icms_dc=0 , 0.2762118 secs]
    76898.232: [GC 76898.232: [ParNew: 125483K->0K(131008K), 0.3109439 secs] 15624155K->15528482K(28671936K) icms_dc=0 , 0.3111342 secs]
    76914.416: [GC 76914.416: [ParNew: 130944K->0K(131008K), 0.3065572 secs] 15659426K->15542745K(28671936K) icms_dc=0 , 0.3067479 secs]
    76924.748: [GC 76924.748: [ParNew: 130883K->0K(131008K), 0.2937243 secs] 15673628K->15544088K(28671936K) icms_dc=0 , 0.2938988 secs]
    76942.226: [GC 76942.226: [ParNew: 130944K->0K(131008K), 0.2960886 secs] 15675032K->15547980K(28671936K) icms_dc=0 , 0.2962779 secs]
    76951.345: [GC 76951.345: [ParNew: 130944K->0K(131008K), 0.3050291 secs] 15678924K->15573683K(28671936K) icms_dc=0 , 0.3052196 secs]
    76961.936: [GC 76961.936: [ParNew: 130944K->0K(131008K), 0.2914707 secs] 15704627K->15595952K(28671936K) icms_dc=0 , 0.2916589 secs]
    76972.575: [GC 76972.575: [ParNew: 129330K->0K(131008K), 0.2838618 secs] 15725283K->15621207K(28671936K) icms_dc=0 , 0.2840550 secs]
    76986.283: [GC 76986.284: [ParNew: 130939K->0K(131008K), 0.2933898 secs] 15752146K->15643239K(28671936K) icms_dc=0 , 0.2935624 secs]
    76997.181: [GC 76997.181: [ParNew: 130944K->0K(131008K), 0.3075952 secs] 15774183K->15645463K(28671936K) icms_dc=0 , 0.3077828 secs]
    77007.913: [GC 77007.913: [ParNew: 130944K->0K(131008K), 0.2958084 secs] 15776407K->15647422K(28671936K) icms_dc=0 , 0.2960437 secs]
    77018.011: [GC 77018.011: [ParNew: 130910K->0K(131008K), 0.2964236 secs] 15778333K->15649978K(28671936K) icms_dc=0 , 0.2966224 secs]
    77034.694: [GC 77034.694: [ParNew: 130944K->0K(131008K), 0.3092856 secs] 15780922K->15652024K(28671936K) icms_dc=0 , 0.3094763 secs]
    77047.053: [GC 77047.054: [ParNew: 130944K->0K(131008K), 0.3015745 secs] 15782968K->15657359K(28671936K) icms_dc=0 , 0.3017561 secs]
    77057.249: [GC 77057.249: [ParNew: 130944K->0K(131008K), 0.3185589 secs] 15788303K->15680967K(28671936K) icms_dc=0 , 0.3188166 secs]
    77070.581: [GC 77070.581: [ParNew: 130944K->0K(131008K), 0.3062147 secs] 15811911K->15706444K(28671936K) icms_dc=0 , 0.3064015 secs]
    77078.801: [GC 77078.801: [ParNew: 123632K->0K(131008K), 0.3221894 secs] 15830077K->15732164K(28671936K) icms_dc=0 , 0.3223794 secs]
    77092.282: [GC 77092.282: [ParNew: 130944K->0K(131008K), 0.3141997 secs] 15863108K->15754279K(28671936K) icms_dc=0 , 0.3143788 secs]
    77104.965: [GC 77104.965: [ParNew: 130936K->0K(131008K), 0.2957323 secs] 15885215K->15756444K(28671936K) icms_dc=0 , 0.2959160 secs]
    77120.762: [GC 77120.762: [ParNew: 130944K->0K(131008K), 0.2967338 secs] 15887388K->15759133K(28671936K) icms_dc=0 , 0.2969243 secs]
    77125.566: [GC 77125.566: [ParNew: 130944K->0K(131008K), 0.3192459 secs] 15890077K->15761500K(28671936K) icms_dc=0 , 0.3194239 secs]
    77134.280: [GC 77134.280: [ParNew: 130930K->0K(131008K), 0.3128382 secs] 15892430K->15763820K(28671936K) icms_dc=0 , 0.3130111 secs]
    77148.565: [GC 77148.565: [ParNew: 130944K->0K(131008K), 0.3146629 secs] 15894764K->15766067K(28671936K) icms_dc=0 , 0.3148481 secs]
    77166.762: [GC 77166.762: [ParNew: 130944K->0K(131008K), 0.2902859 secs] 15897011K->15769686K(28671936K) icms_dc=0 , 0.2904642 secs]
    77173.957: [GC 77173.957: [ParNew: 130944K->0K(131008K), 0.3132502 secs] 15900630K->15794955K(28671936K) icms_dc=0 , 0.3134416 secs]
    77184.689: [GC 77184.689: [ParNew: 130944K->0K(131008K), 0.3122028 secs] 15925899K->15817089K(28671936K) icms_dc=0 , 0.3123857 secs]
    77195.961: [GC 77195.961: [ParNew: 130944K->0K(131008K), 0.3101975 secs] 15948033K->15823153K(28671936K) icms_dc=0 , 0.3103801 secs]
    77212.697: [GC 77212.697: [ParNew: 130944K->0K(131008K), 0.3109774 secs] 15954097K->15845044K(28671936K) icms_dc=0 , 0.3111528 secs]
    77217.947: [GC 77217.947: [ParNew: 130933K->0K(131008K), 0.2913624 secs] 15975978K->15846428K(28671936K) icms_dc=0 , 0.2915358 secs]
    77237.788: [GC 77237.788: [ParNew: 129457K->0K(131008K), 0.2967028 secs] 15975885K->15849363K(28671936K) icms_dc=0 , 0.2968859 secs]
    77248.232: [GC 77248.232: [ParNew: 130441K->0K(131008K), 0.3249377 secs] 15979804K->15872164K(28671936K) icms_dc=0 , 0.3251147 secs]
    77259.231: [GC 77259.231: [ParNew: 130939K->0K(131008K), 0.3262398 secs] 16003104K->15893957K(28671936K) icms_dc=0 , 0.3264322 secs]
    77269.578: [GC 77269.578: [ParNew: 130944K->0K(131008K), 0.3244924 secs] 16024901K->15897801K(28671936K) icms_dc=0 , 0.3246682 secs]
    77280.109: [GC 77280.109: [ParNew: 129785K->0K(131008K), 0.3440615 secs] 16027587K->15923895K(28671936K) icms_dc=0 , 0.3442430 secs]
    77290.806: [GC 77290.806: [ParNew: 125725K->0K(131008K), 0.3185027 secs] 16049620K->15950674K(28671936K) icms_dc=0 , 0.3186805 secs]
    77302.797: [GC 77302.797: [ParNew: 130859K->0K(131008K), 0.3043288 secs] 16081533K->15958590K(28671936K) icms_dc=0 , 0.3045180 secs]
    77312.365: [GC 77312.365: [ParNew: 130944K->0K(131008K), 0.2918505 secs] 16089534K->15960772K(28671936K) icms_dc=0 , 0.2920314 secs]
    77322.862: [GC 77322.863: [ParNew: 130944K->0K(131008K), 0.3015737 secs] 16091716K->15963449K(28671936K) icms_dc=0 , 0.3017476 secs]
    77343.729: [GC 77343.729: [ParNew: 130944K->0K(131008K), 0.3236395 secs] 16094393K->15967208K(28671936K) icms_dc=0 , 0.3238134 secs]
    77354.586: [GC 77354.586: [ParNew: 130944K->0K(131008K), 0.3131893 secs] 16098152K->15970188K(28671936K) icms_dc=0 , 0.3133721 secs]
    77364.952: [GC 77364.952: [ParNew: 130944K->0K(131008K), 0.3102413 secs] 16101132K->15992949K(28671936K) icms_dc=0 , 0.3104283 secs]
    77377.458: [GC 77377.458: [ParNew: 130935K->0K(131008K), 0.3312504 secs] 16123885K->16015429K(28671936K) icms_dc=0 , 0.3314204 secs]
    77386.642: [GC 77386.642: [ParNew: 130944K->0K(131008K), 0.3294257 secs] 16146373K->16018109K(28671936K) icms_dc=0 , 0.3296290 secs]
    77397.408: [GC 77397.408: [ParNew: 130944K->0K(131008K), 0.3466004 secs] 16149053K->16041639K(28671936K) icms_dc=0 , 0.3467640 secs]
    77407.720: [GC 77407.720: [ParNew: 127181K->0K(131008K), 0.3291395 secs] 16168820K->16067781K(28671936K) icms_dc=0 , 0.3293197 secs]
    77419.256: [GC 77419.257: [ParNew: 127292K->0K(131008K), 0.3417004 secs] 16195074K->16101594K(28671936K) icms_dc=3 , 0.3418733 secs]
    77426.886: [GC [1 CMS-initial-mark: 16101594K(28540928K)] 16165188K(28671936K), 0.0349381 secs]
    77426.921: [CMS-concurrent-mark-start]
    77428.941: [GC 77428.941: [ParNew: 130944K->0K(131008K), 0.2950079 secs] 16232538K->16108380K(28671936K) icms_dc=3 , 0.2951910 secs]
    77438.826: [CMS-concurrent-mark: 0.913/11.904 secs]
    77438.826: [CMS-concurrent-preclean-start]
    77438.826: [CMS-concurrent-preclean: 0.000/0.000 secs]
    77439.028: [CMS-concurrent-abortable-preclean-start]
    77439.028: [CMS-concurrent-abortable-preclean: 0.000/0.000 secs]
    77439.480: [GC 77439.480: [ParNew: 126872K->0K(131008K), 0.3251631 secs] 16235253K->16139128K(28671936K) icms_dc=3 , 0.3253437 secs]
    77447.411: [GC[YG occupancy: 66352 K (131008 K)]77447.411: [Rescan (parallel) , 0.0551127 secs]77447.466: [weak refs processing, 0.0308647 secs]77447.497: [class unloading[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor28]
    77447.504: [scrub symbol & string tables, 0.0084419 secs] [1 CMS-remark: 16139128K(28540928K)] 16205480K(28671936K), 0.1156339 secs]
    77447.528: [CMS-concurrent-sweep-start]
    77450.331: [GC 77450.331: [ParNew: 127555K->0K(131008K), 0.3276881 secs] 16257886K->16148782K(28671936K) icms_dc=3 , 0.3278723 secs]
    77471.167: [GC 77471.168: [ParNew: 130944K->0K(131008K), 0.3443864 secs] 16264980K->16156348K(28671936K) icms_dc=3 , 0.3445624 secs]
    77484.330: [GC 77484.331: [ParNew: 130944K->0K(131008K), 0.3138211 secs] 16282337K->16155285K(28671936K) icms_dc=3 , 0.3139971 secs]
    77490.323: [GC 77490.323: [ParNew: 130887K->0K(131008K), 0.3463333 secs] 16266084K->16158092K(28671936K) icms_dc=3 , 0.3465076 secs]
    77503.075: [GC 77503.075: [ParNew: 130944K->0K(131008K), 0.3230820 secs] 16246239K->16117912K(28671936K) icms_dc=3 , 0.3232641 secs]
    77513.508: [GC 77513.508: [ParNew: 130944K->0K(131008K), 0.3446744 secs] 16232772K->16104890K(28671936K) icms_dc=3 , 0.3449231 secs]
    77526.076: [GC 77526.076: [ParNew: 130173K->0K(131008K), 0.3488064 secs] 16219569K->16093708K(28671936K) icms_dc=3 , 0.3490094 secs]
    77535.048: [GC 77535.048: [ParNew: 130944K->0K(131008K), 0.3444742 secs] 16091984K->15984538K(28671936K) icms_dc=3 , 0.3447258 secs]
    77540.284: [CMS-concurrent-sweep: 1.808/92.757 secs]
    77540.285: [CMS-concurrent-reset-start]
    77540.637: [CMS-concurrent-reset: 0.352/0.352 secs]
    77547.483: [GC 77547.483: [ParNew: 130944K->0K(131008K), 21.2268491 secs] 569606K->465738K(28671936K) icms_dc=0 , 21.2270424 secs]
    77570.056: [GC 77570.056: [ParNew: 129623K->0K(131008K), 21.8197998 secs] 595362K->492094K(28671936K) icms_dc=0 , 21.8200025 secs]
    77592.450: [GC 77592.450: [ParNew: 130901K->0K(131008K), 22.4998156 secs] 622995K->513309K(28671936K) icms_dc=0 , 22.5000306 secs]
    77615.471: [GC 77615.471: [ParNew: 130865K->0K(131008K), 24.1625520 secs] 644174K->515142K(28671936K) icms_dc=0 , 24.1627472 secs]

    Might it be possible for you to check if the same behaviour reproduces
    with the latest (b76?) Mustang JVM?
    If so, let us know and we'll look into this more closely.
    PS: Could you also pstack the process once it gets into
    one of these long scavenges, and see if you find a lot
    of "block_start" calls at the top of the stack (during card
    scanning). It's almost certainly some performace pathology
    related to block offset table accesses during card scanning
    in the presence of large contiguous blocks would be my
    guess.

  • Can't view output for concurrent request

    I apologize if this is a common error - I tried to research this in the forums but didn't find anything that I haven't already tried. I checked the OPP - it is running with 3 processes - no error in the log that I can see. I checked the profile for the OPP timeout and have increased it....
    I have registered the data definition, registered and associated a template - created the concurrent program but when I try to run it completes with a warning and can't view output. The log states:
    XDO Data Engine Version No: 5.6.3
    Resp: 20420
    Org ID : 81
    Request ID: 2322744
    All Parameters: PO=5026930
    Data Template Code: GISDOSXML
    Data Template Application Short Name: XXGISD
    Debug Flag: N
    {PO=5026930}
    Calling XDO Data Engine...
    Start of log messages from FND_FILE
    End of log messages from FND_FILE
    Executing request completion options...
    ------------- 1) PUBLISH -------------
    Unable to find an Output Post Processor service to post-process request 2322744.
    Check that the Output Post Processor service is running.
    ------------- 2) PRINT   -------------
    Not printing the output of this request because post-processing failed.
    --------------------------------------

    also - I found a note on using the XML Republish Report and I tried it with the report I ran and it erred completely. Here is the log for the republish:
    Oracle XML Publisher 5.6.3
    Updating request description
    Waiting for XML request
    Retrieving XML request information
    Preparing parameters
    Process template
    --XDOException
    java.lang.reflect.InvocationTargetException
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at oracle.apps.xdo.common.xml.XSLT10gR1.invokeParse(XSLT10gR1.java:517)
         at oracle.apps.xdo.common.xml.XSLT10gR1.transform(XSLT10gR1.java:224)
         at oracle.apps.xdo.common.xml.XSLTWrapper.transform(XSLTWrapper.java:177)
         at oracle.apps.xdo.template.fo.util.FOUtility.generateFO(FOUtility.java:1044)
         at oracle.apps.xdo.template.fo.util.FOUtility.generateFO(FOUtility.java:997)
         at oracle.apps.xdo.template.fo.util.FOUtility.generateFO(FOUtility.java:212)
         at oracle.apps.xdo.template.FOProcessor.createFO(FOProcessor.java:1657)
         at oracle.apps.xdo.template.FOProcessor.generate(FOProcessor.java:967)
         at oracle.apps.xdo.oa.schema.server.TemplateHelper.runProcessTemplate(TemplateHelper.java:5888)
         at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3438)
         at oracle.apps.xdo.oa.schema.server.TemplateHelper.processTemplate(TemplateHelper.java:3527)
         at oracle.apps.xdo.oa.cp.JCP4XMLPublisher.runProgram(JCP4XMLPublisher.java:683)
         at oracle.apps.fnd.cp.request.Run.main(Run.java:161)
    Caused by: oracle.xdo.parser.v2.XMLParseException: '=' missing in attribute.
         at oracle.xdo.parser.v2.XMLError.flushErrors1(XMLError.java:324)
         at oracle.xdo.parser.v2.NonValidatingParser.parseAttrValue(NonValidatingParser.java:1556)
         at oracle.xdo.parser.v2.NonValidatingParser.parseAttr(NonValidatingParser.java:1461)
         at oracle.xdo.parser.v2.NonValidatingParser.parseAttributes(NonValidatingParser.java:1394)
         at oracle.xdo.parser.v2.NonValidatingParser.parseElement(NonValidatingParser.java:1225)
         at oracle.xdo.parser.v2.NonValidatingParser.parseRootElement(NonValidatingParser.java:314)
         at oracle.xdo.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:281)
         at oracle.xdo.parser.v2.XMLParser.parse(XMLParser.java:266)
         ... 17 more

  • Rtf template not showing as uploaded in concurrent program

    Hello
    I have created xml data definition and uploaded a rtf template. Then linked it to my concurrent program. But when i ran the concurrent program successfully all i get is the xml output. Upon closer inspection it shows that no template is uploaded. Yet in xml publisher it shows as uploaded.
    so my question is: what can prevent a rtf template from attaching to a concurrent program?

    If you and send the template, it would be helpful.
    kindly send it to [email protected]
    Deepa

  • Concurrent mailbox moves from Exchange 2007 to 2013

    We are in the process of migrating from Exchange 2007 to Exchange 2013. We have about 200 mailboxes and we want to move them in groups of 40-50 at a time. I am trying to get more then 1 mailbox to actually sync to the new database at once.
    I start the batch with 49 mailboxes but only 1 mailbox is showing any progress when I go to details. They all have a status of "syncing" but only one has any "items synced".
    I have run multiple articles about increasing concurrent migrations from 2007 to 2010 and 2010 to 2013 and they all mention going to MsExchangeMailboxReplication.exe.config on the destination server and setting the “MaxActiveMovesPerTargetMDB" value
    to something larger. By default 2013 has it set to 20 would should be more than enough  for me. However despite this setting I still only see 1 mailbox syncing at a time.
    Is there someplace I should be making a similar change on the 2007 box? I can't find a file with that name so I am not sure if there is something to change or if it's even needed.
    Why is this not working? Any help is much appreciated. Thanks!

    Outlook will show the infamous login popup and users will not be able to access Exchange 2013 Public Folders.
    You can check the Outlook Clients version in Exchange Management Shell with Get-LoginStatistics (ex. Outlook 2010):
    Get-Logonstatistics | select-object username,clientversion | where {$_.clientversion -gt "14.0*" -AND $_.clientversion -lt "14.0.6117.5001"}
    Step by Step Screencasts and Video Tutorials

  • Help needed for building report with execution method Java Concurrent prog

    Hi,
    I have saw a report like this:
    The report has executable "XML Publisher Data Template Executable", short name as "XDODTEXE", application "XML Publisher",execution method "Java Concurrent program". Also the report has a XML publisher Data Template and Data definition and in the data definition a .xml file is attached.
    I could not understand what is the data source?
    Could anyone help me on how to build or update this type of report?
    Is there any link or help docs which has proper step by step procedure to build this type of xml publisher report?
    Please help.
    Thanks.

    The xml file which is attached to the data definition is the data source and it has sql queries and structure of xml file.
    Check this out for step-by-step guidance.
    http://www.oracle.com/technetwork/middleware/bi-publisher/overview/xmlebsrep-132947.pdf
    http://apps2fusion.com/at/ps/51-prabhakar/262-xml-publisher-and-data-template-sql-query-to-develop-bi-publisher-reports
    For more on data templates refer user guide
    http://download.oracle.com/docs/cd/E10415_01/doc/bi.1013/e12187/T421739T434255.htm

  • Purge Concurrent Request and/or Manager Data program:

    Hi Friends,
    I am purging all my test report output logs using the above program, but the table
    FND_CONC_PP_ACTIONS is not being deleted;
    SQL> select count (*) from FND_CONC_PP_ACTIONS;
    COUNT(*)
    9470
    FND_CONC_PP_ACTIONS
    Stores the post request processing actions(e.g., print, notify) for each
    submitted request. There's a concurrent_request_id here for each request_id
    in the FND_CONCURRENT_REQUESTS.
    How can i forced delete the tables? since im still on the testing phase its OK if i zero out
    all of it.
    Thanks a lot

    or I want it zero (0) to delete all You cannot set it to zero (0). The Age parameter should be between (1) and (9999999).
    Did I mess it up? when I manually deleted the contents of
    I thought I can delete this logs manually because they are on filesystem.
    I thought only the database tables are needed to be cared for. Even though you should not bother yourself and delete the files manually under $APPLOG and $APPLOUT directories since the concurrent request will do the job for you, it is safe to delete it manually. The only impact you would have here is, you would not be able to access the log/out files of the concurrent requests (if the requests still presented in the tables and you can see it from the application).
    Did you try to use the "Count" parameter instead of the "Age"? The "Count" parameter indicates the number of (most recent) records for which you want to save concurrent request history, log file, and report output files.

Maybe you are looking for

  • 2 iPods/iTunes on one computer?

    I have an iPod with iTunes on our home computer. I'd like to get my husband an iPod, as well. Is there anyway we can have two separate iTunes programs on our computer? I don't want to mix up our music (very different tastes!).

  • Lion install fail on my macbook "a recovery service cannot be created" please help!

    Trying to install lion on my Macbook but keep getting install fail error saying a recovery service could not be created" I have a usb hard drive connected with time machine and a bootcamp 12 gig partition with windows XP Please help its driving me ma

  • How do I get my music stored in ICloud on my laptop?

    How do I get my music stored in ICloud on my laptop?

  • Applying profiles: Did I do right?

    I'll try keep this simple... Objective To supply a page advertisement as a press-ready PDF to publishers specification 1.3 PDF Ink density not to exceed 300% Processes and Results I downloaded and installed the following profile 'ISO coated v2 300% (

  • WLS, WLP 8.1 sp5 : XHTML compliance

    Hi, I'm working on a portal application, coded with Workshop and Portal Frameworks. A migration of presentation layer is needed. That implies a full XHTML 1.0 strict compliance. It looks that generated code by BEA tags is not compliant at all : - URL