From: afx@ibm.de (Andreas Siegert)
Subject: AIXTIPS NEWS 92286
Followup-To: comp.unix,aix
Reply-To: aixtips@ibm.de
Organization: IBM AIX Field Support Center, Munich
Date: Mon, 28 Sep 1992 17:34:13 GMT

This is AIXTIPS NEWS for customers released at Mon the 28. Sep 1992.

Table of contents:
92286. Arrow keys for command-retrieve mode -- suggestion
92295. ASCII console hang problems
92296. Circumvention for the installation problem with PTF U406391
92297. How to get junk data for testing - Use LPTEST
92303. You can't use a 320 or 32H as a /usr client
92306. Steady blinking light on a CD-ROM with no activity
92310. AIX malloc and fault tolerance - just the facts
92317. errdemon and syslog / syslogd
92319. Benchmark results: xlc vs gcc optimization (ammended)
92320. Announcing xmgr Release 2.09 (aka ACE/gr Motif)
92322. Andrew on CD-ROM
92324. Dynamic loading
92325. HOTW: Need a generic-ANSI terminfo definition?
======================================================================
 
Note:
The information in this document has not been submitted to any formal IBM test
or review and is distributed on an "as is" basis without any warranty either
expressed or implied. The use of this information is a customer responsibility
and customers attempting to adapt these techniques to their own environment
do so at their own risk.

Some of the tips might reference internal TOOLS disks for more information.
Please contact your IBM representative if you need those documents.

Your AIXTIPS Team 		              Internet: aixtips@ibm.de
======================================================================
>92286. Arrow keys for command-retrieve mode -- suggestion

 This refers to tip 92284 wich had some suggestions on remapping the aixterm
 keys so that ksh command line editing in vi mode could be done with cursor
 keys. 

The last of the tips in the most recent transmittal mentions the
possibility of interfering with the operation of some applications by
remapping keys via X windows for Korn shell command retrieval.  Some
time ago, I ran into that problem and discovered a fairly simple
solution which I think other folks might find useful -- I can have two
kinds of X terminal windows; one for shell interaction, and the other
(without key remapping) for applications like pcsim and em78.

This is an excerpt from my .mwmrc file:
> Menu RootMenu
> {
>     "Root Menu"    f.title
>     no-label       f.separator
>     "New Window"   f.exec "aixterm -name KornShell &"
>     "pcsim mono"   f.exec "aixterm -title pcsim -n pcsim -e pcsim"
>  ...
> }
(note the use of -name parameter on aixterm for the shell window.)

Now here's the translation section of .Xdefaults (for
  emacs mode):
> KornShell.translations: #override \
>          <Key>Home:   string(0x01) \n\
>          <Key>Delete: string(0x04) \n\
>          <Key>End:    string(0x05) \n\
>          <Key>Left:   string(0x02) \n\
>          <Key>Right:  string(0x06) \n\
>          <Key>Up:     string(0x10) \n\
>          <Key>Down:   string(0x0E) \n

By using -name on the aixterm command for shell windows, you can
change the program name seen by the X resource manager, so that in
this case the command retrieval key mappings only apply to programs
which have been 'renamed' to "KornShell."  The shell window gets the
translations, but the pcsim window doesn't.

Rich

Note: the aixterm will still use all axiterm resources unless overriden by
      the resource that is set with the name given with the -name flag.
======================================================================
>92295. ASCII console hang problems

 If you have an ASCII terminal as console and use a non IBM cable or the
 console is switched off or the terminal is not connected to the tty port,
 the system will not work ok. Eg. you'll get:

      Multi-user initialization completed

 or

      Initialisierung fuer Mehrbenutzerbetrieb abgeschlossen

 at IPL and nothing will happen. Also shutdown will hang in /etc/tcp.clean.

 Solution: Change tty via smit and add 'clocal,' in the lines:

      STTY attributes for RUN TIME
      STTY attributes for LOGIN

 The reason is that an open to the /dev/ttyX will hang if HW handshake is
 not satisfied.

 Rem: The problem has nothing to do with XON/XOFF !

 Mit freundlichen Gruessen / best regards
 Bernhard Zeller
======================================================================
>92296. Circumvention for the installation problem with PTF U406391

 Problem:

   PTF U406391 is not installable via SMIT, the last message shown by SMIT is
           installp:  Performing requisite checking
                  (This may take several minutes.)
   After that installp seems to loop and eats paging space.

 Circumvention:

   Install PTFs U403173 and U406852 first and then U406391.
   They are all shiiped on one tape.

   Instructions:
       1.)  Install U403173   ( Install Updates Only )
       2.)  shutdown -Fr
       3.)  Install U406852   ( Install Updates Only )
       4.)  And then install U406391
       5.)  shutdown -Fr

 O. R.
======================================================================
>92297. How to get junk data for testing - Use LPTEST

 The LPTEST command generates the barberpole/ripple test pattern
 that is typically used for printer testing.  This can also be useful
 for driving terminals or networks when you need lots of junk data
 quickly.

 Example:  $lptest 80 24

           FillS your screen with 24 lines of 80 characters each.
 -drr
======================================================================
>92303. You can't use a 320 or 32H as a /usr client

 Most people know that a 32x machine can't be used as a diskless machine.
 But it also can't be used as a normal /usr client because it still would 
 need some rom that fetches things from a remote /usr before it can mount 
 /usr.
 Sorry folks.
======================================================================
>92306. Steady blinking light on a CD-ROM with no activity

 So why does the amber light on the CD-ROM drive blink when you
 aren't running any programs that use it?  No - it is not a message
 from Elvis!

 The lens is dirty - time to clean the drive and/or CD itself.

 -drr
======================================================================
>92310. AIX malloc and fault tolerance - just the facts

If you care about how AIX handles paging space low conditions, read on.

Important:
I did not design the way AIX handles malloc/sbrk/paging space.
I did not write any code that implements this stuff.
I do not know why it is designed they way it currently is.
I *personally* do not like the way it currently works.

Note: But they guy who wrote it confirmed by a different posting to
      comp.unix.aix what Mickey says here.

But, since there is some confusion on the net, I decided to
consult the true "source" of information, and I will present
some facts about the implementation.

The AIX malloc() does almost nothing but increment your brk
value, if necessary.  It does not touch the paging space, or
consult the paging space free, etc.  It just returns an address.
Paging space is used when you touch the malloced space with
either a read or a write to the page.  Now paging space is used.

Each time a page is allocated from the paging space, the kernel
checks to see if we are below the "warning" threshold.  If so,
*ALL* processes that are not kernel processes and in a "normal"
state (not zombies, etc.) will receive the SIGDANGER signal.
The default action for all AIX applications is to ignore this
signal.

Once this is done, two things can happen.  1) paging space will
become free; or 2) the situation will get worse.

If 1) happens everything is cool, and the system will continue
as usual.  This will only happen if some application catches
SIGDANGER and reduces its paging space requirements by either
exiting, or by calling the disclaim() system call, or if an
application just happens to exit at this time.

If 2) happens, the system will loop through all processes
to check if they are not kernel, not currently being killed,
not catching SIGDANGER, and not zombies.  From the processes
that are left (most processes, actually), the kernel selects
the "youngest" process to kill.  This is determined by finding
the largest value in the u_start member of the user structure.

The system will repeat this process every time a page of paging
space needs to be allocated - until enough free space is available.

Some important points to notice:
1) Simply calling sigaction for SIGDANGER _will_ prevent your
   process from being sent the SIGKILL signal.
2) The system kills processes based *SOLELY* on process age.  The
   most recently started processes are killed first.
3) The only process that *might* get suspended is a process
   asking for paging space - only until space is free.
4) The size of a process is *NOT* a factor in deciding which
   process will be killed (this is different from AIX 3.1).
5) Touching pages does allocate paging space (ie calloc),
   but it really doesn't help the problem.

**** The X server tip ****

Here are three easy steps to get the X server to catch SIGDANGER:

1) in a file called /usr/lpp/X11/lpp.linkX/initext enter the following:
{  /* open curly bracket */
  #include <sys/signal.h>
  /*
  ** SIGDANGER means "system crash imminent; free up some page space".
  ** Simply catching this signal will prevent the kernel from killing
  ** the X server when paging space becomes critically low.  Of course,
  ** this doesn't really help too much, because the system can crash.
  */
  void NoopDDA();
  struct sigaction action;
  action.sa_handler = NoopDDA;
  action.sa_mask.losigs = 0;
  action.sa_mask.hisigs = 0;
  action.sa_flags = 0;
  sigaction( SIGDANGER, &action, NULL);
}   /* close curly bracket */

2) Stop your X server.
3) Run the shell script /usr/lpp/X11/makeX/server/linkXext (as root).
This will, of course, require the C compiler be installed.

**** End X server tip ****

I hope this clarifies some of the issues with the way AIX
currently handles malloc().  If not, flame on.

--
Mickey Coggins  mcog@chvm1.vnet.ibm.com
======================================================================
>92317. errdemon and syslog / syslogd

To redirect syslog messages to the error log you need to edit
/etc/syslog.conf and specify 'errlog' as the destination. For example
*.debug     errlog
will redirect a messages of severity debug or higher to the error log.
After you edit syslog.conf you will need to restart syslogd for this
to take effect.

G. B.
======================================================================
>92319. Benchmark results: xlc vs gcc optimization (ammended)

From the newsgroup comp.unix.aix

From: jonathan@cs.pitt.edu (Jonathan Eunice)
Summary: Give the Toronto folks raises
Date: 25 Aug 92 13:55:09 GMT
Organization: University of Pittsburgh Computer Science

This article was posted once before, with slightly different results in
one case.  Garrett.Wollman@uvm.edu noted that xlc's -OQ mode would be a
fairer comparision to gcc's -O2 than the pure -O I originally used.  I
agreed; the relevant changes appear here. The original conclusions were
strengthened by this change.

Abstract:   To compare the quality of optimization between IBM's xlc
            compiler (version 1.02) and GNU's gcc (version 2.2.2), I
            compiled and ran the public JPEG code (which is compute-
            intensive and integer-operation-oriented) under a variety
            of optimization settings and against several input files.

Results:    Xlc optimizes code significantly better than does gcc.
            It also compiles significantly faster than gcc.

Details:    When no optimization is used (the default), gcc code ran
            10%-20% faster than that compiled by xlc.

            When basic optimization (-O) was used, xlc code turned the
            tables to beat gcc code by approximately 35%.

            With full optimization (-O2 for gcc, -OQ for xlc) turned
            on, gcc narrowed the gap, but xlc code still runs about 26%
            faster.

            In no-optimize mode, gcc takes 103% longer than xlc to
            compile. This must be balanced against the fact that, as
            noted above, it produces significantly better code in this time.

            In basic optimization mode (-O), gcc takes about 7% longer
            than xlc, but produces much worse code.

            With full optimization (-O2 or -OQ) invoked, gcc takes
            about 10% longer than xlc, but still produces significantly
            weaker code.

Discussion: Xlc really does do a good job of optimization, and it does
            it quickly, just like the marketing glossies say.

            Though further tests (see below) would be required to fully
            support this assertion, the public JPEG programs are large
            enough (total of just over 15,000 non-blank lines), complex
            enough, and "real-world" enough to be convincing by themselves.

            It is reasonable to assume that portability extracts its
            price from gcc. Because portability is one of gcc's best
            attributes, this represents a price that must be paid.

            Garrett.Wollman@uvm.edu also suggests that gcc's use of a
            separate assembly stage contributes significantly to its
            longer compile time.

            The xlc performance win suggests using it in "production
            mode"--for code you want to run as fast and efficiently as
            possible. Code coming from net.sources and/or that is to be
            repeatedly used rather than worked with are good
            candidates. There is seldom a good time to gratuitously
            waste resources.

            On the other hand, most code is not as compute intensive as
            JPEG, and thus will see less overall improvement because of
            good optimization. Even the compute-intensive compilation,
            compression, and decompression stages of my tests all had
            wall-clock times 2-3x longer than the sum of user and
            system times, indicating considerable I/O waiting.

            No matter how compute- or I/O-intensive a program may be,
            its developers' time is always valuable.  Thus for many it
            will be worthwhile to trade xlc's additional performance
            for gcc's other benefits, including its integrated support
            for C++, its near-unique debugging of optimized code, its
            portability, and its free availability.

Extensions: Though interesting, these results are narrow.

            Only two, related, integer-oriented programs were tested. A
            broader spectrum of test programs, including some that are
            floating-point-oriented, would generalize the results. The
            SPEC benchmark suite would provide a good test set.

            It would be particularly interesting to test systems other
            than the RS/6000. By testing various vendors' compilers
            against a vendor-neutral, freely-available alternative, one
            could get a pretty good idea of which are spending their
            compiler investments wisely, and which are not. It could
            also help put in perspective their marketing claims.

* Test Notes

The following tables gives both absolute and relative timing
measurements.

JPEG compression / decompression was used as a test case because:  (1)
its compute-intensive nature will focus execution resources on compiler
output, and (2) its free availability and portability.

The public JPEG implementation provides two key programs: cjpeg
(compresses files into JPEG format) and djpeg (decompresses files from
JPEG format). GIF is used as the "other" format being compressed
to/from, mainly for convenience.

All timings were run on an RS/6000 Model 320 with 32 MB RAM and AIX
3.2. The absolute timings presented will depend entirely on this
configuration. Relative timings (ie, the % difference between xlc and
gcc absolute timings), however, should be valid across all
configurations--indeed, would be largely valid across multiple vendors,
UNIX implementations, and processor architectures.

Three execution times are presented: compiling with default
optimization (typically none), with basic optimization (-O flag used),
and high optimization (-O2 flag used for gcc, -OQ for xlc).  The -Q
option to xlc indicates that the compiler should try inlining, which is
implicit in gcc's -O2.

For execution time tests, only the user-mode time is compared for
execution time, as it relies almost solely on compiler output.
Real-clock and system time are not considered because both rely heavily
on factors outside the influence of the compiler; additionally, neither
of these shows meaningful distinctions with respect to the tests run.
Additionally, the system times were insignificant.

Each of four input files was tested, five times each. The average time
over all trials is reported here. The files are various images of cars
which have appeared recently in the newsgroup alt.binaries.pictures.misc.
These files were selected to give a variety of file sizes (56K-164K for
JPG files, 120K-376K for GIF files).

The compile time tests were run five times each, with the average
reported here. The sum of user-mode and system-mode times is used, as
system mode execution has become a significant contributor.

The correctness of results for each compiler / optimizer configuration
was verified prior to running this benchmark, but no correctness tests
were made during the benchmark.

** Decompressing JPG to GIF via "djpeg -G ${file} >junk"

*** Absolute execution times (user)

File             xlc  xlc -O  xlc -OQ      gcc   gcc -O gcc -O2
=--------------------------------------------------------------
67gto.jpg       25.2     8.7      8.3     20.4     11.9    10.4
blackrx7.jpg    35.5    13.0     12.0     29.6     17.5    15.3
mgs.jpg         16.7     5.7      5.4     13.6      7.9     6.9
mustang.jpg     35.9    13.0     12.4     28.8     17.3    15.3

*** Relative performance, gcc vs xlc

                 gcc      gcc -O      gcc -O2
                  vs          vs           vs
File             xlc      xlc -O      xlc -OQ
=--------------------------------------------
67gto.jpg      19.1%      -36.0%       -25.3%
blackrx7.jpg   16.7%      -34.0%       -27.7%
mgs.jpg        18.4%      -37.3%       -27.4%
mustang.jpg    19.6%      -33.8%       -23.7%
=--------------------------------------------
Average        18.5%      -35.3%       -26.0%

** Compressing GIP to JPG via "cjpeg ${file} >junk"

*** Absolute execution times (user)

File             xlc  xlc -O  xlc -OQ      gcc   gcc -O gcc -O2
=--------------------------------------------------------------
67gto.gif       13.8     6.0      6.0     12.3      8.0     7.2
blackrx7.gif    21.3     9.4      9.4     19.1     12.6    11.2
mgs.gif          7.8     3.3      3.3      6.9      4.6     4.1
mustang.gif     24.9    10.8     10.8     22.3     14.5    13.0

*** Relative performance, gcc vs xlc

                 gcc      gcc -O      gcc -O2
                  vs          vs           vs
File             xlc      xlc -O      xlc -OQ
=--------------------------------------------
67gto.gif      10.9%      -33.2%       -26.0%
blackrx7.gif   10.5%      -34.5%       -26.3%
mgs.gif        11.1%      -37.3%       -26.9%
mustang.gif    10.6%      -33.4%       -24.2%
=--------------------------------------------
Average        10.8%      -34.6%       -25.8%

** Compiling the public JPEG code

*** Absolute compilation times

                 xlc  xlc -O  xlc -OQ      gcc   gcc -O gcc -O2
=--------------------------------------------------------------
real            89.9   208.4    261.1    186.8    228.6   292.7
sys              7.4    15.4     14.7     10.3     10.0    10.0
total           97.3   223.8    275.8    197.1    238.6   302.8

*** Relative compilation performance, gcc vs xlc

                 gcc      gcc -O      gcc -O2
                  vs          vs           vs
File             xlc      xlc -O      xlc -OQ
=--------------------------------------------
real         -107.8%       -9.7%       -12.1%
sys           -39.0%       34.9%        32.0%
total        -102.5%       -6.6%        -9.8%
======================================================================
>92320. Announcing xmgr Release 2.09 (aka ACE/gr Motif)

From the newsgroup comp.unix.aix

From: pturner@amb4.ese.ogi.edu (Paul J Turner)
Date: 29 Aug 92 15:36:06 GMT
Organization: Center for Coastal and Land-Margin Research
Originator: pturner@amb4.ese.ogi.edu

Announcing xmgr Release 2.09

I wish to thank all who have participated in the development of
xmgr.

Xmgr is an XY-plotting tool for UNIX workstations using
X or OpenWindows. There is an XView version called xvgr for
Suns. Collectively, these 2 tools are known as ACE/gr.
Compiling xmgr requires the Motif toolkit version 1.1
and X11R4 - xmgr will not compile under X11R3/Motif 1.0x.

Xmgr has been compiled and tested on:

 IBM RS6000 - AIX 3.2 X11R4/Motif 1.1
 DECstation - Ultrix 4.2a X11R4/Motif 1.1
 SGI Indigo - Irix 4.0.1 X11R4/Motif 1.1
 Sun SPARC  - SunOS 4.1.1 X11R4/Motif 1.1

It should compile on HP 7xxx's but I'm presently unable to test this.

2.09 is a bug fixer and has removed from it any reference to the notion
that I'll be able to respond to every email message sent to me. Time
constraints prevent me from making individual answers. Also, any references
to a mailing list in previous versions have been removed - again,
time constraints make it impossible for me to maintain any sort of
mailing list. I would suggest that the users of xmgr get together
and form either a traditional mailing list, or use an existing
news group for the discussion of bugs, comments, complaints, etc.
Comp.sys.sun.apps would probably be an appropriate news group for
xmgr, or maybe comp.windows.x.apps as this would cover both versions.
I'm inclined to answer questions in some forum that has a larger
audience.

If you are using any version of xmgr less than 2.04, you should
consider upgrading.

A current version of the sources, documentation, and some
examples are available via anonymous ftp to amb4.ese.ogi.edu
129.95.20.76 in CCALMR/pub/acegr/xmgr-2.09.tar.Z. Compiled
binaries distributed in previous versions will not be available
due to space limitations.

Remember to use a binary file transfer. I am not able to E-mail xmgr,
but there are services provided by various Internet sites that allow
ftp by mail. You might try sending mail to ftpmail@decwrl.dec.com
as follows:

Subject: (hit return) Body-of-letter: help (return) quit

I've not tried this, but it should give you instructions on how to use
this service.

ACE/gr is an unfunded, unsupported, after-hours project that I hope proves
useful.

A few of its features are:

   * Motif and XView versions.
   * Plots up to 10 graphs with 30 data sets per graph.
        each data set is limited by the size of available memory,
        I've plotted data sets in excess of 700k points.
        The 10 graphs may be displayed simultaneously with
        a popup that allows the graphs to be conveniently stacked,
        in rows and/or columns.
   * Data read from files and/or pipes.
   * Graph types XY, log-linear, linear-log, log-log, bar,
        stacked bar charts.
   * Sets may be drawn with error bars in both directions equal or unequal
        on either side of the datum in X and in Y. Support for HI LOW OPEN
        CLOSE data, Numerous symbol types, both hollow and filled, skyline
        plots, histograms, impulse. Sets may be draw as polygons filled
        in several different ways, from the data to the graph minimum Y,
        maximum Y, minumum X, maximum X, X = 0.0, Y = 0.0, or as a polygon.
   * Block data feature for those data sets arranged in equal length
        columns allowing sets of any type to be formed by any combination
        of the columns. Presently there is a 30 column limit, the length
        of the columns is limited by available memory.
   * Continuous display of the location of the pointer depending on
        the current graph scaling. The format of the display can be
        set to any of the time-date formats, latitude/longitude. The
        default is to display the XY coordinates of the mouse in user
        coordinates. As the graph focus changes, so does the format
        and scaling of the locator.
   * User-defined scaling, tick marks, labels, symbols, line styles,
        colors. Tick labels may be drawn at any angle on either
        or both sides of the graph, staggered (offset for long
        labels). There are several formats for tick labels, including
        many time-date formats, latitude-longitude, decimal, exponential
        and power-of-10. Tick labels and tick marks may be specified
        by the user. Grid lines may be drawn in lieu of tickmarks.
        Each coordinate direction allows 3 axes, the primary, zero,
        and an alternate axis that allows a scale differing from the
        graph coordinate scaling.
   * Graph legends.
   * Annotative text with sub/super scripts, lines with/without arrow heads,
        boxes filled or unfilled.
   * Operations on data sets, kill, copy, move, reverse, sort, drop,
        join, coalesce, write, swap.
   * Region operations, define a region as inside or outside a polygon,
        or half planes defined by a line. Extract points from a region
        to a set, delete points, evaluate an expression on points in a
        region. Area and perimeter calculations from a polygon.
   * Mouse powered point editing, add points to a set, delete points
        from a set, move a point in a set (horizontally, vertically,
        or in both directions). There is a feature called tracker that
        when active, warps the pointer forward or backward through the
        points in a set, displaying the set number, the index of the point,
        and the X, Y location of the point. There is a find point feature
        that allows information to be displayed about arbitrary points
        in sets.
   * Batch mode for unattended plotting.
   * Read and write parameters used during a session.
   * Polynomial regression, splines, running averages/minimums/maximums/
        standard deviations/medians, DFT/FFT, spectrum, phase, sampling,
        cross/auto-correlation, numerical integration, numerical
        differentiation, histograms, evaluate expressions on sets.
   * Pan, zoom (mouse powered), shrink and expand the graph scaling,
        with each graph allowing 20 different views through a mechanism
        called the world stack. The graph viewport (where it appears
        on the page) can be set manually or by the mouse.
   * Command line interpreter with a history list and playback feature.
   * Autoscaling along each or both coordinate directions, on all sets
        or a selected set.
   * Support through device independent graphic drivers for
        PostScript, HPGL, and FrameMaker .mif format.

Comments, suggestions, bug reports to pturner@amb4.ese.ogi.edu (if mail
fails, try pturner@ese.ogi.edu). Due to time constraints, replies will
be few and far between.

--Paul

Paul J Turner - pturner@amb4.ese.ogi.edu
Center for Coastal and Land-Margin Research
Oregon Graduate Institute
Beaverton, OR 97006-1999
======================================================================
>92322. Andrew on CD-ROM

                          The Andrew Consortium
                                presents
                           Andrew 5.1 on CDROM
         - the Integrated User Environment for UNIX Workstations

(June 19, 1992)  The Andrew Consortium announces Andrew 5.1, the
integrated user environment for UNIX workstations running the X11
windowing system.

With Andrew you can turn your UNIX workstation running the X11 windowing
system into a comfortable, personalized environment that allows you to
communicate multi-media information in a most flexible manner.  The
Andrew User Environment consists of a set of pre-constructed tools such
as a multi-font text editor, spreadsheat, shell interface, raster
editor, message reader, directory browser, and application creation
tool.  The majority of these tools can be embedded in one another such
that, for example, you can create a text document that contains a real
"live" raster object, editable in place within the document.  The Andrew
messages program allows you to mail such multi-media documents to an
ever-increasing number of recipients -- messages can produce
MIME-compliant mail -- giving you the ability to communicate with more
expressiveness than ever before.  In conjunction with the Andrew File
System (AFS) from Transarc Inc., messages can give you access to the
world of electronic mail at the touch of a button.

With Andrew you can create networks of rich multi-media documents
connected with a hyperlink that, when clicked, will transfer you to the
target document.  The Andrew help program gives you access to your
system manual pages, which are automatically converted from their native
format (troff) to a rich text format.

Andrew is perfect for:

    - a cost-effective end-user environment (it's free)
    - creating rich, expressive multi-media documents
    - an interface to the world of electronic mail
    - creating on-line courseware or other presentations
    - rapid prototyping of graphical interfaces (Application Development
      Workbench)

The Andrew system is now available on CDROM which can be read by any
ISO-9660 or Rock Ridge compliant CDROM device driver.  The CDROM
contains Andrew source as well as binaries for the following platform:

        IBM RS/6000 (AIX 3.1)
        SUN 4c Sparcstation  (SunOS 4.1.1)
        DECstation 3100 PMAX  (Ultrix  4.2)
        Hewlett-Packard 720 "Snake" (HPUX 8.05)

Andrew can also be retrieved via anonymous ftp from the internet host
emsworth.andrew.cmu.edu (128.2.30.62) or you can get the sources or
binaries on one of a number of other media.  The Andrew Consortium is an
organization formed to support the continued evolution of the Andrew
system.  Current Consortium members include IBM, HP, Bell South, MIT,
SunSoft, The National Institute of Health.

You may contact the Consortium for more information on Andrew or the
Consortium itself a number of ways.  Phone:  phone: +1-412-268-6710;
FAX:  fax: +1-412-621-8081 or email to
info-andrew-request@andrew.cmu.edu.
======================================================================
>92324. Dynamic loading

From: pgainer@vnet.ibm.com (Patrick Gainer)
Date: Wed, 29 Jul 92 08:00:02 EDT
Newsgroups: comp.unix.aix
Subject: Re: more dynamic loading problems...
Organization: IBM - Toronto Lab
Disclaimer: This posting represents the poster's views, not those of IBM

In <45808@shamash.cdc.com> Paul Dokas x4629 writes:
>I thought that I had solved my problems with dynamic loading, but things
>still aren't working properly.  It seems that when I create a dynamically
>loadable module, that the value returned by nlist() is not always the
>correct offset to the begining of the routine.  The included code for
>example creates a dynamically loadable module with 2 functions 'a_function()'
>and 'b_function()'.  Using nm, I find that the symbol 'a_function' has
>a value of 0x54.  But if I use dbx to look at the location pointed to by
>fn_ptr, I find that the value of 'a_function' should really be 0x18!

Also, I have posted this from a VM system (gasp) and the left and right
square brackets may be corrupted (I can't tell from here but it has happened
before).

================================CUT HERE====================================
/*=========================================================================*/
/*                                                                         */
/* DESCRIPTION:  A quick and dirty prototype of runtime loading and        */
/*               binding.                                                  */
/*                                                                         */
/*                                                                         */
/* Usage: cc -g -o dyload dyload.c  = builds this executable               */
/*        ld -T512 -H512 -e entry_point -lc -o object_file object_file.o   */
/*                                                                         */
/*=========================================================================*/

#include <stdio.h>
#include <nlist.h>
#include <malloc.h>


/* Type definitions */
typedef struct function_t
{
  char                  name[128];       /* function name */
  int                   (*code)();       /* function pointer */
  int                   arr[3];          /* 12 bytes for func descriptor */
} Function;

typedef struct nlist n_list;


/* Function prototype */
int
  load_and_bind(Function   *flist, char   *file);


main(int   argc, char   **argv)
{
  char                  *libpath="/u/patrick/tools/dyload:.";
  int                   result;
  int                   loop_control=1;
  char                  file_name[128];
  char                  func_name[128];
  Function              flist[2];

  /* optional arg for object file name */
  if (argc < 2)
  {
    printf("Enter name of object file to be loaded.\n");
    result = fgets(file_name, 128, stdin);

    /* remove carriage return from file name */
    file_name[strlen(file_name)-1] = 0x00;
  }
  else
  {
    strcpy(file_name,argv[1]);
  }

  /* load object module, resolve entry point information */
  flist[0].code = load(file_name,0,libpath);
  if (!flist[0].code)
  {
    printf("load call failed. Exiting.\n");
    exit(-1);
  }

  do       /* until user quits by setting loop_control == 0 */
  {
    /* get function to execute from user, preface name by a '.' */
    printf("Enter name of function you wish to execute.\n");
    flist[1].name[0] = '.';
    result = fgets(&(flist[1].name[1]), 128, stdin);

    /* remove carriage return from file name (added by fgets) */
    flist[1].name[strlen(flist[1].name)-1] = 0x00;

    /* hardcode function entry point - bad programming practise */
    strcpy(flist[0].name,".ibm_start");

    /* resolve function name and generate a function pointer */
    result = load_and_bind(flist,file_name);
    if (result != 0)
    {
      printf("function name resolving failed. Exiting.\n");
      exit(-2);
    }

    /* execute function */
    (flist[1].code)("Test input string",17);

    printf("Continue? (Yes == 1)\n");
    fflush(stdin);
    scanf("%d",&loop_control);
    fflush(stdin);

  } while (loop_control);

}



/*
 * Given a function name (string), this routine generates a function
 * descriptor and a function pointer to that descriptor. All addresses
 * are resolved so that the function pointer can be directly executed
 * by the calling procedure.
 *
 * Parameters:
 *  flist - contains two entries. The first holds the name of the entry
 *          point for the entire module. This is used to calculate a base
 *          address for the function to be resolved. The second contains
 *          the name of the function to be resolved.
 *  file  - contains the name of the object module containing the functions.
 */
int
  load_and_bind(Function   *flist, char   *file)
{
  int           i;
  n_list        *nlptr;
  int           result;


  /*===================================================================*/
  /* allocate array of 3 nlist structure - 1 for object module header, */
  /* 1 for function we wish to find, and 1 to NULL terminate array.    */
  /*===================================================================*/
  nlptr = (n_list *) calloc(3,sizeof(n_list));
  if (!nlptr)
  {
    return(-3);
  }

  /* set nlist name field for object module entry point */
  nlptr[0]._n._n_name = flist[0].name;

  /* set nlist name field for function name to be resolved */
  nlptr[1]._n._n_name = flist[1].name;

  /* set nlist name field terminator (NULL name) */
  nlptr[2]._n._n_name = "";

  /* call nlist to get function offsets from a name list */
  result = nlist(file, nlptr);
  if (result == -1)
  {
    perror("nlist");
    return(-4);
  }

  /*=========================================================================*/
  /* Here is where the addresses are resolved. Basically, the nlist call     */
  /* returns with the offsets from the entry point for each function. The    */
  /* entry point address was obtained via the load() call in main.           */
  /*                                                                         */
  /* Each function is associated with something called a function descriptor.*/
  /* This structure (12 bytes) contains the function's virtual address in    */
  /* bytes 0 to 3 and the Table Of Contents address for the module in bytes  */
  /* 4-7. Bytes 8-11 are not used. A function pointer is just a pointer to   */
  /* this structure. To resolve a function's runtime address, The TOC entry  */
  /* from the entry point is used (since the TOC is the same for all funcs   */
  /* in a module) but the virtual address must be calculated. The entry_point*/
  /* offset (obtained from nlist) is subtracted from the function-to-be-     */
  /* resolved's virtual address. This gives a base address. Then, the        */
  /* function-to-be-resolved's nlist offset is added to this base address to */
  /* get the function's virtual address. Finally, the function pointer is set*/
  /* to point to the function descriptor structure just created.             */
  /*=========================================================================*/

  /* copy entry point function descriptor to func-to-be-resolved's descriptor*/
  memcpy(flist[1].arr,flist[0].code,12);

  /* set function pointer to point to newly obtained function descriptor */
  flist[1].code = (int(*)()) flist[1].arr;

  /*==============================================================*/
  /* Subtract the nlist offset for the module from the ptr value  */
  /* in flist[1].arr[0-3]. This will yield a base virtual address.*/
  /*==============================================================*/
  *((int *)flist[1].arr) = *((int *) flist[1].arr) - nlptr[0].n_value;

  /*==============================================================*/
  /* Add the nlist offset for this particular symbol to the base  */
  /* virtual address.                                             */
  /*==============================================================*/
  *((int *)flist[1].arr) = *((int *) flist[1].arr) + nlptr[1].n_value;

  /* done - free memory and return */
  free(nlptr);
  return(0);
}
======================================================================
>92325. HOTW: Need a generic-ANSI terminfo definition?

 The terminfo source definition for this needs to be built.
 Enter the command shown below:
                                                                               
     tic /usr/lib/terminfo/virtual.ti

 -drr
======================================================================

--
Andreas Siegert / Postmaster   IBM Deutschland GmbH   |   Never grep a yacc
AIX Field Support Center       Pocci Strasse 11       |   by the i-node!
Internet: afx@ibm.de           D-8000 Muenchen 2      |   Opinions are my own,
VNET: SIEGERT@MUNIVM4          Voice: (49)-(89)-7670-509  not IBM's.
Newsgroups: comp.unix.aix