# "STARTING WITH ISN" Clause isn't working **URL:** \ **Category:** Forum\ **Tags:** Adabas-Natural, Natural, mainframe\ **Created:** [December 14, 2022, 1:00pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334 "2022-12-14T13:00:51Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![Priscilla\_G\_Souza](https://avatars.discourse-cdn.com/v4/letter/p/c4cdca/32.png) [@Priscilla\_G\_Souza](https://techcommunity.softwareag.com/u/Priscilla_G_Souza)\ **Post date:** [December 14, 2022, 1:00pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/1 "2022-12-14T13:00:51Z")
#### Hi guys! I have 2 READ loops: the first READ loop reads 10 records in DESCENDING order and stores the ISN of the 10th record; the second READ should start reading the records from this ISN (this one has a STARTING WITH ISN clause). But this clause seems not to be working in the READ 2. I printed #ISN-START value after READ 1 and the ISNs of the records read in the READ 2, but the same 10 records read in READ 1 are being read in the READ 2 and I don’t understand why. Could someone give me a little hand with this? Thanks in advance. ```auto READ-1. READ MULTI-FETCH OF 300 FILE DESCENDING BY SUPER FROM #SUPER-INI TO #SUPER-FIM * ADD 1 TO #COUNT * IF #COUNT = 10 #ISN-START := *ISN ESCAPE BOTTOM END-IF END-READ * READ-2. READ MULTI-FETCH OF 300 FILE DESCENDING BY SUPER FROM #SUPER-INI TO #SUPER-FIM STARTING WITH ISN = #ISN-START ..... END-READ ``` ---
**Author:** ![markus.toepfer](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@markus.toepfer](https://techcommunity.softwareag.com/u/markus.toepfer)\ **Post date:** [December 14, 2022, 2:02pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/2 "2022-12-14T14:02:14Z")
Hi, I think is not posible to read by Superdiscriptor AND starting in this area by ISN. Kind regards, MTÖ ---
**Author:** ![Eugene.Miklovich](https://avatars.discourse-cdn.com/v4/letter/e/ce73a5/32.png) [@Eugene.Miklovich](https://techcommunity.softwareag.com/u/Eugene.Miklovich)\ **Post date:** [December 14, 2022, 2:12pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/3 "2022-12-14T14:12:22Z")
You are not reset COUNT so ISN-START will be the same after first set when count gets to 10… ---
**Author:** ![Eugene.Miklovich](https://avatars.discourse-cdn.com/v4/letter/e/ce73a5/32.png) [@Eugene.Miklovich](https://techcommunity.softwareag.com/u/Eugene.Miklovich)\ **Post date:** [December 14, 2022, 2:40pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/4 "2022-12-14T14:40:21Z")
Also. If you want to really continue from the record 10 then recognize you should store Starting value as well. When doing a read logical the STARTING with ISN is within the starting Value. This is designed for restarting when a DE (or SUPER) has multiple ISNs with same value. For Example: READ EMPLOYEES by NAME = ‘SMITH’ Starting with ISN #LASTISNPLUS1. Hope this helps ---
**Author:** ![Eugene.Miklovich](https://avatars.discourse-cdn.com/v4/letter/e/ce73a5/32.png) [@Eugene.Miklovich](https://techcommunity.softwareag.com/u/Eugene.Miklovich)\ **Post date:** [December 14, 2022, 2:43pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/5 "2022-12-14T14:43:34Z")
BTW I don’t normally recommend doing Multifetch More than 25. More than that gives marginal results and in your case actually hurts performance as you are asking ADABAS to read and return 300 records but only processing first 10… ---
**Author:** ![Craig\_Soehnlin1](https://avatars.discourse-cdn.com/v4/letter/c/e19b73/32.png) [@Craig\_Soehnlin1](https://techcommunity.softwareag.com/u/Craig_Soehnlin1)\ **Post date:** [December 14, 2022, 2:54pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/6 "2022-12-14T14:54:32Z")
This is from the ADABAS command reference manual. It is saying the same thing Gene said. **Rules for Reading Backward (Descending Option)** If the starting descriptor value specified in the value buffer _is_ present in the logical read sequence, specifying: ■ an ISN of zero results in positioning to the _last_ (_highest_) ISN with that descriptor value; ■ a non-zero ISN results in positioning to the _highest_ ISN _less than_ the specified ISN with that descriptor value, if such an ISN exists. Otherwise, positioning is to the _last_ ISN of the _next_ _lower_ descriptor value. If the starting descriptor value specified in the value buffer is _not_ present in the logical read sequence, positioning is always to the _last_ ISN of the _next lower_ descriptor value, regardless of the specified ISN. ---
**Author:** ![Jerome\_LeBlanc](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/jerome_leblanc/32/111_2.png) [@Jerome\_LeBlanc](https://techcommunity.softwareag.com/u/Jerome_LeBlanc)\ **Post date:** [December 14, 2022, 2:54pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/7 "2022-12-14T14:54:51Z")
Eugene is correct. To use STARTING WITH ISN you must also specify the descriptor. Your program would look like this: ```auto READ-1. READ MULTI-FETCH OF 10 FILE DESCENDING BY SUPER FROM #SUPER-INI TO #SUPER-FIM * ADD 1 TO #COUNT * IF #COUNT = 10 #ISN-START := *ISN #SUPER-FIM-2 = SUPER ESCAPE BOTTOM END-IF END-READ * READ-2. READ MULTI-FETCH OF 300 FILE DESCENDING BY SUPER FROM #SUPER-INI TO #SUPER-FIM-2 STARTING WITH ISN = #ISN-START ..... END-READ ``` Also be aware that STARTING WITH ISN actually does not start with the ISN specified but with the next record. For example, if I had the following data: ```auto RECORD SUPER ISN R1 ABC 10 R2 ABD 15 R3 ABD 25 R4 ABD 30 R5 ABE 12 ``` and I did: ```auto READ FILE BY SUPER FROM 'ABD' STARTING WITH ISN 25 ``` The first record read would be R4. If I was reading in descending order: ```auto READ FILE DESCENDING BY SUPER FROM 'ABD' STARTING WITH ISN 25 ``` The first record read would be R2. ---
**Author:** ![Eugene.Miklovich](https://avatars.discourse-cdn.com/v4/letter/e/ce73a5/32.png) [@Eugene.Miklovich](https://techcommunity.softwareag.com/u/Eugene.Miklovich)\ **Post date:** [December 14, 2022, 3:42pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/8 "2022-12-14T15:42:47Z")
I might recommend the changes highlighted below ---
**Author:** ![Douglas\_Kelly](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/douglas_kelly/32/102_2.png) [@Douglas\_Kelly](https://techcommunity.softwareag.com/u/Douglas_Kelly)\ **Post date:** [December 14, 2022, 5:28pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/9 "2022-12-14T17:28:57Z")
Why wouldn’t your second READ start from #SUPER-FIM-2? that’s the ending value from the first READ, right? ---
**Author:** ![Eugene.Miklovich](https://avatars.discourse-cdn.com/v4/letter/e/ce73a5/32.png) [@Eugene.Miklovich](https://techcommunity.softwareag.com/u/Eugene.Miklovich)\ **Post date:** [December 14, 2022, 6:01pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/10 "2022-12-14T18:01:42Z")
Because there is an escape bottom out of the loop I am assuming that 1st read doesn’t get to FIM2…. ---
**Author:** ![Priscilla\_G\_Souza](https://avatars.discourse-cdn.com/v4/letter/p/c4cdca/32.png) [@Priscilla\_G\_Souza](https://techcommunity.softwareag.com/u/Priscilla_G_Souza)\ **Post date:** [December 14, 2022, 6:11pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/11 "2022-12-14T18:11:28Z")
The amount of 10 is just an axample… in the real case I read more than 600 records. ---
**Author:** ![Eugene.Miklovich](https://avatars.discourse-cdn.com/v4/letter/e/ce73a5/32.png) [@Eugene.Miklovich](https://techcommunity.softwareag.com/u/Eugene.Miklovich)\ **Post date:** [December 14, 2022, 6:47pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/12 "2022-12-14T18:47:08Z")
This is deviating from initial problem, so I have changed the Subject. So let’s take your example of 600 records read. If you don’t use Multifetch you would have 600 ADABAS calls. If you choose a Multifetch of 10 you would have 60 adabas calls, a 90% improvement. If we go to MF of 25 then we will have 24 Calls a 96% improvement (but only 6% better than 10). If we go to MF of 50 then we will have 12 calls, a 98% improvement (but on 2% better than 25). So you can see this is the law of diminishing returns. I find going beyond 25 doesn’t give me much but requires larger buffers and may degrade performance if we end up reading more records than we need. Just my own guideline…. ---
**Author:** ![Jerome\_LeBlanc](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/jerome_leblanc/32/111_2.png) [@Jerome\_LeBlanc](https://techcommunity.softwareag.com/u/Jerome_LeBlanc)\ **Post date:** [December 14, 2022, 8:00pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/13 "2022-12-14T20:00:04Z")
Because it is reading DESCENDING. The FROM key value still needs to precede the TO key value so we read TO #SUPER-FIM-2, but we are really starting from there and reading backwards. ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [June 12, 2023, 8:01pm UTC](https://techcommunity.softwareag.com/t/starting-with-isn-clause-isnt-working/267334/14 "2023-06-12T20:01:00Z")
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.