ptx/LAE provides a Linux Application Environment for DYNIX/ptx® V4.6.1 that enables you to install and run supported Linux applications.
ptx/LAE requires that the following products also be installed:
DYNIX/ptx V4.6.1
ptx/TCP/IP V4.7.1
Certain Red Hat® Linux® V6.2 components (purchased from a commercial retailer other than IBM, and which must be installed after ptx/LAE is installed and the system is rebooted)
To find out which products are supported for use with ptx/LAE V1.0.0, consult the following URL: http://oss.software.ibm.com.
Refer to the DYNIX/ptx V4.6.1 and Layered Products Software Installation Release Notes for information about installing ptx/LAE and the required Red Hat Linux components. Refer to the section entitled "Install Linux Applications and Packages" (later in these release notes) for information about installing Linux applications and packages.
The following limitations apply to ptx/LAE:
ptx/LAE does not support hardware other than that supported by DYNIX/ptx.
Linux administrative tools, except for the application's use of syslog, are not supported. DYNIX/ptx must be used for all system administration tasks.
The Linux kernel does not execute. Linux kernel code, Linux kernel patches, Linux device drivers, and Linux loadable modules are not supported.
Linux and DYNIX/ptx code cannot be mixed inside a process. Consequently, Linux executables cannot use DYNIX/ptx libraries (static *.a's or shared *.so's).
Virtual 8086 mode is not supported.
Applications that use unsupported system calls may not work properly.
ptx/LAE does not support the /proc filesystem, except for the /proc/meminfo and /proc/cpuinfo files.
To avoid conflicts with DYNIX/ptx, ptx/LAE installs Red Hat Linux components in an alternate root directory, /linux/root. ptx/LAE provides a feature called pathmapping that enables Linux applications to access the objects in /linux/root automatically. When a Linux application is invoked, the pathmapping feature attempts to map the file path specified by the application to /linux/root/filepath. If this fails, then the original path is used.
The DYNIX/ptx kernel uses the following methods to recognize a Linux binary application and then performs the necessary pathmapping:
All Linux system calls trap through interrupt 0x80. When the kernel encounters this interrupt, it recognizes the binary as Linux.
If exec() tries to open the shared library ld-linux.so.2, the kernel recognizes the binary as Linux.
A Linux shell script is recognized as follows:
Shell scripts written for Linux require Linux semantics (pathmapping, running under the BASH shell) to execute correctly.
A special flag must be used to "mark" a shell script for Linux semantics. The flag is the "sticky" bit, which previously did not have a meaning for shell scripts. (See chmod(2), ls(2), etc.)
If a shell script is marked with a sticky bit, pathmapping will be enabled on all commands. For example, a #!/bin/sh script will run with /linux/root/bin/sh. If a #! interpreter is not present, then the Linux version of the current shell /linux/root/bin/[sh,ksh,csh] will be used to process the shell script.
Linux applications require that the following /proc files be present on the system: mtab, fstab, meminfo, cpuinfo. ptx/LAE provides a script, genlaefiles, that creates these files. The script runs every 30 minutes as a cron job to keep the files up to date.
The genlaefiles script uses the following methods to create the files:
/linux/root/etc/mtab: Maps information from the DYNIX/ptx file /etc/mnttab.
/linux/root/etc/fstab: Maps information from the DYNIX/ptx file /etc/vfstab.
/linux/root/proc/meminfo: Uses output from the DYNIX/ptx sar, swap, and showcfg utilities. The values for Buffers and Cached are set to -1.
/linux/root/proc/cpuinfo: Calculates data based on the cpuid assembly instruction.
ptx/LAE implements the following system calls:
1 exit |
2 fork |
3 read |
|
4 write |
5 open |
6 close |
|
7 waitpid |
8 creat |
9 link |
|
10 unlink |
11 execve |
12 chdir |
|
13 time |
14 mknod |
15 chmod |
|
16 lchown |
18 stat |
19 lseek |
|
20 getpid |
23 setuid |
24 getuid |
|
25 stime |
27 alarm |
28 fstat (old) |
|
29 pause |
30 utime |
33 access |
|
34 nice |
36 sync |
37 kill |
|
38 rename |
39 mkdir |
40 rmdir |
|
41 dup |
42 pipe |
43 times |
|
45 brk |
46 setgid |
47 getgid |
|
49 geteuid |
50 getegid |
54 ioctl |
|
55 fcntl |
57 setpgid |
60 umask |
|
61 chroot |
63 dup2 |
64 getppid |
|
65 getpgrp |
66 setsid |
67 sigaction (old) |
|
68 sgetmask |
69 ssetmask |
70 setreuid |
|
71 setregid |
72 sigsuspend |
73 sigpending |
|
75 setrlimit |
76 getrlimit |
77 rusage |
|
78 gettimeofday |
79 settimeofday |
80 getgruops |
|
81 setgroups |
82 select (old) |
83 symlink |
|
84 lstat |
85 readlink |
90 old_mmap |
|
91 munmap |
92 truncate |
93 ftruncate |
|
94 fchmod |
95 fchown |
96 getpriority |
|
97 setpriority |
99 statfs |
100 fstatfs |
|
102 socketcall |
104 setitimer |
105 getitimer |
|
106 newstat |
107 newlstat |
108 newfstat |
|
114 wait4 |
117 ipc |
118 fsync |
|
119 sigreturn |
120 clone |
122 newuname |
|
123 modify_ldt |
125 mprotect |
126 sigprocmask |
|
133 fchdir |
136 personality |
138 setfsuid |
|
139 setfsgid |
140 llseek |
141 getdents |
|
142 select |
143 flock |
144 msync |
|
145 readv |
146 writev |
148 fdatasync |
|
156 sched_setscheduler |
157 sched_getscheduler |
158 sched_yield |
|
162 nanosleep |
163 mremap |
164 setresuid |
|
165 getresuid |
168 poll |
173 rt_sigreturn |
|
174 rt_sigaction |
175 rt_sigprocmask |
176 rt_sigpending |
|
179 rt_sigsuspend |
180 pread |
181 pwrite |
|
182 chown |
186 sigaltstack |
190 vfork |
The following system calls are unimplemented in ptx/LAE. They return ENOSYS and allow the application to continue. The system calls preceded by "2.4" are available only in 2.4 kernels.
62 ustat (deprecated) |
154 sched_setparam |
155 sched_getparam |
59 sched_get_priority_max |
60 sched_get_priority_min |
61 sched_rr_get_interval |
177 rt_sigtimedwait |
178 rt_sigqueueinfo |
183 getcwd |
191 - 2.4 getrlimit |
192 - 2.4 mmap2 |
193 - 2.4 truncate64 |
194 - 2.4 ftruncate64 |
195 - 2.4 stat64 |
196 - 2.4 lstat64 |
197 - 2.4 fstat64 |
198 - 2.4 lchown |
199 - 2.4 getuid |
200 - 2.4 getgid |
201 - 2.4 geteuid |
202 - 2.4 getegid |
203 - 2.4 setreuid |
204 - 2.4 setregid |
205 - 2.4 getgroups |
206 - 2.4 setgroups |
207 - 2.4 fchown |
208 2.4 - setresuid |
209 - 2.4 getresuid |
210 - 2.4 setresgid |
211 - 2.4 getresgid |
212 - 2.4 chown |
213 - 2.4 setuid |
214 - 2.4 setgid |
215 - 2.4 setfsuid |
216 - 2.4 setfsgid |
218 - 2.4 mincore |
219 - 2.4 madvise |
The following system calls are unimplemented in ptx/LAE. They return the SIGSEGV signal, causing the application to core dump and abort. The system call preceded by "2.4" is available only in 2.4 kernels.
0 unused by Linux |
17 unused by Linux |
21 mount |
22 unused by Linux |
26 ptrace |
31 unused by Linux |
32 unused by Linux |
35 unused by Linux |
44 unused by Linux |
48 signal (old) |
51 acct |
52 unmount |
53 unused by Linux |
56 unused by Linux |
58 unused by Linux |
59 olduname |
74 sethostname |
86 uselib |
87 swapon |
88 reboot |
89 old_readdir |
98 unused by Linux |
101 ioperm |
103 syslog (admin) |
109 uname |
110 iopl |
111 vhangup |
112 idle will |
113 vm86old |
115 swapoff |
116 sysinfo |
121 setdomainname |
124 adjtimex |
127 create_module |
128 init_module |
129 delete_module |
130 get_kern_syms |
131 quotactl |
132 getpgid |
134 bdflush |
135 sysfs |
137 unused by Linux |
147 getsid |
149 sysctl |
150 mlock |
151 munlock |
152 mlockall |
153 munlockall |
166 vm86 |
167 query_module |
169 nfsservctl |
170 setresgid |
171 getresgid |
172 prctl |
184 capget |
185 capset |
187 sendfile |
188 unused by Linux |
189 unused by Linux |
217 - 2.4 pivot_root |
ptx/LAE does not support other Linux system calls. If an application uses an unsupported system call, the kernel will take one of the following actions:
Return a "not implemented" (ENOSYS) error to the application, which may then be able to use alternate functionality.
Issue a SIGSEGV, and the application will terminate and dump core. Also, an error will be written to the system log.
The following IOCTLs are supported in ptx/LAE. Unsupported IOCTLs return EINVAL.
TCGETS |
TIOCOUTQ |
TCSETS |
TIOCSTI |
TCSETSW |
TIOCGWINSZ |
TCSETSF |
TIOCSWINSZ |
TCGETA |
FIONREAD |
TCSETA |
FIONBIO |
TCSETAW |
TIOCGETD |
TCSBRK |
TIOCSETD |
TCSBRK |
TCSBRKP |
TCXONC |
FIOCLEX |
TCFLSH |
FIONCLEX |
TIOCSPGRP |
FIOASYNC |
TIOCGPGRP |
The modify_ldt() system call allocates Local Descriptor Tables (LDTs) in low kernel memory. When a process calls modify_ldt(), the call creates a per-process LDT. This LDT is freed when the process exits.
Many processes do not use modify_ldt(). For those processes (such as Java®) that call modify_ldt(), there can be one LDT per process.
The low kernel memory used for LDTs must be reserved at boot time. ptx/LAE provides a tunable parameter, LAE_MAX_LDT_CNT, that specifies the maximum number of LDTs that can exist at any given instant. By default, LAE_MAX_LDT_CNT reserves memory for 200 concurrent LDTs. You can use the ptx/ADMIN "Kernel Configuration" option to modify this parameter. The range of values is 10 to 3000.
The Linux environment provides the following:
If the sticky bit is set on a shell script and ptx/LAE is installed, pathmapping will be enabled and the shell script will act as though it is a native Linux script.
Special functionality in cp, tar, and chmod to handle the sticky bit. See "DYNIX/ptx Support for the Sticky Bit."
rpm performs some additional steps when it installs Linux packages. See"Install Linux with rpm (Red Hat Package Manager)" later in these release notes.
The lae_mark command sets the sticky bit on a non-ELF regular file. The DYNIX/ptx kernel uses the sticky bit to distinguish between DYNIX/ptx and Linux scripts.
You can use the lae_mark command to set the sticky bit on Linux scripts that you create.
![]() | REFERENCE lae_mark(1LAE) |
When ptx/LAE is installed, a non-root user can set the sticky bit. When ptx/LAE is not installed, only root can set the sticky bit. (This is standard DYNIX/ptx behavior.)
The following DYNIX/ptx utilities support the sticky bit when ptx/LAE is installed:
If the sticky bit is set on a shell script and the first line of the shell script does not list a specific interpreter with a first line of the form #! interpreter [arg], then the Linux version of the current shell /linux/root/bin/[sh,ksh,csh] will be used to process the shell script.
Two debugging tools are available to debug Linux applications on DYNIX/ptx: gdb and truss. truss is provided as part of DYNIX/ptx; gdb is provided as part of ptx/LAE.
When ptx/LAE is present on the system, truss traces all Linux system calls automatically. The utility provides options for excluding or including specific Linux system calls.
For Linux system calls supported by ptx/LAE, truss displays the name, parameters, and return value of each call. The verbose option displays additional parameter information. For Linux system calls not supported by ptx/LAE, truss displays only the system call name.
![]() | REFERENCE truss(1) |
The ptx/LAE log input file /linux/root/dev/log is created when syslogd starts. If the /linux/root/dev directory does not exist after the system is booted or is removed after syslogd is started, then ptx/LAE logging will not work until syslogd is restarted.
Once you have installed ptx/LAE and the required components from Red Hat Linux V6.2 (see the DYNIX/ptx V4.6.1 and Layered Products Software Installation Release Notes for instructions), you may wish to install Linux applications and packages. To do so, use one of the following three methods:
Use the ptx/LAE rpm command to install Linux packages that are provided as Red Hat Package Manager (RPM) packages. For details on this method, refer to "Install Linux RPM Packages on DYNIX/ptx" later in these release notes.
Use the DYNIX/ptx tar command to install tar files. You need to use either the -L flag to tar, or set the _LAE_INSTALLING environment variable to 1, or use lae_mark after tar has completed. Both will cause the sticky bit to be set on all non-ELF regular files.
Use the ptx/LAE command lae_mode during the Linux application installation phase or when the Linux application is provided on a read-only medium. For details on this method, refer to "Install Linux Applications with lae_mode" later in these release notes.
rpm is an open packaging system that enables Linux applications to be more easily installed, upgraded, and deinstalled. During installation, rpm manages configuration files so that site-specific customizations are not lost. RPM also maintains a database of installed packages and their files, which enables you to more easily manage the Linux applications on your host.
ptx/LAE includes a version of rpm (the ptx/LAE rpm command) that has been ported for use with DYNIX/ptx. Specifically, the rpm command is a port of RPM 3.0.6 to DYNIX/ptx as provided under the terms of the GNU General Public License.
ATTENTION Do not install Linux native rpm.
ptx/LAE rpm provides the following default behavior:
Installs packages in the /linux/root directory. This directory is used as the Linux alternate root directory on DYNIX/ptx. You can designate a different location with the --root rootdir option. Alternatively, you can set the value of the RPM macro _lae_root in the system /etc/rpm/macros file or in your home RPM macros file ~/.rpmmacros.
Records the installation in the RPM database /linux/root/var/lib/rpm. By default, the RPM database /var/lib/rpm is not used by ptx/LAE rpm. To designate an alternate RPM database for the installation, use the rpm options --root rootdir in conjunction with --dbpath path, which will use the RPM database in /rootdir/path.
Logs installed RPM packages in /etc/versionlog. The log entry specifies the install mode and root path used for the installation. This feature can be turned off by setting the rpm macro _lae_etcversionlog to No.
Marks non-ELF regular files by setting the sticky bit. This enables the DYNIX/ptx kernel to distinguish Linux scripts from DYNIX/ptx scripts and then execute them with the appropriate shell and commands.
Does not require the use of the rpm option --ignoreos when installing Linux RPM packages on DYNIX/ptx.
Note that although the rpm command will install files and set the sticky bit on them, other installation steps may be required to complete the installation. If this is the case, you must run the lae_mode command to install any additional scripts, and then run lae_mark on the files the scripts generate so that the sticky bit is set. See "Install Linux Applications with lae_mode" for more information about running lae_mode and lae_mark.
When ptx/LAE is installed on a host, the DYNIX/ptx tar command can be used to extract .tar files that contain Linux applications. In order to set the sticky bit on the files you are installing, use either the -L option to the tar command or set the _LAE_INSTALLING environment variable to 1.
For example, to extract the archive file ABCLinux.tar that is located in /usr/local:
tar -xvfL /usr/local/ABCLinux.taror
export _LAE_INSTALLING=1 (if using ksh)
tar -xvf /usr/local/ABCLinux.tar
Note that although the tar command will have expanded the installed files and set the sticky bit on them, other installation steps may be required to complete the installation. If this is the case, you must run the lae_mode command to install any additional scripts, and then run lae_mark on the files the scripts generate so that the sticky bit is set. See "Install Linux Applications with lae_mode" for more information about running lae_mode and lae_mark.
The lae_mode command runs the install command for a Linux application so that it, and any scripts or files generated during the installation process, will act as if they were Linux scripts and allows them to be properly interpreted. You must use the lae_mode command when a Linux application has its own installation program or it is on a read-only medium since there is no other way for the installer to interpret them as Linux applications. Once a Linux application has been installed with lae_mode, you must "mark" any of the application's scripts that were installed by setting the sticky bit on the files with lae_mark or manually with chmod. Marking the Linux files enables the DYNIX/ptx kernel to recognize the files as Linux files. (You do not need to mark binaries and directories.)
The installation procedure for Linux applications when using lae_mode is the same as on native Linux, except that you use the lae_mode command to run the install command for the application you are installing. For example, if the install command for a product is install_product, use the following command to install the product with ptx/LAE:
lae_mode install_product
ATTENTION For application installations that use graphical-user interfaces, you must set the following: LD_LIBRARY_PATH=/usr/X11R6/lib and DISPLAY=your display. For example:
LD_LIBRARY_PATH=/usr/X11R6/lib
DISPLAY=your display
export LD_LIBRARY_PATH DISPLAY
Next, use the lae_mark command to set the sticky bit on the installed files. For example, if the Linux application is installed in /oracle, use the following command to recursively mark all the files in this directory and any subdirectories:
find /oracle | xargs lae_mark
For Linux application-specific installation information, refer to the documentation provided with the Linux application you are installing.
You can deinstall ptx/LAE by using the Software Management option on the System Administration menu in the ptx/ADMIN menu system. If you are not familiar with the steps to deinstall a product, refer to the ptx/INSTALL Software Installation Guide.
ATTENTION To deinstall Red Hat components, ptx/LAE must be installed. Do not deinstall ptx/LAE until after you deinstall Red Hat components, unless you intend to keep the Red Hat components.
To deinstall Red Hat components, use the rpm command. A package can only be deinstalled by the user who installed the package (usually root).
To determine the names of installed Red Hat packages, issue this command:
# rpm -qa
To deinstall a single package, issue this command (where package_name) is the name of the Red Hat package you wish to deinstall:
# rpm --erase package_name
To deinstall all Red Hat packages, issue this command:
# rpm --nodeps --erase 'rpm -qa'
This release of ptx/LAE includes the following open software defect. The number in parentheses identifies the problem in the IBM problem-tracking system.
Java applications using JDKTM V1.3 may freeze, due to an internal thread locking problem when the JDK is run on ptx/LAE.
Workaround. Use JDK V1.1.8.