You will doubtless quickly note that there are two different types of
Makefile, each in a variety of flavours for particular types of workstation.
Note again that "tagibm" is a service run on an Ultrix workstation but
designed for people connecting to it over LAT from terminal servers.
What I usually do is make a symbolic link of Makefile to the particular
one that I am currently using.

The files of name Makedebug.<workstation> are clearly for creating a
debugging version, i.e. one which will put debugging information onto
file /tmp/outf or /tmp/log. Remember not to have long sessions with a debug
version: these files can be quite long (especially if you call the program
with the -l flag). These Makedebug files produce a program module by the
name of t3270. They do NOT have any "make install" possibility, which
means that some files necessary for proper execution (such as the various
help files, the map3270 file etc.) may not be in place. You can, of course,
set the environment variable MAP3270 as the fully qualified file name
for the map3270 file which you want.

The files of name Makefile.<workstation> are for creating and installing
a production version. Just running a simple "make" will create a program
module called 3270: a subsequent "make install" will, amongst other things,
move this to your desired binary directory with the desired program name.

For people who don't like reading documentation note that you have a pretty
fair chance of things working by simply choosing the Makefile appropriate
to your workstation

 *****************
 * PROVIDED THAT *
 *****************

you create certain directories named at the start of the Makefile
OR
let them be created by a "make install" (normally as root)
OR
change the Makefile to say that they are not to be used.

The production version Makefiles start with the usual site-dependent
installation information (installation OWNER, MODE etc., modelled on the
way that X does it). Both production and debug Makefiles then continue
with the specification of these above-mentioned directories

	# Place where libraries (news, help, mhelp etc.) go

	LIBDIR = /usr/local/lib/3270
	DLIB = -DLIBDIR=\"$(LIBDIR)/\"

The above is the directory for files required for the on-line help
procedures, including the keyboard mapping help files, the current
information message, if any, etc.
The files therein must be read-accessible by any user of the program.

	# Place where the map3270 (keyboard mapping) file goes

	PROFILE = /usr/local/lib/3270/map3270
	DPRO = -DPROFILE=\"$(PROFILE)\"

It is sometimes convenient to put the map3270 file into the same directory.
However, it is also quite common to put it into /etc (where I believe
other 3270 implementations quite often expect to find it). Take your pick.

	OPTDIR = /usr/local/lib/3270/options
	DOPT = -DOPTDIR=\"$(OPTDIR)/\"

The above is to have a directory in which I keep a file of information
for each user who makes use of the program, so that I know which are his/her
preferences and whether the current information message has already been
seen. For a workstation the user is normally identified according to the
login identifier used: for a tagibm-style service (i.e. the -DTTY option
mentioned below) I will prefer an IBM login name specified in the program
call line, possibly qualified by the IP address of the specified IBM if
it is not the default one. Don't worry about the details unless you are
implementing a tagibm-style system! Do, however, ensure that all users of
the program have the right to write such a file.

	# The FILE in which to write a log file.

	LOGFILE = /tmp/3270log
	DLOG = -DLOGFILE=\"$(LOGFILE)\"

Self-explanatory, I think, but do not confuse it with the debugging logfile
used if you compile a debug version! For my own usage I actually write
into file /usr/var/adm/3270/3270log and I have a crontab procedure which
at midnight renames 3270log so that 3270log.n (n = 0, 1, ... 7) is the
log of n days ago. This file contains a few lines per 3270 session,
including user name, IBM system connected to, reason for the session end
and so on.

	# The DIRECTORY in which to put files of screen prints.

	PRINTDIR = /usr/local/lib/3270/prints
	DPRINT = -DPRINTDIR=\"$(PRINTDIR)/\"

Also self-explanatory. If not defined then the program will normally use
the current working directory.
At CERN I have implemented a scheme whereby the directory is regularly
scanned by a crontab script process: this checks the files therein and
may decide to print them on a printer (indicated by part of the file name)
or to send them by email (to an address also indicated by part of the
file name). The relevant part of the file name can be set by the user
in the options sub-menu of the on-line help, with the actual details
being dependent on the script and possibilities for printing and email.

After this the production Makefiles allow you to specify the name and
version of the installed program as PROG and VERSION respectively.
The installation will use the name ($PROG)v($VERSION), currently 3270v3.5,
and will also create a symbolic link so that the user can simply use the
name $PROG.

Now I offer a chance to redefine the C-compiler. The default is simply "cc",
assuming that this will normally work, but you may want an alternative.
If you do use an alternative remember to include the various compiler-specific
options immediately.

Next, and frequently last, you just have to define the workstation type
by a line such as

	SYSTEM_TYPE = sys_sun

and away you go (I hope).

The rest of the Makefile does actually offer different options for
sophisticated users or ones for whom the standard setup fails for some
peculiar reason. If you do HAVE TO make changes there for some reason
then please tell me! For those with a curious mind, the setting of the
various options which normally go together with the choice of SYSTEM_TYPE
is done at two levels. Firstly, SYSTEM_TYPE determines a default operating
system (AIX | BSD | BSD4.3 | SVR4 | SYSV), and then the operating system
determines a default terminal interface (tty | SYSV termio | POSIX termios).
This is done in the globals.h header file, which (at the time of writing!)
gives the following :-

sys_apollo      BSD43
sys_hpux        SVR4            Note that SVR4 may
sys_rs6000      SVR4            be considered as a
sys_solaris     SVR4            subset of SYSV!
sys_sun         BSD
sys_ultrix      BSD             (default)

SVR4            POSIX termios
SYSV            SYSV termio
BSD, BSD4.3     tty             (default)

One thing that is to be noted concerning this definition of SYSTEM_TYPE
is that there is on offer a different map3270 for each possible value of
SYSTEM_TYPE. The installation procedure then makes this into the map3270
file to be installed. I also have different keyboard mapping help files
for xterm usage according to the SYSTEM_TYPE value and I link the correct
one to be that used when the terminal type $TERM is seen to be xterm.

There is, however, a nasty problem there: the help file is picked up
from where the program is run. However, the xterm server (where you have
your screen and keyboard) may be different (a different type of workstation,
an X-terminal, even a Mac or PC with an X server) and so the actual keyboard
layout, escape sequences of different keys etc. may be different.
To get around this there is also a definition of symbol USER_TYPE. This
may be the same as SYSTEM_TYPE for the case that the software is to be
run on and from a workstation. However, if the user might be on a different
screen/keyboard, including being on a different X server, USER_TYPE can
be defined as "tagibm", meaning a general-purpose gateway to an IBM. This
causes a completely general keyboard mapping file and on-line help file
to be used.
