We're seeing something that is confusing us, and were hoping someone could
help.
A couple of jobs that define a VSAM file and build an alternate index have
failed in the BIX, generating an IEC070I 209-220 message. In the IDCAMS
output, we see:
IDC3351I VSAM I/O Return Code is 28 - RPLFDBWD = X'2908001C'
IDC2658I Sort Product Failed
All these messages basically say that VSAM could not extend the file - end
of volume, extent limit, etc. But the DATACLAS used for our VSAM files, by
default, contains the dynamic vol count parameter (up to 8 volumes). We
have many DATA components in the pool that spread over volumes, but is there
a problem with alternate index DATA components being able to jump volume
boundaries?
I've searched IBM Link for a fix and not found any. Since we are on z/OS
1.3, I would have hoped that if this were a bug it would have already been
found. But that leaves us no closer to understanding the root cause of this
failure. The pool has available space, so it isn't just an issue of
actually not having the space. One failure seemed to result from hitting
123 extents, and the other seemed to be end of volume - both conditions that
the dynamic volume count should have handled...I thought.
Thanks for any insight.
Greg Shirey
Ben E. Keith Company
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
You need to define your alternate index with candidate volumes. We've run the same errors, etc...past IBM until we noticed that it was the AIX that generated the failure (usually during a mass insert to the base cluster). The error codes show up in the REPRO, but the real codes are in the job logs. These codes have the name of the AIX component, not the base cluster.
What made it even more confusing is that our backup and restore process did not have a separate del/def step for either the base or the aix. That was done dynamically by the restore software (FAVER). The define would use the same values the file had when it was backed up.
Once we got the AIX defined with multi-volume capability, the problem went away.
IBM-Mainiacs,
Thanks for any insight.
****************************************************************************************************
This e-mail and any files transmitted with it are confidential to abc distributing, llc.
("abc"), and may contain proprietary or copyrighted materials belonging to abc, which
are intended solely for the individual named. If you are not the named addressee, you
are notified that any copying, dissemination, distribution or disclosure of any or all of its
contents, and any action taken in reliance on the transmission, are unauthorized and
prohibited. Please notify abc immediately by e-mail reply if you have received this
transmission in error and take all necessary and appropriate actions to permanently
delete it from your system.
*****************************************************************************************************
Greg Shirey
Ben E Keith Company
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Behalf Of Matthew Stitt
BTDTGTTS. <g>
You need to define your alternate index with candidate volumes. We've run
the same errors, etc...past IBM until we noticed that it was the AIX that
generated the failure (usually during a mass insert to the base cluster).
The error codes show up in the REPRO, but the real codes are in the job
logs. These codes have the name of the AIX component, not the base cluster.
What made it even more confusing is that our backup and restore process did
not have a separate del/def step for either the base or the aix. That was
done dynamically by the restore software (FAVER). The define would use the
same values the file had when it was backed up.
Once we got the AIX defined with multi-volume capability, the problem went
away.
----------------------------------------------------------------------
I believe the 123-extent limit is "absolute", no matter how much space is
available.
-jc-
One thing we noticed is that a listcat doesn't show the SMSDATA and RLSDATA sections for an AIX. IBM told us that this information is not stored for an AIX.
I'd say it sounds like it PMR time because it appears the dynamic volume count is not being honored.
-----Original Message-----
From: Greg Shirey [mailto:WGSh...@ibm-main.lst
BTDTGTTS. <g>
****************************************************************************************************
This e-mail and any files transmitted with it are confidential to abc distributing, llc.
("abc"), and may contain proprietary or copyrighted materials belonging to abc, which
are intended solely for the individual named. If you are not the named addressee, you
are notified that any copying, dissemination, distribution or disclosure of any or all of its
contents, and any action taken in reliance on the transmission, are unauthorized and
prohibited. Please notify abc immediately by e-mail reply if you have received this
transmission in error and take all necessary and appropriate actions to permanently
delete it from your system.
*****************************************************************************************************
----------------------------------------------------------------------
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2s210/7.3.3?DT
=20020116164710
Greg
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Behalf Of Chase, John
Sent: Thursday, May 13, 2004 1:13 PM
I believe the 123-extent limit is "absolute", no matter how much space is
available.
-jc-
----------------------------------------------------------------------
* VSAM data sets, up to 255 extents per component but only up to 123
extents per volume per component.
* Striped VSAM data sets, up to 4080 extents per data component.
Terry Traylor
charlesSCHWAB
DE&I Mainframe Storage Management
dei-mf-storage
(602) 977-5154
WARNING: All email sent to or from this address will be received by the
Charles Schwab corporate e-mail system and is subject to archival and review
by someone other than the recipient.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Of Chase, John
Sent: Thursday, May 13, 2004 11:13 AM
To: IBM-...@BAMA.UA.EDU
Subject: Re: VSAM I/O Return Code 28
> -----Original Message-----
> From: Greg Shirey
>
I believe the 123-extent limit is "absolute", no matter how much space is