R98CRTGL:
All R98CRTGL does is loop through F9860 and find all tables that are not bootstrap (F98611, F986101 etc) and central objects tables (F987*). It then calls the JDB API JDB_OpenTable for that table. At this point JDB is responsible for finding the table specs. JDB looks for specs in one of two places. First it will look in gbltbl.xdb and .ddb. Obviously, since the tables are being built by running R98CRTGL, it will not find them there. It then looks in local TAM (ddtabl, ddclmn, ddpkeyh and ddpkeyd) if it does not find table specs in local TAM it will give an error. JDB does not look at the central objects tables for table specs. Once JDB has located the table specs in TAM it will add them to gbltbl.xdb and .ddb. If the call to JDB_OpenTable is successful, R98CRTGL then calls JDB_CloseTable and proceeds to process the next table it finds in F9860.
Run R98CRTGL locally (not on the server) from a FAT client. This will build a full set of glbltbl.xdb and glbltbl.ddb files and place these new files in the B7/"pathcode"/Spec directory. (these files will not need to be moved)
R92TAM:
In order to build the table spec JDB needs to find the data dictionary specs for all the data items in the table. First it will look in local TAM (dddict). If it does not find the data item in dddict it will then go to look in the data dictionary tables in RDB and JITI the specs down to local TAM. The reason customers will run R92TAM before R98CRTGL is to save time on having to JITI data dictionary specs down. The TAM files created by R92TAM are put in the root of the client workstation. DDCLMN specs will come from local TAM on the workstation where R98CRTGL is being run. Local Tam is the workstation specs or if you are on the deployment server then local Tam would be the path code specs.
Run R92TAM locally (not on the server) from a FAT client. This will create the dddict.xdb, dddict.ddb, ddtext.xdb, and ddtext.ddb in the B7 directory on that workstation.
R01131P:
Purges Work Center Messages
R9698711:
The R9698711 report was designed as a verification tool after performing an install or upgrade to verify table information compared to spec information. This report is based off the F9860 Object Librarian Header table. This table contains a record for every table in the system, but does not contain information regarding the path codes where this table has been promoted. The Object Librarian tables are shared for all environments, therefore, even when logged into and running a report on the production environment the report will still display tables that have not been promoted into production as these records exist in the Object Librarian table.
This reports functions as designed especially due to the fact that it is intended to be a verification after an install / upgrade. Therefore, you will need to be aware of any tables that exist within your environment that have not been promoted into production and treat the error message as informational only for these tables.
R98860P:
Purges Workflow messages.
In order for Workflow to run it creates F98860 (Process Instance) and F98865 (Activity Instance) records. If you choose to have your Workflow process keep these records for history purposes the files can grow very large. Maintaining large files may take up needed storage resources and hinder performance. To free up storage resources and increase performance, the F98860 and F98865 messages can be periodically purged using R98860P-Purge Completed Processes.
The UBE does not have processing options.
The UBE is shipped to purge records when the Workflow Instance is Complete, Terminated or at an Error Status. This is based on the data selection set with BC Process Status (F98860) equal to 03-Complete, 05-Terminated or 06-Error.
Additional data selection can be used with the R98860P to further restrict the records being deleted.
For a more specific set of data you can filter on Process End Dates so that you may keep recently completed Workflow Process history readily available.
