Because the I/Os and I/O delays are such that loading it into a large table with key lookup in storage and the move to the buffer are done at the speed of light while the actual I/Os are done at the speed of sound. So we can get a 12hr long job (elapsed time) done in about 12% of the time. (Ok, so it is a bit slower than light).
Now, if this is demand by mobile devices, we can get the info in less time than it takes to schedule the SSCHs for index and data reads. Thereby improving service using less CPU. Again, what the need is is incredibly similar to the exchange (C/O for a telco) billing process PacBell ran into circa 1992. They were able to load their billing table into a data space and cut their time to process their records from, IIRC, from ~ 30 days to about 12 hrs. You don’t want to know what the DB2 times were. So, yes they were using KSDS before going to data space and using Access Registers w/ ALC programs to get to their table entries. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Oct 18, 2018, at 4:33 PM, Frank Swarbrick <frank.swarbr...@outlook.com> > wrote: > > Why do you want to load a KSDS in to storage instead of just doing random > access on the file? Or am I misunderstanding? > ________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Steve Thompson <ste...@copper.net> > Sent: Thursday, October 18, 2018 1:01 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL 64bit > > We have run into a situation, quite recently, where we would love > to have COBOL 6.2 to be doing 64bit storage because we need to > load a large table (actually, we want to load a data set into > storage). > > Assume that this data set is a VSAM KSDS. And assume that we do > random access of the records, and that those records contain > pricing and rules for same. > > [Shades of PacBell circa 1992 when they had to load into a data > space and use access registers to get the CO-CO billing table in > memory] > > The only way there is to write ALC code to effect a local/same > address space, data base using ATB storage and have the COBOL > code get to it by calling the ALC code that handles it all. > > Then it was pointed out that this also needed to be done in the > CICS address spaces. > > IBM missed the boat with ESA and COBOL back then, and now, I > think they are missing the boat with COBOL NOT being able to > provide large storage spaces. > > This is yet another example of some processing style/type that we > have been doing with our mainframes and just like Client Server, > and Parallel Sysplex (Ok, Geographically Diverse Sysplex), some > marketing person came up with the name of what we (customers) > have been doing. > > Is it possible to get them to catch up with their customers this > time? > > Regards, > Steve Thompson > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
