Thursday, September 23, 2010

XMLP Report Generation and Download Issue

There were two issues reported by user recently related to XMLP:
1) Suddenly XMLP Reports were not getting generated
2) Also, user is not able to download the existing template

App Server Log file shows following error messages while generating an XMLP Report:
Output Xliff file: XDOException:No source available for parsing
During calling method PTRTFPocessor.generateXSL, the XDO engine throws an exception: No source available for parsing. (235,3101) (235,2304)


Trace File shows following exception message for downloading the XMLP Template:
PSAPPSRV.4931 (339) 1-334 12.37.03 0.000042 ExecuteGetAttachmentDB: lpszTblName = PSFILE_ATTDET
PSAPPSRV.4931 (339) 1-335 12.37.03 0.001462 ExecuteGetAttachmentDB: Fetching data
PSAPPSRV.4931 (339) 1-336 12.37.03 0.002891 ExecuteGetAttachmentDB: failed trying to write file
PSAPPSRV.4931 (339) 1-337 12.37.03 0.000005 ExecuteGetAttachmentDB: Data fetched
PSAPPSRV.4931 (339) 1-338 12.37.03 0.000054 ExecuteGetAttachmentDB: Finished getting file.
PSAPPSRV.4931 (339) 1-339 12.37.03 0.000027 193: If &Rtn <> %Attachment_Success And
PSAPPSRV.4931 (339) 1-340 12.37.03 0.000015 194: throw CreateException(235, 5, "Error downloading file");


The XMLP Report logging was found enabled for the environment which was creating huge files ( in /tmp/xdodebug) and have occupied most of temp space over the period of 2 months - making /tmp filesystem 100% full. This caused both the issues.

To resolve this, delete the old files created under /tmp/xdodebug folder (or whatever location is defined in your /jre/lib/xdodebug.cfg file). Also, you can choose to disable the XMLP logging by deleting the xdodebug.cfg file. Recreate the config file when you want to enable the XMLP Logging to replicate the issue - xdodebug.cfg file contains following two parameter:
LogLevel=OFF or STATEMENT
LogDir=/tmp/xdodebug

Monday, September 13, 2010

Troubleshooting Tips

Would like to share my troubleshooting tips - not necessarily among the best in the business but these suit me well:


1- Think of all the possible reasons - The Environment Components, Connectivity, Port, Side effect of any release/bundle/fix applied, The nature of the issue - consistent/intermittent etc.

2- Do Not implement any resolution immediately that you come across while surfing the community - rather think logically from your environment perspective and then take a call

3- Understanding of your infrastructure would be helpful while you start ruling out the culprit


Maybe FIELDTBLS32 is not set properly

It's been such a long time since my last post - was/am too busy to post new learnings, will now try to be bit more regular :)

In Tuxedo 9.1 in PeopleTool 8.49 recently encountered with an issue where WebServer was not able to connect to the App Server - even though App Server was up. While checking the TUXLOG, following message was found:

093006.!JSH.26507.1.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name 'JPOOL_685'; client name ''"
093006.!JSH.26502.1.-2: JOLT_CAT:1185: "INFO: Userid: [JPOOL_683], Clientid: [] timed out due to inactivity"
093006.!JSH.26502.1.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name 'JPOOL_683'; client name ''"
093029.!JSH.26502.1.-2: Fldid32(PATTERN) failed for .GETALL: LIBFML_CAT:11: ERROR: Cannot find or open field table. Maybe FIELDTBLS32 is not set properly.
093029.!JSH.26507.1.-2: Fldid32(PATTERN) failed for .GETALL: LIBFML_CAT:11: ERROR: Cannot find or open field table. Maybe FIELDTBLS32 is not set properly


The issue appeared to be with the settings of FIELDTBLS32 and FLDTBLDIR32 variables in psappsrv.ubx post Tuxedo 9.1 RP 095. In order to resolve this values of these variables needs to be modified in psappsrv.ubx:

From FIELDTBLS32=tpadm to FIELDTBLS32=jrep.f32,tpadm
From FLDTBLDIR32=$TUXDIR\udataobj to FLDTBLDIR32={$TUXDIR}/udataobj


*** make sure to use the correct "/"
*** There are two places in psappsrv.ubx where these changes are required to be made. Reconfigure and restart the AppSrv domain.

Thursday, October 15, 2009

Monday, October 12, 2009

App Server boot problem - PSCLOCK

Last week I faced an issue while trying to boot the application server. I checked for all the common things that could have caused the problem like password, connectivity, path etc. But everything looked well. I configured the app server for SQL trace and issued the boot command.

From trace file, it was observed that the app server boot was stuck up at SELECT CURRENT TIMESTAMP FROM PSCLOCK command. While issued the command SELECT * FROM PSCLOCK, PSCLOCK table was found blank and was responsible for this problem.

I imported PSCLOCK table from another environment and started the app server to success.

Incidentally, the reason for how data from PSCLOCK table have been deleted was not identified.

Wednesday, June 3, 2009

PeopleTools 8.50 RVP Available

FYI, Oracle has made available PeopleTools 8.50 RVP (Release Value Propositions) - Click Here to read the Oracle blog.

Some notable PeopleTools 8.50 Enhancements are:

  • Partial Page Refreshes using AJAX technology
  • Menu Navigation (menu 2.0) by providing a new AJAX-enabled left navigation menu pagelet
  • Search Page Enhancements by providing an option to specify the maximum number of rows returned
  • Change Assistant enchancement by allowing parallel file deployment
  • Extending Support for 64-bit Technology by providing supports to only 64-bit Operating Systems
  • Securing Server Based File Directories by de-coupling PS_HOME so that executables, logs, and configuration files will no longer be contained in the same place
  • Number of exciting new enhancements in Integration Broker

There are n number of interesting enhancement in PeopleTools 8.50... For complete information - read Oracle blog here

Thursday, May 28, 2009

PROCESS GROUP

Process group is crucial in securing the processes and jobs in the system. It is possible to restrict access to certain processes within PeopleSoft by establishing process groups. A batch process is assigned a 'Process Group' when created. That 'Process Group' is then linked to a permission list (PL). The PL is then assigned to a 'Role' and, subsequently, to a USERID. Process groups are collections of process definitions that you create using PeopleSoft Process Scheduler.
Navigations to Assign a Process to a Process Group:
PeopleTools -> Process Scheduler -> Processes -> Process Definition Option Tab -> Process Security section
Navigations to Assign a Process Group to a Permission List:
PeopleTools -> Security -> Permissions & Roles -> Permission -> Process tabs -> Process Group Permissions

Users can run only the processes that belong to process groups assigned to their roles. For example, you may have a set of process definitions that relate to your Human Resources department and another set for your Manufacturing department. If process 'P1' is in the process group 'PG1' and any of the Permission List (PL) of the user, say 'USER1', does not have access to that process group 'PG1' - then - that user 'USER1' cannot run the process 'P1'. A process definition can be a member of multiple process groups.

The process group are not stored in any setup table of its own. They are stored in the table - PRCSDEFNGRP and PRCSJOBGRP (where process and job definitions are stored). If you look at the prompt for PRCSGRP field in those tables, it is a 'PROMPT WITH NO EDIT' - It means, you can keep adding new Process groups on the fly, on process and job definition components. You may want to execute below queries for better understanding:
select * from PS_PRCSDEFNGRP
select * from PS_PRCSJOBGRP

OCI - Attach Block Volume to Windows VM

Tip: Although creating and attaching Block Storage to a Windows VM is pretty straightforward (OCI documentation is pretty good for that), th...