Managing Application Engine Programs

This chapter discusses how to:

• Run Application Engine programs.

• Debug Application Engine programs.

• Restart Application Engine programs.

• Cache the Application Engine server.

• Free locked temporary tables.

Running Application Engine Programs

This section provides an overview of program run options and discusses how to:

• Create process definitions.

• List process definition parameters.

• Start programs with the Application Engine Process Request page.

• Use PeopleCode to invoke Application Engine programs.

• Use the command line to invoke Application Engine programs.

Understanding Program Run Options

You run Application Engine programs in one of the following modes: batch using PeopleSoft Process Scheduler, online using a PeopleCode function, or manually using the command line. The following table lists some differences between online and batch programs:

Batch Programs Using PeopleSoft Process Scheduler

The most typical run mode is batch. You invoke programs that run in this mode using PeopleSoft Process Scheduler or the Application Engine Process Request page. Batch mode is also referred to as an asynchronous run, meaning that it runs independently in the background. Application Engine runs on any operating system that Oracle supports as an application server. If your site uses an operating system that is not supported for Application Engine, you must run Application Engine programs on the application server. The only exception is OS/390 (z/OS).

To run Application Engine programs on the batch server, you must install BEA Tuxedo. This condition applies to both UNIX and Microsoft Windows NT batch servers. If you run your batch server on the same server machine as your application server, then the application server and the batch server can share one BEA Tuxedo installation. If your batch server is separate from your application server, then you must install BEA Tuxedo on your batch server.

The TOOLBINSRV parameter in the PeopleSoft Process Scheduler configuration file determines where PeopleSoft Process Scheduler invokes an Application Engine program. For high-volume batch environments, specify the PS_HOME\bin\server\winx86 directory that exists on the same machine where the Application Engine program runs.

Online Programs Using PeopleCode

Application Engine programs that run online are typically run from a page with the CallAppEngine PeopleCode function. Such online processes are synchronous, meaning that subsequent processes wait for the results. For instance, a page may be frozen until the online process returns the necessary results. With the CallAppEngine function, no Commit statements are issued. However, if you use the asynchronous online PeopleCode option, ProcessRequest, Commit statements are allowed.

Manual Programs Using the Command Line

Usually, you use this mod only during testing or if you need to restart a program manually.

Creating Process Definitions

Select PeopleTools, Process Scheduler, Processes to access the Processes - Process Definition page.

To use PeopleSoft Process Scheduler for starting Application Engine batch programs, create a process definition for each program. Running Application Engine programs is similar to running any COBOL or Structured Query Report (SQR) program that you typically invoke with PeopleSoft Process Scheduler. Use Application Engine as the generic process type definition. Each Application Engine program that you invoke using PeopleSoft Process Scheduler requires a unique process definition derived from the generic process type definition.

Note. When creating a process definition based on the Application Engine process type definition, the process name you assign must match your Application Engine program name exactly.

Listing Process Definition Parameters

Select PeopleTools, Process Scheduler, Processes, Process Definition Options to access the Processes - Process Definition Options page.

Use this page to list parameters. The complete parameter list is:

• -ct MICROSFT

• -cd %%DBNAME%%

• -co %%OPRID%%

• -cp %%OPRPSWD%%

• -r %%RUNCNTLID%%

• -i %%INSTANCE%%

• -ai %%PRCSNAME%

Starting Programs with the Application Engine Process Request Page

You also can start an Application Engine program by using the Application Engine Process Request page. Using this request page enables you to specify values and parameters in addition to those that appear within PeopleSoft Process Scheduler process definitions.

Most users start Application Engine programs from an application-specific request page using PeopleSoft Process Scheduler. A systems expert or power user may, at times, need to create custom process requests that require multiple programs to perform parallel processing or that need to set specific, initial values in a state record. You might use the Application Engine process request page for one of these cases.

Note. Generally, if seed data or other Application Engine request settings are required for a particular program, the application-specific request page has SQL executables that do the work that is transparent to the user. Typically, no user should invoke programs from the generic process request page. Use this page for internal testing and as a basis for designing program-specific request pages.

Tables Used in the Process Request Page

The Application Engine process request page inserts values into the following tables:

• AEREQUESTTBL

  Contains all of the values that appear on the page except those in the Parameters group box.

• AEREQUESTPARM

  Includes only initial state record values specified in the Parameters group box, if needed.

Note. Inserting a row in either of the Application Engine request tables is not required to run an Application Engine program. This change is a key difference between Application Engine versions prior to PeopleTools 8, where a row in Application Engine request tables is required to start a program, regardless of how it is invoked. The run control ID is available to your program using %RunControl, whether or not a row is inserted into the AEREQUESTTBL table.

You need to use the Application Engine Request page to invoke Application Engine and insert a row into the Application Engine request records only if you need to perform any of the following tasks:

• Insert initial values into the state records associated with a particular program.

• Set an as-of date for the Application Engine program to perform retroactive processing.

• Set a non-default market for the program.

• Set up a temporary table image to use if you are submitting a PeopleSoft EPM process request that performs parallel processing. Refer to PeopleSoft EPM application documentation for details.

Note. Entries in the AEREQUESTTBL table do not have any effect on Application Engine programs called from PeopleCode using the CallAppEngine function.

Application Engine Requests

Select PeopleTools, Application Engine, Request AE to access the Application Engine Request page.

Process Origin	Displays where the program was invoked, from PeopleSoft Process Scheduler, from the command line, and so on.
Process Instance	Displays the process instance assigned to the previous program run.
Status	Displays the status of the last program run, whether it is successful, pending, and so on.
Process Frequency	Specify how long a particular process request will remain active or valid: Always: Select to run the process request as needed. Once: Select if a process request is a one-time-only request. Don’t: Select to disable a process request so that no one invokes it and potentially corrupts data.
As Of Date	If you are requesting retroactive processing, specify the appropriate as of date.
Bind Variable Name	Enter the appropriate field or bind variable for which you are inserting a value.
Value	Enter the initial value that you want to set for the specified field.

Using PeopleCode to Invoke Application Engine Programs

To call a specific Application Engine program from a page using PeopleCode, use the CallAppEngine function in SavePreChange or SavePostChange PeopleCode. The basic syntax for CallAppEngine is:

CallAppEngine(applid [, ​statereclist ]);

Note. The RemoteCall function is no longer valid for invoking Application Engine programs in PeopleCode. However, the RemoteCall function still applies to calling other COBOL functions. If you do not convert the RemoteCall PeopleCode that previously called an Application Engine program to use the new function, an error message appears.

Use CallAppEngine if the program you are invoking is a quick process. Because the process is synchronous, users must wait for any process invoked by CallAppEngine to complete before starting another process. If the called program causes an unreasonable delay, then use another alternative, such as the ScheduleProcess PeopleCode function.

Use CallAppEngine when you have a complex, SQL-intensive business process that must run in batch and online, or the process requires the use of dedicated temporary tables. If this is not the case, you are usually better off writing the entire program in native PeopleCode. If you have written logic in PeopleCode, presumably for online execution, and you want to reuse it in a batch program, you may be forced into row-by-row processing. Design the batch logic first and then decide whether to have a separate online version or reuse the batch code using CallAppEngine. Consider the trade-off between code reuse and performance. It is inherently more difficult, but not impossible, to develop a common solution that performs adequately in both batch and online environments.

Do not use CallAppEngine within an Application Engine PeopleCode step. If you need to call an Application Engine program from another Application Engine program, you must use the Call Section action.

Do not use CallAppEngine to control the commit operation. Programs called with CallAppEngine are embedded within a larger unit of work defined by the page trigger, such as a page save.

Note. Online PeopleCode that calls CallAppEngine should be set to run on the application server. You encounter performance issues if you run PeopleCode on the client in a three-tier configuration because every SQL statement that Application Engine issues must be serialized and then sent to the application server to be run.

Using the Command Line to Invoke Application Engine Programs

You might invoke an Application Engine program through the command line to:

• Restart

  When a program abends, a system administrator might restart the program using the command line. If needed, you can locate all of the specific program and process information from Process Monitor in the Process Request Detail dialog box. Normally, users or system administrators perform a restart from the Process Monitor.

• Develop or test

  Many developers include the command line in a batch file to launch a program they are developing or testing. This way, they can quickly execute the batch file as needed. This method also enables separation of development of the application program from its associated pages.

• Debug

  To debug a program running on the server, you can sign into the server (using telnet, for example) and invoke the program from the command line.

To start an Application Engine program from the command line, you must specify the Application Engine executable (PSAE.EXE) followed by the required parameters, as shown in this example:

psae -CT ​dbtype -CS ​server -CD ​database_name -CO ​oprid -CP ​oprpswd?
 -R ​run_control_id -AI ​program_id -I ​process_instance -DEBUG (Y|N)?
 -DR (Y|N) -TRACE ​tracevalue -DBFLAGS ​flagsvalue -TOOLSTRACESQL ​value?
 -TOOLSTRACEPC ​value -OT ​outtype -OF ​outformat -FP ​filepath

Or, if your command line options are stored in a text file, you can enter:

psae ​optfilename

Note. For Microsoft Windows NT and UNIX servers, you must set the PS_SERVER_CFG environment variable before you invoke an Application Engine program from the command line. PS_SERVER_CFG must contain the fully qualified name of a correctly configured Process Scheduler PSPRCS.CFG file. When Application Engine runs from the command line, it resolves %PS_SERVDIR% to the value of the environment variable PS_SERVDIR instead of the parent directory of a Process Scheduler configuration.

Command Line Options

&ProcessRqst.OutDestType = %OutDestType ;

Query.RunToFile(Record QryPromptRecord, %OutDestFormat);

If All(%FilePath) Then
   &FILENAME = %FilePath | &FILENAME;
&MYFILE = GetFile(&FILENAME, "E", %FilePath_Absolute);
Else
  &MYFILE = GetFile(&FILENAME, "E", %FilePath_Relative);
End-If;

Debugging Application Engine Programs

This section discusses how to:

• Enable the Application Engine debugger.

• Set debugging options.

Enabling the Application Engine Debugger

To run a program in debug mode:

1. Set the debug option.

   You can set the debug option in the following locations:

   • Start PeopleSoft Configuration Manager and select the Process Scheduler tab.

     In the Application Engine group, enable debug by selecting the Debug check box. This method applies to all methods of invocation.

   • If you used the command line option to invoke your Application Engine program, then you can include the −DEBUG Y parameter in the command line you submit to PSAE.EXE.

     If the Debug check box is already selected in PeopleSoft Configuration Manager, then you do not need to include the −DEBUG parameter in your command line.

     Note. Setting debug capabilities in either PeopleSoft Configuration Manager or the command line turns debug mode on. However, if you have debug enabled in Configuration Manager and you submit −DEBUG N on the command line, then the PeopleSoft Configuration Manager setting defines your default command line value and the command line can override the default.

   • If you have PeopleCode in your Application Engine program, enable the PeopleCode debugger.

     When you launch your program and the PeopleCode action runs, enter the PeopleCode debugger.

2. Run the Application Engine program to debug.

3. At the Application Engine Debugger prompt, enter a command to enable a debugging option.

   Each command is represented by a single letter, such as X, L, or M. Enter the letter that corresponds to the option you want to engage. To see a list of the available debugging options, enter ? at the prompt.

To enable the PeopleCode debugger for Application Engine:

1. Sign on to PeopleTools using the same user ID that you will use to invoke the Application Engine program.

2. Open Application Designer.

3. Select Debug, PeopleCode Debugger Mode.

   Your Application Engine program can be open on the desktop, but you do not need to open the Application Engine program or the PeopleCode action that you want to debug.

4. Select Debug, Break at Start.

   This command will cause the Application Engine program to break before executing any PeopleCode programs within it.

Setting Debugging Options

Each debugger option is represented by a single letter that you specify at the prompt. To engage the option you select, press Enter.

Debugging Tips

Become familiar with these tips about debugging programs:

• In some cases, such as when setting breakpoints or watch fields, submenus offer additional options.

  After you are familiar with the commands, you can enter multiple items on the command line to combine commands and bypass the submenus. For example, to see a list of the breakpoints, you could enter B L.

  To set a field as a watch field, you could enter W S MY_FIELD.

  To set a field as a watch field on a different state record, enter W S MY_AET.MY_FIELD.

  Note. The exception to this option is Modify, which always displays the current value and then prompts you to enter a new value. You can, however, enter M MY_AET.MY_FIELD to go directly to the new value prompt.

• Letter commands are not case-sensitive.

  For example, Q and q are valid commands.

Debugging Options

Example of the Look Option

To view the value stored in a specific field of the state record after a step or action, enter the appropriate field name at the Field Name prompt. For example, if you entered AE_TESTAPPL_AET at the Record Name prompt and AE_INT_6 at the Field Name prompt, you would see the value of the AE_INT_6 field in the AE_TESTAPPL_AET record.

You can also use an asterisk (*) as a wildcard to get a partial list. For example, if you enter AE_INT* at the Field Name prompt, you see only the fields that start with AE_INT; this is also true for the Record Name prompt. This feature is useful for both listing multiple fields across multiple records and as a shortcut. If you know that only one state record starts with XXX, you do not have to type the full name, just type XXX.

Example of the Modify Option

If you wanted to set the AE_INT_15 field in the AETESTPROG to 10, you would enter the record (AE_TESTAPPL_AET) at the Record Name prompt and the field (AE_INT_15) at the Field Name prompt.

Then you would see the current value of the field. At the prompt, you could enter a new value.

Using the Look command, you can check to see that the value you specified now exists in the state record.

Example of the Watch Option

Enter S to set a watch field. After you enter S, you enter the record name (such as AE_TESTAPPL_AET) and field name (such as AE_INT_7) at the appropriate prompts.

Enter U to unset, or remove, a watch field from the list. After you enter U, you see a list of active watch fields. Enter the watch field ID number to remove a field. For example, if the field AE_INT_7 were second in the watch field list, you would enter 2 to remove it.

After a step or action completes, enter L to list, or view, the values of all the fields that you included in the watch list.

Note. You cannot set a watch on a long text field.

Restarting Application Engine Programs

A key feature of Application Engine is its built-in checkpoint and restart capabilities. If a program step terminates abnormally or fails, you can restart the request from the last successful checkpoint or from the step immediately preceding the step that failed. You restart the program from the process request page.

This section provides an overview of restart and discusses how to:

• Determine when to use restart.

• Control abnormal terminations.

• Restart Application Engine programs.

• Start Application Engine programs from the beginning.

• Enable and disable restart.

Understanding Restart

Application Engine programs save to the database (perform a commit) only when an entire program successfully completes. You must set individual commits where appropriate.

At the section level, you can set a commit after each step in a section. At the step level, you can require or defer commits for individual steps, or you can increase the commit frequency within a step to N iterations of a looping action, such as a Do Select of Do While, within a step.

The commit level that you select affects how restart works in a program. Each time Application Engine issues a commit with restart enabled, it records the current state of the program. The recording of the current state that Application Engine performs is referred to as a checkpoint.

Using the restart feature enables you to perform commits more often in a program. Restart reduces the overall effect on other users and processes while the background program is running because it reduces the number of rows that are locked by the program. Fewer rows allows multiple instances of the program to run concurrently (parallel processing), which may be useful for high-volume solutions.

With restart, if a failure occurs at any point in the process, the user can restart the program and expect the program to behave as follows:

• Ignore the steps that have already completed up to the last successful commit.

• Begin processing at the next step after the last successful commit.

The ability for Application Engine to remember completed steps depends on a record called AERUNCONTROL, which is keyed by process instance.

When a program runs, each time Application Engine issues a commit it also saves all of the information required for a program restart in the AERUNCONTROL record.

Determining When to Use Restart

Usually, you want to develop programs to take advantage of Application Engine restart capabilities. Programs that are good candidates for restart do a lot of preparation work initially, such as joining tables and loading data into temporary work tables. Also, you should consider restart capabilities for programs that might put data in an unstable state if they terminate abnormally during a run. As a general rule, restart is essential for programs that primarily do set-based processing.

However, you may want to disable restart if your program has one the following characteristics:

• It is mainly row-by-row processing.

• The overhead involved with Application Engine performing a checkpoint during the program run is not desirable.

• The program commits after N iterations of a looping construct within a step, and the Select statement driving the loop is composed in such a way that if the program terminated and then started again it would ignore transactions that were already processed in the previous program run. In a sense, the program processes the restart internally: Application Engine treats each start of a program as a fresh start, instead of restarting a previous instance.

When developing for restart, consider the consequences if a program fails and you cannot restart the program. Given the commit structure that you defined for your Application Engine program, would your data remain in an usual state if a failure were to occur after any of the commits? Would it be easy to recover from such a case?

Using Restart at the Program Level

Application Engine automatically updates all state records. When an Application Engine program starts, it inserts a row in the state record for the assigned process instance. Then the system updates the state record whenever the program performs a commit to store changed values into the database. Finally, the system deletes the state record row upon successful completion of the application.

However, if the state record the program uses is a work record, you cannot make any database updates to the record. Consequently, if you restart the program, you might get unexpected results because the memory was lost when the program terminated. In fact, the system re-initializes any state records that are work records at each commit in order to ensure consistent behavior during a normal run and a restarted run. Therefore, you may need to make at least one of your state records a SQL table to contain values that must be retained across commits or in case of termination.

Finally, the other consideration for programming for restart at the program level is to check both the Application Engine Program Properties dialog box and PeopleSoft Configuration Manager to make sure the Disable Restart check box is not selected.

Using Restart at the Section Level

The section level property associated with restart is section type, which has the options Prepare Only and Critical Updates.

If a section only prepares data, as in selecting it, populating temporary tables, or updating temporary tables, then set the section type to Prepare Only. However, if the section updates permanent application tables in the database, then set the option to Critical Updates.

During runtime, when the system arrives at the first section set to Critical Updates, it sets the AE_CRITICAL_PHASE value in the AERUNCONTROL record to Y. Once set, the value of AE_CRITICAL_PHASE remains Y until the program completes successfully. When the program completes, the corresponding row in AERUNCONTROL is deleted. Therefore, a Prepare Only section following the Critical Updates section will not reset the AE_CRITICAL_PHASE value to N.

If your program terminates, the user can check the AE_CRITICAL_PHASE value. If it is Y,then the user knows that the section that failed is critical and that the program should be restarted to ensure data integrity. If AE_CRITICAL_PHASE is N, restarting may not be necessary; however, as a general rule you should restart even if AE_CRITICAL_PHASE is set to N.

Using Restart at the Step Level

In the Where clause of a Do Select action in your program, you should include conditions that reduce the answer set returned from the Select statement.

For example:

SELECT RECNAME, FIELDNAME
   FROM PS_AE_RECFIELD
   ORDER BY RECNAME, FIELDNAME

If you ran this Select statement as part of a Do Select action with Restartable selected as the Do Select type, the system might process some of the rows twice after a restart. Also, if you specified Reselect, the program could execute in an infinite loop because no code exists to reduce the answer set. However, if you modified the Select statement as follows, you could make it Restartable:

SELECT RECNAME, FIELDNAME
FROM PS_AE_RECFIELD
WHERE RECNAME > %Bind(RECNAME)
OR (RECNAME = %Bind(RECNAME) AND FIELDNAME > %Bind(FIELDNAME))
ORDER BY RECNAME, FIELDNAME

You can convert a Do Select action that was coded for Restartable to Select/Fetch, but the opposite is not true.

The previous example shows the use of a key column to reduce the answer set. A key column can be convenient if your record has only one or two key fields; however, if your record has three or four keys, your SQL would become overly complex.

Instead of matching key fields, you could add a switch to the selected table and then have the processing of the called section modify the switch as it processes the row. In this example, your Select statement might look like this:

SELECT COLUMN1, COLUMN2, . . .
   FROM PS_TABLE1
   WHERE PROCESSING_SWITCH=’N’. . .

Controlling Abnormal Terminations

A controlled abnormal termination (sometimes called an abend) means that Application Engine exits gracefully because of a calculated error condition. Examples of controlled abends are:

• SQL errors while On Error is set toAbort.

• A PeopleCode return value when On Return is set to Abort.

• A SQL statement that affects no rows when On No Rows is set to Abort.

In these situations (when Application Engine is in control), the Run Status field in Process Monitor reads Error.

An uncontrolled termination occurs when a memory violation occurs or a user terminates a process. In these cases, the Run Status field in Process Monitor reads Processing.

Restarting Application Engine Programs

You can restart an Application Engine program in one of these ways:

• From the command line.

• From a process request page.

Note. The following procedures for restarting a failed Application Engine program assume that you have rectified the error that caused the program to fail in the first place. For instance, suppose the name of a referenced table has changed. Regardless of how many times you restart the program, it will continue to fail until you modify all references to the old table name.

Restarting from the Command Line

Normally, only developers and system administrators use the command line for restarting Application Engine programs. Users, in most cases, should not be expected to use this method.

You can use the command line option to restart programs that run on the client or the server. Application Engine references only the process instance of the failed process. Therefore, if you run a process on the client and it fails, you can restart it from the server using the server command line. Likewise, if you run a process from the server and it fails, you can restart it from the client using the command line.

To restart an Application Engine program from the command line:

1. Collect the command line values associated with the failed program.

   These values include database type, database name, user ID and password, run control ID, program name, and process instance. You can find these variables in the Process Details dialog box, the corresponding state record, or the Application Engine Run Control table. Where the values reside depends on how you invoked the program. For instance, if you invoked the program using the command line or from outside of PeopleSoft Process Scheduler, then you cannot view details associated with the program run in the Process Details dialog box.

2. Enter the following command line syntax at the command prompt, substituting the values from the previous step:

   PSAE.EXE −CT ​DB_TYPE -CD ​DB_NAME -CO ​OPRID -CP ​PASSWORD -R 
   ​RUN_CONTROL -AI ​PROGRAM_NAME -I ​PROCESS_INSTANCE

   Note. Some database platforms, such as Sybase, also require that you include a server name in the argument list.

Restarting from a Process Request Page

The only programs you can restart from a process request page are those that run on the server.

To restart an Application Engine program from a process request page:

1. Open PeopleSoft Process Scheduler by selecting PeopleTools, Process Scheduler, System Process Requests.

2. Locate the run control ID number of the program to restart.

3. To display the details of the failed process, click the Process Detail link.

4. On the Process Request Details page, select Restart Request and click OK.

Bad Restart Errors

If you attempt to restart a process that completed successfully according to Application Engine, you will receive a bad restart message. You will also get this message if your Application Engine application is defined with restart disabled.

Starting Application Engine Programs from the Beginning

When an Application Engine program ends abnormally, you may have to decide whether you should restart the process or start it from the beginning. As your Application Engine program ran at least part way through, starting over may leave your data in an unknown state. Also, application logic might need to be undone, depending on the stage of the program when it failed, what data the program had committed, and so on.

However, if restart is enabled and you attempt to start a new process that matches the run control ID and user ID for another process, then you receive a suspend error. Because the process instance for these two processes is different, the new request fails. This event usually occurs when a user tries to run the program again after receiving an error on the previous attempt.

To start the program over from the beginning, you can use SQL to delete the row that corresponds to the failed program from the Application Engine run control table and your state record.

To restart an Application Engine program from the beginning:

1. Open your native SQL editor and manually delete the row in PS_AERUNCONTROL that corresponds to the program you want to start from the beginning.

   Use the following SQL to accomplish this step:

   DELETE FROM PS_AERUNCONTROL
   WHERE OPRID=OPRID
   AND RUN_CNTL_ID=Run_Control_ID

2. Delete from your state record the row that corresponds to the failed program run.

   Use the following SQL to accomplish this step:

   DELETE FROM PS_MY_AET
   WHERE PROCESS_INSTANCE=Process_Instance

Note. To restart the program, you can also select Restart Request from the Process Request Details dialog box.

Enabling and Disabling Restart

To disable restart, use any of these methods:

• Select the Disable Restart check box in the Application Engine Program Properties dialog box.

  To access program properties, select File, Definition properties and select the Advanced tab.

• Select the Disable Restart check box in the Configuration Manager profile.

  To access the profile, start Configuration Manager, select the Profile tab, and click Edit. Then select the Process Scheduler tab.

• Include the -DR Y option in the command line of PSAE.EXE.

If you disabled restart in any of these three places, restart is disabled.

If you want the program to restart in a production environment while still keeping a restart condition from getting in the way during development and testing, you can deselect the Disable Restart check box in the Application Engine program properties. Then, during development, you can select the Disable Restart check box in Configuration Manager or invoke your program from the command line with the -DR Y option without having to reconfigure the program for testing.

Caching the Application Engine Server

Application Engine caches metadata just like the application server. This caching enhances performance because a program can refer to the local cache for any objects that it uses.

Cache Directory Location

Application Engine programs that run on a Microsoft Windows NT or UNIX server lock their own cache directory for the duration of a run. You find these directories under the master cache directory. The master directory is created under the directory specified by the CacheBaseDir variable in the PeopleSoft Process Scheduler configuration file. If all existing cache directories are locked, a new one is created. Cache subdirectories are named sequentially, starting at 1.

If you do not enter a fully qualified path for the CacheBaseDir variable, then Application Engine creates a cache directory within the directory in which the program is set to run.

Note. Do not share the CacheBaseDir variable with application servers and do not use environment variables when specifying CacheBaseDir because the system does not resolve them. For example, do not set CacheBaseDir to $PS_CFG_HOME.

Cache Parameters

The PSPRCS.CFG (PS_SERVER_CFG) file has two additional cache parameters. They are:

• Enable Server Caching

• Server Cache Mode

Do not alter these settings from the delivered defaults. These settings are reserved for future use.

Freeing Locked Temporary Tables

If you use dedicated temporary tables for Application Engine programs, then you might need to free, or unlock, a temporary table if the program running against it terminates abnormally. Because most Application Engine programs run through PeopleSoft Process Scheduler, typically you use Process Monitor to unlock the temporary tables. Deleting or restarting a process using Process Monitor automatically frees the locked temporary tables.

For the programs that you invoke outside of PeopleSoft Process Scheduler, use the Manage Abends page. Programs running outside of Process Scheduler include those invoked from CallAppEngine PeopleCode and the command line.

To free locked temporary tables using the Manage Abends page:

1. Select PeopleTools, Application Engine, Manage Abends.

2. Identify the program that has locked the temporary tables you want.

   Use the process instance, run control ID, program name, user ID, and run date and time columns to uniquely identify programs.

3. Click the Temp Tables link.

4. On the Temporary Tables page, click the Release button to unlock the temporary tables associated with the program.