Chapter 4: Publishing Applications

The UNIX Option enables you to create applications on Net Express, and then publish them on a UNIX system. Application development is therefore off-loaded from the UNIX environment, enabling you to use the tools and facilities provided by Net Express. The publishing of applications is handled by the Net Express Publisher. All source-code management occurs on the PC, and is transparent to Publisher.

Publisher

Access to Publisher is provided through the UNIX menu in the Net Express Integrated Development Environment (IDE). If the UNIX Option has been installed, the UNIX menu contains the following options that enable you to publish an application:

Note: You cannot publish to a UNIX system applications that have been generated using the Net Express Data Access Wizard.

Using Publisher

To publish an application on the UNIX system, click on UNIX, Publish, to publish to the specified server only those source files modified since the last publish, or Publish All, to publish all of the files in the project.

If any of the directories you specified on the Server Settings dialog cannot be found on the server, you are asked if you want the Publisher to try to create them. If you do not want the directory created, or the directory creation fails, the publish operation fails. You need to check your server settings and/or create the directory manually.

If you checked Source Verify on Publish on the Server Settings, all source files in the project are verified in order to check that none of the files have been modified on the server. If any of the files have been modified, you are informed of this and have the option of continuing or stopping the publish.

Note: The source verify option performs CRC32 checking on the source files. This CRC checking can detect changes very reliably; however, it requires that the entire file is read. This can be a lengthy process, and you should only enable this option if you operate in an environment where changes to the files on the UNIX system are likely.

If you change any settings associated with the project and then click Publish, all of the files are published to ensure that the new settings are enabled.

The progress of a publish operation is monitored in the Output window of the Net Express IDE.

Publishing CGI Programs

Publishing a CGI program involves some extra steps that you should be aware of.

Note: Although Publisher can handle the publishing of CGI programs to your UNIX system, you should be aware of other factors you might need to take into account when deploying a CGI application on a UNIX system. You are advised to read the following sections in your CGI-based Applicationsbook:

The following steps give an overview of publishing CGI applications:

  1. Use the UNIX Option Setup dialog (click UNIX, Setup) to specify the server settings. You should also specify that the application is a CGI application by checking CGI Support in UNIX Option Setup.

    Within the CGI program, Form Designer specifies the filenames for the forms in upper case, so make sure that filename mapping is configured correctly. The ACCCGI module can only find the files if they have a lower-case .htm extension . Upper case .HTM or lowercase .html will not work.

  2. Ensure that in the Net Express project definition for the CGI application, the application will be compiled as a system executable (.exe) file.
  3. Click Publish on the UNIX menu. This copies the application files, the required preprocessor, and run-time support modules to the remote system, and modifies the build process.

    If your HTML files are in the source pool, they are transferred to the UNIX system as well. You will probably need to modify the HTML files (either manually or by using the search/replace facilities of the Publisher) so that they point to the URL of the CGI trigger program (see next step). The path to the trigger is dependent on the web server configuration.

  4. Create a trigger program (usually a shell script) on the UNIX system to run the CGI. You can use the mfenv.sh shell script created by Publisher. In this case, the complete trigger would be:
    #!/bin/sh
    ./mfenv.sh cgiapp 

    Save the trigger.

    Note: You do not need to do this step if you are publishing to Server Express.

  5. Copy the trigger file, and all application and HTML files to the required directories on your UNIX system. Normal HTML files should be placed at the appropriate place on the web server. CGI executables and support files need to be executable by the web server, so should be placed in an executable location (these executable locations are controlled by the ScriptAlias configuration parameter for most UNIX web servers such as NCSA or Apache).

    The files can be automatically copied to the correct place if you:

  6. Make sure the files can be read by all users; for example, change the file permissions: chmod +r *.htm.

You can alias your build directory to the CGI directory; this can be useful for making quick changes, as you do not have to copy files from directory to directory.

You can enter commands in the Post-Build Command field of the Setup dialog to copy files to the correct CGI directory.

When you publish a CGI application, the run-time support module ACCCGI.int is copied to your build directory where it is recompiled and linked to your CGI application. If you want to publish your application as .int files or .gnt files, you will need to manually rebuild the Acccgi run-time support module on the UNIX system. If you do this, you need to ship the Acccgi module with your application.

Publishing Java and Enterprise JavaBeans Applications

This section describes the additional steps you need to carry out when publishing an application that contains Java or Enterprise JavaBeans. The steps are exactly the same for Java and Enterprise JavaBeans; Net Express automatically determines the type of application and tailors the publishing details accordingly. Publishing a COBOL bean automatically creates all required files on the UNIX system, including .class and JAR files.

Before publishing any application including Java or Enterprise JavaBeans, you need to specify the details of the Java environment on the UNIX system. You do this using the .mfenv file, as described in the section Environment Variables.

The exact settings of the environment variables you need to set in .mfenv depend on the platform you are using. The list below describes the required settings in generic terms. See your Server Express documentation for example settings for the different platforms.

Note: If the settings you need to include in your .mfenv file include an embedded environment variable, you must surround the environment variable's name with parentheses. For example, instead of adding the following to .mfenv:

export PATH=$JH/bin:$PATH

you should use:

export PATH=$(JH)/bin:$(PATH)

Net Express IDE Settings and Publisher

Several settings in the Net Express IDE affect the operation of Publisher.

Compiler Directives

Compiler directives set in the Project, Properties, Project Directives dialog are used by Publisher to create a Compiler directives file on the UNIX system. The directives file is called projectname.dir.

The following Compiler directives, set by default by Net Express, are ignored during the publish:

Compiler directives specified in the Build Settings, Directives dialog are included in the Compiler command line on the UNIX system as check phase directives only; directives cannot be passed from this dialog to the generator phase of the UNIX compilation process.

Entry Points

For system executable files published to the UNIX system, entry points are defined by Entry Point Name in the Link tab of the Project, Build Settings dialog.

Environment Variables

The remote shell server on UNIX does not execute the standard system initialization files such as .profile, .cshrc, .kshrc, and so on, and only provides a minimal set of environment variables. In order to modify, or specify additional, variables in the environment to which you are publishing, put them in the file .mfenv. You can define .mfenv files in both your $HOME directory, and in the build directory. In effect, the .mfenv file in the $HOME directory acts as a global file. When a project is published, the UNIX Option looks for an .mfenv file in the $HOME directory; if the file is found its environment variables are added to the build environment. The UNIX Option then looks for an .mfenv file in the build directory; if the file is found its environment variables are added to the build environment.

An .mfenv file is a subset of the UNIX Bourne shell and can contain:

If value refers to another environment variable:

For example:

MYPATH=$PATH
$PATH is not expanded. The environment variable MYPATH is set to the literal value $PATH
MYPATH=$(PATH)
The current environment is examined for a variable called $PATH. If it is found, it is expanded and replaces the value ${PATH}. If it is not found, it is assumed to be an empty string.
MYPATH=$(PATH:="/usr/mybin")
Not supported. Attempts to find an environment variable called PATH:="/usr/mybin"; this fails and is replaced by an empty string.

System Copyfiles

Some COBOL components call system copyfiles when you build an application. On Net Express, all of these system copyfiles are stored in one place (Net Expess\Base\Source). On COBOL for UNIX, however, the system copyfiles are stored in a number of directories, and might have the extension .cpy or .CPY.

When an application is published to the UNIX system, system copyfiles are not copied to the UNIX server, as COBOL for UNIX has to use its specific system copyfiles. During the Publish operation a message is displayed in the Publish pane of the IDE informing you that the system copyfile has not been copied.

Publisher cannot dynamically search for these system copyfiles on the UNIX system, so assumes that they are in the directory $COBDIR/cpylib. The Makefile created by Publisher on the UNIX system expects system copyfiles to be in this directory.

Most system copyfiles are in $COBDIR/cpylib, and should cause no problems. However, if your build fails due to a problem locating a required system copyfile, you should copy the system copyfile to the directory $COBDIR/cpylib and rebuild the application using the make command. Your build might also fail if the name of the system copyfile used on Net Express is in a different case to that on COBOL for UNIX. In this case, also rename the file; alternately, use the filename mapping facility of Publisher Set-up.

Publishing Applications to AIX

You need only read this section if:

If this is the case, you must have an export file for the shared library you are trying to create. This file is not created automatically. The export file is a standard part of the AIX Linker and should contain one exported symbol per line. The name of the export file is the basename of the target with the file extension .exp.

For example, if you have a project that creates a shared library called mylib.dll, that contains prog1.obj and prog2.obj; there is only one valid entry point, called prog.

To publish to AIX, you would need to have a file called mylib.exp. This file would be a text file with one line containing the text "prog". If you add this to your project it is transferred automatically to AIX at each publish. Alternatively, you could just maintain the file on the AIX system.

Note: The export file is only required for AIX; it is not needed if you publish to any other UNIX system.

Using the State Maintenance Routines

The state maintenance library routines (MF_CLIENT_STATE_n) enable you to create an Internet application which can store user and application state information on the web server. If you have used these routines in an application, then you need to ensure that the run-time support module for these routines is published to the UNIX system along with your application.

To do this, copy the filesstate.int from Net Express\Unix\CGI-SUP into your project. When you publish your application, sstate.int will also be published to the UNIX system.


Copyright © 2007 Micro Focus (IP) Ltd. All rights reserved.