This week on the podcast, Dan and Kyle discuss password rotation and safety, a great tip to speed up the NavBar, and Kyle’s app servers having connection issues.
This week David Kurtz joins us again to talk about the application server. David get’s into the details on how the application server works. Dan and Kyle also discuss a proposal for Control-J information on mobile devices and Fluid pages.
We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at firstname.lastname@example.org, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.
A comment on the Build Images with DPK post had a great question. Instead of answering it there, I wanted to share the solution as a post so more people would see it. The question deals with enabling (or disabling) features on the app server using the DPK. With the current PI’s based on PeopleTools 8.55.01, you can change app server configuration when you create the PI’s using the DPK.
If you have already built the PI’s, the 8.55.01 DPK doesn’t handle changes to the current configuration well.
To enable the WSL and Debugger when you build a DPK:
- Run the VBox or NativeOS DPK
Noto the “Do you want to continue with the default initialization” question.
- Create the file
psft_customizations.yamlin the folder
- Add these lines to your
psft_customizations.yamlfile (notice the lines
DBGSRV: "Yes"are different)
- Navigate to
puppet apply site.pp
If you have already build the PI, you can do in manually through
psadmin, but that’s no fun 😉 In PeopleTools 8.55.03, the DPK (Puppet modules) is better at handling configuration changes in the
psft_customizations.yaml file. I’d guess the next PI’s will be based .04 (or higher), so this should be able to make the change after you built the PeopleSoft Image.
Update: If you want to learn more about the DPK, check out our new PeopleSoft DPK QuickStart course. This free course will introduce you to the DPK, show you how to use the DPK with PeopleSoft Images, and show you how to customize the DPK for your servers.
The other day we had an app server that stopped responding to requests after it restarted. The domain was running, but our web server wasn’t able to talk to the app server. When we attempted to log in, we received the
CHECK APPSERVER LOGS. THE SITE BOOTED WITH INTERNAL DEFAULT SETTINGS, BECAUSE OF: bea.jolt.ServiceException: Invalid Session error.
You can get this from a few errors:
- The Domain Connect Password doesn’t match.
- The Web Profile user or password is wrong (or locked).
- The app server domain is actually down.
But, none of these applied to us. We knew the domain was up, we hadn’t changed the Domain Connect Password, and the Web Profile user account was correct. I then ran a
netstat -an command to make sure I could see the ports where listening. That’s when I found that our app server was listening on the wrong IP address.
In our environment, we have our regular IP addresses for the network, but our VM’s have a management network on a different IP range. The app server had booted up and was listening on the management network IP. I opened up the
psappsrv.cfg file and the
WSL listening IP’s were using the
%PS_MACH% variable will grab the first network card’s IP address on the machine. With Windows, that’s not a consistent way to get the IP address if you have more than one netword card.
The fix is to assign an IP address to the
WSL processes in the
psappsrv.cfg file. You can assign a specific IP address using:
When assigning an IP address you have two options:
- Listen to a specific IP address
- Listen to all IP addresses
If you want to listen on all IP addresses, use
0.0.0.0 for the listening address value.
You may not want to do this if you have more than one network card on the machine. Often, the second (or more) network cards are for different networks that specific uses. In our case, the second network card was for VM management and I don’t want our app server accepting any connections from that network segment. Our network traffic should be limited to our internal PeopleSoft network segment. To do specify an IP, list the specific IP address you want your app server to listen on in the
Time for everyone’s favorite language: COBOL! Well, it’s not my favorite, and probably not your favorite, but it is important to PeopleSoft. Many core programs in HR use COBOL and will most likely stay COBOL for a while. Those COBOL programs are stable, fast, and once you compile you rarely have to touch them. Because COBOL is important to PeopleSoft, let’s talk about setting up the compiler, runtime, and learn how to compile COBOL programs.
Installation and Configuration
PeopleSoft delivers COBOL source files with some of the applications, but you need to install the COBOL compiler separately. Oracle will give you a license to MicroFocus, so you don’t need to buy your own. Oracle Support has a nice article on downloading MicroFocus and acquiring a license. As a PeopleSoft customer, a MicroFocus license is included with the product to compile COBOL programs. Keep in mind, you can only use the compiler for PeopleSoft programs!
After you install the compiler, you will need to install the Runtime License on any server were your compiled COBOL will run: process schedulers and application servers. To install the runtime, open a command prompt and navigate to the folder that contains
setupMF.exe. Run these commands:
setupMF.exe e:\psoft\psft-mf—nx-as-licenseto install the license folder
e:\psoft\pt-85x.xx(your path to PS_HOME)
MFLMWin.exe -ito install the License Manager service.
- For Windows, you may need to change the security for
MFLMWin.exe. Right-click on that file, select the Compatibility tab, and check the box for “Run this program as an administrator”
- In the Services panel, verify the “MicroFocus License Manager” service has started and set to start Automatically
Clients Are you on PeopleTools 8.53 or lower? You’ll still need a 32-bit client for COBOL. That means installing the 32-bit client on your process scheduler and app server (for the remote call COBOL programs).
If you need the 32-bit client on your process schedulers and app server, you’ll need to make sure the domains know where to find them. The simplest solution is to add the 32- bit client to the PATH in the
psprcs.cfg files. I added the client path the beginning of the PATH variable. For the
psprcs.cfg files, change this setting to your 32-bit client path:
Add to PATH=e:\oracle\product\12.1.0\client_32;[existing entries]
COBOL PeopleSoft delivers scripts to simplify the compilation process. The scripts know about the decoupled homes and can compile all homes, or just your customizations. Under the
PS_HOME\setup folder you’ll find the main script,
cblbld.bat. Here is the basic usage for
- Set up your environment variables for MicroFocus and homes
- Tell the script where to compile
- Tell the script which homes to compile
The script will handle copying source files, compiling, and deploying to the
CBLBINx folder. For example, let’s compile all the source COBOL in our demo environment:
set PS_HOME=e:\psoft\pt-file-8.5x.xx set PS_APP_HOME=e:\psoft\hr-file-9.2.xxx set PS_CUST_HOME=e:\psoft\HR92DMO set COBROOT="e\:Program Files\MicroFocus\bin" cd %PS_HOME%setup cblbld.bat e: temp\compile
The last command will compile
PS_HOME first and deploy and PeopleTools COBOL programs to
PS_HOME\CBLBINx. Then, it will compile
PS_APP_HOME source files and deploy to
PS_APP_HOME\CBLBINx. Last, it will compile any source files in
PS_CUST_HOME\src\cbl\base and deploy to
PS_CUST_HOME\CBLBINx Let’s dig into this script to understand what is happening behind the scenes. The
CBLBLD.bat script is powerful and can really help out when compiling programs.
CBLBLD.bat script takes four parameters:
- Drive Letter
- Compile Directory
- Encoding (Optional)
- Directories to compile (Optional)
CBLBLD.bat assumes you have set the environment variables mentioned above so it knows where to grab the sources files for compilation. To compile only your custom COBOL source files, pass
CBLBLD.bat. For example:
cblbld.bat e: temp\compile PS_CUST_HOME
You can also pass in
PS_CUST_APP_HOME to compile only those directories. The script uses the directory name to copy the COBOL sources files to the compile directory. Then, the script
CBLBLD_MF.bat is called to start up MicroFocus and compile everything in the compile directory. The
CBLBLD.bat script will call the
CBLBLD_MF.bat script that will set up the directory and flags for the compiler. Then
CBLBLD_MF.bat will call
CBLMAKE.bat to compile everything in the and
CBLBIN.bat to copy the
.exe files to the appropriate
“But what if I modify a copy book that is used in lots of delivered programs? Do they compile if I only pass in
CBLBLD.bat script also calls the Perl script
searchCOBOLPgms.ps. This Perl script will look at the files in your
PS_CUST_HOME and look at
PS_HOME to see if the copy books or programs you have modified to see if they are referenced by any delivered code. So, if you have modified a copy book (e.g, change an array size), this script will copy any program that uses the copy book to the Compile Directory. This makes the copy book change apply to all programs that use the copy book. The source files will still live in
PS_HOME, but the compiled programs will be located in
There is a bug with the searchCOBOLPgms.ps script. If you make a copy book change in a sub program, the searchCOBOLPgms.ps script will only copy the sub program to the Compile Directory; it doesn’t look for the sub programs’ parent program. So, it can miss programs that use a copy book during the compile. Another part of the bug (or design) is that programs that run out of
PS_HOMEdo not use the
CBLBINsearch path in
psprcs.cfgto find .gnt files. This is how we found the bug in
searchCOBOLPgms.ps. We had a program that needed an array increase. We modified a copy book, compiled, and re-ran the program. But, the program would still run in
PS_APP_HOME\CBLBINxand ignore the new copy book in
PS_CUST_HOME\CBLBINx. I filed an SR on that a few weeks ago; I’ll update the post when fix is posted.
UPDATE: December 1, 2015 The Oracle analyst I worked with agrees that the
searchCOBOLPgms.ps script does not account for the subprograms. When a fix is scheduled, I’ll post another update.
UPDATE: April 18, 2016 To address some of the issues with the
searchCOBOLPgms.ps script, but to also make COBOL source programs work better with selective adoption, I am starting to use a
PS_APP_PATCH_HOME in our decoupled-home setup.
When using the command line to rebuild a Tuxedo domain, there is a new flag to keep your settings:
–keepfeaturesswitch in the following command was introduced in PeopleTools 8.54.
psadmin –c import [PS_CFG_HOME] –d [old domain name] –n [new domain name] -keepfeatures
This came from the Best Practices guide for Mid-tier Deployment White Paper. At the end of the document, there is a good overview for the steps needed with a PeopleTools upgrade and the commands to help you script the upgrade.