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), there's one crucial step needed before you can use it - you must initialize and create a new volume from within the Windows VM's Disk Management tool (pic below).  

This video from Oracle shows how https://www.youtube.com/watch?v=JKbwtXP8v9s. I prefer to use the Paravirtualized attachment type instead of iSCSI.  

How to find the navigation of a Process

SELECT DISTINCT RTRIM( REVERSE ( SYS_CONNECT_BY_PATH(REVERSE (portal_label), ' > ')) ,' > ') PATH FROM PSPRSMDEFN
      WHERE portal_name = 'EMPLOYEE' 
        AND portal_prntobjname = 'PORTAL_ROOT_OBJECT' 
  START WITH portal_uri_seg2 IN (
                        SELECT DISTINCT pnlgrpname 
                        FROM ps_prcsdefnpnl 
                        WHERE prcsname in ('PROCESS_NAME_HERE') ) 
  CONNECT BY PRIOR portal_prntobjname = portal_objname;

Query to Find the Row Count of Tables in the Database

During upgrade this query can be quite handy to find the Row Count of tables in the database.


set linesize 999
set pages 0
set trimspool on

spool D:\row_count_FSCM88_01_bfr_upgrade.txt
-- spool D:\row_count_FSCM91_02_afr_upgrade.txt


SELECT table_name, to_number(extractvalue(xmltype(dbms_xmlgen.getxml('select count(*) c from 'table_name)),'/ROWSET/ROW/C')) AS COUNT FROM DBA_TABLES WHERE table_name IN (SELECT TABLE_NAME FROM DBA_TABLES WHERE TABLE_NAME LIKE 'PS%')AND owner = 'SYSADM' GROUP BY table_name ORDER BY table_name
/


spool off

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

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.

Oracle Open World 2009

Today is the last day of Oracle Open World 2009. Some exciting bloggers have taken time to keep us updated on this. You may wish to visit them for sure:

Grey Sparling Blog
Graham's PeopleSoft Blog
PeopleSoft Corner Blog
PeopleSoft Wisdom
Arun Gupta's Miles to go...
Official Oracle OpenWorld Blog