Re: TBDISPL, TBSORT, TBSCAN
Thanks for the help Alan, working the way I want it to now. --Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
TBDISPL, TBSORT, TBSCAN
If someone can tell me what I am doing wrong, I would appreciate it. ISPF seems to be my nemesis. I have RTFM'd for quite some time, and cannot understand why this is happening. I have a table that is created with 5 variables. When rows are added to the table, they get 1 extension variable. Logic is in the application to process SORT and FIND commands on 2 of the variables in the table. In my testing, after the table is first displayed, a SORT is done to sort one of the columns into descending order. The display after the sort shows the rows in proper order. A FIND command is then issued to find the row with a value that is equal to the 2nd variable in the 3rd row. It was the 2nd variable that the sort was based on. The find command causes a TBSCAN for the value specified, in the 2nd variable. The correct row is found. The CRP is 3. I next do a FIND for a value in the 1st variable that is displayed in the table at row 10. Another TBSCAN is done using that named variable. Instead of searching forward from the CRP to row 10, the TBSCAN returnd row 2. Row 2 does have the value in the variable, but I expected the TBSCAN to start with the CRP, and go forward. It is what the manual states. What is really crazy is that after the 2nd TBSCAN, the CRP is correct in that is has a value of 2, but ZTDTOP has 3. Does anyone know what I have to do to make the TBSCAN start at the CRP and go forward? --Dave Day -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TBDISPL, TBSORT, TBSCAN
Hi Dave, I believe that the problem may be related to TBDISPL rather than TBSCAN. After your first TBSCAN, I assume that you are issuing TBDISPL to facilitate entering of FIND in the primary command area. If this is indeed the case, TBDISPL will reset the CRP to 0 if now row is selected when you press enter to process the FIND command. If I have described your scenario, the solution is: 1) In the first TBSCAN, save the CRP in a variable using the POSITION keyword. 2) After enter is pressed to process FIND, invoke the TBSKIP service to reposition to that CRP before issuing the second TBSCAN. Hope that helps! Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dave Day Sent: Friday, April 30, 2010 11:42 To: IBM-MAIN@bama.ua.edu Subject: TBDISPL, TBSORT, TBSCAN If someone can tell me what I am doing wrong, I would appreciate it. ISPF seems to be my nemesis. I have RTFM'd for quite some time, and cannot understand why this is happening. I have a table that is created with 5 variables. When rows are added to the table, they get 1 extension variable. Logic is in the application to process SORT and FIND commands on 2 of the variables in the table. In my testing, after the table is first displayed, a SORT is done to sort one of the columns into descending order. The display after the sort shows the rows in proper order. A FIND command is then issued to find the row with a value that is equal to the 2nd variable in the 3rd row. It was the 2nd variable that the sort was based on. The find command causes a TBSCAN for the value specified, in the 2nd variable. The correct row is found. The CRP is 3. I next do a FIND for a value in the 1st variable that is displayed in the table at row 10. Another TBSCAN is done using that named variable. Instead of searching forward from the CRP to row 10, the TBSCAN returnd row 2. Row 2 does have the value in the variable, but I expected the TBSCAN to start with the CRP, and go forward. It is what the manual states. What is really crazy is that after the 2nd TBSCAN, the CRP is! correct in that is has a value of 2, but ZTDTOP has 3. Does anyone know what I have to do to make the TBSCAN start at the CRP and go forward? --Dave Day -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TBDISPL, TBSORT, TBSCAN
SNIP I believe that the problem may be related to TBDISPL rather than TBSCAN. After your first TBSCAN, I assume that you are issuing TBDISPL to facilitate entering of FIND in the primary command area. If this is indeed the case, TBDISPL will reset the CRP to 0 if now row is selected when you press enter to process the FIND command. If I have described your scenario, the solution is: 1) In the first TBSCAN, save the CRP in a variable using the POSITION keyword. 2) After enter is pressed to process FIND, invoke the TBSKIP service to reposition to that CRP before issuing the second TBSCAN. Hope that helps! Alan SNIP Trying it now. Thanks very much. I could not find that in the manuals anywhere. --Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
