Skip to Main Content
Cloud Platform


This is an IBM Automation portal for Cloud Platform products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.


Status Submitted
Created by Guest
Created on Dec 27, 2024

Update Post-APPLY ++SHELLSCR to allow use of System Symbols for SYMLINK creatio

The Post-APPLY ++SHELLSCR that are delivered with the z/OS Java FMIDs and every PTF that creates the SYMLINKs for /usr/lpp/java/current... should be updated... It was appropiate back in time when there was only one Java version available: Java 8. Before Java 8, there were no SYMLINKs created from the Post-APPLY script.

In these days, with multiple Java versions available, it is no longer the right way to just use the actual Java version for the SYMLINK creation, because multiple used software instances that may not support the actual  Java version, yet, use the SYMLINKs (in our example: CICS doesn't support Java 21 at the moment, the support PTF is planned for 03/2025).

The installations should be able to decide the Java version for the SYMLINKs by their own. In parallel, the Shell Scripts delivered with Java 17 and Java 21 were initially wrong and after installation the SYMLINKs pointed back to Java 8. See: PH57948 for Java 17, for Java 21 we've currently no APAR number, but the Java team is working on. This is specially problematic on V3R1 that requires at least Java 11.

Our installation currently uses Usermods to update the SYMLINKs. As the same SYMLINKs are created by Java 8 (31+64), Java 11, Java 17, Java 21, we would require 5 usermods to just update one SYMLINK to get a trigger once a PTF is installed for any of the installed Java versions. This is very error prone.

z/OS comes with a unix function called "sysvar" to read System Symbols. I think a better way to create the symlinks would be: Use "sysvar" to read System Symbols like "SYSJAV31" and "SYSJAV64". If these are set, create the SYMLINKs according to the System Symbols. If these are not set, create the SYMLINKs like they are created today: Use the actual Java version. The only situation that could be a bit problematic could be a release migration (maybe V3R2 would rely on Java 21, but the customer has set Java 17 as default). This could be overcome by a HOLD action to make a note for the customer.

 

Idea priority Urgent