IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> wrote on 08/04/2005 08:13:03 PM:
> > 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. I would expect VIO to ESTOR (ESA/390) or real storage (z/Architecture) would be considerably faster than doing real I/O. But if you are going to use a given amount of ESTOR or real storage for sorting, it is probably more efficient (in terms of CPU cycles) to let the sort product access the storage directly through a Hiperspace (for ESTOR in ESA/390) or 64-bit virtual or data space (for real storage in z/Architecture), thus avoiding the CPU cycles to build a channel program, only to have EXCP expend more cycles to interpret the channel program. VIO to ESTOR or real storage remains a good I/O avoidance method for programs which are not designed to exploit real/expanded storage directly, and for passing data to a subsequent job step. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- 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
