My comment on the posting below is that the language providers (COBOL, PL1, C/C++, etc.), the LE providers and the VSAM providers need to get together so that the users don't have to go through these contortions. If it is legal to create a VSAM space and then use it, the languages and supporting routines should handle it. I have been railing against the inconsistencies of VSAM handling for years. There are things that can be done when creating VSAM data sets via JCL that can't be done through IDCAMS and vice versa. The LSR problems are of long standing. If someone wants me to enlarge on this rant, I will be more than happy to do so.
On 10 Aug 2005 16:04:59 -0700, [EMAIL PROTECTED] (Bill Klein) wrote: >The definition of "AVAILABLE" file for VSAM is a little odd (obscure? >strange?) > >Check out: > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg30/1.10.6 > >A VSAM file *must* be "available" to OPEN I-O. > >See also the information at: > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg30/1.10.3.2 >1 > >HOWEVER, (after finding all of that), I found what I think is MOST relevant >in the latest Enterprise COBOL V3R4 manual (with revision bars indicating it >is new). From: > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg30/1.10.3.2 >1 > >" When you are loading an extended-format VSAM data set, file status 30 will >occur on the OPEN if DFSMS system-managed buffering sets the buffering to >local shared resources (LSR). To successfully load the VSAM data set in this >case, specify ACCBIAS=USER in the DD AMP parameter for the VSAM data set to >bypass system-managed buffering." > > >"Greg Shirey" <[EMAIL PROTECTED]> wrote in message >news:<[EMAIL PROTECTED]>... >> Hello all, >> >> We modified our ACS routines so that our production VSAM files will be >> defined as extended format VSAM, after months of testing with "test" VSAM >> files and having no issues. >> >> Early this morning, a production program that is in a job that runs every >> day issued an OPEN I-O on a data set and got a status code of 30, which >led >> to a the program abend. A couple of steps earlier in the job, the VSAM >file >> is deleted and defined, but nothing is REPRO'd into it. The programmers >are >> saying that the job and the program have not changed, implying that they >> have been able to open for I-O an empty VSAM file, but are now unable to >> because of the change to extended format VSAM. (They got the job to run >by >> "seeding" the empty VSAM file before running the program that opens it.) >> >> We've been searching for some definitive information on whether this is >> expected behavior for extended format VSAM, but are not having much luck >> searching the bookshelves. I thought I might turn to the collected wisdom >> of the list for feedback. >> >> We were also surprised by the return code of 30 - Permanent I/O Error? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
