Jeffrey, > > First was that the efficient access methods built into the product were > not > as effective when using VIO.
Seeing as most of these methods work on principles of 3390 physical disk layout, then this argument would also recommend against cached DASD and arrays that emulate 3390. I think that covers all the disk you can buy today. I would love to see Syncsort actually explain "why" a Data-in-Memory access is slower than a real IO to disk. "Efficient access methods built in blah blah blah" sounds like you got the pre-sales guy and not tech support. > > Second was that the decision to place the temporary dsn in VIO was based > only on the primary allocation and that if the sortwork used a number of > secondary allocations, it could cause a resource availability problem. Gee, this would apply to everything in VIO wouldn't it? Ask him to write on the blackboard 100 times - "I WILL USE &MAXSIZE FOR VIO IN MY ACS ROUTINES." If this SYNCSORT fellow uses &SIZE to test for VIO candidates then its his dog, and he can stay away from SMS ACS routines where I am working. > > I was not looking to spend a good deal of time on the phone with them and > hardly have to the knowledge to argue the points well, no simply nodded my > head (sort to speak). But now that I'm thinking about it, neither sounds > completely valid. Isn't VIO simply storage of another sort and the access > methods used to get there are the same as those that get to my disk? And > couldn't all temporary datasets use secondary allocations within VIO? > My point exactly. When VIO went straight to the Locals these recommendations were valid, but Expanded Storage turned VIO into a real DIM technique, and it us just as valid for SORTWK as it is for any other dataset. Has it really been a decade since we got ES? > In the end, I'm going to leave it excluded from VIO because 1) its what > the > vendor suggests, 2) its already excluded, and 3)its working fine. (be kind > in response to that, please ;-) > Fine by me. Small Datasets in VIO is a choice. It's done because it is a good practice. Choosing to exclude SORTWK is probably not slowing your batch run by any significant amount. However, if someone is building an initial SMS environment, then I would recommend not excluding SORTWK from VIO. Ron ---------------------------------------------------------------------- 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
