Open-source Languages & Tools for z/OS

I am trying to use the Make package provided as part of the Rocket Tools for z/OS but am having issues with it when trying to export a value to s system environment in order for it to be used in a sub-make task. With other Make executables on other platforms (and even earlier version on z/OS) this worked - but with the GNU Make v4.1 version this does not work.

I have the following test makefiles

test1.mk

export TEST=xxxx

all: first
        @echo test1_all, $(TEST)

first:
        @echo test1_first, $(TEST)
        make -f test2.mk

test2.mk

all:
        @echo test2_all, $(TEST)

When I run the test1.mk file with the following command “make -f test1.mk” I get the following output.

test1_first, xxxxx
test2_all,
test1_all, xxxxx

Where it can be seen that in the sub-make file that is called the value for TEST is not set, whereas when the same make files are run on an earlier version (or on another platform) I get

test1_first, xxxxx
make[1]: Entering directory '/u/groeges'
test2_all, xxxxx
make[1]: Leaving directory '/u/groeges'
test1_all, xxxxx

Notice that the value of TEST in the sub-make is set to xxxxxxx.

Is this a bug in the build of GNU 4.1 that is available from Rocket.

Also, I see that in the execution on earlier or other platforms the output shows the lines
"make[1]: Entering directory ‘/u/groeges’"
whereas on the 4.1 version it does not.

Please can you help here as I need to use GNU Make 4.1 due to other issues in earlier versions of Make.

Thanks
Steve Groeger

Porting team is backlogged at present. It will be several weeks before this can be looked into.

Is there any update on if this has been identified as an issue and when it might be fixed.

I have opened internal Rocket ticket USSP-941 to track this.

Note, when all our engineers are occupied working on issues from users that are paying Rocket for support on these z/OS tool and language ports, the paying customers will take precedence over any request from a non-paying (forum) request. We do provide free support as well but it is a question of priorities and times to resolve. In other words, if this problem is mission-critical you may want to consider getting a support contract.

Is there any update on this bug? It is still an issue.

Still, not. We have make 4.2.1 as a miniconda package now and it has the same bug. We’ve opened another internal issue USSP-1231 for the corresponding version of make tool. Stay tuned.