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.

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.

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

Posting Issue - For Restarted AE, Dist Status is in ' Posting' forever

Note 1: AE Process restarted in Process Scheduler remains in Posting status forever. According to Oracle, it is a known issue in PT 8.48.08 and has been fixed in PT 8.48.11)

Note 2: Below is just an workaround to let other processes, which stuck up in posting status because of the re-started AE, go posted.

I recently came across a posting issue where lot of AE prcess were in Success/No Success runstatus but not getting posted... They were stuck up in POSTING dist status. Output were getting generated successfully in log_output directory, however, the process were in POSTING distribution status only (few of them were in the same status for 3-4 days)

PeopleTools 8.48:
One way to resolve such issue MIGHT be to upated the Distribution Status of such process instances from POSTING (7) to NOT POSTED (4) in PSPRCSQUE and PSPRCSRQST tables... And then post them again using RE-SEND option.

*** Find the prcs instances with distribution status of POSTING (7):

select PRCSINSTANCE, RUNSTATUS, DISTSTATUS from PSPRCSRQST where DISTSTATUS='7';

select PRCSINSTANCE, RUNSTATUS, DISTSTATUS from PSPRCSQUE where DISTSTATUS='7';

*** Update these process instances' dist status from POSTING(7) to NOT POSTED (4)...

-- update PSPRCSQUE set DISTSTATUS='4' where PRCSINSTANCE IN (prcsinst_1, prcsinst_2, prcsinst_3);

-- update PSPRCSRQST set DISTSTATUS='4' where PRCSINSTANCE IN (prcsinst_1, prcsinst_2, prcsinst_3);

update PSPRCSRQST set DISTSTATUS='4' where PRCSINSTANCE in (select PRCSINSTANCE from PSPRCSRQST where DISTSTATUS='7');

update PSPRCSQUE set DISTSTATUS='4' where PRCSINSTANCE in (select PRCSINSTANCE from PSPRCSQUE where DISTSTATUS='7');

*** Post them again using RE-SEND option.

*** Also make sure all the three tables PSPRCSRQST, PSPRCSQUE, PSPRCSPARMS are in synce:

select count(*) from PSPRCSRQST;

select count(*) from PSPRCSQUE;

select count(*) from PSPRCSPARMS;

*** Values of Distribution Status can be found by using below query:

SELECT FIELDNAME, XLATLONGNAME, FIELDVALUE FROM PSXLATITEM WHERE FIELDNAME = 'DISTSTATUS';

FIELDNAME XLATLONGNAME FIELDVALUE

------------------------------------ ------------------------------------------------------------ ----------

DISTSTATUS None 0

DISTSTATUS Scheduled 1

DISTSTATUS Processing 2

DISTSTATUS Generated 3

DISTSTATUS Unable to Post 4

DISTSTATUS Posted to Web 5

DISTSTATUS Delete 6

DISTSTATUS Posting 7

8 record(s) selected.

COBOL - Configuring instance specific CBLBINs

Sharing a file server to multiple instances is a common practice in may PeopleSoft Infrastructures... Many a times scenerio occurs where we want to have applied some bundles or Maintenance Packs to few of these instances... In such cases many of the external objects like SQRs, CRYSTALs, COBOLs etc would be different for bundled and non-bundled environemtns. For such cases, we would require to have a separate directory for COBOL executable other than the shared one or default one.

Here are the setting required to be done for such scenerio:

1) Create new CBLBIN directory for each instance INS1, INS2, INS3, etc under $PS_HOME (or any other prefered location) like $PS_HOME/CBLBIN_INS1, $PS_HOME/CBLBIN_INS2, $PS_HOME/CBLBIN_INS3 etc.

2) ## Copy the compiled COBOLs into new CBLBIN directory i.e., to $PS_HOME/CBLBIN_INS1, $PS_HOME/CBLBIN_INS2, $PS_HOME/CBLBIN_INS3 etc

3) Process Scheduler Settings for instance INS1:
Modify psprcsrv.ubx - COBPATH={$PS_HOME}/CBLBIN_INS1
Modify psprcsrv.env - COBPATH={$PS_HOME}/CBLBIN_INS1
Modify psprcsrv.cfg - in RemoteCall Section RCCBL PRDBIN=%PS_HOME%/CBLBIN_INS1

4) Application Server Settings for instance INS1:
Modify psappsrv.ubx - COBPATH={$PS_HOME}/CBLBIN_INS1
Modify psappsrv.env - COBPATH={$PS_HOME}/CBLBIN_INS1
Modify psappsrv.cfg - in RemoteCall Section RCCBL PRDBIN=%PS_HOME%/CBLBIN_INS1

##Besides this, you may also want to modify psrun.mak and pscbl.mak, so that while compiling the cobols - compiled files get copied, automatically at the time of compilation itself, to the newly created CBLBIN directories. For this, here are the required modifications:

1) Create directory INS1 under $PS_HOME/src/cbl and place all COBOL programs to be compiled for instance INS1 at location $PS_HOME/src/cbl/INS1

2) modify psrun.mak:
Replace $PS_HOME/src/cbl/ by $PS_HOME/src/cbl/INS1/

3) modify pscbl.mak: Update PS_CBLBIN parameter from old or default value $PS_HOME/cblbin TO new location of CBLBIN directory for instance INS1 $PS_HOME/CBLBIN_INS1:

PS_CBLBIN=$PS_HOME/CBLBIN_INS1

4) modify pscbl.mak:
Replace $PS_HOME/src/cbl/ by $PS_HOME/src/cbl/INS1/

Then compile and link the cobols.

PSPRCSRQST, PSPRCSQUE and PSPRCSPARMS

In order to avoid various process scheduler related issues, three Process Scheduler tables PSPRCSRQST, PSPRCSQUE and PSPRCSPARMS must be in sync.

Execute below queries:

select count(*) from PSPRCSRQST;select count(*) from PSPRCSQUE;select count(*) from PSPRCSPARMS;

If these queries give different results, you should bring them in sync by executing below statements:

DELETE FROM PSPRCSQUE QUE WHERE NOT EXISTS (SELECT 'X' FROM PSPRCSRQST RQST WHERE RQST.PRCSINSTANCE = QUE.PRCSINSTANCE);

DELETE FROM PSPRCSPARMS PARMS WHERE NOT EXISTS (SELECT 'X' FROM PSPRCSQUE QUE WHERE QUE.PRCSINSTANCE = PARMS.PRCSINSTANCE);

Also, Column RUNSTATUS of any process instance in table PSPRCSRQST must have same value in table PSPRCSQUE for that process instance... below query will show check for it.

select R.PRCSINSTANCE, R.RUNSTATUS, Q.PRCSINSTANCE, Q.RUNSTATUS from PSPRCSRQST R, PSPRCSQUE Q
where R.PRCSINSTANCE=Q.PRCSINSTANCE and R.RUNSTATUS != Q.RUNSTATUS

*** Also, it is a good practise to delete the processes with delete, error or cancelled status from the PeopleSoft tables:

DELETE FROM PSPRCSRQST where RUNSTATUS = '2' --> 2 is the run status for delelted process. DELETE FROM PSPRCSQUE where RUNSTATUS = '2'

*** Key Point: Data in PSPRCSRQST, PSPRCSQUE and PSPRCSPARMS tables must be in sync.

Process Run Status - PSXLATITEM

You can query PSXLATITEM table to know the value corresponding to a process run status.




SELECT XLATLONGNAME, FIELDVALUE FROM PSXLATITEM WHERE FIELDNAME = 'RUNSTATUS';




XLATLONGNAME ------------ FIELDVALUE

------------------------- ----------

Cancel ------------------------ 1

Not Successful --------------- 10

Posted ------------------------ 11

Unable to post --------------- 12

Resend ----------------------- 13

Posting ----------------------- 14

Content Generated --------- 15

Pending ----------------------- 16

Success With Warning ------ 17

Blocked ----------------------- 18

Restart ----------------------- 19

Delete ------------------------- 2

Error -------------------------- 3

Hold -------------------------- 4

Queued ----------------------- 5

Initiated ---------------------- 6

Processing -------------------- 7

Cancelled --------------------- 8

Success ----------------------- 9



19 record(s) selected.

Process Scheduler Run Status

--Run Status-- --- --- --- --- --Value--

Cancel	1
Delete	2
Error	3
Hold	4
Queued	5
Initiated	6
Processing	7
Cancelled	8
Success	9
No Success	10
Posted	11
Not Posted	12
Resend	13
Posting	14
Generate	15

Process Scheduler and Report Manager Issue

Troubleshooting Common Process Scheduler and Report Manager Issues
By David Ratway for PeopleSoftPros.net

http://www.sap-pros.net/net/articles/pssched-issues.pdf

Enabling PeopleCode Debugger

For PeopleSoft - PeopleCode 3-tier debugging, use PSADMIN to make sure that the following items are set.

1) The appropriate PSDBGSRV Listener Port is specified in the PeopleCode Debugger section of PSADMIN.

For example: Values for config section - PeopleCode Debugger
PSDBGSRV Listener Port=9500

2) At least two PSAPPSRV processes configured to boot in the domain with the Service Timeout parameter set to 0 (zero).

The minimum requirements for PeopleCode debugging are:
- Two (2) PSAPPSRV server processes configured to boot in the domain.
- The Service Timeout value in the PSAPPSRV configuration section must be set to zero (0).

The following example shows a sample PSAPPSRV section properly configured for debugging PeopleCode:
Values for config section - PSAPPSRV
Min Instances=2
Max Instances=2
Service Timeout=0
Recycle Count=0
Allowed Consec Service Failures=0
Max Fetch Size=5000

3) Enter y for Yes at the "Enable PSDBGSRV Server Process" prompt at the end of the PSADMIN interface.

After you have specified your settings using PSADMIN the system prompts you with a series of options, such as setting up messaging server processes, enabling Jolt, and so on. When prompted to enable the PSDBGSRV, enter Y. The Developer template defaults to Y.

Tuxedo 8.1- Unable to connect 3-Tier Windows Client with 128 bit encryption

xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">






href="When%20the%20WSL%20encryption%20is%20set%20to%20128_files/filelist.xml">

When the WSL encryption is set to 128, though the domain boots,
user is unable to login. It gives an error,

 

Network API error – unable to connect to appserver because of
possible causes...

 

Tuxedo log shows a warning:

***************: WSNAT_CAT:1229: WARN: A client failed
encryption negotiation

***************: WSNAT_CAT:1229: WARN: A client failed
encryption negotiation

 

Check BEA On-line documentation for the description of
WSNAT_CAT:1229- style='color:#3333FF'>http://edocs.beasys.com/tuxedo/tux65/ style='font-size:11.0pt'>

 

Starting with the Tuxedo 7.1 release, there is no 128 encryption
add on package. The way it now works is that both the client and server need
128 bit license. Hence the solution here is to copy the style='font-size:11.0pt;font-family:"Trebuchet MS";color:#990000'>lic.txtstyle='font-size:11.0pt;font-family:"Trebuchet MS";color:black'> from the
Tuxedo install, $TUXDIR/udataobj to %PS_HOME%\tuxedo\udataobjstyle='font-size:11.0pt;font-family:"Trebuchet MS";color:black'> on your file
server (the location where you are launching the executable to logon 3-tier).style='font-size:11.0pt;font-family:"Trebuchet MS";color:#000033'> style='font-size:11.0pt'>

 

How to find the Jolt patch level in Tuxedo 8.1?

Where can you find the joltpatchlev file in Tuxedo 8.1?

• While Jolt 1.2 is a separate software package from Tuxedo 6.5, Jolt 8.1 is not.

• In Tuxedo 8.1, Jolt 8.1 is packaged together with Tuxedo 8.1. Jolt 8.1 also shares the same patch file. So, there is no longer a "joltpatchlev" file. There is only a Tuxedo patch level because Jolt is a part of Tuxedo 8.1. You can get the Tuxedo patch level from ${TUXDIR}/udataobj/patchlev.

• You can also run tmadmin -v to obtain the Tuxedo patch level. For example,

$ tmadmin -v
INFO: BEA Tuxedo, Version 8.1, 32-bit, Patch Level 091
INFO: Serial #: 616351266349-1322302213900, Expiration 2005-03-10, Maxusers 1000
INFO: Licensed to: BEA Internal Developer
INFO: 128-bit Encryption Package

• You can also look in the Tuxedo userlog. When the BBL boots, you'll see the Tuxedo patch level. Again, there is no Jolt patch level, anymore. Since Jolt is a part of Tuxedo, there is only a Tuxedo patch level.

114536.lcsol19!BBL.15032.1.0: 03-18-2004: Tuxedo Version 8.1, 32-bit, Patch Level 091
114536.lcsol19!BBL.15032.1.0: LIBTUX_CAT:262: INFO: Standard main starting