Question: A client, moving from HR Classic to emPath, recently asked for tips on several issues about compiling and testing on the business tier in an emPath configuration.
Response: Following are responses to the clients specific questions:
(1) Question: Do we compile on the Business Server or just move files over ( Source, executable, etc).
Response: What I have used and seen at several clients is the following approach. Each developer has a copy of NetExpress / Microfocus COBOL on their personal PC. The programs are developed and compiled on their personal PC. Only the executable (exe) is moved to the emPath business tier. The source is normally maintained in a common Visual SourceSafe (VSS).
The command procedures, sort specifications, SQL statements, etc are also normally maintained on VSS and copied to the emPath business tier.
(2) Question: For testing do we have to automatically add to the emPath Menu as an Item to the right or can the program be easily added as part of the list for Batch Reports Menu Item.
Response: Most batch custom development should be added as a batch reports menu item. Adding menu items outside of the batch reports area is normally done for online customs.
Note that while it is possible to create a menu item, outside of the batch reports area, which involks a command procedure it is important to note that this method of invoking a command procedure results in a job running on a client PC not the business tier.
The steps to add a batch reports menu item are simple and quick. They are as follows:
(2.1) In emPath select menu item setup > reports
(2.2) Hover over the edit icon then select "new report entry"
(2.3) Enter new report entry values. An example is shown below which was used to create the menu item to execute the example command procedure in article 50017.
(2.4) Hover over the edit item and select "elements". Note that these are the elements which the user will be prompted for. They will be added to the users PYT file. Logic in your custom command procedure can read these PYT elements and control the processing in your command procedure.
NOTE - Atleast one element is required even if your command procedure does not use it.
(2.5) Hover over the edit item and select "new element"
(2.6) Enter element values as shown in the attached screen print.
(3) Question: Can we test a cobol program from the dos prompt of the server.
Response: Yes you can, however it is not recommended. My recommended approach is to use the batch reporting features from emPath in combination with the custom command procedure recommendations shown in article 50018. This will result in a detailed log showing the results from your test.
However, because there are instances where you may need to run the custom program from the DOS prompt I will share two alternatives for testing from the dos prompt.
(3.1) Recommended Alternative - Create a command procedure and a batch reporting menu item. Then when you submit the job place a future time in the start time (see screne print below). This will result in a command procedure ready to execute placed in your hrlogdir folder. The job will be scheduled to run on the empath business tier using the windows scheduler. However, you can run the job, line by line, from the DOS prompt.
(3.1.1) Logon to the emPath business heir and locate the command procedure created. Note that emPath combines the command procedure you create with additional statements which are very important. Note the the location for this resulting command procedure is where ever you have defined your HRLOGDIR folder for the emPath environment you are testing with.
(3.1.2) Open a DOS prompt, edit the command procedure, then copy paste from the command procedure to the DOS prompt.
(3.2) Second alternative - Create a batch file which defines the environment you wish to test in. You can create this batch file by doing the following:
(3.2.1) Open the RES file you are using to define the test enviornment you are using.
(3.2.2) Create a batch file. Then copy paste the statements beginning with set_env from your RES file to your manual setup batch file.
(3.3.3) change the statements to set= instead of set_env= statements. A SQLServer example is shown below:
set=HR_ROOT=c:\Nsl63\emPath_bc
set=HRDLLS_DIR=c:\Nsl63\emPath_bc\Dll
set=HRRPC_B=c:\Nsl63\emPath_bc\Dll\hrrpc_b32.dll
set=DBIO_B_DLL=c:\Nsl63\emPath_bc\Dll\dbio_odbc.dll
set=DBIO_B=ODBC
set=HRSYSCONFIG=c:\bowpgm\demo63Sql\rpc\sysconfig_emPath63sql.bat
set=HRDATACONFIG=c:\Nsl63\emPath_bc\rpc\dataconfig.bat
set=RSILOGFILE=c:\Nsl63\emPath_bc\Logs\rsitrace.log
set=SP_RDB_ERROR_FILE=c:\Nsl63\emPath_bc\Logs\database_errors.log
set=ROSSPYHR=xxxxxxxx/xxxxxxxx/xxxxxxxx
set=datadrive=c
set=appdrive=c |
(3.3.4) Open a DOS prompt
(3.3.5) run the manual setup batch file
(3.3.6) type the specific statements to test your program. For example:
(SET dd_RPT_PR852=%HRRPTDIR%\pr852.rpt)
(if exist �_RPT_PR852% del �_RPT_PR852%)
(pr852.exe)
(4) Question: Of course a command file exist for each of the programs.
Response: Normally a command procedure exist for each custom program or set of related programs.
*** Overall notes on the subject of compiling and testing on the business tier in an emPath configuration
Note that it is possible to move away from COBOL and develop most of your reports and/or interfaces using SQL scripts.
Note that if you have a significant number of customs my recommendation is to have a sperate test and a production server environments.
Note that if you have multiple developers I recommend the use of Microsoft VSS to control the source.
Note that you will be developing much more than just executables. You will also need to consider control of command procedures, SQL scripts, sort control files, FTP control files, email distribution batch files, windows Script Hosting (WSH) files such as VB scripts, and others. I recommend you consider the examples shown in article 10007.
Note that one of the examples, in article 10007, show how to use embedded SQL in a MicroFocus COBOL program. Following is a screen print showing part of that example:
