Hi all,

I have been collecting a list on POSIX related items.  Mark Bixby
asked to see the list since he can't atend IPROF.  So, here it is...

I will accept corrections, comments, additions any time.

thanks,
Jeff Vance, CSY


 ========================================================================

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Please note:
This is a discussion list and is not a commitment from CSY to do
any of these items.  This list will be discussed at SIGMPE at IPROF
on Tuesday and Thursday.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Below is a list of Posix related items, that if addressed, will facilitate
better use of POSIX on MPE.  Porting Unix applications and tools to MPE/iX
will be easier for a Unix (non-MPE) developers.  Unix documentation and
man pages will more closely reflect the expected behavior on MPE.

I have tagged the "no brainer" items with an "*".
I have tagged items that I suspect are low priority with a "-"

Please let me know if some items are obviously '*' items to you, and
likewise let me know about low priority items.


A. Freeware / Porting Environment:
----------------------------------

*1) Distribute the gnu (and other freeware) via FOS.  Do not only support
only web access to obtain the software, as is done today.
This is actively being worked on with the idea being to create a new FOS
account named FREEWARE. If there are serious drawbacks to this idea then
we can consider using patch technology to make the freeware available.
Note: the FREEWARE account structure and various support files are mimicked
(and thus will be beta tested :) via Lund's IPROF freeware tape.

Discussion point: if third parties are willing to organize the "FREEWARE"
tape, is it good use of HP time to make this data available on FOS when
it is widely and freely available elsewhere?

2) Support the gnu environment.  Our customers want to know that this suite
of tools is supported (not necessarily by HP?) before they commit large
development projects to g++.  There is a "chicken and the egg" issue
here since CSY wants to see an interest in g++ before they spend time
and money arranging for support.  My recommendation is have IPROF
attendees vote.  "Will you start using g++ and/or the other gnu tools for
production development within the next year if it officially supported?"
How important is HP support vs 3rd party support? It needs to be made clear
that portions of gnu are necessary for other products that are on MPE,
like Java.

3) CSY needs to make public certain header files so that g++ can be
sent back to the Free Software Foundation for re-distribution. Currently
Mark is under NDA on these header files, which *are* distributed with
hp-ux.  The header files define the SOM structures.

4) POSIX make is poor.  gmake is vastly superior but is not supported.
This issue goes away if gnu is supported.

5) We should relink all of HPBIN.SYS, the gnu files, the Java files, etc.
to use shared libraries (XLs).  This saves considerable disk space,
is common practice for MPE developers and makes program maintenance easier.
Where POSIX XLs have already been built we need to include them with FOS.

6) Support several alternate record separators and provide generic
emulation from one of these alternates to MPE fixed or variable and
vice versa.  Alternates should include: LF, CR, CRLF. The record
separator character should be a permanent attribute of a file.

7) Fix LINKEDIT to suppress the warning that the NMOBJ filecode is missing
Teach LINKEDIT to use signals so that link errors can be detected by
code that does wait(&status).

8) Consider enhancing execv() et. al. and wait() et. al. to also interrogate
CIERROR so that POSIX apps can invoke MPE apps and get expected POSIX
behavior (since the MPE apps don't use any signals).


B. Missing Functionality / Deficiencies
-----------------------------------------------

1) The select() function needs to support terminals.  This is known as the
"file descriptor" problem. rlogin, telnet, remsh, etc. would be easy ports
with this feature.  Java and Samba are impacted by the absence of this
expected feature.  We need to determine how much of the POSIX General Terminal
Interface (GTI) is required.  Full GTI is very expensive.

2) Incomplete implementation: libcurses, links, termIO, process management,
X11, chroot (esp. for annonymous ftp), pty/vty, fork performance, others?

3) Too many MPE subsystems do not directly support POSIX filenames:
LINKEDIT, TDP, EDITOR, HPEDIT, compilers, FCOPY, Transact, etc.  Minimally,
LINKEDIT and a non-vi editor should be enhanced to support POSIX names.

4) It is desirable to be able to run programs requiring capabilities
greater than PH (like MR, DS, PM) from directories under an MPE account.
Perhaps we need to re-think our (somewhat arbitrary) rule governing program
capabilities and directories.  We can fairly easily detect if a directory
is under an MPE account or group.  Maybe we can add capabilities to
directories. Maybe we can enhance ACDs to include capabilities paired to
subjects, in addition to the current subject:access pairs?  Maybe we
need to relax some of the DS, PM restrictions in place now.  Maybe the
cap check can be avoided for SM users, and/or implement setuid
programs, where the program assumes the privileges of its creator rather
than the user.  There is, however, great value in the MPE capability model
when compared to the unix model of "all or nothing".

Obviously symbolic links from the HFS namespace to an MPE group with the
required capabilities is how most folks workaround this issue.  Aside from
the greater maintenance with symbolic links, why are these not an
acceptable alternative?

*5) Some POSIX functions should not require PM: read/write to a port,
write to $stderr via the FWRITE intrinsic, I know there must be more!!??

*6) Support more special characters in POSIX filenames.  This will likely
necessitate defining a generic CI escape character, like "\".  Today "!"
acts sort of like an escape char in !!varname or !![expression], etc.

7) Support CGI MPE programs (in Pascal, COBOL, C, etc) and MPE scripts.
this includes letting $stderr be opened non-privileged, not requiring PM
to read/write to pipes, and more...

8) Allow inetd to pass a TCP socket connection via stdin and stdout, rather
than only fd 0 as today.  Is this a dup of 10 ??

9) Remove the 30,000 byte limit in our BSD sockets code.
This may be a CM carryover?

10) Allow terminal file descriptors to interoperate with network fd's.
Specifically, allow network sockets to be passed to processes that are not
using NetIPC. Support within the ioctl functions for I_SENDFD and IRECVFD
commands would improve the situation by allowing unrelated processes to pass
file descriptors to each other


C.Install / POSIX "Out-of-the-box"
----------------------------------

*1) The FOS /etc/profile file has several problems.  Jeff Kell and others
have enumerated the sections of the file that should be changed in order
to make POSIX more usable to anyone right "out of the box".
Include: several common aliases like "ll", "help", etc.  Check if
/usr/local/etc/profile exists and if so execute it at the end of /etc/profile,
this way users don't loose their customizations.

*2) General installation problems: files not cleaned up, no uninstall ability,
wrong permissions on files, missing files (like .exrc), etc.  Another problem
may be that each install possibly overwrites the customer's customized files.
install.sh fails with an instruction error (bug).

3) As part of POSIX installation, create a symbolic links from /bin/sh
(and other common shells) to /SYS/HPBIN/SH.  This keeps unix scripts that
start with #!/bin/sh working.

4) Change the shell to look for the .sh_history and .profile files from the
user's home group (~) rather than the CWD.  This eliminates the need for the
SH UDC to change the user's CWD to their home group -- which often is *not*
what they want done.



D. Documentation
----------------

*1) MPE POSIX has poor documentation: man pages are obsolete and inaccurate
in many places. Several of the POSIX papers, the Developer's kit documentation,
run-time library descriptions, man pages, shell/utility user's guide are
missing from CDROM.  The existing sockets manual is obsolete.  The MPE
Developers Kit manual has many errors, is missing the supported lstat()
function, missing many relevant MPE implementation details (like the
requirement to call GETPRIVMODE prior to setuid()), and many typos.


Z. Miscellaneous
-----------------

1) MPE POSIX has a split personality which is exasperbated by certain
mutually exclusive header files.  Part of POSIX is BSD Unix and part is
ATT System V Unix.  Ex: c89 and libbsd vs. gcc, termio.h vs termios.h.
We need to pick one (note hp-ux is leaning more towards SV). If we go
with gcc we may need to re-compile Samba (which is currently c89).

-2) It is desirable to have a single user name for MPE, like unix.  This
name can be mapped to a conventional MPE user.acct name.  This idea makes
utilities like who, finger, w, last, sendmail, annonymous ftp easier to port.
Unix only has one password: the user's password.  MPE can have user, account
and group.  The FTP (user,acct) password model my work fine.

-3) No other unixes uses our HPUID and HPGID databases for passwords and
groups.  If this is an issue perhaps we can converge these databases
with the unix /etc/passwd and /etc/group.  The current databases (HPUID,
HPGID) are designed for fast lookup.  Maybe we can create /etc/passwd
and /etc/group from HPUID and HPGID at boot, newuser, altuser, newacct and
altacct time?  Of course the existence of /etc/passwd will cause someone
to edit the file and then what?

4) The lack of a DNS server on MPE forces a non-MPE box into a site
if they wish to get on the internet.  Supporting DNS on MPE helps the
installed base by not requiring them to learn/support an additional O/S.
Additionally,  perhaps the "bind" package can be ported.  This provides
nslookup and the named daemon.  We may be able to get DHCP (or at least
bootp) too.

5) To better integrate MPE programs (esp. the CI) into the POSIX environment,
we need a pipe-to-fixed and pipe-to-variable format emulator (analogous
to our existing bytestream-to-fixed and bytestream-to-variable emulators).

6) Support direct logon to the POSIX shell, bypassing CI.PUB.SYS.  This
is being worked on as part of a System Limits ("CI elimination") project.

7) Support Control-C in the POSIX shell.  Possibly other interrupts too?
Related to "CI elimination" since the logon shell may want MPE break
functionality.

--