I have an ISPF application that is built around a table of about 90,000 rows. Performance is acceptable, but the app is read-only except for the overnight batch process that builds it. The build process is a bit of a pig.
The Locate command was a problem. My first attempt was a brute force scan until the desired row was reached. When I changed it to use a binary search performance improved greatly. A “filter” command driven by TBSARG works very well and is my customary way of zooming to the rows that I am interested in. On Tue, Dec 17, 2019 at 13:27 Wayne Bickerdike <wayn...@gmail.com> wrote: > If you have CICS, use REXX/CICS. Do end users go through ISPF? There's an > overhead already. > > Under CICS you have a neat interface to DB2 or VSAM with the full set of > API calls. > > > > On Wed, Dec 18, 2019, 04:46 Al Ferguson <afergu...@neptunescove.org> > wrote: > > > For that many rows I would use a Database, or SQLite 3 (CBT Tape #965 and > > there is compile JCL on the CBT Tape the can be used against the current > > version of SQLite from the sqlite.org website). BPXWDYN makes a great > > interface to SQLITE via REXX (my preference for ISPF Apps), or there is > an > > include API for COBOL. > > > > _______________ > > > > Al Ferguson | mailto:afergu...@neptunescove.org > > Milwaukee, WI USA | http://www.neptunescove.org > > > > Dulcius ex Asperis > > > > > On 17 December 2019, at 09:40, Lizette Koehler < > stars...@mindspring.com> > > wrote: > > > > > > Everything depends on what your application needs to do. > > > > > > 1_ What type of performance is excepted from the application? As > > others have stated, the number of rows will make it very slow to use > > > > > > 2_ how many users will be in the table at one time? > > > > > > 3_ Is it going to be shared in multiple LPARs or one LPAR? > > > > > > 4_ What is the backup and recovery process you will be using for this > > application? > > > > > > 5_ What is the business impact if it is unavailable - for an hour, a > > day, a week? > > > > > > 6_ Do you have any Database products? (IMS, VSAM, DB2, DataCom, etc?) > > > > > > > > > You want to write an application that is more robust than what you will > > get in an ISPF Table with this amount of data. > > > > > > Once you determine the who, what, when, why and OMG answers, you should > > be able to determine how best to create the application. > > > > > > Lizette > > > > > > > > >> -----Original Message----- > > >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > > Behalf Of > > >> Billy Ashton > > >> Sent: Tuesday, December 17, 2019 7:19 AM > > >> To: IBM-MAIN@LISTSERV.UA.EDU > > >> Subject: Max Size of ISPF table? > > >> > > >> Hello, I am working with an application team, and they are creating an > > ISPF > > >> application. One of the options is to use an ISPF table for the data > in > > one > > >> component, but they will have between 50,000 and 80,000 rows in the > > table. > > >> > > >> What are your experiences with large ISPF tables, and is a table of > > 80,000 > > >> rows acceptable or practical? Another option is to write the ISPF > > application > > >> in COBOL and use VSAM or a database (although having only a single > > table in > > >> the database doesn't sound like the best course of action, > > >> either.) Data is loaded on a monthly basis (maybe 500-700 records) and > > >> otherwise this is a read-only ISPF application. > > >> > > >> Thanks for your thoughts. > > >> > > >> Billy. > > >> > > >> ---------------------------------------------------------------------- > > >> 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 > > > > ---------------------------------------------------------------------- > 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
