Skip to Main Content
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.

Status Not under consideration
Categories z/TPF
Created by Guest
Created on Mar 27, 2019

Make the TSTB size configurable

We would like to have the option to set the number of tape status table (TSTB) slots to a different value at SIP time. Failing that, we would like to see a larger hardcoded TSTB size.

The number of TSTB slots is defined in SIP macro sptabs.mac:
&SXCATAP SETA 63 TOTAL # OF TAPE DRIVES ALLOWED

This value is used in SIP macro sksycn.mac:
PUNCH 'CPMANT EQU &SXCATAP+1 # TAPE DRIVES ON SYSTEM'

Currently our z/TPF production system has 48 tape devices available on a local VTS and a further 48 tape devices on a remote VTS in our disaster recovery centre. These 96 devices are all connected to our Production CPU (and also to our fallback CPU). If our Production CPU could have these 96 tape devices defined in its TSTB then this would allow a smooth failover in case of problems on the local VTS. Unfortunately the TSTB capacity is 64 slots which is not enough for 96 tape devices.

We prefer to see the TSTB capacity made configurable, for instance by means of a new parameter on SIP macro config.mac with a default of 63 as per the current value in sptabs.mac.
Failing that, we would like to see the TSTB capacity increased so that we can use 96 tape devices.

In case this request is accepted I would like to point out that some IBM software do use a hardcoded value for the number of TSTB slots. This should be updated, I suggest using the conkc interface (label @02ANT). I did not perform an exhaustive scan.

Example 1: corm.c
for (tstbindex=0; /*PJ25098*/
( (tstbindex < 64) && (best_tape == 0) ); /*PJ25098*/
tstbindex++)

Example 2: bxdc.asm
BXTPSRCH DS 0H @410.049
SR R15,R15 GET TAPE SYMB MOD NUMBER @410.049
CINFC R,CMMTS1 GET TSTB SECTION 1 BASE ADDR IN R14
ITSTB SEC=1,REG=R14 @410.049
BXDC57A DS 0H @410.049
CLC CPMTNM,BXCUD2SX IS THIS THE TAPE NAME @410.049
BE BXDCSO YES, SO SEE IF IT IS A STANDBY
BXDC57B DS 0H @410.049
LA R15,1(,R15) INCREASE R15 @410.049
AL R14,=A(CPMT1S) POINT TO NEXT ENTRY @410.049
ST R14,EBX100 SAVE R14 @411.074
CL R15,=A(64) AT THE END OF THE TABLE @410.049
BNE BXDC57A NO CONTINUE SEARCH @410.049
DLAYC @410.049
B BXTPSRCH GO CONTINUE SEARCH @410.04

Idea priority Medium
  • Guest
    Reply
    |
    Sep 4, 2019

    Withdrawn by originator.

  • Guest
    Reply
    |
    Sep 4, 2019

    This RFE can be closed because we can reduce our TSTB requirements.
    Since "forever" our system runs Capture with an I/O time factor value of 1 (i.e. IOTIME-1). The TPF lab has explained to us that this value is meant for use in a Loosely Coupled environment; the SNCF z/TPF system is not loosely coupled. After analysing the expected I/O load and testing on our main test platform, we successfully (and effortlessly) completed a Capture run on our Production environment with IOTIME-0, significantly reducing the Capture run time while at the same time significantly reducing the number of parallel Capture tapes. With this result we can reduce the tape group for Capture to such an extent that the current TSTB size services our requirements so that the reason for our request is gone.
    NB for those readers who wonder why the SNCF runs Capture despite using Hitachi HUR support for database restore: we don't use Capture /Restore for recovering from a database corruption because Hitachi HUR services that purpose admirably. We use the Capture to refresh our nobase test systems.