Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
TK5 error message
|
Recently, when saving a member to a PDS I've been getting this message
SCOTT? ?,ISPFTSO ,294,DA,SYS00083,WRITE ,OVERFLOW INCOMP,0000000A000A02,BSAM returning to REVEDIT, displays "I/O error", and another save operation works fine.? The 294 DASD is a 3380 volume that I've created with dasdinit, and seems to work just fine otherwise. This is the only place I've seen an error in regards to this volume. Any ideas?? Yes, I'm backing up the entire dasd set 2 or thee times a day to not lose any work. Thanks in advance, Scott |
|
Scott Johnson wrote:
Recently, when saving a member to a PDS I've been gettingThat's an MVS message, yes? Does anything also appear on the Hercules console when this error message? If yes, then it's a bona fide I/O error. Second question: is it reproducible? Is there a sequence of actions that can trigger this error on demand? If yes, then I would suggest enabling CCW tracing on device 294, so we can the CCW chain that MVS is issuing. That would provide a clue as to what's going on. May we see your Hercules log when this error occurs? Seeing your config file might also help. Thanks. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
|
I¡¯ll get it together tomorrow, I¡¯m not at the system right now.? It¡¯s intermittent at best.? It happens only when I¡¯m saving changes to that volume, but not every time.? Saving the changes again works properly.? There is a message on the console, ?I¡¯ll capture that tomorrow as well. It¡¯s running on Debian, currently using yesterday¡¯s Aethra, previously the SDL version with the same intermittent messages.? I haven¡¯t noticed any data loss or corruption.? This volume contains some source code I¡¯m updating daily as well as a couple of vsam clusters that all appear to be intact.? I¡¯m still backing it up at the Linux level multiple times daily, just in case. ¡ª³§³¦´Ç³Ù³Ù On Mon, Jan 22, 2024 at 2:49 AM Fish Fish <david.b.trout@...> wrote: Scott Johnson wrote: |
|
I missed part of this.? Yes, it¡¯s MVS, the tk5, update 2 distribution. On Mon, Jan 22, 2024 at 2:49 AM Fish Fish <david.b.trout@...> wrote: Scott Johnson wrote: |
|
On 22/01/2024 1:20 pm, Scott Johnson wrote:
Recently, when saving a member to a PDS I've been getting this messageMight the error occur once, and then not again until you compress the PDS? I suspect a bad track in the allocated space of the PDS, and saving it again will commence writing to space after the location of the I/O error. After a compress, saving data will eventually hit that spot again. That message text comes from REVIEW's DCB SYNAD exit where SYNADAF ACSMETH=BSAM is coded, which is why it says BSAM and not BPAM. IBM's doc for OVERFLOW INCOMP is: Invalid track format, trying to write too much data on a track or the format of the data on the track was not valid for the type of operation being performed. I expect moving all the data sets on that volume to a new DASD volume would solve the problem, after which you could delete that volume image. If you did not want to do all that, you could copy the PDS to a new PDS to save the data, and rename the PDSes so you can continue normal processing with the relocated copy. You could abandon the old disk space by leaving the old (now renamed) data set there to prevent reuse of that space and so avoid future I/O errors, or you could try running somitcw's EOFDISK program to the old data set which deletes all the data from each track in the allocated space of the target DD, and hope that clears the error. I expect others can make even better suggestions. Cheers, Greg |
|
That was the problem, interesting thing though, once I mounted the volume on 38F, all the data was there, but ISPF wouldn't start with an error saying it couldn't access the libraries.? Take it back out of the equation and ISPF started at logon as usual, so I created a new 3380 volume, attached it to 38F, initialized it and ISPF stayed working.? In any event I was able to back up all the data (except the VSAM clusters which weren't important--only test data) and it's back in action.? Lesson learned.
I appreciate all the help and advice received here.? Thank you all. --scott |
Rob Prins
to navigate to use esc to dismiss