IBM z/OS Container Platform image (z/OS only)

The container image for IBM® SDK, Java™ Technology Edition, Version 8 is available in IBM container registries. You can pull the IBM Java 8 z/OS® container image, and verify the image by using the cryptographic hash. Images are signed, and you can verify the signature.

Running the Java 8 z/OS container image

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

The IBM Java 8 z/OS container image is hosted on the IBM Cloud® Container Registry under the icr.io/zoscp/ibmjava namespace.

Note: To obtain the Java 8 container image, open a case through https://www.ibm.com/mysupport/, with "z/OS Container Platform" (PID: 5655-MC3) as a Product option. Replace <key> with the entitlement key value that is provided to you.
podman login -u iamapikey -p <key> icr.io
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/ibmjava:8
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 IBM Java z/OS image as explained in the following section.

Verifying signature of the IBM Java 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 ibm-java-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 ibm-java-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 command to pull the image into local storage:
    mkdir images
skopeo copy docker://icr.io/zoscp/ibmjava:8 dir:./images

    You can either authenticate first and do a skopeo copy or directly use --src-creds iamapikey:<entitlement 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/ibmjava:8 ${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/ibmjava     8       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:

  • Within a z/OS Container Platform instance, the java.nio.File.getFileStore() API might throw a java.io.IOException: Device not found exception if it queries a file that is hosted on a bind mount file system. A potential workaround is to migrate the files to a Temporary File System (tmpfs).
  • _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.