Preparing private program packages for installation

Private program packages and third-party program packages must first be adapted to the form described below before they can be installed with the POSIX installation program:

• The product components must be available in a PLAM library.

• The PLAM library must have the product-specific name
  <prefix>LIB.<product>.<version>.[<package>]

• Executable programs must be available as L elements of the library.

• Header files, shell scripts and other components such as text files must be available as S elements of the library.

• The PLAM library must contain the following product-specific installation and deinstallation scripts as S elements:

  • INSTALL.<product>.<version>.[<package>]

  • DELETE.<product>.<version>.[<package>]

  These scripts describe the location of each product component in the POSIX file system. They also supply additional information relating to the storage area. The next section describes how the structure of these scripts.

Format of installation and deinstallation scripts

The individual lines of the installation and deinstallation scripts must have the following format:

element:selector:path:link name:access mode:user-number:group-number

The column width is variable. The colon delimiter (:) must be specified even if no value is specified. Comment lines start with “#”.

Entries for selector and access mode are explained in more detail below.

• The selector marks the installation subfunction (in alphabetical order):

  b	Create a binary file (PLAM element type X) under the specified name
  d	Create the directory indicated by the path name
  f	Create the command under the specified path name (link to element in PLAM library)
  i	Specify the installation path. The i entry must be the first statement line
  l	Create a hard link for the specified link name
  m	Create the command under the specified path name (as an LLM in UFS)
  o	Entry for files to be removed
  p	Create a procedure (element) under the specified path name
  r	Execute the script (procedure) with the specified path name
  s	Create a symbolic link for the specified link name
  u	Coded T files for iconv
  v	Entry for directories to be removed

• The access mode represents the access permission for owner, group and others (octal).

Environment variables in the installation and deinstallation scripts

You can use the following additional environment variables in installation scripts:

USER	BS2000 user ID under which installation was started.
IPATH	Installation path in the POSIX file system. If IPATH is an empty string, the installation path is equal to “/”. If no installation path was defined with :i: (see below), $IPATH will not be interpreted, i.e. the string “$IPATH“ will then be part of a path name or link name.
IUID	BS2000 installation ID Either the installation userid from the dialog mask BS2000 POSIX package installation or the BS2000 user ID from the complete file name which is returned by IMON for the Logical-ID%SINLIB of the product to be installed. The leading dollar sign is a component of the string.

Installation path in the installation and deinstallation scripts

Using the code “i”, you can specify the installation path for the components of a product in the POSIX file system. The definition of an installation path must be the first statement line in the installation script, otherwise it has no effect.

An entry of this kind has the following syntax:

:i:installpath:access mode:user-number:group-number

This means:

installpath	Complete path name of a directory in the POSIX file system.
access mode	Access permissions assigned to installpath.
user-number	POSIX user ID of the owner of installpath
group-number	POSIX group ID of the owner of installpath

It is possible to install a product several times in the POSIX file system using this mechanism.

Specifying an installation path in the installation script results in the following:

• When installing in interactive mode, this installation path is displayed in the installation mask of the POSIX installation program. You can change the installation path there as you wish. The value which appears last in the dialog mask is effective.

• When installing in batch mode, this installation path applies if the parameter file does not contain an installation path. If an installation path was specified in the parameter file in the appropriate statement line, the installation path is taken from the parameter file, see the section “Administer POSIX filesystems”.

• The variable $IPATH in the installation script is replaced by the current value of the installation path. This applies to every specification of a path name or link name with the prefix $IPATH (except, of course, in the definition of the installation path).

Example

:i:/opt/C/022A10::0755:2:2      # default installpath
:d:$IPATH/bin::0755:2:2         # subdirectory
C89:f:$IPATH/bin/c89::0755:2:2  # command

It makes no sense to define an installation path in the deinstallation script. The specification :i: is ignored if it is syntactically correct.

The variable $IPATH in the deinstallation script is replaced:

• in interactive mode, by selecting the appropriate item in the deinstallation mask in which all currently installed products are listed.

• in batch mode, by the installation path which is specified in the statement line of the parameter file.

Messages, inputs and return codes in installation scripts

Shell scripts can be executed in installation scripts. Messages can be output from these shell scripts, and inputs can be made to them. Depending on the type of installation, the following applies for the inputs/output:

• In the event of installation in interactive mode, the inputs are read from the terminal and the outputs appear on the terminal, i.e. stdin, stdout and stderr are redirected to the terminal.

• In the event of installation in interactive mode, the inputs are read in from a response file. This file must be located in the directory from which the shell script is started. The name must consist of the name of the shell script plus .response.

  The outputs (stdout and stderr) are always directed to SYSOUT.

Control statements

A shell script can contain control statements which report the exit status if the return code is not 0 and determine how installation is to continue. These control statements always start with a lozenge and an exclamation point in the 1st line and can be contained at any position in the shell script.

The following control statements are possible:

#!REPORT_SHELLSCRIPT_ERROR={ON | OFF}

ON	If the return code is not 0, a message is output (default). This message has the following format: "shell script script name reports error exit value" The meaning must be described in its context in the product description. To prevent ambiguity, the return codes of the shell scripts should be in the range 128 – 255 as the POSIX shell also sends return codes.
OFF	No message is output.

#!EXIT_ON_SHELLSCRIPT_ERROR={ON | OFF}

ON OFF

If the return code is not 0, product installation is aborted. Installation of the product is continued (default).

Example

The product sample (Version 123) is installed from the product library SINLIB.SAMPLE.123. The installation script INSTALL.SAMPLE.123 contains the following lines:

:i:/tmp/sample.install::0755:2:2
sample.sh:p:SIPATH/script::0555:2:2
sample.rs:p:SIPATH/script.response::0555:2:2
#!REPORT_SHELLSCRIPT_ERROR=ON
#!EXIT_ON_SHELLSCRIPT_ERROR=OFF
:r:SIPATH/script::::