Re: Max Size of ISPF table?
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 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 > 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 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
Re: Max Size of ISPF table?
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 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 > 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 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
Re: Max Size of ISPF table?
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 > 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 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
Re: Max Size of ISPF table?
Performance will kill you long before you hit the size limit. Have you considered using, e.g., DB2, to store the data? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Billy Ashton Sent: Tuesday, December 17, 2019 9:18 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
Re: Max Size of ISPF table?
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 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
Re: Max Size of ISPF table?
Billy, you can access DB2 table (or VSAM with a small trick) directly from your REXX ISPF programs. IMHO the table size you've described is better in a "DB-like" object. Regards. Max Il giorno mar 17 dic 2019 alle ore 15:19 Billy Ashton < bill00ash...@gmail.com> ha scritto: > 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
Re: Max Size of ISPF table?
RXVSAM from Rexx is a possible replacement that may provide much better performance than an ISPF table for that volume of records. File 268 on the CBT Tape website. HTH Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Billy Ashton Sent: Tuesday, December 17, 2019 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Max Size of ISPF table? EXTERNAL EMAIL 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. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Max Size of ISPF table?
With a table of that size, do NOT make it a keyed table. That would just makes it extremely slow and almost unusable. Dan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Max Size of ISPF table?
ISPF Tables are great but not ideal for the volume that you are planning. If you decide to use ISPF Tables then be sure to create them in anything other than REXX which is extremely slow due to an inefficient design in this area. Table serves will work but your performance may not be what you really want to have. VSAM would definitely be a better option for you if that is something that will work for you. Lionel B. Dyck < Website: http://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Billy Ashton Sent: Tuesday, December 17, 2019 8: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
Re: Max Size of ISPF table?
Hi Billy, Permanent ISPF tables reside in a PDS data set which will have to be sized appropriately. If the ISPF table is keyed then you have big problems. ISPF tables are basically just linked lists and not dictionaries, so if they are keyed I would advise you to use VSAM. On 2019-12-17 10:18 PM, Billy Ashton wrote: 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
