IBM Mainframe Forum

This code is linked to 99 other codes via an alternate index which has reached it's currently defined maximum.

This is the key point. The number of alternates reached the maximum number allowed so obviously you need to delete the AIX, redefine it with a larger record size, and then rebuild the AIX and path.

There is probably no easy way -- if any at all -- to reconcile the differences. The VSAM Demystified recbook explicitly states that the primary keys in an alternate index are kept in ascending sequence. However, since the current file is hitting the maximum number of keys allowed in an AIX record, there's no way to tell which record caused the maximum to be reached -- so rebuilding the AIX may cause differences since the primary keys will be loaded in ascending order, not in the order added to the base cluster. And since the whole purpose of rebuilding is to increase the record size for the alternate index, you cannot directly compare the old and new anyway -- since the new will have records with more than 99 primary keys and the old is limited to 99 primary keys.

Really appreciate the help Robert

btw how do you know what the recordsiZe of the alternate index is?
where do we check? can't seem to find it using listcat?

archiegaw wrote:btw how do you know what the recordsiZe of the alternate index is?
where do we check? can't seem to find it using listcat?

Hi Please ignore my previous post
btw any way to copy the VSAM file together with the alternate index and reproduce it in test?
I guess i've been able to build an alternate index , but i'm unable to reproduce the error being encountered by the user.
i'm told that i'm unable to recreate the error is because i'm unable to recreate the live alternate indexes.

I usually back up the VSAM file by using DF/DSS and restoring to a new name. As long as the base cluster and alternate index have the same high level qualifiers, this can be a single DUMP and a single RESTORE command in ADRDSSU (DF/DSS).

thanks Robert
I was able to recreate the error encountered by the users in test region, and was also able to resolve the rrro encountered by user by extending the record size for the affected alternate index.

I tried using job below GVEXPORT to Copy the VSAm file to tape.
and tried to restaore the tape to vsam file by using GVRESTOR,
But not sure how to code using GVRESTOR,
encountered the problem below since i'm trying to restaore 3 alternate indexes,

GV017 - ERROR IN AMS INPUT
DATA (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.AIX1.DATA))-
INDEX (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.AIX1.INDEX))-
PATH (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.PATH1))
AIX (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.AIX2))-
DATA (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.AIX2.DATA))-
INDEX (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.AIX2.INDEX))-
PATH (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.PATH2))
AIX (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.AIX3))-
DATA (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.AIX3.DATA))-
INDEX (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.AIX3.INDEX))-
PATH (NAME (GDUBAGA.PADTPR.KSCI1DU.PF0061X.PATH3))
BrightStor CA-FAVER - END OF JOB - HIGHEST CONDITION CODE WAS 16

Would you know how to code this?
For using ADDRSSU would it be possible to restore the 3 alternate indexes?
how would the code look like?

thanks

I don't use CA-FAVER so I have no idea about the commands, syntax, or error messages. If your backup was taken using CA-FAVER, I don't think ADRDSSU can be used to restore it since ADRDSSU uses its own formats for backups. If you have a backup taken with ADRDSSU and can post the actual backup command used, I can make suggestions about the RESTORE command.

Hi Robert

Here's the job i using ADRDSSU, The backup was successful, i think? how do i restore the VSAM including all the ralternate indexes using addrsu?

//BACKUP2 EXEC PGM=ADRDSSU,
// COND=(0,GT)
//SYSOUT DD SYSOUT=X
//SYSPRINT DD SYSOUT=Y
//SYSUDUMP DD SYSOUT=Q
//TAPEOUT DD DSN=GDUBAGA.PADTPR.KSCI1DU.PF00610.TAPX,
// DISP=(,CATLG),UNIT=SYSDA,SPACE=(CYL,(200,10),RLSE)
//SYSIN DD *
DUMP SPHERE -
ODD(TAPEOUT) -
DATASET(INCLUDE( -
PADTPR.KSCI1DU.PF00610 -
)) SHR TOL(ENQF)

btw i just found another issue that worries me.

I found that in the program there's this code below

PC-BCF-REC-LEN is 1200, should code be changed? length of the copybook for PRR018 is also only 1200

MOVE LOW-VALUE TO F006-INDEX2
EXEC CICS READ DATASET (WF-SPEC-BCF-IND-2)
INTO (PRR018)
LENGTH (PC-BCF-REC-LEN)
RIDFLD (F006-INDEX2)
KEYLENGTH (PC-BCF-KEY-IND2)
GTEQ
END-EXEC
MOVE SPACES TO PRR018.

I was able to test my VSAM file with the longer alternate index and the abend was not encountered anymore. i just don't know what the impact of the code above will have?

thanks Robert reallly sorry for the lots of questions. .

btw i tried to restore using this job

//GDUBAGAR JOB UNPMFFXXXX,'JOB 111',CLASS=A,MSGLEVEL=(1,1),
// MSGCLASS=X,NOTIFY=&SYSUID,REGION=4048K
//RESTOR#1 EXEC PGM=ADRDSSU,REGION=5120K
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//*ASD1 DD UNIT=SYSDA,DISP=SHR
//* VOL=SER=(HTSTZB)
//TAPEIN DD DISP=SHR,DSN=GDUBAGA.PADTPR.KSCI1DU.PF00610.TAPX
//SYSIN DD *
RESTORE INDDNAME(TAPEIN) -
DATASET(INCLUDE(PADTPR.KSCI1DU.PF00610)) -
RENUNC(PADTPR.KSCI1DU.PF00610 -
GDUBAGA.PADTPR.KSCI1DU.PF0061X)

but only the base was restored to GDUBAGA.PADTPR.KSCI1DU.PF0061X, the alternate indexes were not restored.

The restore should be something likeIf the file requires additional packs, you can include //DISK02 .... and put them in the OUTDD parameter.

Merely changing the length of an alternate index should require absolutely no program changes. The record size for an alternate index tells how many duplicates you allow -- and has nothing to do with the base cluster definition. No base cluster definition changes, no code changes.