AIX Manual sysmgt

Chapter 7.
System Management
7.1 Printer Support Enhancements
7.1.1 Improved SMIT Print Interface

The SMIT print/spooling interface is being revised to improve usability, make
printer management easier and make it easier to attach unsupported printers.
In as many places as possible, the user will deal with a single object (a print
queue) rather than the previous four objects (queue, queue device, virtual printer
and printer device).
• Adding or removing a print queue is a one-step operation.
• When changing a print queue, only the valid changes for the selected queue
are presented to the system administrator.
• When submitting a print job, only the valid options for the selected queue are
presented to the user. The options will be validated for correctness before
the print job is submitted.
• Help text will be added to some SMIT panels.
7.1.2 Printer Subsystem Packaging

Some printer names are changed from AIX Version 3.2 to AIX Version 4.1. This
could break shell scripts that call the mkvirprt command with the old printer
names. A listing of the changed names follows:
Table 5 (Page 1 of 2). AIX Version 3.2/AIX Version 4.1 Printer Name Changes
AIX Version 3.2 AIX Version 4.1 AIX Version 3.2 AIX Version 4.1
name name name name
2380 ibm2380 2380-2 ibm2380-2
2381 ibm2381 2381-2 ibm2381-2
2390 ibm2390 2390-2 ibm2390-2
2391 ibm2391 2391-2 ibm2391-2
3812-2 ibm3812-2 3816 ibm3816
4019 ibm4019 4029 ibm4029
4037 ibm4037 4039 ibm4039
4070 ibm4070 4072 ibm4072
4076 ibm4076 4079 ibm4079
4201-2 ibm4201-2 4201-3 ibm4201-3
4202-2 ibm4202-2 4202-3 ibm4202-3
4207-2 ibm4207-2 4208-2 ibm4208-2
4212 ibm4212 4216-31 ibm4216-31
4224 ibm4224 4226 ibm4226
4234 ibm4234 5202 ibm5202
5204 ibm5204 5575 ibm5575
 Copyright IBM Corp. 1994 73

Table 5 (Page 2 of 2). AIX Version 3.2/AIX Version 4.1 Printer Name Changes
AIX Version 3.2 AIX Version 4.1 AIX Version 3.2 AIX Version 4.1
name name name name
5577 ibm5577 5585 ibm5585
6180 ibm6180 6182 ibm6182
6184 ibm6184 6185-1 ibm6185-1
6185-2 ibm6185-2 6186 ibm6186
6252 ibm6252 6262 ibm6262
7372 ibm7372 prt1021 bull1021
prt1072 bull1070 prt0201 bull201
prt9282 bull924N prt9702 bull970
pr88 bullpr88
Also, removing the AIX Version 3.1 symbolic links (4.7.6, “AIX Version 3.2
Symbolic Links Being Repackaged” on page 23) may affect users who do not
install the symbolic link compatibility package. For example, the /usr/lpd/pio/ddi
files are actually in the /var/spool/lpd/pio/@local directory.
See 4.7.3, “Printer Subsystem Packaging” on page 22 for other printer packaging
information.
7.1.3 Spooler Enhancements

Support is added to move print jobs from one print queue to another, and to hold
and subsequently release print jobs in a print queue to improve functionality.
Holding and releasing a spooled job will allow a user to put a spooled job in a
holding state where that job will stay queued and not get printed until it′ s
released. If a job is already running when the user tries to hold or release it, the
qdaemon will give an error message that it can not hold or release a running
job. Changes include:
• The -j flag is added to enq and lpr, and the -# j flag is added to qprt. These
new flags will return the job number when submitting a job. The -s flag is
added to lp to suppress the job number.
• A new front-end command, qhld, will be added to do holding and releasing of
spooled jobs.
• A new command, qmov, will be added to move a print job from one queue to
another.
74 All About AIX Version 4.1

7.1.4 Plotter and Printer Support
Support has been added for the following IBM plotters and printers:
• IBM 6180 M1 Color Plotter
• IBM 6182 Color Plotter
• IBM 6185 Model 1 Color Plotter
• IBM 6185 Model 2 Color Plotter
• IBM 2380-001 Personal Printer II
• IBM 2380 Plus Printer
• IBM 3812-002 Page Printer
• IBM 3816-01D and 01S Page Printer
• IBM 3825 Advanced Function Printer
• IBM Advanced Function Magnetic Ink Character Resolution (MICR) Printer
• IBM 3831 Page Printer
• IBM 3916 Page Printer, models AS0, AS1, NS0, NS1
• IBM 3835-001 Advanced Function Printer
• IBM 3835-002 Advanced Function Printer
• IBM 4019-001 LaserPrinter
• IBM 4019-E01 LaserPrinter E
• IBM 4028-NS1, AS1 LaserPrinter
• IBM 4029-010 LaserPrinter 5E
• IBM 4029-020 LaserPrinter 6
• IBM 4029-030 LaserPrinter 10
• IBM 4029-040 LaserPrinter 10L
• IBM 4037 5E Page Printer
• IBM 4039-10R LaserPrinter 10R
• IBM 4039-10D LaserPrinter 10D
• IBM 4039-12L LaserPrinter 12L
• IBM 4039-12R LaserPrinter 12R
• IBM 4039-16L LaserPrinter 16L
• IBM 4070 IJ Printer Model 1
• IBM 4072-001 ExecJet* Printer
• IBM 4076 ExecJet II Printer
• IBM 4079-001 Color JetPrinter
• IBM 4201-002 Proprinter II
• IBM 4201-003 Proprinter III
• IBM 4202-002 Proprinter II XL
• IBM 4202-003 Proprinter III XL
• IBM 4207-002 Proprinter X24E
• IBM 4208-002 Proprinter XL24E
• IBM 4212-001 Proprinter 24P
Chapter 7. System Management 75

• IBM 4216-031 Personal Page Printer II
• IBM 4224-301, 302, 3C2 and 3E3 Serial Printer
• IBM 4226-302 Printer
• IBM 4232-302 Dot Matrix Printer emulating the IBM 4202
• IBM 4234-009 Line Dot Matrix Printer
• IBM 4234-13 Line Dot Matrix Printer
• IBM 5202-001 Quietwriter* III
• IBM 5204-001 Quickwriter*
• IBM 6252 Impactwriter
• IBM 6252 AS2
• IBM 6252 AP8 Impactwriter*
• IBM 6252 AS8 Impactwriter*
• IBM 6262 A12, A14, A22
• IBM 6408 Line Matrix Printer
• IBM 4208-502 Proprinter* XL24E
• IBM 4216-510 Personal Page Printer II
• IBM 5327-011 Line Dot Matrix Kanji Printer
• IBM 5572 Model B02 Kanji Printer
• IBM 5575 Model B02, F02, and H02 Serial Dot Matrix Kanji Printer
• IBM 5577 Model B02, F02, and G02 Serial Dot Matrix Kanji Printer
• IBM 5579 Model H02 Kanji Printer
• IBM 5587 Model G01 and H01 Page Kanji Printer
Non-IBM supported plotters and printers include:

• Canon Laser Shot
• Canon Laser Shot LBP-B406E
• HP LaserJet Series II
• HP LaserJet Series III
• HP LaserJet Series III Si
• Hewlett Packard LaserJet 4
• TI Omnilaser 2115
• DATAPRODUCTS LZR 2665
• PRINTRONIX P9012
• DATAPRODUCTS BP 2000
• QMS Colorscript 100 Model 20
• Bull Compuprint PageMaster 1015
• Bull Compuprint 1070
• Bull Compuprint 4/51
• Bull Compuprint 4/54
• Bull Compuprint 914N

• Bull Compuprint 924 N
• Bull Compuprint 924N
• Bull PR-88
• Bull PR-88 VFU Handling
• Bull PR-90 Printer
7.1.5 troff/cmdtext Enhancements

Enhance paper size handling capabilities of the nroff/troff utilities. nroff/troff
enhanced to handle varying paper sizes, including A4, A5, B5, executive, and
legal. pic enhanced to produce pictures larger than 8 x 8 inches. New print
queue specification flag -P was added to enscript command. Landscape printing
orientation capability was added to the HP LaserJet troff postprocessor.
7.2 Backup/Restore Support
7.2.1 System Backup Command Improvements (Cloning)

In AIX Version 3.2, mksysb services provided the ability to backup the rootvg
volume group and recover device information. In AIX Version 4.1, mksysb is
enhanced and new services (like savevg and restvg) will provide the following
extensions:
• Save and restore user volume groups
• Save the definition of paging spaces in both the rootvg and user volume
groups
• Provide a non-interactive install that provides information required at install
time through a data file
• Save the inter/intra policy for the logical volumes (LVs)
• Save map files for LVs if requested by the user
− Provide the ability to shrink the filesystem and logical volume in a
volume group at install time
− Save the filesystem block size and number of bytes in inode
− Save the filesystem compression characteristics
− Allow the user to restore a single or multiple files from a system image
Volume group images will be saved in backup format (BFF). In AIX Version 3.2,
the rootvg image was saved in tar format. The rootvg is created as an
installable image; other volume groups may be backed up as separate images
on separate tapes.
If the mksysb tape is used for a backup of the source system, it is considered a
system backup . However, if the intent of the backup is to provide a customized
system for use on other machines, the mksysb is considered a clone. Cloning
means preserving either all or some of a system′s customized information for
use on a different machine.

The AIX Version 3.2.5 and AIX Version 4.1 mksysb files are system specific (320,
530, 970, ...). If the mksysb file is created on one system type, it cannot be used
to install a machine of a different system type. Trying to use a mksysb on
different system types fails because of differences in the I/O bus architectures.
In addition, if the mksysb is created on a uni-processor machine, it will not work
on a multi-processor machine. And a mksysb created on a multi-processor
machine will not work on a uni-processor machine.
In AIX Version 4.1, the running system will be ″custom″ tailored to the hardware
on that system; that is, only devices installed on the system will be supported. If
the user needs additional device support for other systems, it will have to be
specifically installed onto the running system before the mksysb is created.
If a system backup is being made to use to install another system or to reinstall

the existing system, a customer can predefine install information so questions at
installation time are already answered. This keeps user interaction at the target
node to a minimum. The AIX Version 4.1 system backup and BOS Install interact
through several files. mksysb saves the data used by install through taking a
snapshot of the current system and its customized state.
A container is a general term used to describe the information required to

recreate the container itself as well as the contents of the containers. Examples
of containers are logical volumes, volume groups and systems. The system
resources that mksysb will generally save are:
• vg data
− Number of disks
− Size of vg
− Names of disk in vg
• Disk data
− Disk location
− Disk size
− Disk name
• Logical volume data
− Logical volume location
− Logical volume name
− Volume group owner
− Map file information
− Logical volume size
• Filesystems
− Filesystem size
− Logical volume device name
− Mount point
− Block size
− Bytes in inode
− Filesystem compression characteristics
• Devices (saved as part of backing up the ODM and using the RDA utility at
install time)
− Device names
− cudv information (customized device)
− cuat information (customized attributes)

− cudep information (customized dependencies)
− cudvdr information (customized device driver)
• User volume groups data and definition
− Logical volumes
− Paging spaces
− JFS filesystems
− Non-JFS filesystems (definition only)
• Paging spaces
− Location
− Size
7.2.1.1 Packaging of System Backup

The AIX Version 4.1 utilities for creating a system backup include messages,
SMIT menus, and commands that are packaged in the bos.sysmgt.sysbr option of
the bos.sysmgt package. They are separately installable. The product media as
delivered to the user does not include the mksysb and bos install routines. The
user must install the bos.sysmgt.sysbr option to get these commands.
7.2.1.2 Data Files

The data files consist of two main files for rootvg:
1. The installation/target information, called bosinst.data. The bosinst.data file
allows an administrator to specify the requirements at the target system and
how the user interacts with the target system. It provides flexibility by
allowing different target hardware to use the same backup image. The
system backup utilities simply copy the /bosinst.data as the first file in the
rootvg image on the mksysb tape. If this file is not in the / (root) directory,
then /usr/lpp/bosinst/bosinst.template is copied to the /bosinst.data.
2. The information for creating the system containers, called image.data. The
image.data file has information used by bos install for creating the target
rootvg. The image.data file, while being flexible, is not intended for every
user. The mksysb utility calls mkszfile (if -i or -m flags specified) to create
an image.data file from existing container information. If users edit the
image.data file, then they should call the mksysb command without the -i or
-m flags to use the existing image.data file (see commands section for
mksysb below).
7.2.1.3 Commands
1. mksysb - Create an installable image of the rootvg onto a bootable tape
media or to a file. The mksysb command will only backup the rootvg volume
group.
The Type 6015 Model 0U0 PowerPC Personal System does not support
booting from a tape or making a boot image on a tape. If the system is a
Type 6015 Model 0U0 PowerPC Personal System, the tape will not have a
″boot image″; it will only have a bos Install image and then the actual
mksysb image. In other words, the tape format will be:
RISC System/6000 system - boot image,
bos install image, dummy TOC, mksysb image
Type 6015 Model 0U0 PowerPC Personal System - dummy boot image,
bos install image, dummy TOC, mksysb image

This change will always put the mksysb image as the fourth image on the
tape.
The command will check and determine what the system is, so the user does
not have to know. The user should only be aware that the Type 6015 Model
0U0 PowerPC Personal System tape will not be bootable.
To install a Type 6015 Model 0U0 PowerPC Personal System mksysb tape,
the user will have to boot the system with a product CD and choose the
System Maintenance Mode to go the second menu and then choose the
″install from a system backup″ option.
2. savevg - The savevg command can be used to backup any volume group on
the system. It is provided for backing up user volume groups. If the savevg
command is used to backup the rootvg volume group, the only difference
between the images created by the different commands is that the mksysb
command creates the boot/install images and places them on the tape to
create a bootable/installable tape. The savevg image will not be capable of
being installed directly from the tape, but may be used via the Network
Install Manager (NIM).
If a file is specified as the backup media, then the image created by both
commands will be identical; that is, mksysb <filename> and savevg -f
<filename> rootvg will create identical images.
The savevg command will create an ″installable″ tape if the volume group is
rootvg. The tape will be the same as the Type 6015 Model 0U0 PowerPC
Personal System tape format.
3. restvg - Creates the containers as specified in the
/tmp/vgdata/vgname/vgname.data file contained within the backup image
made with the savevg command and restores all the files from the backup
image. The restvg command is only used to create and restore user volume
groups, and not the rootvg volume group. The rootvg can only be created
and installed through the BOS Install routines.
4. mkszfile - Saves the system state for reinstallation on this system or another
system. The information includes system installation information, logical
volume information for the rootvg, and filesystems. This command extends
the AIX Version 3.2 mkszfile command to include information on installation
questions, international language support, and information for logical
volumes and their disk requirements. The information allows bos install to
recreate the logical volume information as it existed prior to the backup.
5. mkvgdata - Generates information on a user volume group. The information
allows restvg to recreate the logical volume information as it existed prior to
the backup. This information is used to create a user volume group image
on a target machine and is similar to mkszfile.
7.2.1.4 Backup/Restore Enhancements

The backup/restore commands are being enhanced as follows:
1. SMIT panels are being added to:
• allow an administrator to backup or restore an individual file, a file
system or a directory tree. An entire restore image may be used to
restore a single file that a user may have accidentally removed or
corrupted.
• support backup by name and backup by inode.

2. Modifications are being made to support the ability to backup and restore
from multiple devices (that is, use multiple mounted tapes without operator
intervention).
3. backup/restore will display the size of each file backed up or restored along
with the file name, with a total at the end.
7.3 System Management Interfaces
7.3.1 Visual System Management Enhancements

This line item is to make the following enhancements to the Visual System
Manager shipped in AIX Version 3.2.5:
1. Add support for setting user languages in Users & Groups Manager
2. Add support for file and directory backup and restore in Storage Manager
3. Changes to VSM for compliance with the Common Desktop Environment
Style Guide
4. Add Visual Install (see 6.1.6, “Visual Install Interfaces” on page 38 for more
information).
7.3.2 GUI Support for Devices, LVM, Printers, and Users/Groups (AIX Version
3.2.5 Work)
Provide a graphical user interface primarily aimed at novice users. There will
be icons to support the following system management activities:
• Management of system access, including password
• Management of logical volumes, volume groups and physical volumes
• Management of printers and their queues
• Management of device configuration
7.3.3 SMIT Packaging Changes

See 4.7.5, “SMIT Packaging” on page 23 for details.
7.3.4 ODME Removed

The Object Data Management Editor (ODME) is removed in AIX Version 4.1.
Support personnel and customers should utilize the odmget, odmdelete, odmadd,
and odmchange commands instead of the editor.
7.4 File System

See also 10.12.1, “Changes to Vnode Interface” on page 177 for vnode
programming changes.
7.4.1 Network File System (NFS)

Modifications to NFS will include the ability for the NFS client to perform
dynamic/adaptive retransmission for its requests to the server. These
modifications will also include bug fixes from IBM customers and the Sun
Microsystems source distribution.

7.4.2 NIS ypbind syntax change
The default behavior of the NIS ypbind daemon has changed. This change was
made to fix a security hole. The default behavior is to reject all requests from
any ypset command. Flags have been added to the ypbind daemon to allow
ypset to be used if the system administrator desires.
usage: ypbind [ -s -ypset -ypsetme ]
The flags:
-s When this flag is specified, the ypbind daemon is run in secure mode.
The daemon will use only priviliged ports for communication.
-ypset If this flag is specified, the local host will accept ypset commands
from the local host and remote hosts.
-ypsetme If this flag is specified, the local host will accept ypset commands
from only the local host. Any ypset commands from remote hosts will
be rejected. This flag will override the -ypset flag if both are
specified.
Note: If neither the -ypset or -ypsetme flags are specified, the local host will
reject all ypset commands from all hosts. This is the most secure mode since
the NIS server can′t be changed.
7.4.3 JFS BSD-Style Disk Fragmentation

Add Fragment support to the Journalled File System (JFS) to make JFS disk
space utilization competitive with other UNIX file systems. BSD-style disk
fragmentation and variable number of disk inode support is being added to the
Journaled File System (JFS).
Fragment support applies to the last partial direct block of small user files and
directories, and long symbolic links. Fragment size is specified for a file system
at creation time and can be a power of 2 division of the file system full block
size, with a maximum fragment factor of 8. In addition, different file systems
may have different fragment sizes, and they may coexist simultaneously within a
single system. Given the full block size of 4096 bytes, the allowable fragment
sizes for JFS file systems are 512, 1024, 2048, and 4096 bytes. For consistency
with AIX Version 3, the default fragment size is 4096 bytes.
Variable number of disk inode support allows users to specify the number of disk
inodes to be created within a file system if more or less than the default number
of disk inodes are desired. The number of desired disk inodes may be specified
at file system creation as the number of bytes per inode (nbpi). For example, a
nbpi value of 1024 causes a disk inode to be created for every 1024 bytes of a
file system. For JFS file systems, allowable nbpi values must be a power of 2
multiple of the minimum value of 512 and can be as large as 16384. For
consistency with AIX Version 3, the default nbpi value is 4096.
The implementation of the fragment and variable number of inode support will
provide full AIX Version 3 disk image compatibility for file systems and file
system logs, allowing AIX Version 3 file systems to be mounted and accessed in
the usual manner without requiring customers to perform any migration
activities. In addition, the provided disk image compatibility will allow AIX
Version 3 file systems to be interchanged between AIX Version 4.1 and AIX
Version 3 systems. For example, an AIX Version 3 file system can be mounted

and accessed on a AIX Version 4.1 system then moved back to an AIX Version 3
system.
Under AIX Version 4.1, AIX Version 3 file systems will be created when both the
file system fragment size and nbpi values are equal to AIX Version 3 values of
4096 bytes. This is done to allow customers to create file systems under AIX
Version 4.1 that can be interchanged between AIX Version 4.1 and AIX Version 3
systems. Since the AIX Version 4.1 default value for both fragment size and nbpi
is 4096 bytes, AIX Version 3 file systems will be created by default.
An AIX Version 4.1 file system will be created when the specified fragment size
or nbpi values are other than 4096 bytes. These file systems will not be
compatible with AIX Version 3 systems; this older version of AIX will have little
hope of understanding the new JFS file system format, including fragment
allocation units, allocation map search tree encodings, the format of file system
disk addresses, and variable numbers of disk inodes. In fact, AIX Version 4.1 file
systems will have a new superblock magic number that will prevent these file
systems from being recognized by the AIX Version 3 implementation. To move
an AIX Version 4.1 file system to an AIX Version 3 system, significant migration
activities (mkfs, dump, restore) will be required. Similar activities will have to be
performed on AIX Version 4.1 systems if fragment or nbpi support is desired for
an existing AIX Version 3 file system.
7.4.4 JFS Compression and Decompression

JFS runtime compression/decompression support will be provided as an
optionally installable fileset available on AIX Version 4.1. It will be part of the
base operating system (not a separately purchaseable option). It will not be
available at release time but will be made available at a future time.
Packaging it as a kernel extension provides the capability to ship enhanced

versions of compression/decompression without re-releasing the AIX Version 4.1
kernel. It will be in a new package named jfscomp.
File compression helps reduce the price/MB of disks and thus helps reduce the
overall price of the system.
One compression algorithm used will be the IBM variant of LZ1.
Fragments or data compression are optionally selected on a per-file-system

basis. AIX Version 3 non-fragmented, non-compressed file systems are made as
the default by the commands crfs and mkfs.
Compression only applies to regular files and long symbolic links; normal
fragment support is used for directories and other metadata is not compressed.
Each logical block of a file is compressed by itself. Normally, the size of the
compressed block is less than a full block, in which case it is written in
compressed form on disk in only the number of contiguous fragments needed.
In the case that a block does not compress, it is written on disk in uncompressed
form and represented as a full block. Thus the space occupied by a file is never
more than for the same file in a non-fragmented non-compressed file system.
Note that the compressed size is only known just before it is written to disk.
Since a program which writes a file does not expect an out-of-space (ENOSPC)
condition to occur after a successful write() (or successful store for mapped
files), it is necessary to guarantee that space will be available when logical

blocks are written. This is accomplished by allocating a full disk block to a
logical block when it is first modified, so that there will be space on disk even if
the block does not compress. If it is not possible to allocate the full block in the
beginning, an ENOSPC error condition is returned.
AIX Version 3.2 compatibility is a requirement on the AIX Version 4.1

implementation because current AIX Version 3.2 customers must be able to
migrate to the AIX Version 4.1 operating system. A significant area of AIX
Version 3.2 compatibility is disk image compatibility. Disk image compatibility
means that users can mount and access AIX Version 3.2 file systems on AIX
Version 4.1 systems without requiring disk migration activities and without loss
of file system performance. In addition to disk images, the AIX Version 4.1
implementation addresses several other areas of AIX Version 3.2 compatibility,
including source, binary, performance, and functional compatibility.
The AIX Version 4.1 implementation will affect the statfs structure and the format
of file system disk addresses. For the purpose of BSD compatibility, the statfs
structure is changed to include a new field for fragment size. The new f_fsize
field specifies file system fragment size in bytes and replaces the existing
f_nlsdirtype field. f_nlsdirtype was originally placed in the statfs structure under
AIX Version 3.2 for the purpose of future National Language Support
functionality, but is no longer required. Since this field has gone unused, it is
unlikely that it is referenced by any application programs: replacing f_nlsdirtype
with f_fsize should not create any binary or source compatibility problems.
Under the AIX Version 4.1 implementation, a new type definition is introduced for
representing JFS disk addresses. The frag_t type describes the area of disk
covered by a disk address, specifying both the starting location and length of the
area. While disk addresses are internally represented within JFS data structures
as frag_ts, the externalized data structures that record file system disk
addresses, including the disk inode and indirect block structures, remain
unchanged and continue to represent disk addresses as unsigned longs. The
details of frag_t are hidden for the purpose of source compatibility. Although
these source code details will be hidden, the format of file system disk
addresses will be documented in the < j f s / i n o . h > header file and the AIX
Version 4.1 user publications. This is done to accommodate the limited set of
customers that require low-level file system details.
Changes are required to the command line interface for the crfs, mkfs, and lsfs
commands. The crfs and mkfs commands will accept new arguments for
fragment size,the number of bytes per inode (nbpi), and compress to select data
compression. If compression is specified, the fragment size must be less than
4096 bytes. The lsfs command will be changed to display the fragment size, nbpi
and compress values for JFS file systems under the -q flag.
One new file system command, defragfs, is added. defragfs is a utility to

defragment a file system.
The fscnt() system call is extended to add a new value for the command
parameter, FS_MOVEBLKS.
The implementation will provide full AIX Version 3.2 disk image compatibility for
file systems and file system logs, allowing AIX Version 3.2 file systems to be
mounted and accessed in the usual manner without requiring customers to
perform any migration activities. In addition, the provided disk image

compatibility will allow AIX Version 3.2 file systems to be interchanged between
AIX Version 4.1 and AIX Version 3.2 systems. For example, a AIX Version 3.2 file
system can be mounted and accessed on a AIX Version 4.1 system then moved
back to a AIX Version 3.2 system.
Two binary compatibility issues exist for the AIX Version 4.1 implementation:
quota support and programs that access JFS file systems through device I/O.
Under disk quota support, a user′s or group′s current disk space usage is
maintained in dqblk structures within quota files in units of 1024 bytes blocks. To
correctly maintain a user′s or group′s current usage, a carry bit is added to the
dqblk structure to account for partial current usage blocks. Since this structure
is an existing AIX Version 3.2 and contains no reserved space, the carry bit is
placed in the existing dqb_btime field. This scheme for recording partial current
usage should not effect the majority of current disk quota users, including those
using 512 bytes fragments. In fact, the impacts are likely be limited to programs
that access disk quota information for file systems with 512 byte fragment
directly through quota files rather than through the quotactl() system call. If any
of these programs exist, they will not be able to understand the format of the
dqb_btime field.
This scheme also does not work for users that take a quota file from a file
system with 512 byte fragments and move it to a file system with a larger
fragment size. This is particularly true if the quota file is moved to a AIX Version
3.2 file system on a AIX Version 3.2 system since this old version of the JFS does
not understand the format of the dqb_btime field. However, moving a quota file
from one file system to another generally makes little sense, particularly when
the file system fragment sizes are different.
File systems are somewhat unique in that they maintain on disk data structures
that are visible to programs through device I/O. In fact, some existing user
applications may accesses AIX Version 3.2 JFS file systems in this manner to
examine and use the on disk data structures. However the format of AIX Version
4.1 file systems differs from that of AIX Version 3.2 file systems. As a result,
programs that accesses AIX Version 4.1 file systems in this manner may not
work.
The implementation will change a number of the JFS specific data structures that
are shipped to customers, including the superblock, the incore inode, disk inode.
In general, these data structures do not represent programming interfaces; they
are externalized by tradition. This means that the changes to these structures
should have little or no impact to the application or kernel extension
environments. In fact, the impacts are probably limited to programs that access
file systems through device I/O and kernel extensions that violate subsystem
layering principles, like AFS.
The superblock structure is changed to include four new fields. The first two
fields describe basic system parameters and consists of s_fragsize and
s_iagsize. The third new field s_compress specifies whether data compression
is in effect. The fourth new field is s_version and specifies the superblock
version number. In addition, a new magic number, fsv4magic is introduced for
AIX Version 4.1 file systems.
A new field, i_movedfrag, is added to the incore inode and is used in recording a
file system object′s old committed resource.

Three new fields are added to the mount inode dependent section of the disk
inode. The first field is di_fperpage and specifies the fragment size, expressed
as the number of fragments per 4096 byte page. The second field is di_iagsize
and specifies the inode allocation group size as the number of disk inodes
contained within each allocation group. The third field is di_compress is equal
to the corresponding field in the superblock, s_compress.
With data compression, the number of processor cycles will also be increased.
Using software, the number of cycles for compression will be approximately 50
cycles per byte, and for decompression 10 cycles per byte (e.g. for a 601, a
compression rate of 1.2 megabytes per second, and a decompression rate of 6
megabytes a second).
7.4.5 > 2GB Filesystem Support

This item removes the addressing constraint which limits the maximum size of a
single filesystem to 2 gigabytes. The size of the variable used as a byte index
into a filesystem is being changed from a 32 bit integer to a 64 bit long long
variable.
The physical capacity of individual DASD devices is exceeding 2 gigabytes. To

make this capacity conveniently available to databases and other large file
applications, the addressing constraint which limits the maximum size of a single
filesystem to 2 gigabytes must be removed.
The impacts to application programs of this enhancement are minimal since few
applications have intimate knowledge of the internal organization or
implementation of the file system. However, applications that directly access
logical volumes would have to be enhanced to enable access to logical volumes
beyond the 2 gigabyte limit. Applications will continue to work properly without
modification within the 2 gigabyte limitation.
The maximum size of an individual file is unchanged, namely 2 gigabytes. The

maximum size of a file system to be supported will be limited to 64 gigabytes.
7.4.6 Disk Striping in the LVM

The goal for software striping is to increase sequential read and write throughput
to approach the number of disks in a striped logical volume times the sequential
throughput of a single disk. This goal assumes that the application is sending
down large enough I/O requests to keep all disks simultaneously busy and that
the disk adapters and CPU are not the bottleneck.
The initial implementation will contains the following restrictions:

• A logical volume may be unmirrored, mirrored, or striped. It may not be
mirrored and striped.
• The physical partitions for a striped logical volume must be evenly
distributed among the disks about to stripe.
The following changes are made to implement striping:

1. mklv − A new option -S with an argument is used to specify the stripe size.
2. extendlv − The extendlv command will only allocate the physical partitions
from the physical volumes which the logical volume was previously created

from. If one of the physical volume does not have enough partitions, this
command will fail with error message.
3. mklvcopy − This functionality, for adding copies (mirrors) to logical volumes,
is not allowed for a striped logical volume.
4. lslv − An additional field will be added to its output to show the stripe size
and stripe width.
5. cplv − If the destination logical volume is not specified and the source
logical volume is striped, the cplv command will create a striped logical
volume with the same stripe size and stripe width as the source logical
volume and copy the data to the newly created logical volume.
6. chlv − The chlv command will not allow the user to change the relocatable
flag on the logical volume to ″yes″ if the logical volume is striped.
7. migratepv − To migrate striped data, the destination physical volume must
not contain any striped data from the same striped logical volume. This is
because of the requirement of evenly distributed data.
7.5 RAS (Reliability, Availability and Serviceability)
7.5.1 System Diagnostics

System Diagnostics will be supported from hardfile, LAN, CD-ROM, or tape.
System Diagnostics will no longer be supported from diskette as a bootable
standalone package.
All currently supported hardware has an existing bootable diagnostics package

available today in the field. The AIX Version 4.1 diagnostics will be available on
hard disk, if they are installed during the install process. Diagnostics on
CD-ROM and tape is expected to be available in late 1994.
Supplemental diskette support is included on the standalone CD-ROM and tape

diagnostic packages. Some AIX Version 3.2 Supplemental diskettes may be
used with the AIX Version 4.1 standalone CD-ROM and tape diagnostic
packages. However, due to some changes made within the kernel and graphic
interfaces, some AIX Version 3.2 Supplementals will not work correctly. Any
Supplemental that supported an HFT device in AIX Version 3.2 will not work with
an AIX Version 4.1 diagnostic package. See 10.2, “Low-Function Terminal (LFT)”
on page 151 for more details.
The following AIX Version 3.2 Supplemental device support has been integrated
into the AIX Version 4.1 standalone CD_ROM and tape packages:
• Fiber Distribution Data Interface Diagnostics Supplement
• Block Multiplexer Channel Diagnostics Supplement
• 128 Port Asynchronous Communications Subsystem Diagnostics Supplement

7.5.1.1 Packaging
Diagnostics is a separately installable package (not part of bos.obj) under BOS.
Hardware diagnostics are now packaged under bos.diag. There is a separate
installable option for each device or adapter supported by diagnostics.
7.5.1.2 Periodic Diagnostic Analysis

Since diagnostics is a separately installable package, a different strategy is used
to run certain diagnostic applications at different times, other than using the cron
job as is done today in AIX Version 3.2. A new service aid is implemented that
will allow the customer or a customer engineer to select certain diagnostics and
their run time.
7.5.1.3 Standalone Diagnostic Diskette Package

Since the standalone diagnostic diskette package is no longer supported, the
Create Diagnostic Diskette service aid has been changed to the Diagnostic
Package Utility service aid. This service aid allows the formatting of diskettes,
plus it allows the standalone configuration diskettes to be created. These
diskettes are the console selection diskette and display rate diskette.
7.5.2 RAS Symptom String Support

This item is also referred to as First Failure Data Capture (FFDC).
First Failure Support Technology (FFST) is a technology for FFDC developed by

FFST Development, which is part of IBM M&S (Marketing and Sales) in Raleigh.
To use FFST, one places ′probes′ in their code at points where software defects
are detected. When a probe call is triggered, the FFST Problem Source Identifier
module captures a selective dump of pertinent failure data, builds a symptom
string, logs the event in the system error log, and generates an operator
notification and a network notification (such as a SNA Alert). M&S offers an
automated problem management and service offering called FFSTService for
products which use FFST.
In lieu of implementing FFST on AIX, the current software service aids are
enhanced to provide First Failure Data Capture. AIX currently provides facilities
for error logging, operator notification and network notification. It would need to
add:
• Symptom string support − As the term implies, a symptom string is meant
to describe a problem symptomatically. It is a sequence of keyword/value
pairs. The keywords are chosen from a predefined group, and the values
are problem specific. The keywords and values should be chosen in such a
way as to make it possible to identify duplicate problems. Ideally, there
should be one and only one symptom string for each valid problem.
The following changes are being made to support symptom strings:
1. Adding calls to allow either application or kernel code to generate a
symptom string as well as error log data.
2. Updating errdemon to put this data into the error log.
3. Updating errdemon to provide notification based on the presence of
symptom data.
4. Adding symptom string support to errpt.
• Selective dump capability − Selective dumping is not supported at present
by FFDC.

7.5.3 RAS Enhancements
New Boot Message Log
AIX Version 4.1 will save output from the boot process into a log file. This
includes the output from the period preceding and following display
configuration. The boot log is a fixed-size (circular) file whose size is
configurable. The default size to expected to be large enough to hold the output
from the two most recent boots.
The boot log is maintained using the alog command which is a new command in
AIX Version 4.1. The alog command is a general-purpose logging program that
reads standard input and writes the output to standard output and copies it to a
fixed-size file at the same time. The alog command works with log files that are
specified on the command line, or with logs that are defined in the alog
configuration objects in ODM. (The ″a″ in alog stands for AIX.)
Error Log Changes
The log file name and the in-memory buffer size are configurable in AIX Version
4.1. New flags have been added to the errdemon command for these functions.
In AIX Version 4.1, there are a couple of changes to the Error Notify Class:
• There is a new field added to the Class. This field (en_symptom) is reserved
for future use.
• The system′s objects are specified by the Error_ID instead of the
Error_Label.
There is a migration method provided to automatically convert the AIX Version

3.2 version of the Error Notify Class to the AIX Version 4.1 version if the
customers use the migration method to install their machines.
If bos.sysmgt.serv_aid is not installed, only the error notification by error ID

(en_crid) will work.
In AIX Version 4.1, a CORE_DUMP error log entry will include the basename of
the program that core dumped. A sample is installed in
/usr/lpp/bos/samples/findcore to show how to locate the core file using the
information provided by the error log. This also serves as a general-purpose
error notification sample.
The errpt in AIX Version 4.1 will not be able to format the AIX Version 3.2 error
log; however, a conversion tool (/usr/lpp/bos.sysmgt/convert_errlog) is provided
to convert the AIX Version 3.2 error log to AIX Version 4.1 error log. If a
customer uses the migration install, the conversion will be done automatically.
errupdate is enhanced to disallow setting the alert flag to True if any of the
message identifiers in the template are not in the range permitted by SNA
Generic Alert Architecture. A new flag ′-p′ is provided to allow the customers to
override this restriction (since it is valid for customers to send alerts with
non-architected message identifiers).

errupdate has two new flags:
-p Override the SNA restriction.
-y Filename Use Filename for alternate error logging template file.
The following errpt enhancements are made:

1. Add a new Error Type, INFO, for logging non-error type information such as
DASD transfer statistics.
2. Add a new Error Class, UNDETERMINED, for logging communications related
errors that are not isolatable to hardware or software but rather are due to
Network failures.
3. Cosmetic changes to the errpt output: Remove the word ′Error′ from the
column and field headings in the errpt output (change ERROR_ID to ID,
change ERROR_DESCRIPTION to DESCRIPTION, change ERROR_LABEL to
LABEL, change Error Type to Type, change Error Class to Class, and change
Error Description to Description).
errpt has several new flags and a couple of changes to existing flags:
-J Error_Label Retrieve error log entries for the specified Error_Label.
-K Error_Label Retrieve all the error log entries except those for the specified
Error_Label.
-y Filename Allow the alternate error record template file specified by the
Filename.
-z Filename Allow the alternate error logging message file specified by the
Filename.
-T Type_list In addition to the existing types (PERM, TEMP, PERF, PEND,
UNKN), there is a new type INFO.
-d Class_list A new class U (undetermined) can be used in addition to the
existing classes, H(hardware), S(software), and O(operator
message.
errdead has one new -i flag to write to an alternate error log file.
errdemon has a couple of new flags and a few changes to existing flag:
-B BufferSize To configure the error log internal buffer.
-i Filename To write to an alternate log file.
-l Lists the values for the name and size for the error log file and
the value for the buffer size.
errclear has several new flags and a few changes to existing flags:
-J Error_Label Delete the error log entries specified by the Error_Label.
-K Error_Label Delete all the error log entries except those specified by the
Error_Label parameter.
-T Type_list In addition to the existing types (PERM, TEMP, PERF, PEND,
and UNKN), there is a new type INFO.
-d Class_list A new class U (undetermined) can be used in addition to the
existing classes, H(hardware), S(software), and O(operator)
message.

-l SequenceNum Delete the error log entries with the specified sequence
numbers.
-y Filename Allow the alternate error template file specified by Filename.
errmsg has one new flag:

-z Filename Use Filename for alternate error logging message file.
errinstall has one new flag:

-z Filename Use Filename for alternate error logging message file.
trace Changes
The previous trace log will be preserved when restarting trace. The original file
is renamed (e.g. trcfile.old) and new data is written to a new file.
Trace templates are not installed in /etc/trcfmt until the trace option is installed.
The trace templates for options that are not in the bos.rte package are now
shipped with each individual option and will be installed when the option is
installed.
Dump Device Changes
In AIX Version 4.1, the default primary dump device will be the paging space.
This saves disk space by no longer requiring you to keep a dedicated section of
your disk for dumps. You may, however, elect to use a dedicated dump logical
volume as before. If you use the migration facilities of base installation, your
dump device will remain unchanged. In either case, you can manually set your
dump device using SMIT or:
sysdumpdev -p.
If your dump goes to paging space, it must of course be copied off before your
system comes up and starts using the paging space again. This is done at boot
time with the savecore command, which copies the dump off your paging space
before paging activity is started.
The dump is copied to /var/adm/ras by default. This directory can be changed

using:
sysdumpdev -d <directory>
or
sysdumpdev -D <directory>
The -D (capital D) parameter indicates that if the copy fails, you are given a
chance to copy the dump to removable media using a menu interface. The -d
(small d) flag tells the system to just continue if the copy fails. In this case,
you′ll lose the dump, but this may be necessary in some cases. The default is
-D, allow copy to external media.
The dump is copied to the file vmcore.n, where n is a sequence number. Your
first dump will be vmcore.1, the second vmcore.2, etc.
The most frequent reason for a copy to fail is that there′s not enough space in
the filesystem for the dump. The same space calculations you applied to your
dump device in AIX Version 3.2 applies to the free space in the target directory.
You may, however, elect to force some free space to be left in the file system

containing the directory by putting a value in the <directory>/minfree file. This
file specifies the number of kbytes to leave free after the copy is finished.
7.5.4 RAS Programming Changes

See 10.11.1, “/usr/include/sys/erec.h” on page 175 for additional RAS changes.
7.5.5 Withdrawal of Electronic Customer Support from AIX Version 4.1

The Electronic Customer Support (ECS) function that is currently supported in
AIX Version 3 will not be included in AIX Version 4.1.
Presently the ECS command is used to access IBMLink via IBM Information
Network. ECS is included as part of the base AIX Version 3 Operating System
for use on the IBM RISC System/6000 only.
7.6 Security
7.6.1 C2 Security Enhancements

There are security functional enhancements needed in AIX to support the
″Minimum Security Functional Requirements″ (MSFR) emerging standard. While
the standard is not finalized, several security functions are also required by our
commercial customers. The following functional enhancements are included in
AIX Version 4.1:
Password Management:
• Password triviality checking
• Settable password expiration warning
• Password re-use
• Password lifetime
Login Controls
• Time of day/day of week restriction - user
• Time of day/day of week restriction - port
• Invalidate user after ′ N′ failed login attempts
• Disable port after ′ N′ failed login attempts
• Login retry delay
• Login completion timeout
The pw_restrictions previously located in the /etc/security/login.cfg file have

been moved to the /etc/security/user file because they now can be set per-user
instead of systemwide. Also, in userconf.h, the ″pw_restrictions″ system
attribute value has been removed.
7.6.2 DCE Integration

7.6.2.1 Integrate with AIX Security
Behavioral integration of the base AIX authentication mechanisms in order to
enable/support loadable authentication and name resolution modules for
integrating DCE. The DCE Licensed Program Product is separately purchased
and installed. The DCE load modules will only be present on a system that has
the DCE environment installed. Changes to some security commands and
libraries are required.
There is no new function visible to the end user of the system. There are new
APIs to support a converged set of authentication interfaces, and there are new
capabilities available to the system administrator with respect to configuring how
and where a user authenticates (assuming DCE is installed).
For DCE, the behavior of the AUTH1 per-user attribute (located in the
/etc/security/user file) has been modified.
7.6.3 DCE and C2 Security SMIT Changes
The existing SMIT functions under the Security and Users menu will be modified
to include the DCE and C2 security enhancements. The SMIT changes fall into
three basic categories:
1. Users − In the dialogs, new attributes were added for per-user password
and login controls and for DCE authentication and password registry
methods. Two new menu items were also added on the Users menu for
locking/unlocking user accounts and changing a user′s password.
2. Passwords − A new menu was added to provide a dialog for password
controls in addition to the existing function of changing a user′s password.
3. Logins − A new menu item on the Security and Users menu was added to
allow access to new dialogs for login controls for users or ports.
7.7 Bosboot, IPL Changes
7.7.1 ″Lite″ Boot

This document consists of designs to streamline bosboot for AIX. The intent is to
reduce disk space requirements, and improve performance and robustness in
generating the boot image. The specific purpose of this feature is threefold:
• Limit the size of the boot logical volume to 4MB for the streamlined bosboot
• Reduce disk space required for building hard disk boot image (or build boot
image in memory)
• Use predefined database instead of BFF files to create bootable tape,
CD-ROMs, and net.
7.7.1.1 Bosboot Command Changes

See 11.1.7, “bosboot” on page 186 for information.

7.8 Performance
7.8.1 Performance Diagnostic Tool (PDT)

New function is being added in the base operating system to identify problems
with RISC System/6000 configurations (hardware and software) that will affect
performance. PDT is installed as the bos.perf.diag_tool of the AIX Version 4.1
base operating system (there is no extra charge associated with it).
PDT attempts to identify performance problems automatically. It collects and

integrates a wide range of performance, configuration and availability data into a
historical record. It regularly evaluates this historical data to identify and
anticipate common AIX / RISC System/6000 performance problems.
Analysis is both static and dynamic. Static analysis focuses on configuration,

such as I/O and paging. Dynamic analysis assesses a variety of metrics over
time. Included are network (ping delays), process CPU and memory
consumption; file sizes; file system usage percentages; error rates; paging space
usage. A final section evaluates a set of simple workload benchmarks over
time. Included are total system queue length (loadavg); number of processes
and distribution of process states and system CPU idle percentage.
PDT must be enabled via the pdt_config command before it starts collecting
configuration, availability, and performance data on a daily basis. The data is
maintained in a historical record for approximately one month. On a daily basis,
PDT generates a diagnostic report that is mailed to the adm userid and written
to /var/perf/tmp/PDT_REPORT.
The tool will operate continuously; thus, there will be no explicit action the user
need take to run the tool. Also, continuous operation will allow customer
support to access tool output, potentially allowing for a post-analysis of the
customer′s problem without the need for further data collection.
7.8.2 Performance PMR Data Collection Tool (PerfPMR)

The Performance PMR Data Collection Tool contains a set of tools, along with
instructions, for use in collecting the data required to open a performance
related PMR.
It consists of shell scripts that collect performance and configuration information

to aid in the performance PMR process. Standard AIX performance and
configuration data sources are used, (such as iostat, vmstat, and sar). In
addition, limited trace information is obtained for later reduction by support
personnel while evaluating the PMR.
The Performance PMR Data Collection Tool will also make use of certain
performance tools (such as tprof, filemon, netpmon) if they are installed on the
system. However, installation of these tools is not a prerequisite; if they are not
installed, then only the data available from the base AIX commands (for
example, iostat) will be collected.

7.8.3 Performance Tools Packaging
The following tools are now located in the perfagent.tools package of the
Performance Aide Licensed Program Product: filemon, fileplace, genkex, genkld,
genld, lvedit, netpmon, rmss, stripnm, svmon, tprof
rmap will not be shipped.
iostat and vmstat remain part of the base operating system.
7.8.4 lockstat command

A new lockstat command reports statistics about contention in the operating
system among simple and complex kernel locks. Reports generated by the
lockstat command can be used to ensure that system performance is not being
reduced by excessive lock contention.
This command is part of the base operating system.


AIX Manual sysmgt

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AIX Manual sysmgt

Uploaded by

Copyright:

Available Formats

Chapter 7.

7.1 Printer Support Enhancements

7.1.1 Improved SMIT Print Interface

7.1.2 Printer Subsystem Packaging

 Copyright IBM Corp. 1994 73

7.1.3 Spooler Enhancements

74 All About AIX Version 4.1

Chapter 7. System Management 75

Non-IBM supported plotters and printers include:

76 All About AIX Version 4.1

7.1.5 troff/cmdtext Enhancements

7.2 Backup/Restore Support

7.2.1 System Backup Command Improvements (Cloning)

Chapter 7. System Management 77

If a system backup is being made to use to install another system or to reinstall

A container is a general term used to describe the information required to

78 All About AIX Version 4.1

7.2.1.1 Packaging of System Backup

7.2.1.2 Data Files

Chapter 7. System Management 79

7.2.1.4 Backup/Restore Enhancements

80 All About AIX Version 4.1

7.3 System Management Interfaces

7.3.1 Visual System Management Enhancements

7.3.3 SMIT Packaging Changes

7.3.4 ODME Removed

7.4 File System

7.4.1 Network File System (NFS)

Chapter 7. System Management 81

usage: ypbind [ -s -ypset -ypsetme ]

7.4.3 JFS BSD-Style Disk Fragmentation

82 All About AIX Version 4.1

7.4.4 JFS Compression and Decompression

Packaging it as a kernel extension provides the capability to ship enhanced

One compression algorithm used will be the IBM variant of LZ1.

Fragments or data compression are optionally selected on a per-file-system

Chapter 7. System Management 83

AIX Version 3.2 compatibility is a requirement on the AIX Version 4.1

One new file system command, defragfs, is added. defragfs is a utility to

84 All About AIX Version 4.1

Chapter 7. System Management 85

7.4.5 > 2GB Filesystem Support

The physical capacity of individual DASD devices is exceeding 2 gigabytes. To

The maximum size of an individual file is unchanged, namely 2 gigabytes. The

7.4.6 Disk Striping in the LVM

The initial implementation will contains the following restrictions:

The following changes are made to implement striping:

86 All About AIX Version 4.1

7.5 RAS (Reliability, Availability and Serviceability)

7.5.1 System Diagnostics

All currently supported hardware has an existing bootable diagnostics package

Supplemental diskette support is included on the standalone CD-ROM and tape

Chapter 7. System Management 87

7.5.1.2 Periodic Diagnostic Analysis

7.5.1.3 Standalone Diagnostic Diskette Package

7.5.2 RAS Symptom String Support

First Failure Support Technology (FFST) is a technology for FFDC developed by

88 All About AIX Version 4.1

Error Log Changes

There is a migration method provided to automatically convert the AIX Version

If bos.sysmgt.serv_aid is not installed, only the error notification by error ID

Chapter 7. System Management 89

The following errpt enhancements are made:

90 All About AIX Version 4.1