Re: Re: quit files

"Gerhard Postpischil [email protected] [hercules-390]" <[email protected]>
Newsgroups gmane.comp.emulators.hercules390.general
Message-ID <[email protected]>
On 6/22/2019 8:32 PM, kerravon86-/[email protected] [hercules-390] wrote:
> Can you elaborate on this? What sort of
> I/O stays pending forever that causes
> data loss if "quit" immediately terminates
> that thread?

I don't know how QUIT is implemented, but if it removes a thread while 
MVS I/O is not complete, interesting things can happen. For DASD that 
applies to sophisticated CCW chains as used by catalog and VTOC updates. 
Under OS/360 the chain did a search for a matching key, read the CCHHR 
data, then used a subsequent CCW to write updated data. IBM made a 
horrible mistake designing the new (3880, etc.) controllers for the 
3375/3380/3390 that break the chain when a second index point occurs, 
thus invalidating the process due to the hit or miss results. Under MVS 
they redesigned things to get around the funky hardware, but that 
requires restarting a CCW chain. I never looked at the current CCW trace 
for a VTOC update, so I don't know whether they use PCI or another I/O.

On real iron a disk can drop ready, and leave the I/O pending or 
partially done. Under VM/CMS, data sets will always be valid, but not 
necessarily up-to-date; the I/O handler finds an unused block, copies 
the new data into it along with a forward chain pointer, then rewrites 
the previous block with a pointer to the new block, then adds the 
bypassed block to the free queue. If this I/O is interrupted, it will 
leave the data set readable, but missing the last update.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
https://www.avg.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.