We are sorry to hear that you didn't find Miniconda installation experience satisfying. The issue you mentioned about missing .ffi folder was discussed and explained several times on this forum.
Here is the explanation:
It's related to how FFI (foreign function interface) works in Python on z/OS. Internally, Python uses libffi to perform the actual work of making FFI calls. For every such call, libffi loads a DLL (an .so file) corresponding to the signature of the function being called. Libffi itself is bundled with a number of pre-built DLLs, located in the lib/ffi subdirectory of the package. This directory, however, is only 'plugged in' when the environment is activated, or, alternatively, when FFI_LIB is set up manually.
If there's no FFI_LIB, libffi cannot 'see' the built-in signatures, and any FFI call presents it a 'new', unknown signature. In such situations, it builds the corresponding DLL on-the-fly and places it into the directory $HOME/.ffi - this is like a personal cache of new FFI DLLs. DLLs are built using XLC, which means you need to be able to run it. If XLC fails for whatever reason, it will result in CEE3501S like Greg was seeing.
When you start conda in OMVS, it's easy to hit this because OMVS storage is limited by TSO region, which is often too small. XLC requires quite a lot of storage, and with a small TSO region, CEE3501S will be all you'll get.
As a workaround, you can set environmental variable FFI_LIB to $CONDA_PREFIX/lib/ffi.
Our team is working on documentation improvements for all our ported portfolio. It will also include a troubleshooting page.
In a few weeks it will be possible to install ported tools via SMP/e without Miniconda. This option as well as individual assistance with installation process will be available for customers with support contract for Rocket Open AppDev for Z