Header Ads

  • Recent Posts

    Remote Call: Process failure due to timeout errors

    In PeopleSoft often times there are COBOL process that are kicked off via remote call and run for a long time. This can result in process failure when the Timeout parameter causes the process to be killed before it has time to complete.
    In any Remote Call process, a "timeout" error message appears similar to the following (the file number may differ):

    "Child program c:\PS\cblbin\PTPEMAIN\ REMOTE/MICROSFT/FSDMO/VPINE/%OPRPSWD%/PGG_SERV43/ (154) did not complete in allowed time (50 seconds). Killing process (2, -1)"


    The following resolution details where to reset timeout parameters to correct these problems.

    1. Increase the Service Timeout for the server that advertises for remote call

    Remote Call via Page/Panel push button:
    Logged in 2-tier --> Config Manager --> Remote Call --> Time out tab
    Logged in 3-tier --> PSAPPSRV.CFG file specifies the ServiceTimeout.
    At the top of the panel there is a Time Out field -- increase the time limit and click Apply or OK. To disable any timeout limit set this value to zero.
    Remote Call Via Application Engine process:
    If the process is submitted to the process scheduler, then relevant setting is in the PSPRCS.CFG file -- RCCBL Timeout because it is the process (Application Engine) which was initiated by the scheduler, that kicked off remote call.

    NOTE:
    The Application Server and the Process Scheduler read their configuration files only once during boot time. So, if you have made a change to the config file, you have to restart the server process for it to take effect.

    2. Reconfiguring the Oracle data base for Cost based optimizing instead of the Rule based optimizing might work.

    3. This error could be also a result of the cobsw being set to -L5. An icon would pop up on the start menu and it would be hidden; the ct would receive this error because the ok button was not pressed out within the timeout requirements. 
    Customer changed the cobsw in the autoexec.bat to say 
    cobsw=+L1 and this caused the dos box and the ok button to go away.

    4. Even though the COBOL programs are in sync with each other, if the GNT and EXE files are not in sync the issue can occur. Again recompiling the COBOL programs might help.

    5. The problems could also be created by loading security info on the PeopleSoft side (PSOPREDEFN etc). The Oracle username passwords may go out of sync.

    Error: COULD NOT START CHILD PROGRAM [path] ...... (2,-1)
    - Running Online Check in 2-tier.
    -Error COULD NOT START CHILD PROGRAM n:\hr750\cblbin\PSPPYRUN
    REMOTE/INFORMIX/Onlihr75_tcp/HCON6/PG/%OPRSW D%//(2,-1)

    Solution:
    a. Copy old DLL from CBLBIN and add them to the New DLL from
    NetExpress BIN Directory and recompile.

    b. One May get error Message CBL_SET_SEMIPHORE. For this
    refer SOLUTION 424376 [NetExpress 3.0 bug; Merant fix] in Oracle Support

    c. The two registry variables ConnectId et ConnectPswd in the branch
    HKEY_CURRENT_USER\Software\PeopleSoft\PeopleTools\Release7.5\Startup 
    contain psuser and people1 information on the PC.

    If the config manager.cfg file has these variables as empty, looks like the COBOL process work perfectly 
    This config. manager suppresses them of the registry and COBOLs work fine.

    d. Uncomment the RCCBL PRDBIN line. 
    RCCBL Redirect=0
    ;-------------------------------------------------------------------------
    ; Location of COBOL programs

    ; By default, RemoteCall looks for the COBOL programs in %PS_HOME%\cblbin
    ;
    RCCBL PRDBIN=%PS_EPHOME%\cblbin

    With this change it had worked fine on some cases.

    Reported by a consultant: "If you are using NetExpress 3.0, the delivered DLL's in the cblbin directory are not compatible. So, what you got to do is - copy the DLL's from the netexpress\base\bin (?) directory and move them into the cblbin directory (essentially replacing/overwriting PeopleSoft's delivered dll's)"

    The slash on the PRDDRIVE option of configuration manager was removed and this resolved the problem. In the Configuration Manager, under the Process Scheduler tab, the COBOL Executable Drive (PRDDRIVE): entry should be {drive letter}: , our entry had {drive letter}:\ , the slash was the problem. The slash was removed and everyone was happy.

    No comments

    Please refrain for marketing messages and unnecessary back links.

    Post Top Ad

    Post Bottom Ad