I am by no means an expert in Unix concepts but I have still spotted a bunch of different issues in z/OS Unix environments in my short career and wanted to share some useful information. I will go over issues I have seen or things people do that hurt their productivity or the environment they're in.

Excessive security bits

z/OS Unix files are secured with groups and security bits. The security bits have 3 sections:

In this example the owner can read, write and exectute, the group assigned to the file or directory has read and execute access, and everyone else has no access at all. You can think of the "other" group as universal access or ID(*) in RACF terms, it's basically the same thing. The other group should basically never have write access, there are very few exceptions to that general best practice recommendation. If the security bits are set to 777 (or RWXRWXRWX) it's pretty much guaranteed to be a security issue and that the person who should have configured the security didn't take security into account. One of the exceptions to this rule though is the tmp folder, it is actually allowed to have this access, some things will stop working if you remove this.

There are many ways to fix these issues if they're widespread in your environment, the easiest is to set up a scanning utility that checks for issues like this, the easiest way is to program a utility in C++ or Python as they have very good standard libraries built in for changing permissions and working with Unix files. See the "os" library in Python.

Not giving the right permission bits to configuration files

This is kind of the opposite problem to the last section, it's important that program or user that needs to read the configuration file has read and execute access. For example Zsh will fail for people if the profile in /etc/zprofile has 700 (rwx------) set as the permissions.

Not respecting Unix folder structures

Unix has a very specific folder structure, especially close to the root (/). It's important that you don't create folders that clash with this organized structure, don't create your own folder for temporary files when you can use the existing one. There are very good explanations on other sites of what goes in these folders, you can mostly learn the system by reading Linux guides since it's about 80% the same, there's a few exceptions like the software folder being /usr/lpp instead.

Neglecting system configuration files

I've seen a bunch of different issues relating to profile files, some are worse than others. One of the lighter ones is not creating a zprofile for the Zsh port we got in z/OS 3.1. Zsh is a lot better than the old shell we had, but a lot of installations have just not done anything with it and are missing out on useful features like autocomplete. Another issue I've seen is people installing software and not adding it to /etc/profile and /etc/zprofile, if very few people will be using the software it's not a problem, but if it's supposed to be widely available it should be added to the system path so people use it without having to create their own shell profile.

Sleeping on SSH

I'm still surprised to see so many people using TSO OMVS or TSO ISHELL over SSH, you get a lot of really cool features if you access Unix via SSH:

• Command line colors that color lines or even individual words
• Autocomplete, allows you to type commands much quicker
• Support for UTF-8 characters

The command and file auto completion alone is a huge boost to productivity, I can't do without it.

Not taking advantage of zOpen

Everyone who spends time in z/OS Unix should request zOpen on the system or install it themselves if they can. zOpen comes with a large array of useful Unix utilities:

• Neovim (Similar to OEDIT but more modern and works over SSH)
• c3270 (3270 sessions from an SSH session)
• sudo (We'll cover this in the next section)

...and many more, see the full list on the zOpen website

Not using sudo

I mentioned sudo in the last section and it's seriously useful from a security perspective, it allows you to give people limited super user privileges. A lot of different roles on z/OS may require access to some privileged commands, but people shouldn't have access to more than they need, with sudo people will have to write "sudo" in front of privileged commands and you can control in the sudoers which privileged commands they should have access to based on the groups they're part of. Everyone mainframe installation that cares about security should have this. Sudo is also useful for system users, they may sometimes need a single privileged command, but it wouldn't be secure to give them more than they need, which is solvable with sudo.