# IBM_PROLOG_BEGIN_TAG 
# This is an automatically generated prolog. 
#  
# bos720 src/bos/usr/sbin/drmgr/sample_scripts/README.S 1.1 
#  
# Licensed Materials - Property of IBM 
#  
# Restricted Materials of IBM 
#  
# COPYRIGHT International Business Machines Corp. 2000,2002 
# All Rights Reserved 
#  
# US Government Users Restricted Rights - Use, duplication or 
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp. 
#  
# IBM_PROLOG_END_TAG 
#
# @(#)07        1.1  src/bos/usr/sbin/drmgr/sample_scripts/README.S, cmdcfg, bos720 8/22/02 11:46:05
#
# COMPONENT_NAME: (CMDCFG)
#
# ORIGINS: 27
#
# (C) COPYRIGHT International Business Machines Corp. 2000, 2002
# All Rights Reserved
# Licensed Materials - Property of IBM
# 
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
#
# Files in this directory and its sub directories(if any) are sample
# files. User is responsible for the use of these scripts.
# User can modify and use them as they see fit. 
#

Dynamic Reconfiguration(DLPAR) script samples
------------------------------------------
This directory contains the DLPAR script examples. These script files
can be used in conjunction with drmgr to make the applications
DLPAR-aware. 
DLPAR subsystem will issue commands to these scripts during the
various phases of dynamic reconfiguration. DLPAR scripts will
use these invocations to get details regarding the DLPAR operation
in progress and then control the applications they are associated
with.
For more details, refer to Chapter "Dynamic Logical Partitioning" in manual:
"General Programming Concepts: Writing and Debugging Programs"

Some of the scripts in this directory and their function is described below:

IBM_template.sh : This is a template shell script file. This can
	used by the DLPAR script developers as a starting point
	while developing their custom DLPAR script.

IBM_XYZ_fail_dr_example.sh : This script file fails the cpu DLPAR release
	operation by returning a non-zero code during the checkrelease
	phase.

IBM_XYZ_fail_dr_2.sh: This script fails the cpu DLPAR release operation
	by binding a dummy application to the cpu being released
	during the checkrelease phase.

IBM_XYZ_move_app_example.sh: This script file demonstrates how an
	application can be moved from one bound cpu to another,
	so that the cpu being released is freed up from application
	bind clutches.

sysadmin_fail_cpu_add.sh: This script file can be used by system
	administrators to stop their system from uni-processor
	environment to multi-processor environment. This may be
	required if some third party application/kernel extension
	cannot adapt to a dynamic transition from uni to multi
	processor environment.
	During checkacquire phase of DLPAR operation, this script
	checks whether the number of processors in the system
	is one. If so it fails the acquire cpu DLPAR operation.

IBM_template.c: This is a C source template file. This file can
	be compiled and the resulting binary could be registerd with
	drmgr for DLPAR management.

IBM_template.pl: perl DLPAR script template

sysadmin_mv_rsets.c: Provides C source that moves the rsets from the
	processor being released to another cpu.

Some notes about these examples:

1. These scripts are associated with a fictitious application named "XYZ"
2. Test these examples only on a test system, whose state is not critical
   to your operation. This is because these examples release and add cpus
   which might not be ok with the normal operation of a critical system.
3. It is suggested that DLPAR script developer use the template provided 
   in this directory as a starting point while developing the DLPAR script.
4. These example script files create a debug file in /tmp directory by
   the name 'script_file_name'.dbg
   Refer to this file for details regarding the execution trace.
5. Some of the example scripts create a dummy application on the fly
   by using "sleep" command. They later use ps and grep to zero in on
   this application. So it is necessary that the there are no more than
   one sleep in the process list for this shell at any given time.
   Kill any pending sleep processes in the current shell before 
   executing the drmgr.
6. WARNING: If you need to spawn children from DLPAR scripts, drmgr will
   wait on them too (stdout/in) for completion. So it is necessary to
   make sure that the children have exited before returning from
   DLPAR script to the drmgr. If you need to spawn any child processes
   in the background over a longer period, close the stdin and stdouts
   of the children processes during the spawn. One can use the k-shell
   directives <&- and >&- to achieve this.