| Using COBSQL with Database Applications | Installing SCP and Samba | |
This chapter describes:
It is very common for CGI applications to be located at various places on the filesystem. For example, a CGI program might need to be in a cgi-bin directory, static HTML pages in another directory and forms in yet another directory.
One easy way to handle this is to use the logical directory feature. Define
a couple of names on the Logical Directories dialog, say HTML Pages
and HTML Forms. Display the File Mapping Configuration
dialog and assign these logical names to the various HTML files. Remember, you
can select multiple files by specifying wildcards or by shift-clicking.
On the Server Settings, Directories tab, enter the correct physical directories that will contain your HTML pages and HTML forms; the files will in future be automatically copied there.
The CGI program itself is always built in the build directory. To have this automatically placed in the correct location, you need to specify a postbuild command in the Server Settings, Postbuild tab.
The UNIX Option search/replace feature uses regular expressions and is very powerful; however, you need some experience to get the best use from it. The best way to get this experience is to experiment, or get advice from someone who has used regular expressions before, or both.
If you are just beginning to use the search/replace feature, try using literals to start with. This just performs a direct text to text replacement.
What is probably hardest to understand is the way in which regular
expressions handle repeating characters. All of the repeating metacharacters (*+?)
operate on the previous regular expression; they do not mean anything by
themselves. Remember that without using parentheses to group a regular
expression, the previous regular expression is just one character. If you are
used to filename-style patterns, this can be confusing. Make sure you read and
understand the examples in the appendix Regular
Expressions.
The Server Control Program (SCP) must be installed on any UNIX system to which you want to publish applications, as it provides the interface between NetExpress and UNIX. If you do not install SCP, you cannot publish your application. See the appendix Installing SCP and Samba for details.
If you receive a message indicating that the server refused to execute the
scp command, check your .rhosts settings. See the appendix
Installing
SCP and Samba for details of how to configure this.
This is caused by a difference in the COBOL functionality between NetExpress and COBOL for UNIX. On NetExpress, it is possible for a program to call a .dll file directly. On COBOL for UNIX, the shared object must be linked to the executable (or run-time system) for it to be accessible.
Note: Server Express enables shared objects to be called directly, in the same manner as NetExpress.
To publish such an application to UNIX you need to trick the IDE into creating a dependency between the executable module and the .dll file so that when the application is published, this dependency is spotted and the shared object linked to the executable correctly.
The following instructions assume that you have one .dll file which is called by one .exe file within the same NetExpress project. The techniques used apply equally to multiple .dll files across multiple projects.
The build area is intended to be used by one user only. The lock on the build area is there to enforce this
The main problem with a shared build area is that source code changes made by one person might become intermingled with source code changes made by another person in the same build area. This could result in anything from failed compilations to subtle errors.
If you really do need to share a build area with a co-worker, it is recommended that you set-up a common user ID that you can both use. It is highly recommended that you use a source code control system to keep your changes in synchronization. If you enable the Source Verify on Publish option on the Server Settings tab, Publisher informs you of any files that differ on the server in comparison to the version the UNIX Option expects.
To change a build area from one user ID to another, the user who currently owns the lock must unlock the area using the Server Lock dialog. Before the new user can successfully publish, it is likely that the ownership of the files in the build area will need to be manually changed from the old user to the new user. Depending on your UNIX system this might require root access.
During a publish operation you might receive errors telling you that the application has not been successfully built due to Publisher being unable to find system copyfiles on the UNIX system. If this occurs you will have to copy the system copyfile to the directory $COBDIR/cpylib. In certain cases, you might also have to change the case of the UNIX system copyfile extension (for example, a copyfile might have the extension .cpy, which might need to change to .CPY).
See the section System Copyfiles in the chapter Publishing Applications for details.
If your CGI application is not working as expected, check the following:
chmod +r *.htm.You are also advised to read the following sections in your Internet Applications (PIpubb03.htm) book:
Copyright © 1998 Micro Focus Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| Using COBSQL with Database Applications | Installing SCP and Samba | |