This portal is to open public enhancement requests against IBM Z Software 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).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
I would really like to have variable substitution and concatenation for LIBPATH, TMSUFFIX and CLASSPATH for the IMS runtime directories, but also to be able to use symlinks in the PATH, LIBPATH and CLASSPATH for the Java Home and DB2 directories. Those symlinks are created and maintained by the teams that support DB2 and Java.
The kludge to allowing the limited dynanicism I was mentioning in this request would be something like each LPAR have a unique symlink at /var/imsRuntime that points to something like /ims/runtimes/IMAA, where IMAA is the IMS subsystem whose SDFSRESL is in the linklist on that LPAR. In other words, LPAR1 might point to IMAA while LPAR2 might point to IMAB. This is not as good as being able to reference the system symbolic referenced by the linklist that identifies the IMS as it leads to a higher likelyhood of a mismatch and is likely to be completely forgotten by individuals without Linux backgrounds.
Here is a sample DFSJVMEV (DFSJVMMS would also be affected--and the -Xoptionsfile content referenced by DFSJVMMS) that currently hard codes the absolute path to the IMAA IMS subsystem and uses (unsupported) symlinks to the db2 and java directories for the use case of JMPs or an individual JBP needing to code to a specific IMS subsystem:
******************************************
* PATH=/usr/lpp/java/J7.1/bin
PATH=/usr/local/java/latest.version_31/bin
*
* LIBPATH=/db2/db2v11/db2a/usr/lpp/db2b10/jdbc/lib
LIBPATH=/db2/db2a/zfs/jdbc/lib:>
/usr/local/java/latest.version_31/bin/j9vm:>
/usr/local/java/latest.version_31/bin:>
/ims/runtimes/IMAA/imsjava/lib:>
/ims/runtimes/IMAA/imsjava/classic:>
/ims/runtimes/IMAA/imsjava/classic/lib:
*
TMSUFFIX=>
/ims/runtimes/IMAA/imsjava/classic/imsjavaBase.jar:>
/ims/runtimes/IMAA/imsjava/classic/imsJDBC.jar:>
/ims/runtimes/IMAA/imsjava/classic/imsXQuery.jar
******************************************
For general JBP use, I have a more generic version of DFSJVMEV that uses the unsupported symlink reference via /var/imsRuntime/imsjava/.... instead of the /ims/runtimes/IMAA/imsjava/... directories.
I would really like to be able to replace these multiple, almost-identical versions of DFSJVMEV (one for each IMS subsystem plus one more for general JBP use) with a single version that allows substituting in variables for the differences and continuing to use (now?) supported symlinks for Java and DB2.
As an aside, please remember that system symbols of the LPAR that a general, non-STC job executes on are available via an instream DDDEF via DD *,SYMBOLS=EXECSYS. Use of system symbols outside of that will depend on using a hardcoded /*JOBPARM SYSAFF=xxx, referencing a specific LPAR to ensure that conversion (where system symbols are resolved, unlike the mentioned example of DD *,SYMBOLS=EXECSYS) and execution occur on the same LPAR, negating the intent of allowing a user or scheduling system to simply submit a JBP like a BMP and having WLM manage which LPAR it executed on.
Can we get more information on the symbolic links planned here? Are you looking more for variable substitution and/or concatenation for the LIBPATH values?