You are also free to modify it and to distribute it, provided you include the existing copyright notices, and don't profit from it.
grep XtSpecificationRelease /usr/include/X11/Intrinsic.h(You may need to use a different path name if your header files are somewhere else.)
If you are running X11R4, the answer will be:
#define XtSpecificationRelease 4If R5:
#define XtSpecificationRelease 5If R6:
#define XtSpecificationRelease 6
(Carefully note the differences in build procedures between Sun OpenWindows and other operating systems -- or you'll end up back here anyway.)
_get_wmShellWidgetClass _get_applicationShellWidgetClassThis is a bug in Sun's X11 libraries, and can be corrected by obtaining patches 100512-02 and 100573-03 from Sun. As a short-term workaround, edit Makefile.openwin; there is a line you can uncomment for just this purpose.
_connect _gethostbyname _getservbyname _setsockopt _shutdown _socketNetwork calls are in a separate library on SVR4 systems. You need to umcomment the line in the Imakefile that begins "#EXTRA_LIBRARIES", then try again with xmkmf.
ccom: Warning: x3270.c, line nnn: Argument 5 Type Doesn't Match prototype description; prototype: pointer to unsigned int is different from actual: pointer to int 0); -------^The prototype arguments for XtVaAppInitialize in
The simplest probem to fix is that you haven't told your X server that there are new fonts it can use. This is corrected with:
xset fp rehashIf this doesn't help, it is possible that your X server font path doesn't include the directory that the 3270 fonts were installed in. Run the command "xset q". The output will include an entry like:
Font Path: /usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/Speedo/,/usr/lib/X11/fonts/75dpi/,/usr/lib/X11/fonts/100dpi/x3270's fonts are usually installed in /usr/lib/X11/fonts/misc. If this (or some variation on it) does not appear in the "xset q" output, you can try:
xset fp+ /usr/lib/X11/fonts/misc/ xset fp rehash(Note that on Sun OpenWindows prior to version 3.3, the only directory in your font path is usually /usr/openwin/lib/fonts, and there is no "misc" directory to add to your path.)
The "X" symbol means that the keyboard is locked. This can be locked for any of the following reasons:
Pressing the Insert key (Alt-i or the Insert key if your keyboard has one) puts x3270 into Insert mode. Pressing it again does not disable Insert mode; to do that you must use Reset.
There is an alternate x3270 action you can bind to the Insert key, ToggleInsert(), to change that behavior.
x3270 has a configurable option, "Blank Fill", which disables this "3270 warts-and-all" emulation behavior.
You can tell exactly which keymap and keymap modifiers x3270 is using with the "About x3270" option on the "Options" menu. There is an entry labeled "Keyboard map:" which lists the keymap(s) in effect. If yours is missing, there are a number of possible causes:
xrdb $HOME/.Xdefaults
x3270.keymap: sun-k5then use xrdb to read in the file, the symbol "sun" may be defined as "1" as the file is read. This turns the above into:
x3270.keymap: 1-k5causing much confusion.
The fix is to add the following line to the top of your .Xdefaults:
#undef sun
xmodmap -e 'add Mod2 = Alt_L'If this fixes the problem, you can add it to your .xinitrc file, so it takes effect every time your start X.
x3270 -tracex3270 will create a trace file in /usr/tmp, which will contain a dump of all of the data that x3270 sent or received, along with its interpretation. x3270 will also pop up a window to view the file while it is being created; the title of that window is the full pathname of the trace file. If you are familiar with the 3270 Data Stream protocol, you may be able to figure out the problem yourself; otherwise, after suitable editing to remove passwords and proprietary information, you may send it in (see below).
One solution is to set your TERM variable to "xterm" after you log in, and to set the number of lines and columns to match the current x3270 model number (this is done through the "stty" command or with environment variables, depending on your system).
A second solution is to create termcap entries for the 3270 terminal types. Here are some sample entries:
I2|IBM-3278-2|x3270 Emulating 3278-2:li#24:tc=xterm: I3|IBM-3278-3|x3270 Emulating 3278-3:li#32:tc=xterm: I4|IBM-3278-4|x3270 Emulating 3278-4:li#43:tc=xterm: I5|IBM-3278-5|x3270 Emulating 3278-5:li#27:co#127:tc=xterm:
x3270 can be modified to work around this problem. An unfortunate side-effect is that it will no longer be able to display APL characters, or line-drawing characters with any of the 3270 fonts.
To rebuild x3270 to work around this bug, edit the Imakefile and add a line at the top:
EXTRA_DEFINES = -DBROKEN_MACH32Then rebuild the makefile, the module "screen.o", and x3270:
rm screen.o xmkmf make depend make
When you send a question about x3270, please include the following information. It makes it much easier to narrow down the problem.