Sunteți pe pagina 1din 29

COBOL ANSWER BOOK

For PeopleTools 6, 7, 7.5

By : Federico Ibarra, Richard Bolella, Chris Chapman Revised On : December 14th 1998 Thanks to the Global Support Center - Pleasanton.

TABLE OF CONTENTS FAQ FOR COBOL........................................................................................................................................4 WHAT IS THE DIFFERENCE BETWEEN THE FILES SUPPLIED IN THE CBLBIN AND CBL\BASE DIRECTORY?.................4 WHEN DO YOU NEED A COMPILER ON NT?.....................................................................................................4 WHAT VERSION OF THE COMPILER SHOULD I BE USING?.....................................................................................5 HOW DO I CREATE AN .INT?......................................................................................................................5 HOW DO I KNOW WHICH FILE SHOULD BE COMPILED AS .GNTS OR .INT?................................................................5 WHAT IS THE DIFFERENCE BETWEEN STATIC AND DYNAMIC SQL?......................................................................6 HOW DO I TURN ON COBOL TRACING AND LOGGING?.....................................................................................6 COBOL SQL Trace on the Client ..........................................................................................................6 COBOL SQL Trace on the Unix Server ................................................................................................7
Enabling COBOL SQL trace on the client: ........................................................................................................6 Location of COBOL SQL trace file on the client: ..............................................................................................7 Enabling COBOL SQL trace on the Unix server: ..............................................................................................7 Location of COBOL SQL trace file on the Unix server: ....................................................................................7

TRACING ON AS/400................................................................................................................................8 COMPILE AND RUN COBOL NT/WINDOWS 95 PEOPLETOOLS 6 AND 7.0X..............................9 I. ISSUES BEFORE USING COBOL .BAT FILES................................................................................................9 II. COMPILE AND EXECUTE ALL THE COBOL SOURCE FILES WITH THE EXPECTED DIRECTORY................................10 III. COMPILE AND EXECUTE COBOL SOURCE FILE ON THE CURRENT COMPILE DIRECTORY......................................10 IV. THE EXISTING .BAT FILES OWNED BY COBOL........................................................................................10 IV. WINDOWS 95 LIMITATION....................................................................................................................12 V. WINDOWS 95 CAPABILITY....................................................................................................................12 COMPILE AND RUN COBOL NT/WINDOWS 95 PEOPLETOOLS 7.5...........................................12 ISSUES BEFORE STARTING USING COBOL .BAT FILES ......................................................................................12 COMPILING PEOPLESOFT ON UNIX..................................................................................................13 INSTALLING A COMPILER FOR UNIX ENVIRONMENTS.........................................................................................13 THE BATCH TRANSFER (BRIEF DESCRIPTION) ................................................................................................15 COMPILING ON UNIX ENVIRONMENTS:........................................................................................................16 TO COMPILE A MODULE:......................................................................................................................18 COMPILING PEOPLESOFT ON OS/390. ..............................................................................................20 DEBUGGING COBOL ON MVS :..............................................................................................................21 RUNNING COBOL ON MVS OUTSIDE OF THE PROCESS SCHEDULER :...............................................................22 COMMON COMPILE ERRORS ON MVS INCLUDE:............................................................................................22 COBOL COMMON ERRORS AND GENERAL INFO.........................................................................22 INSTALLING THE CORRECT COBOL COMPILER:........................................................................22 REQUIRED OPERATING SYSTEM, DATABASE OR COMPILER PATCHES APPLIED:.........23 PLATFORM ENVIRONMENT VARIABLES:.......................................................................................23 COBOL SOURCE CODE PROBLEMS...................................................................................................24 OTHER MISCELLANEOUS ERRORS/QUESTIONS...........................................................................24 ld: 0706-014 the -b rtl option is not recognized. ................................................................................24 Client COBOL fails with Load error file PTPSQLRT error code 189, PC=0, call=1,seg=1.............24 Receive the error Load error file"inoc" error code 198,pc=0,call=3,seg=0. 198 load failure while compiling on any Unix O/S....................................................................................................................25

Is Microfocus COBOL required for any NT workstation? ..................................................................25 Explain HP COBOL Versioning............................................................................................................25 Which should be installed, Procedural or Object Oriented (OO) COBOL compiler?........................25 Error loading /opt/COBOL/cobdir/coblib/libhpCOBOL.1, errno = 12...............................................26 cob:library not found: -lCsup................................................................................................................26 LD.SO.1:PS: PSRUN: Fatal: relocation error File oracle/lib/libclntsh.so.1.0:symbol slpmpordstab: references symbol not found..................................................................................................................27 error loading /opt/COBOL/cobdir/coblib/libhpCOBOL.1,errno=215.................................................27 Error 173: Called program not in drive or directory...........................................................................27 LD: Can't open/ opt/oracle/product/7.3.4/lib/libocic.a........................................................................28 Are Pro*C and Pro*COBOL compilers needed to compile PeopleSoft programs?............................28 Remote Call errors in two and three tier troubleshooting tips.............................................................29

FAQ for COBOL What is the difference between the files supplied in the CBLBIN and CBL\BASE directory? There are several different extensions supplied in those directories: In the CBLBIN, there are: .idy = these do not concern PeopleSoft. These are files created by the compiler to be used by Microfocus Animator, which is not supplied nor supported by PeopleSoft. .obj =You will never physically see these files in the directory. When the compiler is launched, it creates these temporary object files to create the executable files. They are typically more commonly found in error messages while trying to compile in NT. The following is an example: Error compiling GLPDNEXT.OBJ This basically means that a generic error has occurred during compilation. Usually this is a result of a missing or invalid copybook. Be sure to check the corresponding .lis file for the actual error message. .gnt = PeopleSoft creates a .gnt module to be executed by the COBOL runtime system. .gnt modules are preferred because they are binary code and execute very quickly since they have already been translated into binary code during the "generate" phase of the compilation; thus, they take longer to compile than a .int, because of the additional steps involved, but you only compile once. Generally, we are more concerned with modules executing quickly rather than compiling quickly, because we compile once, but we "run many". .int =a .int module is very quick to compile, but slow to run. .int modules are "interpretive. " As each instruction is executed, it must be translated, on the fly, into binary code. Then, that line of binary code is executed and thrown away. Next, COBOL goes on to the next line of code in the program and does the same thing. You can easily see how things run slower as an .int. If we have twenty instructions inside a loop which iterates 100 times, then each of the twenty instructions needs to be "interpreted" 100 times! The performance impact of running .int code is significant. .exe =this is the actual COBOL runtime system for NT. This is the file that is called by the Process Scheduler to launch the COBOL program. Not all COBOL programs require a corresponding .exe file. Other .gnt files are called upon when the executable is launched. The compiler knows to create this file by default according to the .cfg file. In the CBL\BASE directory, there are: .lis =This file will be found in whichever directory you are doing your compilation. This is created by the compiler when an error has occurred while trying to compile a COBOL program. This file will contain the actual error message. .cfg =This file tells the compiler to link and create an .exe for the corresponding executable. .cbl =These are the COBOL source programs. It contains any of the static or dynamic SQL that will be passed to the database by the .gnt file. These are the files you run the compiler against. .dms =The .dms scripts in the src\cbl\base directory are used to populate the stored statements in the PS_SQLSTMT_TBL for the static SQL passed to the database. When do you need a compiler on NT?

If you plan to run COBOL and apply patches on a Windows environment, whether it be NT client, NT server, or Win95, you will need a compiler. PeopleSoft provides the executables needed to run COBOL programs for the initial install only. Since PeopleSoft only provides the source code, a compiler will be needed to re-create the binary files to run against the database. The same applies for the application server. If you plan on running a remote call in 3-tier and the application server resides on an NT box, than you will need to maintain the COBOL executables on the NT server as well. What version of the compiler should I be using? This depends on the platform you are using, such as operating system, PeopleTools version, and RDBMS version. This information can be accessed by the customer through customer connection. Regardless of whether you are compiling on the client or server, you will find what you need in the PeopleSoft Platforms online database. To find this information, go to the following: PeopleSoft Homepage | Customer Connection | Enter | Product Support | PeopleSoft Platforms How do I create an .INT? Get rid of the failing .gnt module. To get rid of the .gnt module, go into the $PS_HOME/bin or $PS_HOME/cblbin (for PeopleTools 7.x and 7.5x) directory where the module resides and rename it. Rename it to anything which does not end in .gnt or .int. For example, if the filename is PAPCSRVC.gnt, do the following: ts-sun01:/-> cd $PS_HOME/bin ts-sun01:/data9/ora/h600o732/bin-> mv PAPCSRVC.gnt PAPCSRVC.gnt.old allow more than one period in a filename) Put the module name in a cblint* file. then go to the directory which has the cblint* files and make your own! ts-sun01:/data9/ora/h600o732/bin-> cd ../src/cbl ts-sun01:/data9/ora/h600o732/src/cbl-> echo PAPCSRVC >> cblint.custom (this way we avoid the "vi" editor) ts-sun01:/data9/ora/h600o732/src/cbl-> cat cblint.custom (just to be sure!) PAPCSRVC (yep, it's there) Recompile. ts-sun01:/data9/ora/h600o732/src/cbl-> cd $PS_HOME/install ts-sun01:/data9/ora/h600o732/install-> pscbl.mak PAPCSRVC Once the compile has completed, the new .int module is in place and the customer may execute the program as it normally would be executed. The same general instructions apply for NT. Make sure that the cblint.* you created is in same directory where you are launching the CBLMAKE.BAT. How do I know which file should be compiled as .gnts or .int? After testing several of the files, our development has determined that some of the files either run better, or can only be run as .int. Sometimes, the I/Os inserted into the .gnt by the Microfocus compiler is not compatible with PeopleSoft. For a list of the files that development has recommended (yes, UNIX will

be compiled as .int, look at the cblint.* files already created. In UNIX, they should be located in the $PS_HOME/src/cbl directory. In NT, they should be located in the PSVER/src/cbl/win32 directory. What is the difference between Static and Dynamic SQL? In a nutshell, dynamic SQL is SQL that is created and executed by a program on-the-fly -- without the benefit of pre-compilation or binding into the programs plan. We use dynamic SQL for several reasons, but mainly to handle changes customers make to their system definitions. For instance, in GL, customers usually change their chartfield setup. Dynamic SQL in our COBOL programs enables us to handle these changes without changes to the COBOL source code. Static SQL are predefined SQL statements that are stored external from the COBOL program and identified by name. We use Static SQL for statements that are constant and access tables that are not commonly customized. The Static SQL statements are loaded into a Tools table called PS_SQLSTMT_TBL using the Data Mover. How do I turn on COBOL tracing and logging? COBOL SQL Trace on the Client You are able to trace all SQL activity generated by COBOL programs run on the client. This includes dynamic as well as static SQL. NOTE: This trace replaces the dynamic SQL (dysql) trace of tools version 5.1 and prior. The COBOL SQL trace on the client is your best tool to figure out why a program failed if: - you are running a COBOL program on the client - you know the COBOL program has started - the COBOL program fails for some reason Enabling COBOL SQL trace on the client: You can trigger a COBOL trace when logged on to the database in either 2-tier or 3-tier mode. Just like the on-line SQL trace, you can enable COBOL tracing on Win95, NT3.51, & NT4.0 workstations using the Configuration Manager. If you turn on any of the SQL Trace options in the configuration manager under the Trace tab, the execution of any COBOL program will generate a trace file. (You DONT have to log off and back on for this to take effect.) This file will have a varying degree of detail, depending on which SQL Trace options are turned on. In addition to the creation of a trace file, there is a log file created on the NT client. The log file contains the text which is normally spit out by the program, even when tracing is not turned on. Typically this log is very useful to find the real error message when a batch job is run through the Process Scheduler. For PeopleTools 7.0X and below, make sure the COBSW=-L1,+S5 in the environment variables. This will set the log files to the same directory as the COBOL SQL trace. For PeopleTools 7.5 and above, check off the Redirect Output checkbox in the Configuration Manager:

Location of COBOL SQL trace file on the client: On Win95, NT3.51, & NT4.0 workstations, the trace files are written to the %TEMP% folder, in the subfolder PS\<database name>\. (ex: c:\temp\ps\hrdmo\) A workstations %TEMP% folder is usually c:\temp or c:\windows\temp. If you cant find the file in one, check the other. The trace file will start with cobsql_ and will have an extension of .trc. After cobsql_, the file name may have the programs name and/or the process instance. Here is a sample file name with the process instance: c:\temp\ps\HRDMO\cobsql_1914.trc (If no process instance is supplied, a timestamp value [MMDDHHMMSS] is used instead to formulate the file name. We have seen this happen when the program is kicked off through an icon rather than a run control panel. Ex: cobsql_0724143454.trc --the date was 07/24 and the time 2:34p) For more information on the COBOL SQL trace on the client, see the following section in the PeopleTools 7.0 PeopleBook: Administrative Tools | Performance Tuning | Batch Program Monitoring and Tuning Utilities | SQL Trace COBOL SQL Trace on the Unix Server You are able to trace all SQL activity generated by COBOL programs run on a Unix server. The COBOL SQL trace on the server is your best tool to figure out why a program failed if: - you are running a COBOL program on a Unix server - you know the COBOL program has started - the COBOL program fails for some reason Enabling COBOL SQL trace on the Unix server: You can enable COBOL tracing on Unix servers by setting a variable in the pstools.ini file on the server. On the Unix server, open the file $PS_HOME/bin/pstools.ini in an editor. Under the section [PSTOOLS], you will find a line saying: TraceSql=0. Comments above this line explain how you can set TraceSql to a value other than zero in order to generate SQL tracing information. Location of COBOL SQL trace file on the Unix server: On Unix machines, the trace files are written to the $PS_HOME directory in the subdirectory log/<database name>. The trace file will start with COBSQL_ and have an extension of .trc. After

COBSQL_, the file name may have the programs name and/or the process instance. Here is a sample file name with the process instance: $PS_HOME/log/FSDMO/COBSQL_1914.trc This will also create a log file. You should find the log file in the following directory: $PS_HOME/log/<database name>. The log file will have the following naming convention: <program name>_<process instance>.log Here is a sample file name for the AP posting program: /apps/psoft/log/FSDMO/APPPVCHR_12638.log For more information on the COBOL SQL trace on the server, see the following section in the PeopleTools 7.0 PeopleBook: Administrative Tools | Performance Tuning | Batch Program Monitoring and Tuning Utilities | SQL Trace. Tracing on AS/400 database monitor (DBMON) can be run against batch, interactive, and active pre-started jobs in an AS/400 Environment. Batch jobs 1- Identify the job queue --> DSPJOBD 2- Hold the job queue --> HLDJOBQ 3- Submit the job 4- Identify and record the job name, userid, and job number --> WRKACTJOB, WRKSBSJOB, WRKUSRJOB 5- Hold the job --> WRKJOBQ opt3 6- Release the job queue --> RLSJOBQ 7- Change the job's message logging level --> CHGJOB JOB(?) LOG(4 00 *SECLVL) LOGCLPGM(*YES) 8- Start a service job (STRSRVJOB JOB(?)) - Invoked from an interactive session 9- Start the debug utility (STRDBG UPDPROD(*YES)) - Invoked from the same interactive session 10- Release the job --> WRKJOBQ opt6 11- Function 10 (F10) at the debug break screen --> access to command line 12- Start the database monitor --> STRDBMON with applicable parameters using *DETAIL 13- Function 3 (F3) at the command line 14- Start job execution <ENTER> 15- Wait for end of job message 16- End the debug utility --> ENDDBG 17- End the service job --> ENDSRVJOB JOB(?) 18- Examine the result file created by the database monitor Interactive jobs 1- Identify and record the job name, userid, and job number --> WRKACTJOB, WRKUSRJOB, WRKJOB 2- Change the job's message logging level --> CHGJOB JOB(*) LOG(4 00 *SECLVL) LOGCLPGM(*YES) 3- Start the database monitor --> STRDBMON with applicable parameters using *DETAIL 4- Start query execution 5- Wait for query to complete 6- End the database monitor --> ENDDBMON 7- Examine the result file created by the database monitor Pre-started jobs (QZDASOINIT in QSERVER subsystem) 1- End the application on the client

2- Identify the prestart job that will be used by the application when restarted. WRKACTJOB SBS(QSERVER) JOB(QZDASOINIT) followed by function 14 (shift+F2). The job with a status of 'PSRW' is the next prestart job to become active. This will occur when the application is started. This job will be used by the application then ended. The job that will be doing the application work you are interested in will be an active job with a higher job number. You will have to research by refreshing the WRKACTJOB screen and looking for this job. 3- Identify and record the job name, userid, and job number. 4- Change the job's message logging level --> CHGJOB JOB(?) LOG(4 00 *SECLVL) LOGCLPGM(*YES) 5- Start the database monitor --> STRDBMON with applicable parameters using *DETAIL 6- Start job execution 7- Wait for query to complete 8- End the database monitor --> ENDDBMON 9- Examine the result file created by the database monitor Compile and Run COBOL NT/WINDOWS 95 PeopleTools 6 and 7.0x I. Issues before using COBOL .bat files. You need to setup 4 environment variables: basedrive, temp, psver, COBOLroot For example: set basedrive=c: set netdrive=q: set temp=%basedrive%\temp set psver=\pt6 set cobroot=%basedrive%\apps\dvlp\COBOL40 Note: %basedrive% %netdrive% %temp% %cobroot% %psver% points to the drive where the compile takes place; usually it is your local or c: drive points to the drive where the COBOL source resides if the COBOL source resides locally, %netdrive%=%basedrive% points to the compile directory points to the base COBOL compiler; it should contain the path right before \exedll directory points to the base directory for the source; it should contain the path right before \src directory if the tree has this structure %netdrive%\%psver%\src\cbl or to your local directory

The PeopleTool directory has this structure: %netdrive%\%psver%\src\cbl The main .bat file (CBLBLD) makes assumption: .All the source codes resides under the directory structure as: %netdrive%\ %psver%\src\cbl The compile is done under the %basedrive% \%temp%\compile The executable files after the compile is copied to %netdrive%\%psver%\cblbin If all the source codes reside under this structure: %netdrive%\%psver%\src\cbl Proceed to II. Else

End IMPORTANT:

Copy all the COBOL sources to your local directory manually, that includes: Tool COBOL sources from Tool directory: copy %netdrive%\%psver%\src\cbl\base\* copy %netdrive%\%psver%\src\cbl\win32\* Application COBOL sources including *.cbl, *.cfg, cblint.* if they exist Note that *.cfg is needed to generate *.exe and cblint.* to generate *.int For more info, please read section IVd. Proceed to III. set COBDIR environment variable to point to where ALL .GNTs reside. For example, you need to run Process Scheduler where PSTOOLS is activated from \bin directory while all GNTs are under \cblbin directory. COBDIR needs to be set to: COBDIR=<path>\cblbin

II. Compile and execute ALL the COBOL source files with the expected directory. Execute CBLBLD.BAT by typing: %basedrive%%psver%\setup\CBLBLD The compile listing is generated under: %basedrive\%temp%\compile\cmpcbl.lis It compiles and executes under: %basedrive%\%temp%\compile It copies the executable files under: %netdrive%\%psver%\cblbin If some of the files fail to compile, ERROR.LIS will be created and at the end of the job: Prints -- The list of file(s) fail to compile or link: type ERROR.LIS If no compile error(s), ERROR.LIS will not be created and at the end of the job: Prints -- ALL the files compiled and linked successfully The error list is located under %basedrive%\%temp%\compile %basedrive%\%temp%\compile can be deleted if they are not needed anymore. The process is done unless you need to extra works as specified on section III. III. Compile and execute COBOL source file on the current compile directory. Follow the instruction section I above to setup the environment variables and copy the necessary files. 1. cd %temp%\compile or cd <where all you source and bat files reside> 2. Execute CBLMAKE.BAT. Please see the CBLMAKE command section IVd below or more details. 3. Then copy the file(s) to %netdrive%%psver%\cblbin or to the directory of your choice copy PTPTEDIT.EXE %netdrive%%psver%\cblbin. Or run CBLSRC.BAT to copy all the files: CBLBIN %temp%\compile %netdrive%%psver%\cblbin 4. You need *.dll files to run COBOL executable. If you dont have *.dll on the directory you run COBOL, copy *.dll files from %netdrive%%psver%\cblbin to your run directory. 5. To run the executable manually not through Process Scheduler: <filename> IV. The existing .bat files owned by COBOL. 1. %PSVER%\setup\cblbld.bat [CONTINUE] If CONTINUE is specified, CBLBLD terminates the job at the end of the compile; otherwise it pauses. By default, it is NO CONTINUE and CBLBLD pauses at the end of the compile process. The file does the following steps: - Create %temp%\compile directory

10

- Copy all the necessary files to do compile/execute to %temp%\compile directory - Compile and execute all the eligible COBOL sources - Copy all the executable files to %basedrive%%psver%\cblbin directory Internally this bat file calls all the .bat files below. 2. %PSVER%\setup\cblsrc.bat <from PSVER directory> <to COMPILE directory> Copy COBOL source files from PSVER to COMPILE directory 3. %PSVER%\src\cbl\win32\cblrule.bat Contains the rules to generate INT, GNT, EXE 4. %PSVER%\src\cbl\win32\cblmake.bat [ ] [ALL] [wildcard filename[ALL]] [wildcard filename/filename without file extension [INT or GNT or EXE]] [LIST] For example: CBLMAKE CBLMAKE ALL CBLMAKE PT* CBLMAKE PT* ALL CBLMAKE PT* INT CBLMAKE PT* GNT CBLMAKE PT* EXE CBLMAKE PTPTEDIT CBLMAKE PTPTEDIT CBLMAKE PTPTEDIT CBLMAKE PTPTEDIT - to compile & execute all COBOL sources - to compile & execute all COBOL sources - to compile & execute all COBOL sources that start with PT - to compile & execute all COBOL sources that start with PT - to generate GNT on all COBOL sources that start with PT. - to generate INT on all COBOL sources start with PT - to execute all COBOL sources start with PT INT - to generate PTPTEDIT.INT INT LIST- to generate PTPTEDIT.INT and create source listing file %temp%\ptptedit.lis GNT - to generate PTPTEDIT.GNT EXE - to generate PTPTEDIT.EXE

LIST option is to create a source listing file under %temp%\<filename>.lis. The LIST option is useful when the compile fails during debugging phase and the source listing file shows exactly where the error is. This option is not recommended when the program compiles successfully because .lis files can grow really big and use up lots of memory. By default, when the compile fails, the source listing is always created under %temp%\<filename>.lis. All the compilation is done using anim compiler option. Dont be surprised when the message says: COMPILE <filename>.INT even when cblmake parameter specifies GNT. Depending on the rule specified, it then removes either .GNT or .INT. By default, the compile generates .GNT unless the exception file exists: CBLINT.?? (where ?? represent the Product Id). CBLINT.?? contains the list of files that need to be compiled to .INT. This exception file is examined only when the second parameter is ALL or none. Thus, the first four CBLMAKE commands above look for CBLINT.?? and generate .INT files as needed. For example the exception file name: CBLINT.PT where PT stands for People Tool.

11

Below is the content/format of CBLINT.PT: Call cblcrint <file name without file extension> For example: Call cblcrint PTPTEDIT CBLMAKE.BAT only creates ERROR.LIS if it fails to compile or link. Note that ERROR.LIS contains the list of files fail to compile/link. The error list is located under %basedrive%\%temp%\compile In order to generate *.exe files, *.cfg should exist and reside on the compile directory. The format of *.cfg file is the same as the previous release. 5. %PSVER%\setup\cblbin.bat <from COMPILE directory> <to CBLBIN directory> Copy COBOL executable files from COMPILE to CBLBIN 6. %PSVER%\src\cbl\win32\cblrun.bat <filename> For example: cblrun PTPTEDIT IV. Windows 95 limitation. Windows 95 can only be used as a client machine: - It can not be an application server. - It can not run the process scheduler server agent. - It can not run the server part of Tuxedo - It will not be able to run the distributed part of the application processor in the future - It will not be able to run Informix, Sybase or Oracle database servers. V. Windows 95 capability. - Windows 95 can run process scheduler client requests. - COBOL will run on the Windows 95 client. - SQR will run on the Windows 95 client. - The COBOL programs can be compiled on NT and execute on Windows 95. - The COBOL programs can be compiled on Windows 95 and execute on NT.

Compile and Run COBOL NT/WINDOWS 95 PeopleTools 7.5 Issues before starting using COBOL .bat files. You need to create 2 variables if they are not defined: PS_HOME, COBOLroot For example: set PS_HOME=c:\pt750 set cobroot=c:\apps\dvlp\netexpress\base Note: %PS_HOME% %cobroot% -points to the PeopleSoft source files -points to the base COBOL compiler; it should contain the path right before \bin directory

The PeopleTool directory has this structure: %PS_HOME%\src\cbl The main .bat file (CBLBLD) makes assumption: All the source codes resides under the directory structure as: %PS_HOME %\src\cbl The compile is done under the parameters specified by CBLBLD The executable files after the compile is copied to %PS_HOME%\cblbin

12

After making sure that all these variables are defined in either you autoexec.bat or Environment (start, settings, control panels, system, environment) for Windows NT refer to the instructions above for instructions on how to compile. Compiling PeopleSoft on Unix. Installing a compiler for Unix environments This section will not really go into the installation of the COBOL compiler you should have received documentation on how to install the COBOL compiler from the software vendor that you purchased the compiler from. What this will cover is more of what environment variables are needed to compile Peoplesoft COBOL programs. NOTE: HP's Release of Microfocus COBOL 4.1 is also called Object COBOL. These are the environment variables that must be set in order to compile. Make sure that the following environment variables are set: COBDIR=/products/mf/oCOBOL-4.1 export COBDIR PATH=$COBDIR/bin:$PATH export PATH LD_LIBRARY_PATH=$COBDIR/coblib export LD_LIBRARY_PATH For HP-UX system also set the following: SHLIB_PATH=$COBDIR/coblib export SHLIB_PATH For IBM AIX system also set the following: LIBPATH=$COBDIR/coblib export LIBPATH SUN Platform Specific Note: Update the $COBDIR/coblib/liblist file to reflect the correct version of C libraries. Any references in the liblist file to "SC3.0.1" must be changed to "SCx.x" where x.x is the correct version. To verify the installed version of the C compiler type the following command: $pkginfo -i | grep SPROcc Also, remove the following two lines form the liblist file: i/opt/SUNWspro/SC3.0.1/lib/__fstd.o p/opt/SUNWspro/SC3.0.1/lib/__fstd.o After installing the compiler we must test a compile to make sure that the compiler is setup correctly. Test the compiler version option by typing the following. $COBDIR/bin/cob -V You should see version information about the product.

13

Test the installation by compiling and running the pi.cbl demo program found in the COBOL demo directory. cp /products/mf/oCOBOL-4.1/demo/pi.cbl /tmp chmod 777 /tmp/pi.cbl su - oracle (or use any other standard user account) [Be sure the COBDIR, PATH, and LD_LIBRARY_PATH variables are set correctly.] cd /tmp cob -Vup pi.cbl At this point you should see output from the compiler. To check the compile, run the program by typing the following: cobrun pi You should see the calculation of pi. IBM AIX Platform Specific Note: If this system is running Oracle you will need to install Microfocus's patch #25554 to fix a linking problem. The patch is also referred to as AIX_COB_FIX. (If you are asked to install COBOL 4.1 on a IBM-AIX box that is running Oracle you will need to also install Micro Focus's patch, referred to as #25554 or AIX_COB_FIX. Micro Focus also uses the patch for COBOL 4.0; however, at this time we have only been asked to install it with COBOL 4.1. You obtain the patch from ftp.microfocus.com. The following are steps to get the patch and install it.) If your system is running AIX 4.2.1/4.3.x and Oracle 7.x/Oracle 8.x and PeopleTools 7.5 edit $COBDIR/coblib/liblist. If a box is running AIX 4.2.1 or 4.3 AND Oracle 7.x and/or Oracle 8.x AND PeopleTools 7.5 along with MFCOBOL 4.1, then the $COBDIR/coblib/liblist file should be edited as follows. See example below: s-H512 s-T512 s-bhalt:4 1-bE:$COBDIR/coblib/rts32.exp i/lib/crt0_r.o (This is the line to modify from i/lib/ crt0.o to i/lib/crt0_r.o. Oracle 8.x requires this and it is optional under Oracle 7.x.) p/lib/mcrt0.o c-L$COBDIR/coblib c-lmbcs.2.0 c-lfhutil.2.0 c-lCOBOL.2.0 c-lasmcrtn.2.0 c-lcrtn.2.0 c-lsupp.2.0 c-lscreen.2.0 c-losx.2.0 c-lmfdce s-lbsd s-lc s-lpthreads (Insert this line. Oracle 8.x requires this and it is optional under Oracle 7.x.) DEC UNIX Platform Specific Note: You must check to make sure the liblist is for the procedural COBOL and not the object oriented. This can be done by changing to $COBDIR/coblib and

14

comparing the "liblist" file size to "liblist_proc" file size. These should be the same. If not, copy liblist_proc" to "liblist". NOTE1: License keys may be obtained via fax or email (through the HP Support Center web site: http://us-support.external.hp.com). The steps below assume you'll be faxing the information to HP. This is all defined in the Installation and Administration for your Data Base and Peoplesoft version. To compile on Unix environments you need to have the environment variables set that are defined above. Then after doing the batch transfer and verifying that it completed successfully you are ready to compile your COBOL. The Batch Transfer (brief description) Before running the Peoplesoft server transfer program, make sure that the DOS environment variable (%TEMP%) is set to a temporary directory to which you have write access. The transfer program will write the following two files to this directory: PSXFR.LOG = A log file summarizing the programs execution. PSXFR.CFT = A configuration file that stores the parameters you selected. Launch the server transfer program and select your appropriate Data Base (ie. Oracle (Unix), ect.). After filling out the correct parameters in the configuration utility and creating the psxfg.cfg you might want to verify that it is correct. You can open this .cfg in any text editor. One thing that causes a lot of problems is the PS_PLT variable. Make sure that this is defined correctly in the .cfg as well as in your environment variables on the server. In the .cfg this parameter is defined as HSTPLT and in UNIX it is PS_PLT Below is a list of the valid PS_PLT parameters. Version/ Operating System PeopleSoft version 6.x IBM RS/6000 AIX 4.1.3 IBM RS/6000 AIX 4.1.4 IBM RS/6000 AIX 4.2 DG AViiON Intel DG/UX 4.11 HP 9000 8xx HP-UX 10.01 HP 9000 8xx HP-UX 10.10 HP 9000 8xx HP-UX 10.20 DEC Alpha Digital UNIX 3.2 DEC Alpha Digital UNIX 4.0 Sequent Symmetry Dynix 4.2.0 Sequent Symmetry Dynix 4.3.0 Sun Ultra Sparc/Sparc Solaris 2.5 Sun Ultra Sparc/Sparc Solaris 2.5.1 Siemens Nixdorg - Pyramid Reliant 4.3 Siemens Nixdorf RM1000 - Pyramid Nile DC/OSX 1.1 Siemens Nixdorf RM1000 - Pyramid Nile DC/OSX 2.0 Siemens Nixdorf RM400/RM600 SINEX 5.42 Intel PC SCO OpenServer 5.02 AT&T GIS 3000 MP RAS 3.0 SGI Challenge, Indy IRIX 6.2 Tandem NR IRIX 6.2 Unisys 6000 Unisys Unix SVR4 1.4 DG AViiON m88K1 DG/UX 4.11 Intel PC SCO Unix 3.2v4.2 Intel PC SCO OpenServer 5.02 UnixWare 2.1 PS_PLT AX4 AX4 AX4 DGI HP0 HP0 HP0 OSF DU4 DY4 DY4 S5 S5 RU1 PY1 PY2 SNI SC5 RA3 IRX IRX UNS DG SCO SC5 UNI

15

DEC AXP Open VMS 6.2 DEC AXP Open VMS 7.1 PeopleSoft version 7.0 IBM RS/6000 AIX 4.2 AT&T GIS 3000 MP RAS 3.0 Worldmark or NCR GIS 3000 MP RAS 3.01 DEC Alpha Digital UNIX 4.0 HP 9000 8xx HP-UX 10.20 Sequent Symmetry Dynix 4.2.0 Sequent Symmetry Dynix 4.4.1 Siemens Nisdorf - Pyramid Reliant UNIX 5.4.3 Sun Ultra Sparc/Sparc Solaris 2.5.1 Sun Ultra Sparc/Sparc Solaris 2.6 HP 9000 8xx HP-UX 11.0 Tandem NR IRIX 6.2 DEC AXP Open VMS 7.1

V62 V71 AIX_4_2 RA3 RA3 DIGITALUNIX_4_0 HPUX_10_20 DY4 DY4 RU1 SOLARIS_2_51 SOLARIS_2_51 HPUX_11_0 IRX VMS_7_1

PeopleSoft version 7.5 IBM RS/6000 AIX 4.2.1 or AIX 4.3 AIX_4_2 AT&T GIS 3000 MP RAS 3.02 RA3 DEC Alpha Digital Unix 4.0 DIGITALUNIX_4_0 HP 9000 8xx HP-UX 10.20 HPUX_10_20 HP 9000 8xx HP-UX 11.00 HPUX_11_00 Sequent Symmetry Dynix 4.4.2 DYNIX_4_0 Siemens Nixdorf Pyramid Reliant Unix 5.4.3 RELIANT_5_43 Sun Ultra Sparc/Sparc Solaris 2.5.1 or 2.6 SOLARIS_2_51 DEC AXP Open VMS 7.1 VMS_7_1 (Follow the Installation and Administration Guide for more details on the Server transfer program). After verifying that all your programs have been transferred over to your server correctly you are ready to compile. Compiling on UNIX environments: In Unix all you need to do to compile all the COBOL is from the $PS_HOME/install directory type: ./pscbl.mak To compile one COBOL program type the compile script plus the COBOL name that you want to compile. Ex. ./pscbl.mak PTPTEDIT This by default will create a .gnt executable unless it is defined in the cblint.xxx file. (PTPTEDIT.gnt). To compile this program as an .int you must create a file in the $PS_HOME/src/cbl directory called cblint.xxx (xxx standing for anything you want. The compiler doesnt read the extension of this file. Just the cblint.). Inside of this file you must have the following line or lines: Example: call cblcrint APPBVCHR. (APPBVCHR being the COBOL program that you want to be a .int) If you would like multiple COBOL programs to be compiled as .ints inside of that same file you created add other lines that read exactly the same way as the example. call cblcrint APPBVCHR call cblcrint PPPXXXXX Now check the error.lst file to make sure no errors have occurred. Look inside of the $PS_HOME/src/cbl/lis directory and see if any possible errors occurred with your compile.

16

Now you should link your COBOL. You should link or relink when: Installing Peoplesoft for the first time. Any COBOL programs have changed. The version of the RDBMS running Peoplesoft has changed. The COBOL compiler has changed. One of the C programs supplied by Peoplesoft has changed. This is where most issues will show up. Refer to the FAQs and Common Errors sections for additional details. To link your COBOL just cd to the $PS_HOME/install directory and type. ./psrun.mak After linking your COBOL a file will be created called PSRUN. This is the main executable that will run all COBOL processes on your UNIX environment. To test to make sure that the link was successful check the file called psrun.err which is located in $PS_HOME/install directory. Compiling (COBOL) on AS/400 -- this is how things work. ( by: Sai Kalur) -- When you try to compile all the COBOL programs with PSCRTOBJ, the default is to Delete the files with type *MODULE. This is what this command does: ----Compile and Create Module -- one per source program Create Service Program -- total of 2. Create Program -- One per Process. Delete Module

What is Module: It is the compiled Object What is Program: It is the static link of all the Modules in a process. For example, PSPCLBLD, the Pay Calendar Build is a Program and it is a static link of all the compiled programs that this process calls (application and tools programs) What is a Service Program: It is a static link of all the Modules that are not statically linked into any particular process. All the modules the application programs dynamically call are linked into a Service Program. PSCRTOBJ has 4 entry points -- *BEGIN, *BNDDIR, *CMD, *CBLMOD *BEGIN -- Does everything *BNDDIR -- ?? What does this do? *CMD -- Compiles only CLP Command Programs *CBLMOD -- Compiles only Cobol programs Hitting F4 after typing PSCRTOBJ will prompt on Entry Point. Hitting F9 now will let you change the defaults. The important default is "Delete Modules = *YES". This command's defaults are designed for compiling programs in production environment. Since all the Programs are static links of all Modules they call, there is no need to keep *MODULEs in production and use up space. In a development environment, you have to change this default to *NO so that the *MODULEs would remain. If you don't have these Modules, you cannot create *PGM or Service Program.

17

There are 2 Service Programs - PTPCMSVP for all products (tools Service Program) and PAPCMSVP for Pension Admin. You create the 2nd one ONLY if you have licensed Pension Admin product. Which *PGMs to create? PeopleSoft delivered process list can be found in file CFGSRC in your Source library. Create *PGMs ONLY for the entries in this file. There is no concept of Binding a plan in AS/400. ** How do you validate the Compiles? Look at the job's spool files and hit Shift-F6 to go to the bottom. If you find QPJOBLOG as the last file and the one before that is a program name, then the compiles are successful. If you find QPPGMDMP or QPDSPJOB as a spool file just before QPJOBLOG, then there was a problem. The way to find out the failing programs is to go to the top and scroll thru the list of spool files and whenever you find a QPPGMDMP, the program above that is the failing program. Display it (option 5), go to the bottom and find out how many severity errors of 30 or higher are there. Severity of 20 is a warning on AS/400 COBOL Compiles; you should be concerned with Severity 30 or higher. Scroll thru the list upwards and find out all the Severity 30 errors and fix the COBOL programs and rerun the compiles. After all the compiles are successful, a way to make sure all the compiles are done is to check the Programs created. Look at the Source Library/CFGSRC file. Get a list of members in this file. Then issue the command WRKOBJPDM LIB(object library) OBJTYPE(*PGM) If you have a *PGM created for each of the members in the CFGSRC, then all the compiles are successful. Better way to validate: Go to QPJOBLOG (You will have QPJOBLOG only if your message logging level is set to 4,00,*SECLVL). In the QPJOBLOG, search for source statement errors. For every program that fails, you will find this string text. COBOL Source Program can be ftp up to AS/400 Platform manually(rather using BATCH TRANSFER PROCESS), but CTs have to add the OS400 REPLACE... line at the top of the programs. Only add the line to the top of PROGRAMS, not COPYBOOKS. The programs has a "P" for the third letter of the name, copybooks have a "C" for the third letter. CT can compile the modules and then link the programs rather than use PSCRTOBJ. Here's what they need to do: To compile a module: Make sure that the source library is first in the library list of the job that runs the compile command. The command to compile COBOL modules (except PTPSQLRT) is: CRTCBLMOD MODULE(object_library/module_name) SRCFILE(source_library/source_file) OPTION(*APOST *NOMONOPRC *CRTF) LINKLIT(*PRC) DBGVIEW(debug_option) The debug options are:

18

*STMT *SOURCE *LIST *ALL *NONE We recommend using *ALL for development and testing, *NONE production. The command to compile PTPSQLRT is: CRTSQLCBLI OBJ(object_library/module_name) SRCFILE(source_library/source_file) COMMIT(*CS) RDB(*NONE) OBJTYPE(*MODULE) OPTION(*APOST *APOSTSQL *SYS) ALWCPYDTA(*OPTIMIZE) ALWBLK(*ALLREAD) DATFMT(*ISO)TIMFMT(*ISO) DBGVIEW(debug_option) USRPRF(*USER) The debug options are: *SOURCE *NONE We recommend using *SOURCE for development and testing, *NONE production. Once the modules are compiled, you need to create the run-time programs (link the modules). Modules are linked in by one of two ways: the module can be linked directly or can be linked as part of a service program. Since most PeopleSoft modules are linked directly, I'll explain the exceptions first, the service programs. There is one main service program -- PTPCMSVP. This service program contains common PeopleTools modules that are called by every application. The modules included in this service program are: PTPDTWRK PTPDYSQL PTPLOGMS PTPNETRT PTPRATES PTPRUNID PTPSETAD PTPSQLGS PTPSQLRT PTPTRACE PTPUSTAT PTPWLGEN

PT7.5 and higher

PT7.x and higher

If you re-compile any of the modules listed above, you would "link" in the module by updating the service program with the new module. The command to do this is: UPDSRVPGM SRVPGM(object_library/PTPCMSVP) MODULE(object_library/module_name) There you have PeopleSoft's Pension Administration, there is another service program, PAPCMSVP. The modules contained in this service program are: PAPUAFMN PAPUALAF PAPUALCS PAPUALDB PAPUALDT PAPUALDU 19

PAPUALFR PAPUALIP PAPUALTL PAPUAUDT PAPUCSTM PAPUDTGN PAPUDTMN PAPUELMT PAPUGRDF PAPUMSGP PAPUPROJ If you re-compile any of the modules listed above, you would "link" in the module by updating the service program with the new module. The command to do this is: UPDSRVPGM SRVPGM(object_library/PAPCMSVP) MODULE(object_library/module_name) Before you can link a module directly to a program, you must make sure that the binding directory is correct. The binding directory lists all of the modules that are available to resolve references ("CALL" statements) in a program. During the initial install (PSCRTOBJ), a binding directory is created for each object library, with the same name as the library. If the module that you compiled is a new module (wasn't included in the original install), you need to add a binding directory entry for the module. To do this, the command is: ADDBNDDIRE BNDDIR(object_library/object_library) OBJ((object_library/module_name *MODULE)) You don't have to do anything with the binding directory if the module was included in the original install, or if it contained in a service program. Once you have completed all changes to the service programs and binding directory, you link the modules into a program using this command: CRTPGM PGM(object_library/program_name) MODULE(*PGM) ENTMOD(*PGM) BNDDIR(object_librayr/object_library) ACTGRP(PSFT) OPTION(*UNRSLVREF *DUPPROC) DETAIL(*EXTENDED) AUT(*ALL) program_name in this command is not the module name, but rather the program that needs this module. It could be the same as the module; this would be the entry point module into the program. But more likely, the program that you are creating will not be the same as the module that you compiled, Also, every program that references the module will need to be re-linked. The source file CFGSRC contains a member with the name of each program that was created during the original install. PSCRTOBJ uses a list of members in this file, not the data in each member. You should contact PeopleSoft to find out which programs use the module that you compiled and need to be relinked. Compiling PeopleSoft on OS/390. Compile and Link-Edit COBOL Submit HLQ.PPVVV.JCLLIB(PSCOBx) to compile COBOL programs

20

NOTE: Previous versions of PSCOB had to be manually broken up into multiple jobs if they contained more then 125 COBOL programs to compile. This step is now done by the Server Transfer process, which will create the PSCOBx members. Next, serialize COBOL jobs to avoid problems associated with concurrent PDS updating, and submit the PSCOB job(s). Acceptable return codes are 4 for pre-compiles and compiles, and 0 for the link-edit step. Common compile errors include: Users inadvertently introducing tab characters to source code while viewing them using workstation editors before file transfer. Check to see if you have X05 (or other odd hex values in the OS/390 source. Failure to file transfer all the BASE and OS/390 copy members from the file server, or perhaps overlaying the OS/390 versions with the BASE versions. Check PSFTXFR.BAT (or PSTXFR.TXT if using FTP) to examine file transfers.

NOTE: Peoplesoft delivers a compile process, PSCOBD, which sets DB2 pre-compiler options DATE(ISO) and TIME(ISO). Do not change these settings, as Peoplesoft applications rely on the ISO format for date and time processing. Debugging COBOL on MVS : If using Peoplesoft version 7 and above , Set the PARM 7 to Y in the shelcblf / Shelcblp to enable tracing when the COBOL job is run through Process scheduler on the server. //* PARMFILE - PARM 1 IS OPRID - LEAVE AS SYMBOLIC //* PARM 2 IS RUN CONTROL NAME //* PARM 3 IS A YES/NO SWITCH FOR PERFORMANCE STATISTIC //* PARM 4 IS PROCESS INSTANCE; 0 TRIGGERS PROC INST LOGIC //* BLANK IF NON-PROCESS SCHEDULER JOB //* PARM 5 IS A YES/NO SWITCH FOR DYNAMIC EXPLAINS //* PARM 5 REQUIRES THAT PARM 3 IS SET TO YES //* PARM 6 IS A YES/NO SWITCH TO ENABLE PARALLEL PROCESSING //* PARM 7 IS A YES/NO SWITCH TO ENABLE SQL TRACE //* //* //PARMFILE DD * %OPRID% %RUNID% N %INSTANCE% N N Y /* If the Peoplesoft version is before 7, then First: Edit PTPSQLRT find any occurrences of DEBUG^* in position 1 and replace the * with a space (You can issue the command: C 'DEGUB *' 'DEBUG ' (note 2 blanks after DEBUG))

21

Second: Recompile the COBOL module Third: Rebind the Plan using PSBNDREP JCL Note: Your output file will have significant amount of data if you replace all occurrences of DEBUG with DEBUG^^ (replacing the * with a space). Subsequently, you may only want to uncomment out the debug parameters which deal with the SQL statements ignoring the 'connect=' variables (leave those commented with the *). Output should be in the SYSOUT DD of the COBOL Job. Running COBOL on MVS outside of the Process Scheduler : COBOL jobs may run outside process scheduler by specifying a 0 (a numeric zero) for the process instance, as shown in the fourth parameter below: //PARMFILE DD * Operator-ID Batch-Run-Id Y 0 N N Sample COBOL JCL is provided in PP.PPVVV.JCLLIB(CBLSAMP). Common compile errors on MVS include: 1. 2. Users inadvertently include tab characters to source code while viewing them using workstation editors before file transfer. Check to see if you have X05 (or other odd hex values in the OS/390 source. Failure to file transfer all the BASE and MVS copy members from the file server, or perhaps overlaying the OS/390 versions with the BASE versions. Check PSFTXFR.BAT (or PSTXFR.TXT if using FTP) to examine file transfers. For example, the PSFTXFR.TXT file should contain two PUT statements for PTPSQLRT.CBL, the first one coming from BASE directory and the second one coming from MVS directory. Some compilers may not accept double quotes as String delimiters. If you have compiler errors with double quotes, try changing them to single quotes .

3.

COBOL Common Errors and General Info. PeopleSoft COBOL and batch errors can be very common. Usually, a very high percentage of these problems can be resolved fairly easily, if you know what is causing the error. A majority of COBOL errors are caused by: 1). Not having the correct COBOL compiler installed. 2). Not having all the required operating system or compiler patches applied 3). Not having the platform environment variables set correctly 4). Not having all the COBOL source code, or the correct version of the COBOL source code, when compiling or not having the correct version of the dms scripts loaded when running. 5). Other miscellaneous errors. Installing the correct COBOL compiler: Check the PeopleSoft website (www.peoplesoft.com) frequently to determine the correct COBOL compiler that is required for your platform. This information can also be found in the PeopleSoft Hardware and Software Guide for the version of PeopleTools you are running.

22

Many problems can arise from not being on the certified version of the COBOL compiler. They are not very predictable. The reason is, all of PeopleTools development is done using a certified COBOL compiler, meaning our developers have successfully compiled and run the COBOL processes using a specific COBOL compiler. If you start encountering problems with your COBOL jobs and you are using a compiler that PeopleSoft has not certified, and therefore never used to test with, it is likely that the problems are being caused by not using the correct compiler. In order to take a compiler problem out of the loop, PeopleSoft requires you to be on a certified platform compiler. As a guideline, Microfocus 4.1 is the certified version for any UNIX operating system for PeopleTools 6 and up. Microfocus 4.0.32 is certified for Windows NT clients for PeopleTools 6 and 7. Microfocus NetExpress 2.0 is certified for Windows NT clients for PeopleTools 7.5 and up. Always refer to the most current copy of the PeopleSoft Hardware and Software Guide for certified compilers and compiler patches. C compiler must be installed before COBOL compiler. This is because the COBOL library liblist is created when the COBOL compiler is installed using specific information from your C compiler. If a C compiler is not found, it defaults information. To assure the liblist is created with accurate information, the C compiler should be installed before the COBOL compiler. Required Operating System, Database or Compiler Patches Applied: Occasionally an operating system or Database bug will effect the COBOL compilation or process run. To be sure, always review the Hardware and Software Requirement and App Server & 3rd Party Product Patches Required for Install document. This is a living document on our website and is updated often. In order to keep from being redundant, please check the system symptoms and the corresponding patches in the Hardware and Software Requirements (PeopleTools 7) or the App Server & 3rd Party Product Patches Required for Install document. Platform Environment Variables: Its quite possible that the most COBOL compile, link or run errors are attributable to environment setup issues. There are many environment variables that need to be set on both Windows and UNIX environments in order to successfully compile, link, and run COBOL programs. When compiling on a Windows 95 or NT client for PeopleTools 6 and 7, there are a few environment variables that need to be set in your autoexec.bat (Windows 95/98) or your System|Environment (Windows NT). These are set assuming there is a valid, certified COBOL compiler on the workstation. basedrive - points to the drive where the compile takes place; usually it is your local or c: drive netdrive - points to the drive where the COBOL source resides temp - points to the compile directory cobroot - points to the base COBOL compiler; it should contain the path right before \exedll directory psver - points to the base directory for the source, otherwise known as your pshome. When compiling on a Windows 95 or NT client for PeopleTools 7.5 and up, there are even fewer environment variables that need to be set. cobroot - points to the base COBOL compiler; it should contain the path right before \exedll directory ps_home points to the base directory for the source, same as the psver in PeopleTools 6 and 7. When compiling on a UNIX operating system, many environment variables need to be set. Most of these variables are set in the psconfig.sh. They are: COBDIR points to the directory that your COBOL compiler is installed.

23

SHLIB_PATH - used only for HPUX operating systems, should include <database home>/lib (ex. ORACLE_HOME/lib) and COBDIR/coblib LIBPATH - used only for IBM AIX operating systems, should be the same as SHLIB_PATH LD_LIBRARY_PATH - used for SUN Solaris operating systems and DEC operating systems, should be the same as SHLIB_PATH PATH - should include, <datbase home>/bin, COBDIR/bin, PS_HOME/bin PS_DB - this is set in your psconfig.sh, but is determined by the input parameters used in the batch transfer program. Should indicate the type of database on the platform. PS_PLT Also set in psconfig.sh, should indicate the type of operating system. PS_DBVER- should be set to the version of the database. COBPATH - Optional. If used, it should be set to the PS_HOME/cblbin, where the COBOL executables are. PS_HOME - Set in psconfig.sh, should be set to the PeopleSoft high level directory. COBOL source code problems Its critical to be running the most recent version of the COBOL source code available. Because of this, many upgrades or fixes are applied to the COBOL source. Quite often, only pieces of a patch or an upgrade are applied to the database machine which cause COBOL compile problems. The most common of these errors is the "operand not defined" error. Typically, this type of message means that the program is searching for a working storage variable, and that variable doesnt exist. This usually means that the program being compiled is an older version than the copybooks used in the program, or vice versa. Either way, the program and its copybooks arent in sync. The first thing to look at is to make sure you have the correct program. Compare the program you are compiling to the program on the install CD/file server or the upgrade or fix disc/patch. If they arent the same, ftp the correct program to the database server and recompile. If the program seems to be OK, scan the program to see what copybooks the program uses. All PeopleSoft copybooks have a C in the third character of the copybook name. Once you have a list of copybooks, compare those on the database server to those on the install CD/file server or upgrade or fix disc/patch. If you find discrepancies, ftp the correct version of the copybook to the database server and recompile. Other Miscellaneous Errors/Questions Problem: ld: 0706-014 the -b rtl option is not recognized. ld:0706-006 cannot find or open library file:-ldl Solution: When running PT 7 psrun.mak on an AIX IBM-9000 using an Oracle Database version 7.3.3 or greater, the customer needs to make sure that their C compiler fileset (xlC.rte) is at least at version 3.1.4.7. Problem: Client COBOL fails with Load error file PTPSQLRT error code 189, PC=0, call=1,seg=1. Solution: In order for COBOL to run correctly on Windows 95 and NT workstations, you may set the Working Directory = %CBLBIN%. To do this, you must modify the Process Type Definition for your client COBOL. 1) Log onto PeopleTools, then select Start/PeopleTools/Process Scheduler. 2) Then select Use/Process Types/Type Definition 1/Update Display. 3) Choose the appropriate COBOL SQL definition for your database platform. 4) Change the Working Directory field from "%DBBIN%" to "%CBLBIN%". 5) Save your changes.

24

Also make sure that the Database Connectivity Drivers directory is included in the DOS PATH. eg: PATH=c:\apps\oracle\bin; c:\apps\mssql\binn Problem: Receive the error Load error file"inoc" error code 198,pc=0,call=3,seg=0. 198 load failure while compiling on any Unix O/S. Resolution: Shared library path was not set correctly in the environment variables or psconfig.sh. For HPUX this variable is the SHLIB_PATH, for SUN, the variable is LD_LIBRARY_PATH and for IBM AIX, the variable is LIBPATH. It should contain the directory $COBDIR/coblib. Its also important to be on a certified version of the COBOL compiler. Question: Is Microfocus COBOL required for any NT workstation? If so, is it required for a single workstation or every runtime user workstation? Under what circumstances is it required? Answer: One copy of the Microfocus Object COBOL compiler for the workstation is required. The run-time version is not enough because it only gives you the ability to run COBOL programs, not compile them. The compiler is needed because recompiles to the workstation COBOL is necessary when we post fixes to the source code. The only circumstance in which it would not be required is if you are not planning to run any COBOL programs on the workstations at all. Several customers have chosen to do this they only run COBOL on the Unix server side. There are many reasons for this, including 1) You don't have to keep two versions of every program up-to-date with customizations and fixes; and 2) (most importantly) performance is up to 66% faster on the server because the network is not involved when the programs need to access the database, and because the Unix server hardware is "beefier" than a user's PC. Question: Explain HP COBOL Versioning. Answer: B.12.25 is what HP calls the VUF (Version.Update.Fix). The version character only changes for major releases. In the case of HP COBOL, the version changed when we switched from shipping the MF COBOL/ET to the MF COBOL/2 product. The update level changes typically when we ship a new MF release and/or ship on a new O.S. release. For example, B.11.xx is V4.0 on HP-UX 10.20, B.12.xx is V4.1 on HP-UX 10.20, and B.13.xx is V4.1 on HP-UX 11.0. The fix level changes with patches. So, for example, B.11.26 is a patch to B.11.25 and should work fine with a product certified with B.11.25. Question: Which should be installed, Procedural or Object Oriented (OO) COBOL compiler? Answer: Error may occur if youve installed your UNIX Microfocus COBOL version 4.1 as Object Oriented, particularly if you dont have a C++ compiler on the machine. Starting with COBOL compiler version 4.1 in all the UNIX boxes, you have a choice to either install Object Oriented or Procedural compiler. The package should come with 3 CD's: 1 for doc, 1 for 'Application Server', 1 for 'Object COBOL'. It needs the 3rd CD which is 'Object COBOL'. If the UNIX machine has no C++ compiler, then it will automatically install a procedural COBOL.

25

If the UNIX machine has C++ compiler, then the install program then asks if you want to install OO or procedural compiler by the question below: Will you be writing object oriented COBOL? N --> to install procedural Y --> to install OO PeopleSoft product only requires procedural compiler. If the sites prefer to install OO, they could, but they have to install C++. The quick way to find out if it is procedural or OO compiler for UNIX COBOL version 4.1 Follow these steps: a) go to the directory where "liblist" file resides cd $COBDIR/lib b) check to see if "liblist" has any reference to "oop" grep -i oop liblist if "oop" is found, it means that OO compiler is installed, otherwise procedural is installed. Note: IBM servers require the COBOL compiler to be installed as Procedural. Problem: Error loading /opt/COBOL/cobdir/coblib/libhpCOBOL.1, errno = 12 /usr/lib/dld.sl: Unresolved symbol: domain_entry_points (data) from /opt/COBOL/cobdir/coblib /liboops.1 /usr/lib/dld.sl: Unresolved module for symbol: localNew__6memorySFi (code) from /opt/COBOL /cobdir/coblib/liboops.1 /usr/lib/dld.sl: Unresolved module for symbol: __vtbl__7cstring (data) from /opt/COBOL/cobdir /coblib/liboops.1 /usr/lib/dld.sl: Unresolved module for symbol: restart__9OORunTime (data) from /opt/COBOL /cobdir/coblib/liboops.1 /usr/lib/dld.sl: Unresolved module for symbol: maxTemplateSize__8switches (storage) from /opt/COBOL/cobdir/coblib/libmfo.1 Load error : file 'PTPUPRCS' error code: 198, pc=0, call=-1, seg=0 198 Load failure Solution: The workaround is to remove the reference to c-loops from the liblist. Problem: If running HPUX COBOL from an HPUX 10.20 O/S and you receive the following error is found in the psrun.err file after running psrun.mak: cob:++none found++ cob:library not found: -lCsup Solution: Apply the most recent O/S patches from the Application Server and 3rd Party Product Patches. The patches for HPUX when this document was written are: PHSS_15380 PHSS_15391 PHSS_15043 These change often, but the HP website will direct you to the replacement patch if they have been superceded. Refer to www.hp.com for the current patch.

26

Problem: After upgrading to Oracle 8.0.4 or higher, if you receive the following message in your psrun.err file after running psrun.mak: LD.SO.1:PS: PSRUN: Fatal: relocation error File oracle/lib/libclntsh.so.1.0:symbol slpmpordstab: references symbol not found Solution: There is an Oracle bug in the shared library. This bug is referenced with number BUG#515423. However, there is a workaround. cd to $ORACLE_HOME/bin vi genclntsh Comment out the line below in BOLD and RERUN genclntsh, then rerun psrun.mak. # # remove sorapt.o from libcommon.a # cp ${ORACLE_HOME}/lib/libcommon.a $LIBCOMMON #ar d $LIBCOMMON sorapt.o Problem: Receiving the following error in the PSPT_PSUNX.stdout log, when attempting to start the Process Scheduler; error loading /opt/COBOL/cobdir/coblib/libhpCOBOL.1,errno=215 Solution: On HPUX: The problem was resolved by applying HP fixes PHSS_13050, PHSS_14716 and PHCO_14891 (Note PHSS_14716 and PHCO_14891 will have been superseded with the next cumulative fix, but those patch names can be found by searching for the ones mentioned here) . The first fix will upgrade their compiler from B12.25 to B12.26 (a higher patched version of Microfocus 4.1). On other platforms: If you have C++ loaded on the machine, add the c-loops line into the $COBDIR/coblib/liblist. Problem: Error 173: Called program not in drive or directory Suggestion: Things to check: (for UNIX only!) A) If the module it cannot find is a COBOL module (ends in .gnt or .int), make sure the directory it is in is in the environment variable COBPATH. Have user type "echo $COBPATH" to check its value. Make sure they are checking from the same userid that is having the problem! B) Is the module being called is a C routine (ie: c_psdefault), it must be linked into the runtime (PSRUN). Use the command 'nm PSRUN|grep routine_name' to see if it is linked in. It should show as an entry point. If not, re-run psrun.mak with the C source or object or archive which contains this routine specified on the compile line (the 'cob' line) in the psrun.mak script. C) If it is in the runtime (found it using 'nm' as in step 2, above), then it simply must find it. If it still does not, use the 'which PRSUN' command to be sure the system is actually trying to run the copy of PSRUN we think it's trying to run.

27

D) Check permissions. If the PSRUN does not have the executable bit set, the kernel will think it's a text file or something and skip over it. Set the file to permission 7 using the chmod command, ie 'chmod 755'. Things to check: (for NT only!) A) Make sure the environment variable COBDIR is set to where the COBOL executables are located on the file server. B) Make sure the CBLBIN and PRDBIN (for pre-7.5 Tools) on the Process Scheduler tab in Configuration Manager are set to the cblbin directory where the COBOL executables are located. C). Verify the COBOL executable actually exists in the cblbin directory. Problem: Error after trying to run psrun.mak: LD: Can't open/ opt/oracle/product/7.3.4/lib/libocic.a LD: No such file or directory. Solution: The libocic.a was used only in Oracle 7.2, so its likely the psrun.mak was trying to read the wrong library. Make sure the PS_DBVER environment variable is set to 7.3, not 7.2. Question: Are Pro*C and Pro*COBOL compilers needed to compile PeopleSoft programs? Answer: No, these Oracle delivered pre-compilers are not needed. We need the ANSI C compiler from the hardware vendor. Don't confuse the Pro* compilers with the regular ANSI C compiler or Microfocus COBOL compiler. The Pro Compilers are used by some Oracle customers to issue queries to the database within C or COBOL code. PeopleSoft does not use any Pro C or Pro COBOL code within our C or COBOL (we use our method of interface), therefore these pre-compilers are not needed for our installation. However there is an exception. This applies to PeopleTools 7.01 and Oracle 7.3.4 on HPUX 10.20 only 1) When you install Oracle, you must select the PRO*COBOL option to get the cobsqlintf.o installed into the /$ORACLE_HOME/precomp/lib. 2) While logged in as the Oracle user, cd to $ORACLE_HOME/rdbms/lib 3) Edit and move the include of cobsqlintf.o to the front of the link list in the Oracle 7.3.4 clntsh.mk as indicated below: Excerpt from Oracle 7.3.4 clntsh.mk: Before: INSTLIBS_NOXA_ALL= -lclient -lsql -lsqlnet -lncr -lsqlnet -lclient -lcommon -lgeneric -lsqlnet -lncr -lsqlnet -lclient -lcommon -lgeneric -lepc -lnlsrtl3 -lc3v6 -lcore3 -lnlsrtl3 -lcore3 -lnlsrtl3 $(ORACLE_HOME)/precomp/lib/cobsqlintf.o INSTLIBS_XA_ALL= -lclient -lxa -lsql -lsqlnet -lncr -lsqlnet -lclient -lxa -lcommon -lgeneric -lsqlnet -lncr -lsqlnet -lclient -lxa -lcommon -lgeneric -lepc -lnlsrtl3 -lc3v6 -lcore3 -lnlsrtl3 -lcore3 -lnlsrtl3 $(ORACLE_HOME)/precomp/lib/cobsqlintf.o After:

28

INSTLIBS_NOXA_ALL=$(ORACLE_HOME)/precomp/lib/cobsqlintf.o -lclient -lsql -lsqlnet -lncr -lsqlnet -lclient -lcommon -lgeneric -lsqlnet -lncr -lsqlnet -lclient -lcommon -lgeneric -lepc -lnlsrtl3 -lc3v6 -lcore3 -lnlsrtl3 -lcore3 -lnlsrtl3 INSTLIBS_XA_ALL=$(ORACLE_HOME)/precomp/lib/cobsqlintf.o -lclient -lxa -lsql -lsqlnet -lncr -lsqlnet -lclient -lxa -lcommon -lgeneric -lsqlnet -lncr -lsqlnet -lclient -lxa -lcommon -lgeneric -lepc -lnlsrtl3 -lc3v6 -lcore3 -lnlsrtl3 -lcore3 -lnlsrtl3 4) Remake the Oracle Shared library file as follows, from $ORACLE_HOME/rdbms/lib: Problem: Remote Call errors in two and three tier troubleshooting tips. Suggestion: Remote call errors are very generic. They usually say could not start child program.. or child program did not complete.. All these messages mean is that the remote call process couldnt finish normally. They dont really give much insight as to what the actual problem is. However, there is a way to determine the problem (for PeopleTools 7 and greater). If running a remote call process in two tier, on the remote call tab of the configuration manager is a remote call redirect flag. Check the flag and rerun the remote call process. This will create two files in your TEMP directory, one ending with .out, the other with .err. The .out file will more than likely contain the reason why the process didnt complete successfully. If running a remote call process in three tier, the COBOL runs on the Application Server. Therefore, the same flag is set, but this time in the Application Server configuration. The parameter RCCBL is defaulted to 0. If it is changed to 1 and rebooted, the same two files will be written to the Application Server logs directory, giving additional information as to why the remote call process failed. For more information on remote call debugging, refer to PeopleBooks.

29

S-ar putea să vă placă și