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. 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. 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.