Yes, you are absolutely correct. I was just trying, maybe feebly, to make the point that one always checks to see that what one started has finished.. When I push the button to open my garage door I always look to see that it opened before driving my car through it.
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Schuh, Richard Sent: Monday, November 03, 2008 11:47 AM To: [email protected] Subject: Re: Reliability of SFS? I hope one would never do a SIO on today's machines :-) I hope one would never do a SSCH (or SIO back in the days) without immediately checking for CC \= 0. If one is programming at that level, it is likely that they are also handling the I/O interrupts, obviating the need for following S*** with T***. I don't remember ever following SIO with TIO or SSCH with TSCH without some intervening condition that required it, and I have written channel programs that ran under several platforms (OS/MFT, OS/MVT, SVS, CMS (4 different releases), TPF (3 different releases) and a special purpose O/S that was IPLed in a virtual machine. It is possible that my memory is failing me, but that is how I remember it. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas > Sent: Monday, November 03, 2008 7:09 AM > To: [email protected] > Subject: Re: Reliability of SFS? > > After all one would never do a SIO without following it with a TIO... > > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] > Behalf Of Alan Altmark > Sent: Sunday, November 02, 2008 1:11 PM > To: [email protected] > Subject: Re: Reliability of SFS? > > > On Friday, 10/31/2008 at 07:12 EDT, Rob van der Heij > <[EMAIL PROTECTED]> > wrote: > > > When my ACCESS has completed with RC=0, I may assume the > mini disk to > > be accessed correctly and remain there until I release it. > > No, you may not make such an assumption. Well, you may, but > you violate Good Programming Practices if you do. A disk may > get a fatal error of some sort, such as a disconnect or > someone powers off the storage controller. If your program > keeps writing after it starts getting RC=36 on FSWRITE, your > program is wasting its time. > > > It is > > making life very complicated when I must write my application to > > expect the disk to be pulled underneath my fingers any moment. I > > understand that one could also take a real disk away, but > SFS servers > > tend to have more fingers in the pie. > > Whoever said writing Good Programs was supposed to be simple? > If you want to insulate yourself from I/O errors, you have > to implement things like HYPERSWAP, not just ignore errors. > Your application may be able to operate without the disk, but > if it cannot, then your application must prepare for the loss > of the data source. Just as a db client is prepared to lose > the db server and the db server is prepared to lose the database. > (db = SFS) > > > When my program code is on a remote file pool, I can't even > trust that > > the disk with my EXEC is still there to read the remainder of the > > program code (including the error handler for example). This is not > > something you can expect me to handle. (I know I can execload the > > stuff, but it is making things complicated). > > If the source of the data goes away (disk or SFS), CMS will > not automatically reaccess the disk or directory. If you're > writing REXX execs, you needn't worry about the disk or > directory going away - the entire exec is read into memory. > > I don't mind high standards, but I don't know why SFS is > being held to a higher standard than minidisks (from the > app's point of view). While it does bring its own issues to > the table, it takes others off the table that a Right And > Proper app has to deal with. > > Alan Altmark > z/VM Development > IBM Endicott >
