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