[Contents] [Prev] [Next]

Appendix I

Installing C-MOLD for Use across Multiple UNIX Platforms

This appendix describes how to configure C-MOLD to share files between two or more UNIX platforms, and how to run commands on another machine in your local area network.

Please note that you should not install C-MOLD into a directory that contains any other C-MOLD installation. This will overwrite parts of the previous installation and cause the current installation to be unstable.

Sharing Files

We suggest that your installations have the same lineage for organization, but different parent directories to avoid corruption. And in order to share files, you will need to install C-MOLD on a disk drive that is available to all desired UNIX platforms.

Configuring the multiple-platform structure

Follow these steps to create the multiple platform structure:

  1. Create a directory named cmold on a shared, NFS-mounted disk. For illustration purposes, we'll call the directory /net/pkg/cmold/.
  2. Change your current directory to the newly created cmold directory.
  3. Create a directory for each of the different platforms on which you wish to install C-MOLD. For example, create a directory named sgi for C-MOLD installed on an SGI system, and a directory named hp700 for C-MOLD installed on a Hewlett-Packard 9000 series 700.
  4. Install each C-MOLD installation in the directory that was created for each different UNIX platform. Following the previous example, we would install C-MOLD for SGI systems in the /net/pkg/cmold/sgi directory and C-MOLD for Hewlett-Packard 9000 series 700 in the /net/pkg/cmold/hp700 directory.
  5. Create symbolic links to directories that will be shared between different UNIX platforms. For example, to share the db directory within the multiple-platform C-MOLD directory structure, issue the following commands:
    $ rm -r /net/pkg/cmold/hp700/cmold98x/db
    $ ln -s /net/pkg/cmold/sgi/cmold98x/db /net/pkg/cmold/hp700/cmold98x/db
  6. Create the cm_defs.csh and cm_defs.sh files.
Following is a sample cm_defs.csh file:

if ( -x /bin/uname ) then
  set host = \Q/bin/uname -n\Q
  else if ( -x /usr/ucb/hostname ) then
    set host = \Q/usr/ucb/hostname\Q
  else if ( -x /usr/bsd/hostname ) then
    set host = \Q/usr/bsd/hostname\Q
  else if ( -x /bin/hostname ) then
    set host = \Q/bin/hostname\Q
  else if ( -x /usr/bin/hostname ) then
    set host = \Q/usr/bin/hostname\Q
  else
    echo ""
    echo "cm_defs.csh: ERROR - no uname or hostname found"
    echo ""
endif
 
if ( $?host ) then
  switch ($host)
  case watkins:
    setenv CMOLD_HOME /net/pkg/cmold/hp700/cmold98x
    breaksw
  case brookton:
  case dryden:
    setenv CMOLD_HOME /net/pkg/cmold/sgi/cmold98x
    breaksw
    default:
    echo ""
    echo "cm_defs.csh: ERROR - C-MOLD not on '$host'."
    echo ""
    breaksw
  endsw
 
endif
 
if ( $?CMOLD_HOME ) then
  source $CMOLD_HOME/cmdefs.csh
endif
 
following is a sample cm_defs.sh file:
 
if [ -x /bin/uname ]
  then
  host=\Q/bin/uname -n\Q
 
  elif [ -x /usr/ucb/hostname ]
    then
    host=\Q/usr/ucb/hostname\Q
  elif [ -x /usr/bsd/hostname ]
    then
    host=\Q/usr/bsd/hostname\Q
  elif [ -x /bin/hostname ]
    then
    host=\Q/bin/hostname\Q
  elif [ -x /usr/bin/hostname ]
    then
    host=\Q/usr/bin/hostname\Q
  else
    echo ""
    echo "cm_defs.sh: ERROR - no uname or hostname found"
    echo ""
fi
 
if [ ! -z "$host" ) then
  case $host in
    watkins)
    CMOLD_HOME=/net/pkg/cmold/hp700/cmold98x ;;
    brookton)
    dryden)
    CMOLD_HOME=/net/pkg/cmold/sgi/cmold98x ;;
    *)
    echo ""
    echo "cm_defs.sh: ERROR - C-MOLD not on '$host'."
    echo ""
    ;;
  esac
 
fi
 
if [ ! -z "$CMOLD_HOME" )
  then
    export CMOLD_HOME
    .  $CMOLD_HOME/cmdefs.sh
endif

Which files can be shared?

 Each C-MOLD installation contains files that are consistent across different UNIX platforms and can be shared, as well as files that are not consistent across different UNIX platforms and can't be shared.

Directories that can be shared

$CMOLD_HOME/bitmaps
$CMOLD_HOME/small/bitmaps
$CMOLD_HOME/dat
$CMOLD_HOME/db
$CMOLD_HOME/examples

Directories that can't be shared

$CMOLD_HOME/app-defaults
$CMOLD_HOME/small/app-defaults
$CMOLD_HOME/bin
$CMOLD_HOME/uid
$CMOLD_HOME/small/uid
Each C-MOLD installation contains a customizable database. If you plan to modify the C-MOLD database, be sure to share it among your different UNIX platforms.

Directories that should be shared

$CMOLD_HOME/db

Running Commands on Another Machine

 To run commands on another machine in your local area network, use the UNIX remote shell command. This is called rsh on some machines and remsh on others. If you're not familiar with the remote shell command, you should read the man page information to learn more about it.

Setting up your environment

The remote shell command uses two methods to make it possible to run commands on other machines without having to supply a password. One way is to set up a hosts.equiv file, usually located in /etc. This file contains a list of trusted hosts with which it shares user names. Users with accounts on both machines with the same user name will be able to use the remote shell command. The other way is to place an .rhosts file that contains similar information into your home directory. Because the exact usage of the .rhosts and hosts.equiv files varies from vendor to vendor, you should read the man pages for each of your systems for details.

The remote shell command can make your computer account less secure in that if a user breaks into your account from another trusted machine, he or she can easily get into your accounts on other machines. You should consult with your computer security staff on these concerns. In many environments, however, the local area network is set up with trust relationships among the machines to facilitate user accessibility to each machine.

C-MOLD uses the UNIX remote shell command to execute simulation jobs on another computer. Setting the CMOLD_HOST environment variable to the name of the machine to run the simulation job before starting C-MOLD enables this capability. Then when you select Run as Batch on the Control Panel's launch dialog, the job will be directed to the other machine. Note that you need proper C-MOLD licensing and to have the C-MOLD environment set up from your shell initialization file to be able to run on the other machine.

Testing the remote shell command

A simple way to test whether your C-MOLD environment is set up correctly to run simulation jobs on another machine is to try the following experiment. Right after the C-MOLD environment is set up, go to your shell initialization file (.cshrc or .profile) and add a definition for CMOLD_HOST for the remote machine's official hostname. Log out and back in again to make sure the new shell initialization occurs, then start C-MOLD. From the Control Panel's command prompt type:

$ !rsh $CMOLD_HOST cmoldlmd -status
This will start an xterm window with the output from the cmoldlmd -status command run on $CMOLD_HOST. On HP computers, the remote shell command is called remsh, so you'll need to change rsh to remsh in the above example.

If your C-MOLD environment is set up correctly, you'll see the output from cmoldlmd. If you get a message that CMOLD_HOST is undefined, it means you've forgotten to define that variable in your shell initialization file. If you get a message that login is incorrect, your remote shell setup is not correct. Check the hosts.equiv and .rhosts files. If you get a message that cmoldlmd is not found, your C-MOLD environment on the remote machine is not set up properly. Check your shell initialization file carefully and make sure the C-MOLD environment is being set up even if there is no terminal attached to the process.

If you run on a single machine, leave CMOLD_HOST unset and you won't have to worry about hosts.equiv or .rhosts.

Enabling UNIX Users to Run Batch Jobs

C-MOLD provides users with an option to launch analyses as batch jobs. For UNIX users, C-MOLD batch jobs are executed on the host computer defined by the CMOLD_HOST environment variable. If the CMOLD_HOST environment variable is not set, which is the default, then the current machine is used. If you want to use the CMOLD_HOST variable to execute batch jobs on another computer, please contact C-MOLD technical support for details.

C-MOLD uses the UNIX batch and at commands to launch batch jobs. On many UNIX systems, however, use of the batch and at commands is not permitted by default. In order to use C-MOLD efficiently, all C-MOLD users must be permitted to use the batch and at commands.

Users are permitted to use the batch and at commands if their user name appears in the file at.allow. If that file does not exist, check the file at.deny to determine if the user should be denied access. If neither file exists, only superuser is allowed to submit a job. If at.deny is empty, all users are given permission. Therefore, to allow all users access to the batch and at commands, make sure that the at.allow file does not exist and at.deny exists but is empty. The at.allow and at.deny files consist of one user name per line. These files can be modified only by superuser. Table I-1 shows the location of the files at.allow and at.deny on each UNIX platform. Refer to your system documentation for the batch and at commands if you need more detailed information.

TABLE I-1. Location of UNIX files at.allow and at.deny
Hardware (CPU)  Operating system  Directory containing at.allow and at.deny  
DEC Alpha AXP  Digital UNIX  /var/adm/cron 
HP 9000/700  HP-UX  /usr/lib/cron 
IBM RS/6000  AIX   /var/adm/cron 
SGI  IRIX  /usr/lib/cron 
Sun SPARC  Solaris (SunOS)  /var/spool/cron 

[Contents] [Prev] [Next]

Copyright © 1997-1998 Advanced CAE Technology, Inc. All rights reserved.