The purge process did not run because the Oprid configured to start the Process Scheduler did not have the required permissions to run the purge process.

 Purge process - Required permissions

The PeopleSoft Oprid used to start the Process Scheduler, as defined in the Scheduler's psprcs.cfg file, must have the following permissions to be able to submit the purge process:

1) "ProcessSchedulerAdmin" Role.
2) "ReportDistAdmin" Role.
3) The Oprid must have the "Can start Application Server" permission assigned.

4) The Oprid must have the TLSALL Process Group permission assigned.
5) The Oprid must have a valid Process Profile and Primary Permission List.


NOTE: "Can start Application Server" and TLSALL process group permissions must be part of a Role assigned to the Oprid.

Steps to add the necessary permissions:

1) Navigate to PeopleTools - User Profiles - User Profiles.
2) Bring up the record for the affected Oprid.
3) Navigate to the Roles tab.
a) Select the + button to add a new row.
b) Assign the "ProcessSchedulerAdmin" role.
c) Select the + button to add a new row.
d) Assign the "ReportDistAdmin" role.
e) Select the + button to add a new row.
f) Assign the "PeopleSoft User" role.
g) Select the + button to add a new row.
h) Assign the "PeopleTools" role.
i) Save the record.
4) Navigate to the General tab.
a) Take note of the Process Profile value.
5) Navigate to PeopleTools - User Profiles - Permissions & Roles.
6) Select Permission Lists and search for the Permission List from step 4a.
7) On the General tab, select the "Can Start Application Server?" checkbox.
8) Select the Process tab.
a) Select the "Process Group" link.
b) Enter a new value: "TLSALL".
c) Hit Ok to return to the previous page.
d) Save the record.

Process Scheduler Fails To Start On Unix: System Lock Semop Failure

Issue :

 The Process Scheduler defined on UNIX will not start.  The following error occurs in the TUXLOG file:

"125432.machinename!BBL.8918.1078784256.0: LIBTUX_CAT:271: ERROR: System
lock semop failure, key = 217338 (errno = 22)
125432.machinename!BBL.8918.1078784256.0: LIBTUX_CAT:268: ERROR: Failed to
stop serving."

Fix :

ensure the OS level userid starting the Process Scheduler has rwxr-xr-x level permissions with regard to the Oracle library libclntsh.so.10.1

Future of Oracle HTTP Server with Peopletools 8.60

 OHS is Certified based on the Weblogic version, not directly with the PeopleTools version being used, however this can be "Certified by association" since each major version of PeopleTools is only Certified with one version of Oracle Weblogic.

PeopleSoft PeopleTools 8.60 is certified with Oracle WebLogic Server 14.1.1.0.0 (minimum patch level).

Oracle Weblogic is Certified with the following OHS versions:
- 12.2.1.4.0
- 12.2.1.3.0
- 11.1.1.9.0

Therefore, the above OHS versions are INDIRECTLY Certified with PeopleTools 8.60, based on the Weblogic version involved.

OpenSearch as the successor of Elasticsearch and Kibana, beginning with PeopleTools 8.60.07 and 8.59.21

 OpenSearch as the successor of Elasticsearch and Kibana, beginning with PeopleTools 8.60.07 and 8.59.21.

Tech Update – Oracle PeopleSoft Transitions to OpenSearch (Doc ID 2950040.1)

As Oracle says:
Over the years, we have seen search in PeopleTools shift with the technologies available in the industry. We initially started with Verity.we moved to Oracle SES (Secure Enterprise Search). During this period, search was largely restricted to navigation and certain specialized application data scenarios such as Job Search, etc. Next, we prepared for the transition to Elasticsearch. During this move, we put a lot more effort and focus on the Search Framework to make the switch of the backend ‘search engine’ as seamless as possible. Due to licensing changes introduced by Elastic (details here), Elasticsearch 7.10.0 and Kibana 7.10.0 will be the last versions used in PeopleTools and PeopleSoft applications.  PeopleTools plans to deliver OpenSearch as the successor of Elasticsearch and Kibana, beginning with PeopleTools 8.60.07 and 8.59.21.

customers never really relied on Elastic to install or support ELK in PeopleSoft. It was packaged and managed entirely within PeopleTools. Similarly, OpenSearch (for search) and OpenSearch Dashboards (for analytics) are planned to be packaged (DPK) and managed as part of PeopleTools.

More details related to Opensearch is under 
https://opensearch.org/faq#q1.2

Failed to Find Ldap Server to Load Schema

 Failed to Find Ldap Server to Load Schema

Solution :

Implement the following workaround to resolve. 

- Navigate to People Tools --> Security --> Directory --> Authentication Map

- Search for a map name and if you do not have one, create new and give it a name.

- Check the box "Use Secure Socket Layer " click save.

- Uncheck the box "Use Secure Socket Layer " click save.

- Run the load schema process again.

- Process runs to success.

ERROR: IP ... is blocked due to too many failed logon attemps!

Run below commands

 On Unix - export TUXCONFIG=$PS_CFG_HOME/appserv/<domainname>/PSTUXCFG

 On Windows - SET TUXCONFIG=<PS_CFG_HOME>\appserv\<domainname>\PSTUXCFG

tmadmbclist -l

It will list the blocked ips

tmadmbclist -b xxxxxx

where xxxxxxx is blocked ip

LDAP : Error running Cache Directory Schema(Cannot load business interlink plug-in (122,19) PSDSSCHE

Issue:  Test Connectivity is fine but as soon as I run CACHE DIRECTORY SCHEMA we are getting below error.

Cannot load business interlink plug-in (122,19) PSDSSCHEMA.DSDIRID.FieldFormula Name:LDAPBind PCPC:21027 Statement:329

Called from:PSDSSCHEMA.DSDIRID.FieldFormula Name:ReadSchema Statement:349

Called from:PSDSSCHEMA.DSDIRID.FieldFormula Name:GetSchema Statement:607

Called from:LDAPSCHEMA.MAIN.GBL.default.1900-01-01.Step02.OnExecute Statement:2

Process 661109 ABENDED at Step LDAPSCHEMA.MAIN.Step02 (PeopleCode) -- RC = 8 (108,524)

Process %s ABENDED at Step %s.%s.%s (Action %s) -- RC = %s

Solution : Issue got fixed by setting PS_HOME under " " in psconfig.sh file in process scheduler server. It was previously not able to read the .dll file