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 :
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
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
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)
$(CC) $(OPT) -o $(PGEN)
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] +
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.
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 :
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);
since __MVS__ is only defined for OS390 / ZOS and MVS ibm's operating system, the above change is compatible with other environments.
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 :
if sys.platform == 'mvs':
import statmvs as 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 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 :
and issue a make conmand
Copyright © 2002,2003,2004 Jean-Yves MENGANT .