Introduction

AIX 5L™, the IBM version of the UNIX® operating system (OS), has already made a name for itself for its scalability, reliability, and versatility in the world of on demand business and Web applications. With the release of AIX 5L Version 5.3 last year, the tradition of excellence continues. With guaranteed binary compatibility with the previous releases on the one hand and features such as NFS Version 4, Virtual SCSI, Virtual Ethernet, Simultaneous Multi-Threading (SMT), and Micro-Partitioning™ technology on the other, users continue to benefit from the features that are regularly being added to this flagship OS.

This article focuses on some of the features that have been introduced in AIX 5L Version 5.3 to assist you in developing your own software.

• POSIX Realtime compliant functions
  AIX 5L Version 5.3 has incorporated the POSIX REALTIME extension standard. As part of this incorporation, this particular release of AIX® provides system interfaces for the following options:
  • Memlock
  • Spin lock
  • Clocks
  • Thread options
  • Barriers
  • Priority scheduling
  • Message passing
  • Semaphores
  • Timers
  • Advisory information
  
  
• Perl 5.8.2
  Perl 5.8.2, the latest version of Perl, is shipped with AIX 5L Version 5.3. It contains fixes for bugs in Perl 5.8.0, which was first shipped on AIX 5.2.0. The version of the installed code can be checked with the following command:

  # perl -v This is perl, v5.8.2 built for aix-thread-multi Copyright 1987-2003, Larry Wall

  
  

  You can run the perldoc command to view the delta in changes between the two Perl versions. The first command line in the example below displays the delta in changes between Perl Version 5.8.0 and 5.8.1 and the second command line does the same between Perl Version 5.8.1 and 5.8.2:

  $ perldoc perl581delta $ perldoc perldelta

  
  

  The Perl environment is packaged and shipped in two filesets: perl.rte and perl.man.en_US. The perl.rte fileset is on the first AIX CD and is automatically installed when installing AIX 5L Version 5.3, or migrating from a previous level of AIX.

  The man pages fileset (perl.man.en_US) is shipped on the second CD and is not automatically installed.

  The 64-bit and 32-bit versions are packaged together, with the 32-bit version being the default version. Both versions reside under the /usr/opt/perl5 directory. Both versions are Perl thread capable, built using the newer ithreads (interpreter threads), and have built-in support for PerlIO.

  Switching to use the 64-bit version only requires redirecting the Perl symbolic links in /usr/bin to point to the 64-bit versions of the same command in /usr/opt/perl5/bin.

  The /usr/opt/perl5 directory includes scripts you can use to change the links for you.

  To switch from 32-bit to 64-bit Perl, enter the following as root user:

  /usr/opt/perl5/link_perl_64

  
  

  To switch from 64-bit to 32-bit Perl, enter the following as root user:

  /usr/opt/perl5/link_perl_32

  
  

• Increased Inter-Process Communication (IPC) limits
  In AIX, the upper limits for the IPC mechanisms are defined, but not configurable. The individual IPC data structures are allocated and deallocated as needed, so memory requirements depend on the current system usage. Prior AIX releases defined the maximum number of semaphore IDs, shared memory segment IDs, and message queue IDs to be 131072 (128 K) for the 64-bit kernel. To cope with anticipated future scalability demands, the maximum number of data structures for each of the IPC identifier types has been increased to 1048576 (1024 K) in AIX 5L Version 5.3.
  
  
• Cryptographic sum command
  Users often use the sum command to generate a checksum to verify the integrity of a file. However, it is possible that two distinct files will generate the same checksum. A cryptographic sum command, csum, has been implemented in AIX 5L Version 5.3, which offers a more reliable tool to verify the integrity of a file. This command allows users to generate message digests using the AIX Cryptographic Library. A cryptographic checksum is considered secure because it is computationally almost impossible to construct data to generate a known checksum, and vice versa.

  The csum command allows users the option to select the algorithm they prefer, including both MD5 and SHA-1, which are considered secure. It is estimated that the order of 2⁶⁴ operations would be required to derive two different files that generate the same MD5 message-digest and that the order of 2¹²⁸ operations would be needed to derive a file that would generate a specified MD5 message-digest.

  csum aids in the AIX e-fix upgrade process by offering the users a mechanism to verify that a file has not been tampered with or corrupted during download.

  The csum command is installed as part of the bos.rte.commands fileset.
  
  
• Java 1.4.2
  Both 32-bit and 64-bit Versions of Java 1.4.2 are shipped with all new orders of AIX 5L Version 5.3. The new orders of AIX 5L Version 5.3 includes the 5300-02 Recommended Maintenance Package.
  
  
• Thread support in gmon.out
  When applications consisting of multiple steps in which different executables (all built with -p or -pg flags to generate profiling information) are invoked in a sequence, each executable causes the previous gmon.out file to be overwritten. It is often difficult to work through the nested scripts and source code to insert commands or subroutine calls to rename the gmon.out files so that they are not overwritten. In AIX 5L Version 5.3, the gmon.out file has been made thread-safe so that each thread from a multi-threaded application has its data in it.

  The current design of gprof provides only process-level interpretation of gmon.out. With a thread-level gmon.out, gprof enables the user to analyze complex multi-threaded applications as well as retain profiling information for a large number of programs executing from within the same directory.

• gprof thread support
  AIX 5L Version 5.3 has added new functionality to gprof so that it can now interpret additional information available for thread-level profiled programs. The additional information would include per thread function call count, per thread arc execution count, and amount of time spent executing a function per thread. The new mode is controlled with a new environment variable, GPROF.
  
  
• Enhanced libc.a
  AIX 5L Version 5.3 has implemented a number of new APIs for the libc.a library. A number of existing functions in this library have been modified as well. This has been done to improve system performance, reliability, and serviceability for the identification and authentication services provided by this library. The modified functions are distinguished by the letter "x" at the end of the function names, for example, authenticatex(), which is a modified version of the previously available function authenticate().
  
  
• New malloc() algorithm
  A new malloc subsystem called Watson Malloc has been implemented in AIX 5L Version 5.3. Watson Malloc provides improvement over the default allocator (Yorktown) in the areas of memory fragmentation and performance for massively multi-threaded applications. Watson Allocator handles small requests quickly and with comparatively little wasted memory.

  You can configure the Watson Allocator in three distinct ways to try and identify which sections of code reveal the largest gains:

  1. It can be enabled with caching mechanisms and with the new bucket allocator.
  2. It can be enabled without the caching mechanisms and with the new bucket allocator.
  3. It can also be enabled without the caching mechanisms and without the new bucket allocator.

  You can disable any of these configurations if they do not prove to be beneficial in regard to speed or memory usage.

• Improvements to malloc subsystem
  The number of malloc-related environment variables supported by AIX 5L Version 5.3 has been reduced to three and the attributes they can assume have been redefined. These environment variables are: MALLOCTYPE, MALLOCOPTIONS, and MALLOCDEBUG. MALLOCOPTIONS is a new environment variable that has been added to take care of all current and future options to the MALLOCTYPE allocators. It supplants the MALLOCBUCKETS, MALLOCMULTIHEAP, and MALLOCDISCLAIM that have been deprecated.

  The three environment variables have the following definitions and some of the attributes they can assume:

  MALLOCTYPE	Used to specify allocator type. Attributes include: 3.1, default allocator, watson, and user.
  MALLOCOPTIONS	Used to specify allocator options. Attributes include: buckets, disclaim, threadcache, and multiheap.
  MALLOCDEBUG	Used to specify debugging options. Attributes include: catch_overflow, report_allocations, Malloc Log, Malloc Trace, and validate_ptrs.

  The following enhancements have also been incorporated:

  • Threadcache option, which reduces contention for heap lock, is now available for applications using the default (Yorktown) as well as the Watson Allocator.
    
    
  • Malloc Log and Malloc Trace functions have been enhanced. Malloc Log offers an extended log and provides for automatic logging of allocations and metadata. Malloc Trace now logs more data including heap and thread IDs.
    
    
  • The output debug option
    Currently, all malloc debugging options that produce printed output send their output to stderr. The output option provides a mechanism to instruct the subsystem to send printed output to a different file stream, as shown in the example below:

    $ MALLOCDEBUG=output:/dev/null $ MALLOCDEBUG=output:stdout

    
    
    
    
  • The continue debug option
    Many malloc debugging options currently call the abort() procedure when they encounter an error. It is often the case, however, that a developer might wish to debug other classes of errors first and would prefer that less serious errors do not produce fatal flaws. With the continue option enabled, synchronous errors do not call the abort() function. Error messages are still logged to the appropriate channels.

    $ MALLOCDEBUG=continue

    
    
    
    
  • Watson Allocator supports the following debugging features:

    catch_overflow	This debugging option attempts to catch writes and reads past the end of a buffer. This is done by allocating an extra guard page and positioning the allocation in such a manner that the end of the allocation is flush against the guard page. The guard page is then protected so that any access causes a segfault.
    Malloc Log	This debugging option creates a live database of active malloc allocations that can be accessed through the use of a debugger.

    
    
    
  • DBX malloc command
    Malloc debugging features have been integrated into DBX. This would allow a developer to query the current state of the malloc subsystem without having to create complex, unwieldy scripts requiring internal knowledge of the malloc subsystem. An application developer can now get information on such items as specific malloc allocations, organization of the heaps, and the free space tree. These features are supported in both live processes and core file dbx sessions. DBX malloc command works in tandem with Malloc Log and allows key-based searches for such items as heap, address, size, and PID. The following are some examples:

    (dbx) malloc	Prints out options, heap statistics, and brk statistics
    (dbx) malloc freespace	Prints out all free nodes in the process's heaps

• Enhanced DBX functionality
  Major enhancements have been made to DBX in Version 5.3. The following is a list of some of them:
  • Users now have additional control over the way DBX uses debug events. Debug events are the user-defined breakpoints, tracepoints, and watchpoints that control the execution of the debugged process. Should a user need to disable the effects of a debug event, DBX currently requires that the event be completely removed. In a scenario where an event must be repeatedly removed and added, a user must manually reenter the event each time it is to be enabled. This inconvenience has been removed with the addition of two new DBX subcommands: disable and enable. These subcommands allow the DBX user to temporarily disable debug events without permanently removing them.
    
    
  • Currently, if any dependent module referenced by a corefile is not available at debug time, DBX displays the fatal error cannot open <dependent module path> and exits. This behavior prevents any debugging of the corefile from occurring until all of the dependent modules are located. DBX now allows the debug session to continue even if any number of dependent modules referenced by the corefile are unreadable or missing. A notification message, including the name of the missing module, is displayed by DBX during initialization for each missing dependent module. DBX also sends notification messages if any dependent module referenced in the corefile is found to be different from what it was at core file creation.
    
    
  • Several new subcommands have been added to DBX. These include proc, kthread, and fd. The purpose of these subcommands is to display data contained within the data structures used by the kernel to keep track of processes and threads. This is beneficial because it makes information about the debug available that was previously very difficult to obtain. Much of the data within the user process or file descriptor structures might have been accessible with various DBX subcommands, but with these new interfaces, all of the data is obtainable from one interface.
    
    
  • To facilitate ease of debugging pthreaded code, the scope of DBX functionality has been enhanced by providing several new subcommands that reveal information about pthread objects and display them in a readable, user-friendly format. These include handler, onceblock, and resource subcommands.
    
    
  • The DBX functionality and usability have been enhanced by adding a subcommand, corefile, that displays information about a debuggee <corefile>. Without arguments, the corefile subcommand prints basic information about the <corefile>. With arguments, more detailed information can be requested. Some function might be limited in cases where FULLCORE was not enabled at dump-time. In these cases, a warning message is printed, as appropriate.

    The corefile subcommand displays information from the header of a corefile, including:

    • The executable name
    • Corefile format versioning information
    • Flags indicating which data is available
    • The signal that caused the crash
    • The execution mode of the process that dumped core

• The Eclipse Runtime Environment
  The Eclipse Runtime Environment is shipped with AIX 5L Version 5.3. This provides a platform on which Eclipse-based tools, including the new procmon performance monitoring tool, will run.

  Note: AIX 5L does not support Eclipse as a development platform.

• tcpdump upgrade to latest level
  The tcpdump command has been upgraded to Version 3.8 for AIX 5L Version 5.3. As a consequence of this upgrade, iptrace and ipreport were also changed to use the new upgraded libcap library for packet capture and dump reading. The tcpdump command prior to AIX 5L Version 5.3 displayed packet timestamps down to 1 ns (10^-9s). The open source tcpdump displays timestamps at 10^-6s. The new AIX tcpdump has 10^-6s timestamp resolution.

  A number of new flags have been added to the tcpdump command. Also, a total of 87 protocol printers have been included to facilitate printing when using the tcpdump command.

• Presentation of man pages
  AIX 5L Version 5.3 includes the following improvements to the man command presentation of man pages that are shipped on the AIX base media and the documentation CD:
  • Sections are now indented. For example, the text of the Purpose section is indented from the heading Purpose, which is lined up in the first column. The same is true of all the sections.
  • The description of each flag is indented so it is clear where the description of the flag begins and ends.
  • There is now a visual differentiation between command names, parameters, file names, and normal descriptive text. This makes the descriptive text easy to read.
  • Multi-column tables are now neatly formatted.
    
    
• Marking executable's read and write sections
  AIX 5L Version 5.3 has introduced a new bit called F_NONEXEC. When this bit is set, the read and write sections (.data, .bss) of an executable, shared library, or object file are not executable. If the bit is not set, all read and write sections are executable. This bit can be set in the f_flags field in the XCOFF header as follows:

  #define F_NONEXEC 0x8000

  
  

  You can set or unset this bit using the ld or ldedit commands, which have been updated to handle this feature. The following is an explanation of the updates:

  • Updated flags for the ld command:

    -b rwexec	Marks the read and write sections in the file as executable. It does not set the F_NONEXEC bit in the XCOFF file header. This is the default.
    -b norwexec	This is a complimentary option to -b rwexec. It marks all read and write sections in the file as non-executable and indicates to the loader to make the stack non-executable. This option sets the F_NONEXEC bit in the XCOFF file header.

    
    
  • Updated flags for the ldedit command
    
    Use the ldedit command to clear the F_NONEXEC flag, as follows:

    ldedit -b rwexec

    
    
    
    Use the ldedit command to set the F_NONEXEC flag, as follows:

    ldedit -b norwexec

    
    

• Block device mapping
  Previous AIX releases did not have the ability to map a device. AIX 5L Version 5.3 extends the mapping capability of the mmap subroutine to block devices.

  A block device is a special file that provides access to a device driver that presents a block interface. A block interface to a device driver requires data access in blocks of a fixed size. The interface is typically used for data storage Devices.

  AIX 5L Version 5.3 utilizes block device mapping to improve performance in the file system maintenance commands. The Version 5.3 JFS2 fsck command makes use of this new capability to reduce the access time to file system metadata. Also, the control of the memory used for buffering is greatly simplified by mapping the device that the file system resides on.

  The new block device mapping capability has the following impact on system calls and subroutines:

  open()	A program that wants to do device mapping opens the special file in the normal way. No special flags or arguments are needed. All existing interfaces and interactions with the file descriptor returned by open continue to operate as before.
  mmap()	The mapping function is initiated by a call to mmap subroutine specifying the file descriptor for the device. The mmap call is the same as for a regular file mapping. The resultant mapping obeys the semantics of regular file mapping. If the file descriptor refers to a device that has already been mapped, the mmap call fails and sets errno to EAGAIN.
  msync()	The data that is written to the mapped device segment can be flushed to disk using the msync call. The flags and arguments used for regular files also apply to Devices.
  disclaim()	The disclaim subroutine can be used to release pages in the mapped segment.

• Thread-based credentials
  GRID applications need the operating system to support thread-based credentials. AIX 5L Version 5.3 introduced a pthread-based API to set and destroy thread-based credential information, such as UID and GID.

  Per-thread credential is a property by which different threads in a process own different credentials and the access rights to a resource are checked at the thread-level instead of at the process-level. This is a useful concept because it allows a single process to handle requests requiring different credentials by creating threads with the appropriate credentials for each request.

• Scalability enhancements
  AIX 5L Version 5.3 has introduced the following features to help achieve better scalability.
  • Kernel round robin locks
    The kernel round robin locks (krlock) were introduced in AIX 5L. Version 5.3 makes performance optimizations to these locks that enable systems to scale over 48 CPUs.
    
    When there is a lock miss during a simple_lock() function call, krlock processing takes place. The simple_lock() function is not changed and current applications using simple_lock() on Version 5.2 are compatible with Version 5.3.
    
    
  • Increased resource limit values in /etc/security/limits file
    The upper limits for the resource values as specified in the /etc/security/limits file have changed. For CPU and open files, the values are a decimal integer that represents a 32-bit value and can have a maximum value of 2,147,483,647 (or 2³¹-1). For the rest, the maximum value is 2,147,483,647 (or 2³¹-1) 512-byte blocks.
    
    
  • CPU time limits
    In prior releases of AIX, a program could avoid a cputime limit set with the ulimit command by simply blocking, ignoring, or handling the SIGXCPU signal that says "you're out of time" to the process exceeding the limit. Under Version 5.3, it is possible to do this to get around a SOFT limit, but not a HARD limit.

Back to top

Conclusion

AIX 5L Version 5.3 has many more features than have been discussed here to assist you in developing your software. I hope that this article has given you a flavor of the type of enhancements you can expect in Version 5.3. The publications listed in the Resources section provide further details on the subject.

Resources

• Browse the AIX 5L Differences Guide Version 5.3 Edition (IBM Redbook, December 2004).
  
  
• Go to the IBM pSeries® and AIX Information Center for more information on pSeries, RS/6000®, and AIX 5L.
  
  
• Read "Enhancements in AIX 5L Version 5.3 for application development" (developerWorks, June 2005) to learn how you can benefit from the features in AIX 5L Version 5.3.
  
  
• To learn more about RAS, Read "What has AIX 5L Version 5.3 done to strengthen RAS?" (developerWorks, February 2005).
  
  
• Want more? The developerWorks eServer™ zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on the eServer brand.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• The IBM developerWorks team hosts hundreds of technical briefings around the world which you can attend at no charge.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Conclusion
• Resources
• About the author
• Comments

Dig deeper into AIX and UNIX on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers