When I use Make 4.1 and use the make file function, make seems to create the file in ISO8859-1 format (it is tagged as such). Whereas, if I use a Make 4.0 version if creates the file in IBM-1047 format. How do I get Make 4.1 to create the file in IBM-1047 format?
Could you specify, how you create files with Make?
GNU Make has a “file” function that allows files to be read and written to (or appended to). It is described here:
We are using this to create a temporary file that is then used later in the make process. So a make file like this
ALL_FILES := \
OUTFILE := /u/groeges/test/TestFiles.txt
will create a file called /u/groeges/test/TestFiles.txt.
When using Rocket make 4.1 this generates a file with in ISO8859-1 format (and tagged as such).
Other make (that we have on our zos machine) generates the file in IBM-1047 (which is the default for z/OS).
Why does the Rocket make create files in a charset/codepage different from the default for the system?
I have reproduced this, and opened internal Rocket ticket USSP-961 to track it.
The problem as I see it is that make is not respecting the file tag on existing files. All Unix programs on z/OS should respect file tags, as long as _BPXK_AUTOCVT=ON is specified. All Rocket ported tools are moving to ASCII internally (which improves the compatibility of behaviour with other Unix systems, especially for tools like Python and perl, where there are large library ecosystems). As a result, most tools will produce ASCII-tagged files by default. In this case, it should be possible to force a file to be encoded as EBCDIC, as illustrated in this Makefile. However, the tag is NOT being respected in particular, the tag is not changed, but the content is always written in ASCII, regardless of the tag.
# Note: If you cut and paste this, you must replace 8 leading spaces with
# tabs to get a valid Makefile
OUTPUT_FILES = file_list file_list_ebcdic file_list_ascii
ALL_FILES = source1 source2
ls -lT $@
touch $@; chtag -tc819 $@
ls -lT $@
touch $@; chtag -tc1047 $@
ls -lT $@
rm -f $(OUTPUT_FILES)
My proposed workaround may be invalid; the file function is being run in the first phase of Makefile processing (Makefile parsing) and not the second (dependency and rule evaluation). At least, that seems to be the observed behavior.
This is not likely to be addressed soon.