Running and Testing Converted Code¶

Running and Testing Converted Code

The purpose of this chapter is to provide a simple guide to getting the converted application running. The instructions are focused on the minimum necessary to run the application for testing. The server and client configurations used for this purpose are not intended for production use, nor are they expected to be suitable for all environments. As an example, there are configuration changes that may be needed to support internationalization requirements such as number formats (see the Internationalization chapter), but such configuration options are not discussed in this chapter. For complete and comprehensive details on how to configure, execute and administer the runtime for testing or production use, see the book entitled FWD Runtime Installation, Configuration and Administration Guide.

Prerequisites¶

The following must have been successfully completed before the converted application can be executed:

FWD runtime environment is installed for both the client and the server. See the Development Environment Setup chapter of the Developer Guide or use the content of part 2 of the Installation Configuration and Administration Guide book.
The relational database to be used is installed. See the Database Setup and Data Migration chapters.
The application was successfully converted (see the Running Conversion chapter) and is fully compiled as a Java archive or jar file (see the Building Converted Code chapter).
The specific database instances are created and each has successfully had its data imported. See the Data Migration chapter.

Determine Application Entry Point¶

The FWD server must be configured with the default entry point for the application. In the Progress 4GL environment, this should be a known procedure filename. For example, assume that there is a program named menu/app-start.p which is the primary application entry point for users. This is the program that is first run in the Progress 4GL runtime to start the application.

In FWD, the replacement for this program has a new name. This name is a Java class name, which must be determined so that the correct value can be specified to the FWD server.

The easiest way to find the Java class name is to inspect the Progress AST associated with the source file. In this case, examine the first 8 lines of the XML file $P2J_HOME/src/my_app/menu/app-start.p.ast:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!--Persisted AST-->
<ast-root ast_class="com.goldencode.p2j.uast.ProgressAst">
  <ast col="0" id="17179869185" line="0" text="block" type="BLOCK">
    <annotation datatype="java.lang.String" key="package-base" value=""/>
    <annotation datatype="java.lang.String" key="pkgname" value="com.acme.my_app.menu"/>
    <annotation datatype="java.lang.String" key="classname" value="AppStart"/>
    <annotation datatype="java.lang.String" key="relative-name" value="menu/app-start.p"/>

The unqualified name of the converted Java class is found in the value attribute of the annotation element with the key=”classname” attribute . In this case, we see the class name is AppStart.

To determine the fully qualified class name, simply prepend the package name to the class name, using the dot (.) separator. The package name is found in the value attribute of the annotation element with the key="pkgname" attribute. In this case, we see the package name is com.acme.my_app.menu, resulting in a fully qualified Java name of com.acme.my_app.menu.AppStart.

Gather Database Configuration Information¶

Certain information about your installed database(s) is required to configure the FWD server. Depending on which RDBMS is used, you will need to gather the following information for each database to which your application will connect:

For the databases managed by PostgreSQL, you will need to determine:
- Host name or IP address. It is assumed this host is available on a network which is accessible to the FWD server host machine. For testing purposes, the FWD server host and database host often are the same machine, in which case localhost is an acceptable value.
- Number of the network port on which the PostgreSQL cluster is listening. By default, this is port 5432, but it may be different, depending upon how the cluster was configured upon installation. A port service name (if one has been defined) is also acceptable.
- Database name. This is the name of the database in the PostgreSQL cluster, which you assigned when you created the database (see Data Migration chapter).
- PostgreSQL user name. This is the name of the PostgreSQL account which the application server will use to establish connections to the database. All connections are made using this account; it is assumed more granular security is administered at the application server. This account should not have superuser rights in a production installation, so using the postgres account is not advisable. Please refer to the Database Setup chapter and to the PostgreSQL user manual for instructions on creating a user account.
- PostgreSQL account password. This is the password associated with the PostgreSQL user account noted above.
For the databases managed by H2, you will need to determine:
- Database access mode. For each database, you will need to determine if it will be managed in embedded mode or it will be managed by a separate H2 server. The JDBC connection URL will have to be built depending on this access mode.
- Host name or IP address. If the database is managed by a separate server, you will need to determine the host name or the IP address of the machine running this server. It is assumed this host is available on a network which is accessible to the FWD server host machine. For testing purposes, the FWD server host and database host often are the same machine, in which case localhost is an acceptable value.
- Number of the network port on which the H2's TCP server is listening. By default, this is port 9092, but it may be different, depending upon how the H2 server was started. A port service name (if one has been defined) is also acceptable.
- Database name. This is the name of the database which you assigned when you created the database (see Data Migration chapter).
- H2 user name. This is the name of the H2 account which the application server will use to establish connections to the database. All connections are made using this account; it is assumed more granular security is administered at the application server. This account should not have superuser rights in a production installation, so do not use the account specified at database creation. Please refer to the Data migration chapter and to the H2 user manual for instructions on creating a user account.
- H2 account password. This is the password associated with the H2 user account noted above.

Edit the Server's Directory¶

The majority of the FWD server's configuration is stored in a file called the “directory”. For the purposes of getting a test environment running, all of the values to be edited reside in that directory file.

The test environment which will be used exists in the FWD project. If that part of the project code was not installed previously, it should be unpacked now. The path is testcases/simple/* within the FWD archive.

Inside this directory tree, there is a simple runtime configuration that allows a server to be started for testing. The directory file to be edited is named $P2J_HOME/p2j/testcases/simple/server/directory.xml. Open that file in a text editor, preferably one that makes it easy to edit XML.

Edit the Default Entry Point¶

Before you can run the converted application, the FWD server must know which converted Java program it will launch by default when a FWD client connects to it. The simplest way to configure this is to set the default "entry point" program in the directory file.

Search for this section in the directory (searching on the text “p2j-entry” should be sufficient):

<node class="string" name="p2j-entry">

  <node-attribute name="value" value="com.goldencode.testcases.Ask.execute" />

</node>

The value attribute specifies the fully qualified name of the Java class name with a suffix of .execute appended. “execute” is the name of the Java method in the converted code which corresponds to the external procedure of the original file. Replace the com.goldencode.testcases.Ask in the value attribute of the node-attribute XML element with the fully qualified name as found previous in the Determine Application Entry Point section above. In the above example, the resulting section of the directory will appear like this:

<node class="string" name="p2j-entry">

  <node-attribute name="value" value="com.acme.my_app.menu.AppStart.execute" />

</node>

Merge File System Configuration¶

The FWD server must interpret some file system related values at runtime. This is usually due to the need for supporting a dynamic behavior of the 4GL. For example, when the VALUE() construct is used to evaluate a string expression and use the result as a filename, the filename string cannot be parsed at conversion time, but must wait until runtime for evaluation. Such runtime processing can be dependent upon knowing how the file system worked on the original Progress 4GL system. It is possible that the source system and target systems have the same file system behavior, but it is also possible that they differ. To resolve this, the server's directory contains a section of file system configuration which needs to be updated to match the values from the source system.

As part of the conversion processing, certain global configuration parameters (see the Project Setup chapter) are read and an XML input file is created with the contents to be merged into the file system configuration section of the directory. The file will be found in the project root as $P2J_HOME/file_sys.xml.

In the directory file, find the section by searching on the text “file-system”. The section will look like this:

<node class="container" name="file-system">
  <node class="boolean" name="case-sensitive">
    <node-attribute name="value" value="TRUE"/>
  </node>
  <node class="string" name="propath">
    <node-attribute name="value" value="/my/original/apps/path"/>
  </node>
  <node class="string" name="pkgroot">
    <node-attribute name="value" value="com.goldencode.testcases"/>
  </node>
  <node class="string" name="file-separator">
    <node-attribute name="value" value="/"/>
  </node>
  <node class="string" name="path-separator">
    <node-attribute name="value" value=":"/>
  </node>
</node>

In an editor, open the file_sys.xml created during the conversion. For each of the entries in this section of the directory, make sure that the value is replaced with the value as specified in the file_sys.xml. A sample file_sys.xml will look something like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<merge path="/server/default/runtime/default/">
  <node class="container" name="file-system">
    <node class="string" name="pkgroot">
      <node-attribute name="value" value="com.goldencode.testcases"/>
    </node>
    <node class="string" name="propath">
      <node-attribute name="value" value="/home/projects/my_app/:/home/projects/my_app/src/app_base_dir:/my/original/apps/path"/>
    </node>
    <node class="string" name="path-separator">
      <node-attribute name="value" value=":"/>
    </node>
    <node class="string" name="file-separator">
      <node-attribute name="value" value="/"/>
    </node>
    <node class="boolean" name="case-sensitive">
      <node-attribute name="value" value="true"/>
    </node>
  </node>
</merge>

The section inside the <merge> element is almost a one-for-one replacement of the section in the directory. It is built directly from the values in the global configuration parameters pkgroot, propath, path-separator, file-separator and case-sensitive. Review the Global Configuration section of the Project Setup chapter for details on the meaning, usage and formatting of these values.

The only change that is needed is to remove the conversion-specific entries in the propath. During conversion, the propath must have a combination of paths that map to the location of the code on the converted system as well as the entries that were necessary on the original source system. This is necessary to allow files to be converted from absolute forms into the properly matched relative form. In particular, some parts of the conversion will deal with filenames that are local to the conversion system and other parts of the conversion deal with filenames as encoded inside source files (which can contain paths that are specific to the original system). For this reason, it is recommended to specify the propath entry in the p2j.cfg.xml as:

${P2J_HOME}:${P2J_HOME}/src/my_app:/my/original/apps/path

If the $P2J_HOME is /home/projects/my_app/ then the value found in the file_sys.xml would appear like this:

/home/projects/my_app/:/home/projects/my_app/src/app_base_dir:/my/original/apps/path

Remove the conversion-specific portion before merging the file_sys.xml into the directory. Here is the portion to remove:

/home/projects/my_app/:/home/projects/my_app/src/app_base_dir:

Configure Persistence Services¶

The simple directory that ships with FWD has persistence services disabled by default, to enable you to get up and running quickly with simple test cases, without having to install and configure a database. As soon as you convert a test case which uses database language statements, however, you will need to configure persistence services in order to run the converted program.

Activate Persistence Globally¶

The first step is to activate a global setting to tell the FWD server that it should initialize the persistence framework. This is done by changing the setting for the directory path server/standard/persistence/active. To find this node quickly, search the directory for the keyword persistence, and you should see the following:

<node class="container" name="persistence">
  ...
  <node class="boolean" name="active">
    <node-attribute name="value" value="FALSE"/>
  </node>
</node>

Change this to:

<node class="container" name="persistence">
  ...
  <node class="boolean" name="active">
    <node-attribute name="value" value="TRUE"/>
  </node>
</node>

Alternatively, you can remove the active sub-node entirely, which will have the same effect as setting its value to TRUE. In the absence of this node, the FWD server initializes persistence services by default, since any non-trivial application is expected to require database access.

Specify the Location of DMO Index Data¶

During conversion of your project's database schemas (including the schemas of all temp-tables in your application), a file named dmo_index.xml is generated in the dmo sub-package of your application's converted source code. This file contains information extracted from the Progress schemas, which is needed by the FWD runtime environment to ensure your converted application behaves as the original application did.

Information in the dmo_index.xml is not available elsewhere (such as in the converted database schemas), so the FWD server must be configured to locate this file at runtime. This is accomplished with another directory setting (with the path server/default/dmoindex). To find the corresponding node quickly in the simple directory provided with the FWD project, search for the keyword dmoindex, and you should see:

<node class="string" name="dmoindex">
  <node-attribute name="value" value="com/goldencode/testcases/dmo/dmo_index.xml"/>
</node>

Set the value com/goldencode/testcases/dmo/dmo_index.xml to the appropriate location of the dmo_index.xml file which was generated for your application. The location you specify should be relative to a location on the CLASSPATH used when you launch the FWD server, since this file will be stored in your application's primary jar file (i.e., the jar file containing the converted business logic of your application).

Configure Databases In Use¶

Each physical database to which a FWD server connects automatically must be configured in the directory file. By “connect automatically,” we mean to include those databases which are always available to a FWD server, and to exclude “remote” databases to which an application may establish a transient connection programmatically, using the converted 4GL CONNECT language statement. A FWD server is said to be authoritative for the database(s) to which it connects automatically.

It is only necessary to configure a database in the directory of the FWD server which is authoritative for that database. For transient connections, the FWD server requesting the connection will interrogate the remote FWD server which is authoritative for the target database on the fly for any necessary configuration information. Thus, it is not necessary to configure remote databases in each server's directory file.

The directory node with the path server/standard/database/{database name} contains all the information a FWD server instance needs to connect to and interact with a physical database. For each permanent database, the parameter {database name} represents the physical name of your PostgreSQL or H2 database. A special node of this type is configured for use with converted temp-tables. In this case, the placeholder {database name} is replaced with the reserved name _temp.

As noted above, persistence services by default are disabled globally in the simple server environment provided by the FWD project. The file contains two database configurations, server/standard/database/p2j_test (a sample, permanent database), and server/standard/database/_temp (the embedded H2 database used for temporary table support). By default, the former is disabled (commented out), and the latter is enabled. The reasoning is that if you enable persistence services globally, there is no additional installation or configuration required to use temp-tables in your test cases. To use the p2j_test database, on the other hand, requires installation and configuration of an external database. In other words, you can get a flavor for basic database use in a converted test case with minimal effort by enabling persistence services and limiting your database use to temp-tables only.

The drawback to these defaults, however, is that if you have converted a program which uses database language statements with permanent tables only (i.e., no temp-tables), you must comment out the server/standard/database/_temp node in the directory entirely. Otherwise, the FWD server will error out during startup.

In the event you need to run a converted program which accesses persistent (i.e., non-temp-table) tables, you will need to un-comment the server/standard/database/p2j_test node and make some adjustments. The un-edited node looks like this:

<node class="container" name="p2j_test">
  <node class="container" name="p2j">
    <node class="string" name="schema">
      <node-attribute name="value" value="p2j_test" />
    </node>
    <node class="boolean" name="load_at_startup">
      <node-attribute name="value" value="true" />
    </node>
    <node class="string" name="embedded-collation">
      <node-attribute name="value" value="en_US_FWD" />
    </node>
  </node>
  <node class="container" name="hibernate">
    <node class="string" name="dialect">
      <node-attribute name="value" value="{sql_dialect}" />
    </node>
    <node class="container" name="connection">
      <node class="string" name="driver_class">
        <node-attribute name="value" value="{jdbc_driver}" />
      </node>
      <node class="string" name="url">
        <node-attribute name="value" value="{jdbc_url}" />
      </node>
      <node class="string" name="username">
        <node-attribute name="value" value="{username}" />
      </node>
      <node class="string" name="password">
        <node-attribute name="value" value="{password}" />
      </node>
      <node class="integer" name="prepareThreshold">
        <node-attribute name="value" value="1" />
      </node>
    </node>
    <node class="boolean" name="show_sql">
      <node-attribute name="value" value="false" />
    </node>
    <node class="container" name="c3p0">
      <node class="integer" name="max_size">
        <node-attribute name="value" value="10" />
      </node>
      <node class="integer" name="min_size">
        <node-attribute name="value" value="2" />
      </node>
      <node class="integer" name="timeout">
        <node-attribute name="value" value="120" />
      </node>
      <node class="integer" name="idle_test_period">
        <node-attribute name="value" value="60" />
      </node>
      <node class="integer" name="acquire_increment">
        <node-attribute name="value" value="2" />
      </node>
      <node class="boolean" name="validate">
        <node-attribute name="value" value="false" />
      </node>
    </node>
    <node class="container" name="cache">
      <node class="boolean" name="use_second_level_cache">
        <node-attribute name="value" value="false" />
      </node>
      <node name="use_query_cache" class="boolean">
        <node-attribute name="value" value="false"/>
      </node>
    </node>
    <node class="container" name="jdbc">
      <node class="integer" name="fetch_size">
        <node-attribute name="value" value="1024"/>
      </node>
    </node>
  </node>
</node>

The items highlighted above must be changed to values appropriate to your database and RDBMS used. The first entry identifies the physical database being configured:

<node class="container" name="p2j_test">

Change p2j_test here to the physical name of the database your application uses.

The next entry specifies the name of the schema associated with this database:

<node class="string" name="schema">
  <node-attribute name="value" value="p2j_test" />
</node>

This is derived from the name attribute of the cfg/schema/namespace element in $P2J_HOME/cfg/p2j.cfg.xml. Usually, it matches the physical database name. Change this to the appropriate schema name for the target database as configured for your project.

The next two highlighted entries determine the database that will be managed by H2 or PostgreSQL. These specify the JDBC driver and the SQL dialect:

    <node class="string" name="dialect">
      <node-attribute name="value" value="{sql_dialect}" />
    </node>
    <node class="container" name="connection">
      <node class="string" name="driver_class">
        <node-attribute name="value" value="{jdbc_driver}" />
      </node>
      …
    </node>

The {sql_dialect} and the {jdbc_driver} entries both represent full class names which implement the SQL dialect and the JDBC driver. If the database is managed by PostgreSQL, the {sql_dialect} needs to be replaced with the com.goldencode.p2j.persist.dialect.P2JPostgreSQLDialect class name; also, the {jdbc_driver} needs to be replaced with the org.postgresql.Driver class name. When H2 is used, the {sql_dialect} will be replaced with the com.goldencode.p2j.persist.dialect.P2JH2Dialect class name and the {jdbc_driver} with the org.h2.Driver class name.

The remaining entries which require change provide the persistence subsystem with the information necessary to connect to your database:

<node class="string" name="url">
  <node-attribute name="value" value="{jdbc_url}" />
</node>
<node class="string" name="username">
  <node-attribute name="value" value="{username}" />
</node>
<node class="string" name="password">
  <node-attribute name="value" value="{password}" />
</node>

Here you will need the information you collected for the Gather Database Configuration Information section above. First, we will need to determine how the JDBC connection URL will look. When PostgreSQL is used as a backend, the {jdbc_url} needs to be replaced with an URL appropriate to your database, in the form:

jdbc:postgresql://{hostname | IP address}[:{port number}]/{database name}

Note that the port number is optional in the URL. If absent, the FWD server will attempt to connect to the database on the default PostgreSQL port (5432) when the PostgreSQL server is used. If the database is managed by H2, the URL will be different, depending on whether the database is accessed in embedded mode or via the H2 TCP server, and if embedded, whether the database backs the _temp database (i.e., temporary tables only), or a permanent database (i.e., persistent storage).

In embedded mode for a permanent database (i.e., one of your application's persistent databases), the URL will look like this:

jdbc:h2:{database name};MVCC=true;MV_STORE=false

{database name} should be replaced by the file system name (including absolute or relative path) of the file containing the H2 database, but without the .h2.db extension.

Example 1. If your database file is named hotel.h2.db and it resides in the /opt/data/ directory, the URL should be:

jdbc:h2:/opt/data/hotel;MVCC=true;MV_STORE=false

Example 2. If your database file is named hotel.h2.db and it resides in a db directory which is a sibling of the current working directory from which the FWD server is launched, the URL should be:

jdbc:h2:../db/hotel;MVCC=true;MV_STORE=false

Embedded mode troubleshooting tip: Note that when H2 runs in embedded mode, a database is created when the first connection is made, if it does not already exist. If you try to run FWD with an embedded H2 database and the server fails to start, but a small (empty) database is created in the file system at the location specified by your database connection URL, it suggests the location of your real, migrated database and the location specified by your database connection URL do not match. If you specify a relative location in your URL, be sure it is relative to the current working directory from which you launch the FWD server JVM process.

If other converted applications need to connect programmatically to an H2 database, embedded mode can not be used. This is because, when the application connects to this remote FWD server, it will need to establish a connection directly to the physical H2 database, in addition to its connection to the FWD server. So, in these cases, the database access will need to be done via an external H2 server (i.e., started in TCP mode), and the connection URL will look like this:

jdbc:h2:tcp://{hostname | IP address}[:{port number}]/{database name};MVCC=true;MV_STORE=false

Note that the port number is optional in the URL. If absent, the FWD server will attempt to connect the database on the default H2 port (9092). A special URL setting is the MVCC parameter. At any time a H2 physical database is used, Multi-Version Concurrency Control must be activated. Note that URL parameters are different than the ones used when importing the data in the database. See the Data Migration chapter for details.

The next settings are the user name and password, used to access the database. Replace {username} and {password} with the appropriate values.

Start the FWD Server¶

Once the directory edits are complete, the FWD server can be started. The converted application runs inside of the FWD server. Each user has a unique security context and dedicated threads for processing. If the server is not started then the application is not running.

Change the current working directory of the command shell to the location of the FWD server.

cd $P2J_HOME/p2j/testcases/simple/server

At a minimum, the classpath of the server must be set properly. That classpath must include both the FWD jar file as well as the converted application jar file.

If the application jar file is not directly available on the server system, copy the converted application jar files from the conversion project build directory on the conversion system into a directory on the application server system. That directory can be the same as where the FWD jars reside or it can be a different directory.

Assuming the converted application jar file is found in $P2J_HOME/build/lib/my_app.jar and the FWD jar file is found in $P2J_HOME/p2j/build/lib.p2j.jar, then the proper classpath will be $P2J_HOME/build/lib/my_app.jar:$P2J_HOME/p2j/build/lib.p2j.jar.

Given this classpath value, this command will start the server on the default port:

./server.sh “-z$P2J_HOME/build/lib/my_app.jar:$P2J_HOME/p2j/build/lib.p2j.jar”

To look at other options (including how to enable debugging), run the script in help mode:

./server.sh -?

The output would be expected to be similar to this:

Usage: ./server.sh [-dyptksw1] [-zcp] [-hheap] [-llog] [-ccfg] [-iinst]

Where:

d       = enable JVM debug mode (debugger port will be set as 2080 + instance #)
y       = in JVM debug mode enable, suspend the JVM on startup (does not suspend by default)
p       = enable JVM hprof (profiling output to gc.log)
t       = test mode (displays the command but doesn't execute)
k       = kill mode (shuts down the specified/default instance)
s       = status mode (displays the status of the specified/default instance)
w       = wait mode (does not return until the specified/default instance is STATUS_RUNNING)
1       = enable C1 HotSpot compiler (client compiler for the JVM)
cp      = override the classpath which would otherwise be set to ../../../build/lib/p2jadmin.jar:../../../build/lib/p2j.jar:
heap    = set JVM max heap size (must be an integer number of MB)
log     = log file name (all STDERR is redirected to this file, defaults to ./server.log)
cfg     = config file name (FWD bootstrap config file name, defaults to server.xml)
inst    = server instance number (0..9, assigns the FWD server port, defaults to 0)

Once the server has started, the command shell will hang there running the server process. If it doesn't hang there, then the server startup failed. The log file should have information regarding the reason for the failure. In all likelihood either the runtime environment is not installed properly or the directory file contains problems.

If the server does hang there, use a different command shell to check if the server started properly. This can be seen by watching the server's primary log file:

tail -f $P2J_HOME/p2j/testcases/simple/server/server.log

The server is fully started when you see text similar to this:

[07/18/2008 15:19:18 EDT] (SessionManager.listen():INFO) {00000000:00000001:standard} Server ready

Satisfy the Application's Client-Side Dependencies¶

Progress 4GL applications can access a range of platform-specific facilities. The most common of these facilities are file-system access (reading/writing files using streams, manipulating the file-system to move or delete files, accessing file-system meta-data), process launching (running shell/command prompt programs for interactive use, running child processes and reading from/writing to the process via streams) and printing.

All such local system access is done on the FWD client system, not on the FWD application server. This is due to the client-centered design of the Progress 4GL. For example, in an interactive Progress application (not on an "appserver" or in Webspeed), printing is done using specific Windows APIs (in GUI applications) or in UNIX or Linux by using child process support. In either case, the processing runs on the client side, as opposed to where the Progress database server is running.

The file-system must be setup in the structure, with the permissions and with the resources that are expected by the application. All the necessary executables (programs) must be available. Likewise, the appropriate printers must be defined/configured in the operating system. Queues and connectivity for all the printers must be setup and the printers must be turned on, attached to the system/network and ready to accept jobs.

If the application has such dependencies, these must be setup before the client is started. Once the client is started, the application will use those programs and features as needed. Since these dependencies are application-specific, the details of this setup are beyond the scope of this document.

Start the FWD Client¶

The server has now "taken over" your previous command shell. Open a new command shell.

There is a "simple" runtime configuration that allows a client to be started which is designed to connect to the "simple" server. Change the current working directory to the location of the simple FWD client:

cd $P2J_HOME/p2j/testcases/simple/client

The location of the p2j.jar file and the libTerminal.so must be specified to the client script. Normally these two files would be located in the same directory and the simple client script makes this assumption. As with previous examples, the path $P2J_HOME/p2j/build/lib/ will be the expected location for these important runtime files.

Due to the design of the FWD client as a thin presentation engine instead of a location where application logic is executed, there is no need for the client's classpath to include the application jar file. Only the FWD code is needed.

Run the FWD client using the following command (warning: do not place an ending slash on the -z parameter pathname):

./client.sh “-z$P2J_HOME/p2j/build/lib”

No login is needed. The simple server's directory is setup with "open" security (which is how Progress is always setup). In this configuration, the application is solely responsible for implementing its own authentication, authorization, access control and auditing. This is useful for test cases but it may not be used in a production environment.

The converted program should run as expected. The first screen should look just like the one in the original Progress 4GL environment for that same program (menu/app-start.p in our example). If there are any problems, you can check the ../server/server.log or ../server/stdout.log to look for server side issues. For any catastrophic, client-side issues, check client/p2j_{username}_{pid}.log (where username is your Unix user name and pid is the process ID of the client process). This file is written to the current working directory from which the client was launched. The naming convention is intended to produce a uniquely named log file across multiple runs of the client, and across multiple users on a particular workstation.

A common problem occurs when the NCURSES library is not properly patched. In such a case, the load of the libTerminal.so will fail trying to find an entry point named auto_getch_refresh. See the Patching NCURSES for details on fixing this.

Project

General

Profile

FWD

Wiki