IBM OS390 Python 2.2 port


HomeLink

Encountered porting problems description and solutions.

I provide below explanations about all the port problem I encountered for MVS os familly( MVS , OS390 , Zos) . All these problems are fixed inside the provide tarball above.

If you're starting with a different python 2 version and if you want to manually patch the python sources the following explanation about the problem I encountered should be usefull :

Build problems

Initial make pbs on some Modules construction :

MODULE

action

tk-lib

Make error on tk-lib : reset the TK-PATH= in configure.in for mvs systems, this does not hurt since the tkinter has no usage on OS390 which does not implement X11 server

plat-os39010·

Make error on plat-os39010 : In order to be able to deal with OS390 or ZOS platform, I modified the configure shell to generate MACHDEP="mvs" when an mvs OS390 platform familly is recognized

-O output cc compiler's fllag position at link time :

IBM's cc compiler is not comfortable when the -o outputfilename is located at the end of the cc command when linking.

the following linker unclear error is then issued :

cc -DNDEBUG -O Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/n ode.o Parser/parser.o Parser/parsetok.o Parser/tokenizer.o Parser/bitset.o Parser/metagrammar.o Python/mysnprintf.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/printgrammar.o Parser/pgenmain.o -o Parser/pgen

IEW2785S D21A AN ATTEMPT TO OBTAIN FILE STATISTICS FOR PATHNAME ./-o FAILED. 'HFS ISSUED RETURN CODE 00000081 AND REASON CODE 053B006C. IEW2785S D21A AN ATTEMPT TO OBTAIN FILE STATISTICS FOR PATHNAME ./Parser/pgen FAILED. 'HFS ISSUED RETURN CODE 00000081 AND REASON CODE 053B006C.

in order to ger ridd of the above pb Inside Makefile change :

$(CC) $(OPT) $(PGENOBJS) $(LIBS) -o $(PGEN)

into

$(CC) $(OPT) -o $(PGEN) $(PGENOBJS) $(LIBS)

this compiler's idiosynchrasy implies changes both in the Makefile.pre.in which is processed by the configure installer and also a change in $(srcdir)/Modules/makesetup script : Line 223 provides following compile rules for added dependencies inserted into Makefile by the setup :

rule="$obj: $src; $cc $cpps -c $src -o $obj"

replaced by :

rule="$obj: $src; $cc-o $obj $cpps -c $src"

The same problem is also present inside distutils/unixccompiler.py python module which provides ccompiler's launch rules for optional python modules distributions the following python statement on line 157 :

self.spawn(self.compiler_so + cc_args + [src,'-o', obj ] + extra_postargs)

has been replaced by :

self.spawn(self.compiler_so + cc_args + ['-o', obj , src] + extra_postargs)

There may be extra changes of this king that I forgot to report here ... Any all of them are concerning either the Makefile.pre.in or the configure.in ... All This changes should be compatible with other unix compiler's.

Non compliant EBCDIC test inside stringobject.c :

command returns hexadecimal display back due to a non EBCDIC compliant test inside stringobject.c in string_print entry ; the following python statements typed inside the python shell :

import sys
dir(sys)

produces hexadecimal display on console ; in order to fix that , I made a tiny portable change inside string_print function :

#ifdef __MVS__ /* EBCDIC */
else if (c < 0x40 || c >= 0xf9)
fprintf(fp, "\\x%02x", c & 0xff);
#else /* ASCII */
else if (c < ' ' || c >= 0x7f)
if printf(fp, "\\x%02x", c & 0xff);
#endif

since __MVS__ is only defined for OS390 / ZOS and MVS ibm's operating system, the above change is compatible with other environments.

/Lib/stat.py do not comply with MVS POSIX.1 implementation:

The values and test done inside the stat.py python module are not compatible with the os390 C implementation as described in include/modes.h prototype. In order to adress this problem, I defined a statmvs.py module which implements the OS390 expected rules. Inside the posixpath.py module, I made following tiny compatible extension :

import os
import sys
if sys.platform == 'mvs':
import statmvs as stat
else:
import stat

This makes the statmvs.py being loaded at startup by the site.py when a 'mvs' platform is recognized. If you don't do this change , the stat.py launch fails at python shell startup due to bad infos returned by original stat.py on OS390 dir.

MVS dynamic loading and build :

MVS provides a DLL implementation , dynamic loading is specific to the os and a dynamic loader module dynload_mvs.c has been added following the standard python loading mechanisms . This module has been added inside the Python source subdirectory , to implement MVS DLL loading idiosynchrasies.

In order to activate DLL usage you must use the following configure flag :

./configure –with-zdll

and issue a make conmand


Copyright © 2002,2003,2004 Jean-Yves MENGANT .