IBM Z Software


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).


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.

Add a new idea Subscribe
Status Not under consideration
Workspace z/TPF Product Family
Categories z/TPF
Created by Guest
Created on Jun 1, 2018

RELATED IDEAS

Ability to IPL from one of several LGFs

We're running a production TPF environment which maintains six data base images (not to be confused with: loader images) by means of the HDS Copy Manager. That is: we have six complete sets of RT DASDs containing recent consistent copies of our TPF Production data to select from at LGF IPL time.
For this purpose we have six different LGF volumes.

Unfortunately keypoint V has only one field for the LGF VSN, namely CKVSLGF (see idsckv.mac). This means that for five out of the six LGFs we need to edit the VSN prior to IPL which is not desirable, especially not in case of an unplanned IPL.

We open this RFE to ask for the ability to IPL from any of six LGF volumes, or more generically:
from any of "x" LGF volumes, each having a unique VSN, where "x" is to be defined at system generation time.
Ideally we should not need to provide a range. We're looking for a solution where we can put a list of LGF VSNs in keypoint V.

Idea priority Low
  • Guest
    Reply
    |     Dec 8, 2020

    IBM recommends that each database image use a different alphabetic portion of the VSNs for the real-time DASD and use a REP card in the load deck to modify CTKV so that the LGF VSN field matches the VSN of the LGF pack being created.

  • Guest
    Reply
    |     Sep 3, 2018

    I talked to our expert today and the VSN issue turns out to be somewhat different from how I described it. So let me answer your VSN question again, this response replaces my previous one.
    Q: How are the VSNs of the RT modules handled? Does each database have a different set of VSNs for the realtime modules?
    A: Please see the slide "Replication". All database images share the same first two (alpha) VSN characters. The modules of the three database images of the local sites all have a different numerical part of their VSN. However, these VSNs are copied to the modules of the remote site. So module "n" of Shadow Image 1 (= the second image on the local site) has the same VSN as module "n" of Shadow Image 3 (= the second image on the remote site), for instance. In any case IPLB roll call will see only one database image because each database image has its own CTK0.

  • Guest
    Reply
    |     Aug 30, 2018

    During the spring TUG of 2013 we gave a presentation on our disaster recovery plan. Please be so kind to give it a look, I'll refer to it for answering your questions.
    http://tpfug.net/MemberServices/Presentations/PPTs/Spring2013/TUG%20Atlanta%20-%20Avril%202013%20-%20SNCF%20Recovery%20Plan.pdf

    Q: Why is a LGF load done in this case instead of an image load?
    A: See in our presentation the slide "Recovery procedure driven by CTK0".
    In order to select a database image we need to load its associated CTK0. Imagine that we are running on database image "Production" and want to fallback to database image "Shadow image one". And imagine that we would decide to use the image loader to load the CTK0 for "Shadow image one" into the keypoint staging area for "Production". Then we do an IPL of the "Production" prime pack (because, how else to activate the new CTK0?) which causes IPLB to roll call the "Shadow image one" database image. But the "Production" database image's prime pack is still connected at that point because it is the IPL device. My best guess is that the IPL procedure will spring leaks at this point because if the IPL DASD is not part of the active database then it should be the GFL pack, not an RT pack of another database. In any case the situation will be dirty: IPLB is not designed for it.
    In contrast, bringing in CTK0 by means of a GFL load is the clean way to do it.

    Q: Does a fallback to a previous version of the program base need to be done as well as a fallback to a previous version of the database?
    A: That depends on the cause of the disaster. If the problem is a database corruption caused by wayward programs then likely yes. Faulty programs will not be OLD'd back onto the system. In case the problem is a severe hardware problem or a database corruption caused by an operational error (loading a wrong pilot tape, say) then likely no, and OLD will be used to activate the latest software as needed.

    Q: How are the VSNs of the RT modules handled? Does each database have a different set of VSNs for the realtime modules?
    A: Relative module "x" on our first database image has the same VSN as relative module "x" on the other database images. Because each database image has its own CTK0 (and thereby its own set of SDAs) this does not lead to problems during roll call. In fact CTK0 pretty much defines a database image. Once again, see the slide "Recovery procedure driven by CTK0" in our presentation.
    (To be honest I don't think it would be a big deal if each database image would use a different alphabetic portion for its RT DASDs, provided the LGF load decks contain the appropriate reps against CTKV).

    In case you have any further questions, don't hesitate to ask!

  • Guest
    Reply
    |     Aug 3, 2018

    Why is a LGF load done in this case instead of an image load? Does a fallback to a previous version of the program base need to be done as well as a fallback to a previous version of the database?

    How are the VSNs of the realtime modules handled? Does each database have a different set of VSNs for the realtime modules?

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.