From: basto@cactus.org (Luis Basto)
Newsgroups: comp.unix.aix,news.answers
Subject: AIX Frequently Asked Questions (Part 2 of 2)
Summary: This posting contains a list of Frequently Asked Questions 
         and their answers about AIX, IBM's version of Unix.
Keywords: AIX RS/6000 questions answers
Date: 14 Dec 92 07:22:02 GMT
Expires: 15 Jan 93 01:23:45 GMT
Reply-To: basto@cactus.org (Luis Basto)
Followup-To: comp.unix.aix

Archive-name: aix-faq/part2
Last-modified: Dec 12, 1992
Version: 2.0


Version: $Id: aix.faq,v 2.0 12/12/92 basto $

Frequently Asked Questions to AIX 3.x and IBM RS/6000
_____________________________________________________

2.07: What's with malloc()?
        
malloc() uses a late allocation algorithm based on 4.3 BSD's malloc()
for speed.  This lets you allocate very large sparse memory spaces,
since the pages are not actually allocated until they are touched for
the first time.  Unfortunately, it doesn't die gracefully in the face of
loss of available memory.  See the "Paging Space Overview" under
InfoExplorer, and see the notes on the linker in this document for an
example of an ungraceful death.

If you want your program to get notified when running out of memory, you
should handle the SIGDANGER signal.  The default is to ignore it. 
SIGDANGER is sent to all processes when paging space gets low, and if
paging space gets even lower, processes with the highest paging space
usage are sent the SIGKILL signal.

malloc() is substantially different in 3.2, allocating memory more
tightly.  If you have problems running re-compiled programs on 3.2, try
compiling them with MALLOCTYPE=3.1. 


2.08: Why does xlc complain about 'extern char *strcpy()'

The header <string.h> has a strcpy macro that expands strcpy(x,y) to
__strcpy(x,y), and the latter is then used by the compiler to generate
inline code for strcpy.  Because of the macro, your extern declaration
contains an invalid macro expansion.  The real cure is to remove your
extern declaration but adding -U__STR__ to your xlc will also do the trick.


2.09: Why do I get 'Parameter list cannot contain fewer ....'

This is the same as above.


2.10: Why does xlc complain about '(sometype *)somepointer = something'

Software that is developed using GNUC may have this construct.  However,
standard C does not permit casts to be lvalues, so you will need to
change the cast and move it to the right side of the assignment.  If you
compile with 'cc', removing the cast completely will give you a warning,
'xlc' will give you an error (provided somepointer and something are of
different types - but else, why would the cast be there in the first place?)


2.11: Some more common errors

Here are a few other common errors with xlc:

305 |     switch((((np)->navigation_type) ? (*((np)->navigation_type)) :
      ((void *)0)))
      .a...........  
a - 1506-226: (S) The second and third operands of the conditional
operator must be of the same type.

The reason for this is that xlc defines NULL as (void *)0, and it does
not allow two different types as the second and third operand of ?:. 
The second argument above is not a pointer and the code used NULL
incorrectly as a scalar.  NULL is a nil pointer constant in ANSI C and
in some traditional compilers.

You should change NULL in the third argument above to an integer 0.


2.12: Can the compiler generate assembler code?

The traditional -S option is not supported by the XLC compiler, and
there is in fact no way to make the compiler generate machine readable
assembler code.  The option -qlist will generate a human readable one in
the .lst file.


2.13: Curses

Curses based applications should be linked with -lcurses and _not_ with
-ltermlib.  It has also been reported that some problems with curses are
avoided if your application is compiled with -DNLS.

Peter Jeffe <peter@ski.austin.ibm.com> also notes:

>the escape sequences for cursor and function keys are *sometimes*
>treated as several characters: eg. the getch() - call does not return
>KEY_UP but 'ESC [ C.'

You're correct in your analysis: this has to do with the timing of the
escape sequence as it arrives from the net.  There is an environment
variable called ESCDELAY that can change the fudge factor used to decide
when an escape is just an escape.  The default value is 500; boosting
this a bit should solve your problems.

Further on the matter of curses, I've received the comments below
concerning extended curses:

From: Christopher Carlyle O'Callaghan <asdfjkl@wam.umd.edu>

1) The sample program in User Interface Programming Concepts, page 7-13
   is WRONG. Here is the correct use of panes and panels.  (This is
   one of the IBM manuals that comes with the RS/6000)

#include <cur01.h>
#include <cur05.h>

main()
{
PANE *A, *B, *C, *D, *E, *F, *G, *H;
PANEL *P;

initscr();

A = ecbpns (24, 79, NULL, NULL, 0, 2500, Pdivszp, Pbordry, NULL, NULL);

D = ecbpns (24, 79, NULL, NULL, 0, 0,    Pdivszf, Pbordry, NULL, NULL);
E = ecbpns (24, 79, D,    NULL, 0, 0,    Pdivszf, Pbordry, NULL, NULL);

B = ecbpns (24, 79, A, D, Pdivtyh, 3000, Pdivszp, Pbordry, NULL, NULL);

F = ecbpns (24, 79, NULL, NULL, 0, 0,    Pdivszf, Pbordry, NULL, NULL);
G = ecbpns (24, 79, F,    NULL, 0, 5000, Pdivszp, Pbordry, NULL, NULL);
H = ecbpns (24, 79, G,    NULL, 0, 3000, Pdivszp, Pbordry, NULL, NULL);

C: = ecbpns (24, 79, B, F, Pdivtyh, 0, Pdivszf, Pbordry, NULL, NULL);

P = ecbpls (24, 79, 0, 0, "MAIN PANEL", Pdivtyv, Pbordry, A);

ecdvpl (P);
ecdfpl (P, FALSE);
ecshpl (P); 
ecrfpl (P);
endwin();
}

2) DO NOT include <curses.h> and any other <cur0x.h> file together.
   You will get a bunch of redefined statements.

3) There is a CURSES and EXTENDED CURSES stuff.  Use only one or the
   other. If the manual says that they're backwards compatible or some
   other indication that you can use CURSES routines with EXTENDED,
   don't believe it. To use CURSES you need to include <curses.h> and
   you can't (see above).

4) If you use -lcur and -lcurses in the same link command, you will get
   Memory fault (core dump) error...  YOU CANNOT use both of them at the
   same time. -lcur is for extended curses, -lcurses is for regular curses.

5) When creating PANEs, when you supply a value (other than 0) for the
   'ds' parameter and use Pdivszf value for the 'du' parameter, the 'ds'
   will be ignored (the sample program on page 7-13 in User Interface
   Programming Concepts is wrong.) For reasons as yet undetermined,
   Pdivszc doesn't seem to work (or at least I can't figure out how to
   use it.)

6) If you're running into bugs and can't figure out what is happening,
   try the following:
   include -qextchk -g in your compile line
	-qextchk will check to make sure you're passing the right number of
  	 parameters to the procedures
	-g will allow you to use the inline debugger on Unix/AIX.
   to use the debugger after you compiled it, 
	type: dbx <fn>
	the command 'help' will give you all of the possible commands to
   	use in the debugger... have fun... :)

7) Do not use 80 as the number of columns if you're gonna use the whole
   screen. The lower right corner will get erased.  Use 79 instead.

8) If you create a panel, you must create at least 1 pane, otherwise you
   will get a Memory fault (core dump).

9) When creating a panel, if you don't have a border around it, any title
   you want will not show up.

10) to make the screen scroll down:
    wmove (win, 0, 0);
    winsertln (win)

11) delwin(win) DOESN'T WORK IN EXTENDED WINDOWS.

    Anyway.. to make it appear as if a window is deleted, you need to do
    the following:
    for every window that you want to appear on the screen
	touchwin(win)
	wrefresh(win)

    you must make sure that you do it in the exact same order as you put
    them on the screen (i.e., if you called newwin with A, then C, then B,
    then you must do the loop with A, then C, then B, otherwise you won't
    get the same screen back).  The best thing to do is to put them into
    an array and keep track the of last window index.

12) mvwin(win, line, col) implies that it is only used for viewports and
    subwindows... It can also be used for the actual windows themselves.

13) If you specify the attribute of a window using wcolorout(win), any
    subsequent calls to chgat(numchars, mode) or any of it's relatives
    will not work. (or at least they get very picky...)


2.14: How do I speed up linking

Please refer to sections 2.03 and 2.06 above.


2.15: What is deadbeef?

When running the debugger (dbx), you may have wondered what the
'deadbeef' is you occasionally see in registers.  Do note, that
0xdeadbeef is a hexadecimal number that also happens to be some kind
of word (the RS/6000 was built in Texas!), and this hexadecimal number
is simply put into unused registers at some time, probably during
program startup.

_____________________________________________________________________________
3.00: Fortran and other compilers

This section covers Fortran, Pascal, Ada, etc.  On fortran, there seem
to have been some problems with floating point handling, in particular
floating exceptions.


3.01: I have problems mixing fortran and C code, why?

A few routines (the most famous one is getenv) exist in both the fortran
and the C library but with different parameters.  You can therefore not
have a mixed program that call getenv from both C and fortran code. 
When linking a mixed program calling getenv from either, be sure to
specify the correct library first on your command line.  If your main
program is fortran and you call getenv from a C routine, you must
therefore add -lc to the xlf command line for linking.

If you want to call getenv from both C and fortran code in a mixed
program, you need to compile all the fortran code with the -qextname
option.  This appends an underscore to all fortran external names and
ensures that no confusion occurs with default C libraries.  Of course an
underscore should be added by hand in the C code to the name of all
routines which are called form fortran and to all calls to fortran
routines.  If you do that, fortran will call something which appears to
C as getenv_ and there will be no confusion.


3.02: How do I statically bind fortran libraries and dynamically
      bind C libraries?
From: amaranth@vela.acs.oakland.edu (Paul Amaranth)

[ Editor's note: Part of this is also discussed above under the C compiler
  discussions, but I felt it was so valuable that I have left it all in. 
  I've done some minor editing, mostly typographical. ]

The linker and binder are rather versatile programs, but it is not
always clear how to make them do what you want them to.  In particular,
there are times when you do not want to use shared libraries, but
rather, staticly bind the required routines into your object.  Or, you
may need to use two version of the same routine (eg, Fortran & C).  Here
are the results of my recent experiments.  I would like to thank Daniel
Premer and Brad Hollowbush, my SE, for hints.  Any mistakes or omissions
are my own and I have tended to interchange the terms "linker" and
"binder".  These experiments were performed on AIX 3.1.2.  Most of this
should be applicable to later upgrades of 3.1.

1)  I have some C programs, I want to bind in the runtime routines.  How
    do I do this? [Mentioned in section 2.04 of this article as well, ed.]

    You can put the -bnso binder command on the link line.  You should
    also include the -bI:/lib/syscalls.exp control argument:
      
      $ cc *.o -bnso -bI:/lib/syscalls.exp -o foo

    This will magically do everything you need.  Note that this will bind
    _all_ required routines in.  The -bI argument tells the linker that
    these entry points will be resolved dynamically at runtime (these are
    system calls).  If you omit this you will get lots of unresolved 
    reference messages.

2)  I want to staticly bind in the Fortran runtime so a) my customers do
    not need to buy it and b) I don't have to worry about the runtime
    changing on a new release.  Can I use the two binder arguments in
    1) to do this?

    You should be able to do so, but, at least under 3002, if you do
    you will get a linker error referencing getenv.  In addition, there
    are a number of potential conflicts between Fortran and C routines.
    The easy way just does not work.  See the section on
    2 stage linking for C and Fortran on how to do this.  The getenv
    problem is a mess, see the section on Comments & Caveats for more.

3)  I have a mixture of C and Fortran routines, how can I make sure
    that the C routines reference the C getenv, while the Fortran routines
    reference the Fortran getenv (which has different parameters and, if
    called mistakenly by a C routine results in a segmentation fault)?

    You can't.  Only one symbol definition is allowed, and it will be the
    _first_ definition on the _last_ link.  Here is the quote from the 
    ld info file:

       In this version of ld, the first definition of each symbol in
       the link takes precedence and is used even if the first reference
       follows the definition.

    The only way I can possibly think of to do this is extremely messy:
    Make the C and Fortran routines separate modules.  Staticly bind them
    with their libraries.  Have them dynamicly call each other.  ech.
    I haven't tried this, however.

    If you want to bind everything together, write yourself an interface
    in one language to use the other's routine.  I did this with getenv
    and it works tolerably well.

4)  I have C and Fortran routines.  I want to bind in the xlf library, while
    letting the rest of the libraries be shared.  How do I do this?

    You need to do a 2 stage link.  In the first stage, you bind in the
    xlf library routines, creating an intermediate object file.  The
    second stage resolves the remaining references to the shared libraries.

    This is a general technique that allows you to bind in specific system
    routines, while still referencing the standard shared libraries.

    Specifically, use this command to bind the xlf libraries to the Fortran
    objects:

       $ ld -bh:4 -T512 -H512 <your objects> -o intermediat.o \
         -bnso -bI:/lib/syscalls.exp -berok -lxlf -bexport:/usr/lib/libg.exp \
         -lg -bexport:<your export file>

    The argument -bexport:<your export file> specifies a file with the
    name of all entry points that are to be visible outside the intermediate 
    module.  Put one entrypoint name on a line.  The -bI:/lib/libg.exp line 
    is required for proper functioning of the program.  The -berok argument 
    tells the binder that it is ok to have unresolved references, at least 
    at this time (you would think -r would work here, but it doesn't seem to).  
    The -bnso argument causes the required modules to be imported
    into the object.  The -lxlf, of course, is the xlf library.

    Then, bind the intermediate object with the other shared libraries in
    the normal fashion:

       $ ld -bh:4 -T512 -H512 <C or other modules> intermediate.o \
         /lib/crt0.o -lm -lc

    Note the absence of -berok.  After this link, all references should
    be resolved (unless you're doing a multistage link and making another
    intermediate).

    NOTE THE ORDER OF MODULES.  This is extremely important if, for example,
    you had a subroutine named "load" in your Fortran stuff.  Putting the
    C libraries before the intermediate module would make the C "load"
    the operable definition, rather than the Fortran version EVEN THOUGH 
    THE FORTRAN MODULE HAS ALREADY BEEN THROUGH A LINK AND ALL REFERENCES 
    TO THE SYMBOL ARE CONTAINED IN THE FORTRAN MODULE.  This can
    be extremely difficult to find (trust me on this one :-)  Is this
    a bug, a feature, or what?
    
    [As mentioned in section 2.03 of this article, it is a feature that you
    can replace individual objects in linked files, ed.]

    The result will be a slightly larger object than normal.  (I say slightly
    because mine went up 5%, but then its a 2 MB object :-)


Comments & Caveats:

   From the documentation the -r argument to the linker should do what
   -berok does.  It does not.  Very strange results come from using the
   -r argument.  I have not been able to make -r work in a sensible manner
   (even for intermediate links which is what it is supposed to be for).
   Note: this is one of the things I gave up on.  I would like to hear
   from anyone with more info on this.

   When binding an intermediate module, use an export file to define the
   entry points you want visible in the later link.  If you don't do this,
   you'll get the dreaded "unresolved reference" error.  Import files name
   entry points that will be dynamically resolved (and possibly where).

   If you are in doubt about what parameters or libraries to link, use the
   -v arg when linking and modify the exec call that shows up into 
   an ld command.  Some thought about the libraries will usually yield an
   idea of when to use what.  If you don't know what an argument is for,
   leave it in.  It's there for a purpose (even if you don't understand it).

   Watch the order of external definitions (ie, libraries) when more than
   one version of a routine may show up, eg "load".  The first one defined
   on the ld command line is the winner.  

   The getenv (and system and signal) problem is a problem that started out
   minor, got somewhat worse in 3003 and, eventually will be correctly fixed.
   Basically, you should extract the 3002 version of these three routines
   from xlf.a before doing the update and save them away, then link these
   routines in if you use these Fortran system services.  


3.03: How do I check if a number is NaN?
From: sdl@glasnost.austin.ibm.com (Stephen Linam)

NaN is "Not a Number".  It arises because the RISC System/6000 uses
IEEE floating point arithmetic.

To determine if a variable is a NaN you can make use of the property
that a NaN does not compare equal to anything, including itself.
Thus, for real variable X, use

	IF (X .NE. X) THEN	! this will be true if X is NaN

Floating point operations which cause exceptions (such as an overflow)
cause status bits to be set in the Floating Point Status and Control
Register (FPSCR).  There is a Fortran interface to query the FPSCR, and
it is described in the XLF Fortran manuals -- I don't have the manuals
right here, but look for FPGETS and FPSETS.

I don't know of any tutorials about IEEE Floating Point beyond the
standards themselves: ANSI/IEEE STD 754-1985 (IEEE Standard for Binary
Floating-Point Arithmetic) and ANSI/IEEE STD 854-1987 (IEEE Standard for
Radix-Independent Floating-Point Arithmetic), both available from IEEE. 
The IBM manual "Risc System/6000 Hardware Technical Reference - General
Information" (SA23-2643) describes what floating point exceptions can
occur and which bits are set in the FPSCR as a result of those exceptions.

______________________________________________________________________________
4.00: Public Domain software

There is a lot of interest in PD software, and a number of people have
compiled some of this.  With the increasing interest in the RS/6000,
configuration files, etc. is often seen in PD software or can be
obtained from people who already ported it.


4.01: How do I find sources?

[ dick@ccnext.ucsf.edu (Dick Karpinski) asked me to include this 
 information, and he forwarded me an article from jik@MIT.Edu
 (Jonathan Kamens).  Ed. ]

There is a newsgroup devoted to posting about how to get a certain 
source.  It is however strongly urged to follow the guidelines in
the article How_to_find_sources(READ_THIS_BEFORE_POSTING), which you
can get via anonymous ftp from pit-manager.mit.edu (18.172.1.27):

/pub/usenet/comp.sources.wanted/H_t_f_s_(R_T_B_P)

Also available from mail-server@pit-manager.mit.edu by sending a mail
message containing:

send usenet/comp.sources.wanted/H_t_f_s_(R_T_B_P)

Send a message containing "help" to get general information about the
mail server.

If you don't find what you were looking for by following these
guidelines, you can post a message to comp.sources.wanted.


4.02: Are there any ftp sites?

Here is a list of some sites that are supposed to have RS/6000 specific
software.  I haven't verified all the entries.

aixpdslib.seas.ucla.edu	128.97.2.211	pub
acd.ucar.edu		128.117.32.1 	pub/rs6000         
acsc.acsc.com   	143.127.0.2	pub
byron.u.washington.edu	128.95.48.32	pub/aix/RS6000
cs.utk.edu		128.169.201.1	pub/ibm_rs6000
merit.edu		35.1.1.42	pub/xntp
lightning.gatech.edu	128.61.10.8	pub/aix
tesla.ee.cornell.edu	128.84.253.11	pub
nic.funet.fi 		128.214.6.100	pub/unix/AIX/RS6000

The first one above is dedicated to software running on AIX.  It might
not always be the latest versions of the software, but it has always
been ported to AIX (normally AIX version 3 only).  Once connected, you
should retrieve the files README and pub/ls-lR.

Please note that the last one is in Finland, i.e.  in EUROPE! They are
having much too many people ftp'ing from the US which is hard on the
transatlantic link - further, most of the software it carries has been
taken from US sites originally.  Therefore, please use this site ONLY if
you are in Europe, preferably only from the northern part of Europe. 

Further, haedener@iacrs1.unibe.ch (Konrad Haedener) has an archive on
a system in Switzerland.  Here is his information about the archive:

As previously announced I have opened our machine for anonymous FTP.  I
have a small but growing collection of RS/6000 software, i.e. versions
of popular software that should readily compile under AIX 3.1.5.

Contributions are always welcome (please consult the /README file).
This is host iacrs1.unibe.ch (130.92.11.3).

Do remember, that Switzerland is in Europe, i.e. keep the transatlantic
transfers on a minimum.


4.03: General hints

In general, curses based applications should be linked with -lcurses and
_not_ with -ltermlib.  It has also been reported that compiling with
-DNLS helps curses based programs.

Note that the RS/6000 has two install programs, one with System V flavor
in the default PATH (/etc/install with links from /usr/bin and /usr/usg),
and one with BSD behavior in /usr/ucb/install.


4.04: GNU Emacs
From: Bill Wohler <wohler@sap-ag.de>

Version 18.57 of GNU Emacs has RS/6000 support.  Here are a few hints:
In the src directory, copy config.h-dist to config.h and make the
following changes:

	o change "s-bsd4-2.h" to "s-aix3-1.h"
	o change "m-vax.h" to "m-ibmrs6000.h"
	o define HAVE_X_WINDOWS
        o define X11
        o define PURESIZE 135000 (120000 is enough without X)
        o if you don't want to compile with debugging information, add:
          #define C_DEBUG_SWITCH
          #define C_OPTIMIZE_SWITCH -O

Now, run "make" and ignore the sed problems while building xmakefile.  

Emacs will core-dump if it is stripped, so don't strip when you install
it.  You can e.g.  edit (a copy of the) Makefile in src replacing all
'install -s' with /usr/ucb/install.

[The latest version of emacs is 18.59 but I did not have a chance to
look at it yet. - ed.]


4.05: gcc/gdb

GNU C version 2.0 supports the the RS/6000, and compiles straight out of
the box.  You may, however, experience that compiling it requires large
amounts of paging space.

The latest versions of gcc and gdb, currently 2.3.1 and 4.6
respectively, requires a patch to the 'as' assembler to compile.  Call
IBM software support and request patch U4     .

4.06: GNU Ghostscript 2.3

The PostScript interpreter GNU Ghostscript Version 2.3 supports the
RS/6000 and can be found on various ftp sites.

4.07: TeX

TeX can be retrieved via ftp from rusmvl.rus.uni-stuttgart.de (129.69.1.12).


4.08: perl

A diff should have been posted here, but I haven't seen it.  If you use
bsdcc from the bsdport document, say no to use perl's builtin malloc(),
and edit config.H to '#define HAS_SYMLINK', you should be on your way. 
Bill Wohler tells me that perl will run without editing config.H and
with cc as well.  So just say no to use perl's malloc().

Doug Sewell <DOUG@YSUB.YSU.EDU> adds:

In addition to not using the perl-provided malloc, when asked if you
want to edit config.sh, change 'cppstdin' from the wrapper-program
to '/lib/cpp'.

The perl wrapper name is compiled into perl, and requires that you keep
that file in the source directory, even if you blow away the rest of
the source.  /lib/cpp will do the job by itself.  I suspect this will
be fixed in perl 4.0pl11 Configure script.

Also, beware if you have gdbm installed per the instructions in the FAQ.
Gdbm is compiled with bsdcc; perl (as I installed it, anyway) was built
with cc, so I used the IBM-provided ndbm routines.


4.09: X-Windows

IBM has released X11R4 and Motif 1.1 in combination with AIX 3.2.0. 
X11R5 is available as AIXwindows 1.2.3 since AIX Level 3.2.3.

Those of you on 3.1 might want to read the following.  Some people from
IBM have released patches for the X11R4 distribution tape available via
anonymous FTP from export.lcs.mit.edu.  Note that as with the RT, there
is no X11R4 server to build, just the libraries.

From: Frederick Staats <fritz@saturn.ucsc.edu>

In mit/config/ibm.cf
	Updated OSName (AIX 3.1.6)

In mit/config/site.def
	Changed ProjectRoot /usr/local/X11R5
	Added ManSuffix (to change suffix from n to 1)
	Added InstallXdmConfig YES and
	InstallXinitConfig YES
	Added HasXdmAuth YES (Copied mit/lib/Xdmcp/Wraphelp.c to source tree)
	Added InstallFSConfig YES

In mit
	nohup make BOOTSTRAPCFLAGS="-Daix" World &
	nohup make install &
	nohup make install.man &

Please note that there are known bugs in Xibm server of the X11R5
release that prevent "xdm" from being usable.  A simple patch (that I'm
not free to redistribute) should be out very soon through the regular
contrib channels.

Also note, that some files in mit/extensions/lib/PEX/c_binding are very
large and are told to require at least 150 Mb paging space to compile.

Apparently, only the Skyway adapter is supported for X11R5.

[the Skyway adapter is "IBM Color Graphics Display Adaptor" in IBM
documents, the "IBM High-Performance N-Bit 3D Color Graphics Processor"
is the Sabine.  Ed.]


From: pierce@claven.cambridge.ibm.com (Andrew Pierce)

The following bugs have been reported with the R5 server and are fixed
(hopefully!), and the fixes have been sent to MIT for inclusion in the
first patch set:

BackingStore does not seem to work (twm menus blank and xman pulldown 
	menus only display once.
Problem in keyclick restoration/bell
Problem with option parsing (-bs does not turn off backing store).
Problem with setting non-blocking I/O on X Connections 
	(resizing xcalc wedges the server).
xdm core dumps. 

There is also a problem in initializing the display adapter when the R5
server is brought up from a poweroff condition on the RISC/6000.  We are
still investigating this problem.  A temporary workaround is to run the
AIX product server first, which seems to do the right thing in
initializing the adapter, then run the R5 server.

As for whether the OSF/Motif window manager will work with the R5
server, I don't know of any reasons why it shouldn't, and I've run it
now and again, although tvtwm is my preferred wm.


From: cary@jove.Colorado.EDU (John R. Cary)

There are (at least) three problems.  

1) The fonts as built with the IBM (Greening) patches of X11R4 do not
work with the AIX3.1.5 server because (according to mleisher@NMSU.Edu)
they likely have the wrong byte order.
2) The ibm fonts that come with AIX3.1.5 must be converted to .pcf fonts
to work with the X11R5 server.
3) Info always looks for its fonts (in /usr/lpp/info/X11fonts)
regardless of which server you are using.  So if you use the X11R5
server, info loads the AIX3.1x .snf fonts, which do not work with the
X11R5 server.

Using the X11R5 server (my choice) means that you must fix problems 2
and 3.

My fix of 3: was simply to rename the info fonts directory so that info
could not find it and load it.  Another fix (I am told) is to set one's
font path with /usr/lpp/info/X11fonts last so that another fonts is
loaded first.  This did not work for me, perhaps because of differences
in my fonts.alias file.

My fix of 2: I first got snftobdf from the X11 contrib directory on
export.lcs.mit.edu and built it. I then made a directory:
mkdir /usr/local/X11R5/lib/X11/fonts/ibm
which I added to my font path with xset in my .xinitrc file.
Then I constructed the chosen .pcf fonts one at a time:
cd /usr/lib/X11/fonts
snftobdf Rom10.snf | bdftopcf >/usr/local/X11R5/lib/X11/fonts/ibm/Rom10.pcf
I actually did this with this script:

#!/bin/ksh 
# A script to convert desired AIX fonts to .pcf fonts for X11R5 
for arg in 6x10 Bld14 Rom14 Rom6 6x12 Bld17 Rom16 Rom7 vtbold 6x13
Erg 14 Rom17 Rom8 vtdhbot 8x13 Itl14 Rom22 cursor vtdhtop 8x13B Rom10
Rom28 fixed vtdwidth 9x15 Rom11 Rom29 Vtsingle 
do

echo "snftobdf $arg.snf | bdftopcf >/usr/local/X11R5/lib/X11/fonts/ibm/$arg.pcf"
snftobdf $arg.snf | bdftopcf >/usr/local/X11R5/lib/X11/fonts/ibm/$arg.pcf

done

If you want to continue using the AIX3.1x server and you want to use the
X11R4 fonts, you must convert these fonts to the correct bit order.  I
did not do this, and so DO NOT KNOW the correct procedure.  I imagine
that once the correct bit order is determined, one can use snftobdf to
convert fonts back tobdf format then bdftosnf with correct AIX3.1.  bit
order to get things correct with the aix3.1x server.


4.10: bash

Bash is ported and has some patches on prep.ai.mit.edu.  The current
version is 1.12 and seems to work fine.


4.11: Elm

Elm should be pretty straightforward, the only thing to remember is to
link with -lcurses as the only curses/termlib library.  You may also run
into the problem listed under point 2.13 above.

4.12: Oberon 2.2

From: afx@muc.ibm.de (Andreas Siegert)

Oberon is Wirth's followon to Modula-2, but is not compatible.  A free
version of Modula-3 is available from DEC/Olivetti at gatekeeper.dec.com.  
This is also not a Modula-2 replacement but a new language.  There are
currently two M2 compilers for the 6000 that I know of.  One from
Edinburgh Portable Compilers, contact +44 31 225 6262 (UK) or the
Gardens Point compiler contact +41 65 520311 (Switzerland).

Oberon can be obtained via anonymous ftp from neptune.inf.ethz.ch
(129.132.101.33) under the directory Oberon/RS6000 or gatekeeper.dec.com
(16.1.0.2).


4.13: Kermit

Available from watsun.cc.columbia.edu [128.59.39.2] directory kermit/sw. 
Get it, uncompress, untar, and "make rs6000", and it works.

5a184 had a bug with the lock file names.  Grab the latest from
watsun.cc.columbia.edu in the kermit/test directory.  (5a is still
officially in beta, so get your bug reports in quick if you want them
fixed before 5b.)


4.14: Gnu dbm
From: doug@cc.ysu.edu (Doug Sewell)

Here's the fixes for RS/6000's: 

apply this to testgdbm.c:
158c158
<   char opt;
---
>   int opt;
166c166
<   while ((opt = getopt (argc, argv, "rn")) != -1)
---
>   while ((opt = getopt (argc, argv, "rn")) != EOF)

Apply this to systems.h:
111a112,114
> #ifdef RS6000
> #pragma alloca
> #else
112a116
> #endif

To compile, edit the Makefile.  Set CC to bsdcc (see /usr/lpp/bos/bsdport
if you don't have 'bsdcc' on your system) and set CFLAGS to -DRS6000 and
whatever options (-g, -O) you prefer.  Don't define SYSV.

Doug Sewell, Tech Support, Computer Center, Youngstown State University
doug@ysu.edu doug@cc.ysu.edu doug@ysub.bitnet uunet!ysu.edu!doug


4.15: tcsh
From: cordes@athos.cs.ua.edu (David Cordes)

tcsh : available from telsa.ee.cornell.edu  (pub/tcsh-6.00 directory)
Compiles with no problems.  You must edit /etc/security/login.cfg
to permit users to change to this shell (chsh), adding the path
where the shell is installed (in my case, /usr/local/bin/tcsh).


4.16: Kyoto Common Lisp
From: cordes@athos.cs.ua.edu (David Cordes)

kcl : Kyoto Common Lisp.  The sources are available from "cli.com".  The
kcl package is the needed base, then also retrieve the latest akcl
distribution.  akcl provides a front-end that "ports" the original kcl
to a number of different platforms.  The port to the 6000s worked with
no problems.  However, you must be "root" for the make to work properly
with some memory protection routines.


4.17: TCL
From: Doug Sewell <DOUG@YSUB.YSU.EDU>

   === building the tcl library ===

First, V3.3 compiled with BSDCC, but tclTest would core-dump.

I retrieved V4.0 from the alt.sources archives, but couldn't get it
to compile on an RS6000, using either the BSD or SYSV versions.

Finally, someone mentioned that Tcl5.0 was available.

I ftp'd sprite.berkeley.edu.  The only version of 'tcl' was 3.3.
The version 5 is a part of 'tk.tar.Z'.  You have to un-tar-Z that
and get tcl 5.0 out of there.

Next, I built it with 'bsdcc' (make "CC=bsdcc").  I had to replace the
provided stdlib.h with the AIX stdlib.h because of some conflicts.  I
built tclTest, cd'd to 'tests', ran ../tclTest and entered 'source all'.

I got an error in file.test when I ran the program as root.  When I ran
it as anyone else, it runs fine - it has something to do with a file you
shouldn't be able to get to, but because I wase root I could anyway.

I copied tcl.a to /usr/lib/libtcl.a, and put tcl.h into /usr/include. 
Your procedures for local libraries and includes may vary.  I also put
tclTest in a public executable directory, since it was a way to putter
with tcl interactively.

NOTE: since libtcl.a was built with bsdcc, you'll probably have to use
bsdcc to write or support any tcl applications, including expect.


4.18: Expect
From: Doug Sewell <DOUG@YSUB.YSU.EDU>
   
To build the command-interpreter version, you must have the tcl
library built successfully.  The expect library doesn't require tcl.
Note: Expect and its library are are built with bsdcc, so applications
using the library probably also need to be developed with bsdcc.

I ftp'd expect from ftp.cme.nist.gov.

You need to change several lines in the makefile.  First you need
to customize source and target directories and files:
#
TCLHDIR = /usr/include
TCLLIB = -ltcl
MANDIR = /usr/man/manl               (local man-pages)
MANEXT = l
BINDIR = /u/local/bin
LIBDIR = /usr/lib
HDIR = /usr/include
...
Next set the compiler, switches, and configuration options:
#
CC = bsdcc
CFLAGS = -O
...
PTY_TYPE = bsd
...
INTERACT_TYPE = select
...
Then you need to make these changes about line 90 or so:
comment out CFLAGS = $(CLFLAGS)
un-comment these lines:
CFLAGS = $(CLFLAGS) $(CPPFLAGS)
LFLAGS = ($CLFLAGS)

Then run 'make'.

You can't run some of the examples without modification (host name,
etc).  I don't remember if I ran all of them or not, but I ran enough
that I was satisfied it worked.

______________________________________________________________________________
5.00: Third party products

[ Editor's note: Entries in this section are edited for formatting and for
  the purpose of not being like advertising. ]

Some information in here seems rather outdated......


5.01: Disk/Tape/SCSI
From: anonymous

- Most SCSI disk drives work (IBM resells Maxtor, tested Wren 6&7 myself)

- Exabyte: Unfortunately only the ones IBM sells are working

- STK 3480 "Summit": Works with Microcode Version 5.2b


5.02: Disks
From: bowman@uiatma.atmos.uiuc.edu

For third-party disks for the RS6000, I can recommend:  Ken Been at
National Peripherals, (708) 325-4151. 


5.03: Memory
From: blain@VM.UoGuelph.CA (Doug Blain)

I have received a FAX from Kingston Technologies on SIMM memory upgrades
for the RS6000 (model 320/520 only so far).  They are complete
replacements for the installed SIMMs from IBM ( you get to keep the IBM
SIMMs and perhaps use them elsewhere).  They have a 16, 32 and 64 MB
range of kits.  The quoted list prices are;

      16 MB SIMM Kit   $ 3,995
      32 MB SIMM Kit   $ 8,995
      64 MB SIMM Kit   $21,585

One option they mention in their letter is to purchase an additional
memory card from IBM (type S1 or higher) and populate it with the new
memory, since the RS/6000 will support two memory cards.  The list price
for the IBM 16mb SIMMs is $9520 (however our SE is hinting at price
reductions of 25% soon).  Kingston Technologies can be contacted at
714-435-2600.  Standard disclaimers apply...no association, benefits, etc. 

From: dick@ccnext.ucsf.edu (Dick Karpinski)

Dick Verling at 415-381-2081 offers a 64MB upgrade for a bit over $5k.


5.04: Others
From: anonymous
       
IBM RISC System/6000 Interface Products

National Instruments Corporation announced April 13 a family of
instrumentation interface products for the IBM RISC System/6000
workstation family.  The interface family consists of three products
that give the RISC System/6000 connectivity to the standards of VMEbus,
VXIbus and GPIB.  For more information, contact National Instruments
Corporation, 512-794-0100 or 1-800-433-3488.


5.05: IBM list of third party products
From: marc@ibmpa.awdpa.ibm.com (Marc Pawliger)

Marc Pawliger post an extensive list periodically on this newsgroup
about various third party hardware products for the RS/6000.  This list
can also be ftp'd from ibminet.awdpa.ibm.com.


5.06: C++ compilers

There are two software vendors providing C++ compilers, Glockenspiel and
Greenhills.  xlC++ is available from IBM. 
______________________________________________________________________________
6.00: Miscellaneous other stuff

6.01: Can I get support by email?

AIXServ is a service tool that allows users connected to the internet
and usenet to report problems using unix mail (E-Mail).  AIXServ is
available at no charge, to request a copy of this package send a note to
one of the following E-Mail addresses:

	Internet:        aixbugs%aixserv@uunet.UU.NET
	USENET:          uunet.UU.NET!aixserv!aixbugs
 austin.ibm.com domain:  aixbugs@austin.ibm.com

with the subject of "package".

The package will be mailed electronically and will contain instructions
for using AIXServ.

Using AIXServ, customers have the ability to 1) open new problem reports
2) update existing problem records 3) Request a status update on an
existing problem record.


6.02: Some RS232 hints
From: graeme@ccu1.aukuni.ac.nz

Q: How do you connect a terminal to the RS232 tty ports when not using
   the standard IBM cable & terminal transposer?
A: 1- Connect pins 2->3, 3->2, 7->7 on the DB25's
   2- On the computer side, loop pins 8->20 (DCD & DTR)

When booting from diskettes, the port speed is always 9600 baud.  If you
use SMIT to set a higher speed (38400 is nice) for normal use, remember
to reset your terminal before booting.

Q: How do you connect a printer to the RS232 tty ports
A: 1- Connect pins 2->3, 3->2, 7->7 on the DB25's
   2- On the computer side, loop pins 4->5 (CTS & RTS)


6.03: VT100 key bindings for aixterm
From: haedener@iac.unibe.ch (Konrad Haedener)

Add this to your .Xdefaults file and start your VAX session with
'aixterm -v -name vt100 -e telnet MYVAXHOST'

-----
vt100.foreground: Wheat
vt100.background: MidnightBlue
vt100.font: Rom14.500
vt100.geometry: 80x25+0+0
vt100.vt102: true
vt100.fullcursor: false
vt100.pointerColor: coral
vt100.cursorColor: gray100
vt100.translations:    <Key>F1: string(0x1b) string("OP") \n\
                       <Key>F2: string(0x1b) string("OQ") \n\
                       <Key>F3: string(0x1b) string("OR") \n\
                       <Key>F4: string(0x1b) string("OS") \n\
                       <Key>KP_0: string(0x1b) string("Op") \n\
                       <Key>KP_1: string(0x1b) string("Oq") \n\
                       <Key>KP_2: string(0x1b) string("Or") \n\
                       <Key>KP_3: string(0x1b) string("Os") \n\
                       <Key>KP_4: string(0x1b) string("Ot") \n\
                       <Key>KP_5: string(0x1b) string("Ou") \n\
                       <Key>KP_6: string(0x1b) string("Ov") \n\
                       <Key>KP_7: string(0x1b) string("Ow") \n\
                       <Key>KP_8: string(0x1b) string("Ox") \n\
                       <Key>KP_9: string(0x1b) string("Oy") \n\
                       <Key>KP_Divide: string(0x1b) string("OQ") \n\
                       <Key>KP_Multiply: string(0x1b) string("OR") \n\
                       <Key>KP_Subtract: string(0x1b) string("OS") \n\
                       <Key>KP_Add: string(0x1b) string("Om") \n\
                       <Key>KP_Enter: string(0x1b) string("OM") \n\
                       <Key>KP_Decimal: string(0x1b) string("On") \n\
                       <Key>Next: string(0x1b) string("Ol") \n\
                       <Key>Left: string(0x1b) string("OD") \n\
                       <Key>Up: string(0x1b) string("OA") \n\
                       <Key>Right: string(0x1b) string("OC") \n\
                       <Key>BackSpace : string(0x7f) \n\
                       <Key>Down: string(0x1b) string("OB")

You should also add

XENVIRONMENT=$HOME/.Xdefaults
export XENVIRONMENT

to your .profile.


6.04  What publications are available for AIX and RS/6000?

The following are free just for the asking:

1. RS/Magazine
   P.O. Box 3272
   Lowell, MA 01853-9876

2. AIXpert
   IBM Corporation
   Mail Stop 36
   472 Wheelers Farms Road
   Milford, CT 06460

3. RiSc World
   P.O. Box 399
   Cedar Park, TX 78613


These manuals should be available from your friendly neighborhood IBM office.
 
SC23-2204-02  Problem Solving Guide
SA23-2631-05  Diagnostic Programs: Operator Guide
SA23-2632-05  Diagnostic Programs: Service Guide
SA23-2643-01  Hardware Technical Reference: General Information
SA23-2646-01  Hardware Technical Reference: Options and Devices
SA23-2629-07  Service Request Number Cross Reference, Ver 2.2
 

6.05: Some acronyms

BOS  - Basic Operating System
ODM  - Object Database Manager
LPP  - Licensed Program Product
SMIT - System Management Interface Tool
PTF  - Program Temporary Fix
APAR - authorized program analysis report
PRPQ - programming request for price quotation
DCR  - design change request
_____________________________________________________________________________
7.00: How do I get this by mailserver or ftp?

Since the articles are crossposted to news.answers, any archive carrying
that newsgroup will also have these articles.


7.01: Contributors

The following persons have been contributing to this list.  If you want
to contribute anonymously, just let me know - but do tell me who you
are.  I apologise if I missed out anyone.

Thank you all, this would definitely not be the same without _your_ input.

Rudy Chukran			<chukran@austin.VNET.IBM.COM>
Christopher Carlyle O'Callaghan	<asdfjkl@wam.umd.edu>
Poul-Henning Kamp		<phk@data.fls.dk>
Richard Wendland                <richard@praxis.co.uk>
Ge van Geldorp			<ge@dutlru2.tudelft.nl>
Chris Jacobsen			<jacobsen@sbhep2.phy.sunysb.edu>
Peter Jeffe			<peter@ski.austin.ibm.com>
Jean-Francois Panisset		<panisset@thunder.mcrcim.mcgill.edu>
John Cary			<cary@boulder.colorado.edu>
Vijay Debbad			<vijay@ingres.com>
Dick Karpinski			<dick@ccnext.ucsf.edu>
Konrad Haedener			<haedener@iac.unibe.ch>
Doug Sewell			<DOUG@YSUB.YSU.EDU>
David Cordes			<cordes@athos.cs.ua.edu>
Graeme Moffat			<g.moffat@aukuni.ac.nz>
Andrew Pierce			<pierce@claven.cambridge.ibm.com>
Stephen Linam			<sdl@glasnost.austin.ibm.com>
Jerome Park			<jerome%aixserv@uunet.UU.NET>
Konrad Haedener			<haedener@iacrs1.unibe.ch> 
Steve Roseman			<lusgr@chili.CC.Lehigh.Edu>
John Burton			<burton@asdsun.larc.nasa.gov>
Thierry Forveille		<FORVEILL@FRGAG51.BITNET>
Joubert Berger			<afc-tci!joubert>
Minh Tran-Le			<tranle@intellicorp.com>
Paul Amaranth			<amaranth@vela.acs.oakland.edu>
Mark Whetzel			<markw@airgun.wg.waii.com>
				<jswillia@nycvmic2.vnet.ibm.com>
Daniel Packman			<pack@acd.ucar.edu>
Ken Bowman			<bowman@uiatma.atmos.uiuc.edu>
Doug Blain			<blain@VM.UoGuelph.CA>
Cary E. Burnette		<kerm@mcnc.org>
Christophe Wolfhugel		<wolf@grasp1.univ-lyon1.fr>
Leonard B. Tropiano		<lenny@aixwiz.austin.ibm.com>
Bill Wohler			<wohler@sap-ag.de>
James Salter			<jsalter@ibmpa.awdpa.ibm.com>
Witold Jan Owoc			<witold@enme.ucalgary.ca>
Marc Kwiatkowski		<marc@ultra.com>
Ronald S. Woan			<woan@austin.vnet.ibm.com>
Mijan Huq			<huq@hagar.ph.utexas.edu>
Herbert van den Bergh		<hbergh@nl.oracle.com>
Michael Stefanik		<mike@bria.UUCP>
John F. Haugh			<jfh@rpp386.cactus.org>
Ed Kubaitis			<ejk@ux2.cso.uiuc.edu>
Jaime Vazquez			<jaime@austin.vnet.ibm.com>
Bjorn Engsig			<bengsig@oracle.com>
Frank Kraemer 			<kraemerf@franvm3.VNET.IBM.COM>

_____________________________________________________________________________
Epilogue

If you have any comments about this list, please mail them to me, as I
cannot guarantee to pick up posted changes.  When you mail stuff, please
change the Subject: line so it doesn't just say "Re: Frequently ....".

All input should be emailed to me at basto@cactus.org on the Internet.  
You can also try using cs.utexas.edu!mavrick!luis.

I work for Computer Sciences Corp. and I am doing this on my own time.
Please do not ask me questions that should be asked to IBM. If you have 
any problems, please ask IBM or post your questions to this newsgroup.
I might respond to the latter.

Opinions expressed here have nothing to do with either IBM or CSC.

All trademarks are the property of their respective owners.
-- 
Luis Basto
Computer Sciences Corporation
Internet: basto@cactus.org
Usenet:   cs.utexas.edu!mavrick!luis
Newsgroups: comp.unix.aix