Open-source Languages & Tools for z/OS

Before installing your distribution you need to unpack it.

All z/OpenSource languages and tools are delivered as gzip tar files (e.g. automake-1.10_b0001.160204.tar.gz) with the exception of gzip which is delivered as a simple tar file (e.g. gzip-1.6-edc_b0002.160204.tar).

If you do not already have gzip on your system you will need to start by downloading and installing gzip and to unpack the gzip distribution you need only issue a standard tar extraction command.

To unpack all other z/OpenSource languages and tools from Rocket enter the following commands using your own
destination directory in place of /rsusr/rocket:

gunzip tool.tar.gz
tar -C /rsusr/rocket -xoUXf tool.tar

For example, if unpacking automake-1.10_b0001.160204.tar.gz, issue the commands:

gunzip automake-1.10_b0001.160204.tar.gz
tar -C /rsusr/rocket -xoUXf automake-1.10_b0001.160204.tar

Each Rocket open source distribution comes with tool-specific installation instructions (README.ZOS) and a version information file (VERSION.ZOS).

These files are located in :

share/doc/<toolName>/<version>

Hi, I have been asked to “Install Python” on our zOS environment(s). I am afraid I am a little stuck. There is alot of information but I am having trouble putting the actual tasks together as well as getting any specific information about ‘uploading to zOS’ that I can find.
I have downloaded the package from rocket software to my PC. It needs to be uploaded to a USS file on zOS? or is that a SMPTFIN type file or the actual tarball? some instruction on how to define the receiving area on zOS would be very helpfull. Also, a general process to install Python would help clear out some of the confusion. Do I need to install GZIP, then Install BASH, Then install Pearl, Then install Python? Is there a ~combined way to install all?
It feels like I am just missing a small peice of information to make everything click.
Thanks in advance for all replies.

Correct. I personally use WinSCP to transfer from my PC to USS and I use the SFTP protocol setting within WinSCP. Be sure you transfer in binary mode.

You guessed correctly more or less. Start with gzip, then the others in any order. You will see that the README.ZOS content for each product has a lot of overlap. There is as yet no way to install them all in one go but we plan to move in that direction eventually. Some familiarity with unix is required to succeed with all this. Also, important to read up on z/OS enhanced ASCII feature set which you can read about here: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxb200/uenha.htm
and here: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxb200/setupa.htm
We are gradually moving all our ports to work internally in ASCII but also support EBCDIC equally well. We are about 2/3rds the way there.
-Peter

Thank you this is very helpful. Do you have some reference for defining the ZFS file ? I know how to run the IDCAMS and issue the mount etc… just looking for size and any special parms I need @ mount time?
Perhaps it’s part of my confusion but don’t I have to upload to the mainframe and unzip before I can see the README file?

What, you don’t have a time machine? This is where we fall on our sword. I did instruct the team to add the README.ZOS for each product to each download file so our users were not caught in a catch-22. But, I guess it has not been universally applied. Sorry.

I will have to get someone else to answer your ZFS question.

thank you again for the information so far. I appriciate any additional information. Larger than a bread box but smaller than a bread truck?

Warning I am not a systems programmer (any more). Answers may contain more than the recommended daily allowance of speculation and misdirection.

That said:

You could determine a very approximate amount of space required by taking the size of the download files (the .tar.gz files), adding them, multiplying by 3 (to account for compression), and rounding up to some nice multiple that feels good to you.

As far as mount parameters: when performing the initial installation, the file system needs to be writable. Once installed, you could remount the file system as read-only.

– Jerry

I did find a comment, in the python documentation, about the final unzipped size if my math is right I am looking at ~ .5 of a 3390 mod9 or roughly 5000 cylinders. but that is just for python. It’s not clear if each product needs it’s own landing place to be unzipped / tared or if each product will have it’s own unique requirement… Either way I think I have a starting guess. If anyone has done this and could provide the output from a zos command #D OMVS,F … that would be really helpfull. A “DF .” in the directory holding these files would also provide a nice look. thanks for the reply, appriciate the help

You can avoid having to actually land the un-gzipped tar files by piping the output of gzip directly into tar. Once you have gzip installed, do something like this:

gzip -c -d <toolname.tar.gz | tar -C /your/install/location -xoUXf -

It’s common practice to install all of the tools in one place (such as /usr/local/rocket).

Looks like there is a README.ZOS file in the downloads. I am not sure if I just missed it or if it was corrected but it is there. That file gives specifics on the 'TAR and 'GZIP commands to get things extracted but it still felt like there was some information that I was missing. So to perhaps help the next person:

Here are the rough size requirements for each product I installed:
Python using ~ 4000 cyl. I allocated 5000.
Perl using ~49 cyl. I allocated 50
Bash using 45 cyl. I allocated 50
Gzip - very small I allocated 50 cyl. but it is using less than 10.

Here is some general JCL to get the HFS defined and mounted:
//ALLOCATE EXEC PGM=IEFBR14
//NZFS DD DSN=xxxxxx.xxxx.xxxxxxx.GZIP,
// SPACE=(CYL,(50,5,1)),
// DSNTYPE=HFS,DCB=(DSORG=PO),
// DISP=(NEW,CATLG,KEEP),UNIT=SYSDA,
// VOL=SER=xxxxxx

//MOUNTHFS EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN DD *
PROF MSGID
MOUNT FILESYSTEM(‘xxx.xxx.xxx’) -
MOUNTPOINT(’/Rocket/gzip/’) TYPE(HFS) MODE(RDWR)
/*

Also, just by convention I installed each on its own file system. I think this will keep things tidy as we deploy out to 60+ LPARS over the next few weeks.

Thansk again for all the help. Let the fun begin

FWIW: Some tools try to determine the location of other tools based on their own paths. For example, “toola” might be in /Rocket/bin and need to use “toolb”; it would first try to find it in that same directory. This is one reason I suggested putting them in a single file system (like /Rocket), rather than many separate file systems (like /Rocket/gzip, /Rocket/perl, etc.).

I would also think that having to mount a single file system, rather than many, would be easier to set up.

Understood and appriciate the feedback. I was working under the impression that ALL the added export statements I added to my .profile would address the issue of where things are. ? Hopefully??
Again, our apparent standard - not written in stone -but at least the convention in our shop is /Vendor/product .

Hi,

I have downloaded and unpacked the auto tools.
I tried to follow the suggestions here, unless I missed something which I don’t know.
Some of the tools seem to work but with m4 I have this strange issue.
If I do ‘./m4 --help’ or ‘./m4 --version’ is just a bunch of unprintable chars coming back.
I execute m4 from the default USS shell.
_BPXK_AUTOCVT was exported to ON.

I am attaching here a putty screenshot.

https://aws1.discourse-cdn.com/business7/uploads/rocketsoftware/optimized/1X/e9ec760438a6c9ed6b7ac3f64ab28c2c6199328f_2_1035x280.png 1.5x, https://aws1.discourse-cdn.com/business7/uploads/rocketsoftware/optimized/1X/e9ec760438a6c9ed6b7ac3f64ab28c2c6199328f_2_1380x374.png 2x" data-small-upload="https://aws1.discourse-cdn.com/business7/uploads/rocketsoftware/optimized/1X/e9ec760438a6c9ed6b7ac3f64ab28c2c6199328f_2_10x10.png">

m4_err1.png1536×418 112 KB

Many thanks in advance,
Adrian.

Hi Adrian,

Which version of m4 do you use?

Hi,

Thanks for coming back to me.
I used the archive: m4-1.4.18_b001.170511.tar

thanks,
Adrian.

Hi,

Some news.
Trying m4 from under the bash shell gives much better results.
Sorry to have disturbed you for this.
I’ll try to solve my issues from under bash and if still have problems I’ll come back here.

Many thanks.
Adrian.

I was trying to unpack the latest (7.52.1) cURL distribution. Based on the instructions in this forum post, I’m supposed to use the -UX options on the tar command. However, I’m not certain if the tar command on our mainframe supports those options.
I get the error:
tar: FSUM7170 .: cannot set mode: EDC5139I Operation not permitted.
It could also mean that my user doesn’t have the proper permissions to be able to run the tar command with those options (I confirmed that I’m authorized to write the folder that I specified on the tar -C … command option). Any help would be appreciated.

Alex

Can you please provide the complete output?

I’m fairly sure that these are only warnings, and are caused by tar attempting to restore the owner and group IDs for the files. If that’s the case, these can be ignored.

That line was the only thing that was output. The command simply returned and didn’t seem to expand anything. I also had our sysprog run it but I still don’t seem to have a usable version of curl. When I run curl --help I get gibberish.

Here are several things that may help:

• The tool download page contains a README.ZOS file that has the installation instructions. I followed those for the curl-7.52.1_b004.170529.tar.gz download (installing into my home directory) and got a working curl. The first part of the instructions is:

 gzip -d curl-7.52.1_<build>.tar.gz
 tar -C /rsusr/rocket -xovf curl-7.52.1_<build>.tar

• You also need to be sure to set the environment variables as indicated:

 export PATH=$PATH:/rsusr/rocket/bin
 export LIBPATH=$LIBPATH:/rsusr/rocket/lib
 export MANPATH=$MANPATH:/rsusr/rocket/share/man
 export _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)"
 export _BPXK_AUTOCVT=ON
 export _TAG_REDIR_ERR=txt
 export _TAG_REDIR_IN=txt
 export _TAG_REDIR_OUT=txt

_BPXK_AUTOCVT=ON is especially important and easy to overlook; this enables EBCDIC/ASCII conversion.

Hope this helps.