IBM z/OS container platform image

The container image for IBM® Semeru Runtime Certified Edition for z/OS®, 17 is available in IBM container registries. You can pull the Semeru 17 z/OS container image, and verify the image by using the cryptographic hash. Images are signed, and you can verify the signature.

Running the Semeru 17 z/OS container image

To run the Semeru 17 z/OS container image, you must have the following set up:

The Semeru 17 z/OS container image is hosted on the IBM Cloud® Container Registry under the icr.io/zoscp/ibm-semeru-runtimes namespace.

Note: The Semeru 17 z/OS container image is entitled as part of the Semeru 17 SMP/E offering on Shopz. To access the container image, you need to order the no-charge Semeru 17 product (PID: 5655-UA1), which includes an entitlement memo that outlines the license terms and instructions for using the container image.
You can pull the container image for z/OS from the IBM Cloud Container Registry by using the following command:
podman pull icr.io/zoscp/ibm-semeru-runtimes:certified-17-jdk-zos
Note: The image requires READ access to BPX.FILEATTR.APF. It is recommended that an image administrator ID with the correct permissions be used to pull the Java™ images into /var/lib/podman/storage for other users of Podman for IBM z/OS (Podman). For more information, see https://www.ibm.com/docs/en/zoscp/1.1.0?topic=platform-pushing-pulling-from-container-registry.

You can then verify the signature of the Semeru 17 z/OS image as explained in the following section.

Verifying signature of the Semeru 17 z/OS container image

To verify the signature of the container image, you must have the following set up:
  • A Linux® environment
  • gpg (install through Linux distribution's packages)
  • Skopeo (install through Linux distribution's packages)
  1. The public key must exist on the Linux machine that is used to verify the signed z/OS container image. To create the public key, copy the following text block exactly as shown into a text editor, and save it as semeru-runtimes-public-gpgkey.gpg.
    -----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGQbR9wBEADR//wuh48qCwcrHnGrURseqEG7binLYxb5G4fpOQd9tH/7dLIC
iU7HyoFbMmGiPS1BP7sJ+gn8Kb1dU5IM9ZpBAO4LlMLCm7g2qyc+bkVqQKYezTBa
fvpgDJhZ+e7b4P1vYkx1Ex9XpDd27S/o4aULGnmPjQ9SMtT3qlZf2b59clN9x30Y
VXM2qoRRrpFAkhkoEYQIboY0644TatrVt5CNAQiECdZBn/c0z5op0b42JWTeXvAl
D/FEOWhilSyjSeY7c8ANvP9q3Ur0k18wBCPt47vhXWf5/h9gbBxNtv0p+vKVNVKQ
8CJdPHmylWdtHyWQsNkxFwGZ4EUzhP6YxxV3JQwy5eNnHB8Mt1Xb8LGhqbRdxSBE
0dlHeQIzzAknex6mhAtKyUxJ/+1mxcU1w+kWiYSBrWw71eIEEKhIWGszqW9JND3F
PJ0tNluTlkMJSlboK457/8rKB/NY5qgqDLTaxF6ZSjZUI7rgb1FcGEfV0Te3l0cO
EdUdjg4fM2DXreVZd54JBcp2bEUdcQOmolUIo4wFTNjQawF6ApPmb7qzq5SV7EZj
Cup4Jg4rE/SJhtOVUM4BIYkQ2SLOo4dIqAdFwOrHogXVm1neUJgMJ5US4tply18C
RJCt9VbGTmiFzQkxMgAKXhi9QFuvET1Xc5GUCzkOgoXSoH/IvdeUl8eUJwARAQAB
tDJJQk0gU2VtZXJ1IFJ1bnRpbWVzIFNpZ25pbmcgS2V5IDxwc2lydEB1cy5pYm0u
Y29tPokCOgQTAQgAJAUCZBtH3AIbDwULCQgHAgYVCgkICwIEFgIDAQIeAQUJAAAA
AAAKCRAMOZfZio1FgmNYEACjElnUd7E7n71AYoNTD27+S7Vl8YTyzGkVUVeb1c+3
L3ASZ+kadEMKLepEYsCjGVqQPNXoeosg2YQ4ziY9IlGj5fvoFMuIqx6qisuL9xjM
HaL3xI9aBCX9C/GtZd8DvvvcmglDb8tbOyLAq6tnkhAP1EEaH9cw2jY8V3zH7k99
xqFso+g8GwaEYA7OGyjlvC2uy4wExo1MRodtv+0cxUmKZWoFqu9fNH7a3C9VPBtr
VX5rRWoRJrcjI0Q6OxqximKs7P9H2S9kZtL7Zm4kxh/ZrSWPXlbC8/brs8TDdiga
oFIDmmlK0rCWpsupna69DqS5aBNEO9WOYH8cAG3aw1MsHV0CSLAYZ9Iez7fb5uYx
FClg5mNYj3vWmYRsiLCyaNrhJapCJyPWRCx6U5592yDkCHM9z0WJbGIweEZtfXXB
KCdGW/LWweHYI0xs3BlVOfkg98RAxzMxr3ut7oAa/J0BsqbyV+VMm+jM/Tm/nReG
JTucOa/s+z4MFyP5cQgJH3JUyrhV73vlUKqEqQaoWUTQjVM4Pp42Ew67lFlafoGZ
i7HB1kG+Tq/Od3vNugSM+SzmC+oxcEbbPxEJt2IU25e4ncsiJSIIb51ZAsysE2Ob
YL0Ace+djFYlq9wVG39w9tlgHn094GOsf60X6urdIL6cK/haHGmLyiOBPDhZ9wyd
NA==
=brr/
-----END PGP PUBLIC KEY BLOCK-----
  2. Import the public key on a separate Linux system to verify the signature of the container image:
    gpg --import semeru-runtimes-public-gpgkey.gpg
  3. Calculate the fingerprint with the following command:
    fingerprint=$(gpg --fingerprint --with-colons | grep fpr | tr -d 'fpr:')

    This command stores the key's fingerprint in an environment variable fingerprint, which the command uses to verify the signature. When you exit your shell session, the variable is deleted. You can set it by rerunning the command during the next login.

  4. Create a directory for the image and use Skopeo to pull it into local storage:
    mkdir images
skopeo copy docker://icr.io/zoscp/ibm-semeru-runtimes:certified-17-jdk-zos dir:./images

    You can either authenticate first and do a skopeo copy or directly use --src-cred id:key to pull the docker image.

    The skopeo copy command downloads the image as a set of files and places them in the images directory (or another directory that you choose).
    • A manifest file named images/manifest.json
    • A signature file named images/signature-1

    You reference both these files in the next step (in the command to verify the signature).

  5. Verify the signature:
    skopeo standalone-verify ./images/manifest.json icr.io/zoscp/ibm-semeru-runtimes:certified-17-jdk-zos ${fingerprint} ./images/signature-1
    You get a confirmation on the successful verification of the signature similar to the following message:
    Signature verified with <FINGERPRINT> , digest sha256:0000000000000000000000000000000000000000000000000000000000000000 
After the image is pulled, the image will be available on the server. You can check the details by using the following command:
$ podman images
Details include the repository namespace from where the image was pulled and the specific pulled image details:
REPOSITORY           TAG        IMAGE ID      CREATED      SIZE   
      icr.io/zoscp/ibm-semeru-runtimes     17       8ef69ad2a6bc   11 days ago   644 MB

Known limitations and workarounds

The z/OS container image usage has the following limitations and requires workarounds to troubleshoot those limitations:

  • When running within a z/OS Container Platform instance, the java.nio.File.getFileStore() API might throw a java.io.IOException: Device not found exception when querying a file that is hosted on a bind mount file system. A potential workaround is to migrate the files to a tmpfs file system.
  • _BPXK_AUTOCVT=ON is set in the z/OS base and Java container images. This ON setting might introduce different encoding handling behaviors for java/nio APIs. To avoid a different encoding handling behavior, set _BPKX_AUTOCVT=OFF to match the default setting on non-containerized z/OS environments.