We have begun to make use of the object browse subp in a few applications. Right now, we only use it for web to mainframe data access for the retrieval of multiple records. And maybe in the not so far future, I hope we will try to make use of it with the object browse dialogs.
I’m seeing something that I don’t really like about how these programs continue to read records from a previous call and the key being used is not unique. It is re-reading records. And this could possibly re-read a lot of records before it finds where it left off last time. My question to this is why doesn’t it make use of the STARTING WITH ISN = statement like the browse models do?? And is there a way around this?
Here is another scenario that I don’t understand:
Object browse is called with USE-UNIQUE-ID = TRUE. Then it is called a second time and USE-UNIQUE-ID = FALSE with intentions of continuing where it left off last time. But it doesn’t. It re-reads the last set of records and returns them. I see the code that causes this in the CHECK-FOR-RESTART subroutine and I all I have to do is RESET #COMPARE-DATA.USE-UNIQUE-ID(#CURRENT) in the INITIALIZATIONS user exit. So my question is, why does it assume a restart in this situation??
Natural 3.1.6 (soon to be 4.1.4)
Construct 4.5.2.8
Sorry for not responding sooner as you raise a valid point.
The STARTING WITH ISN clause was introduced with Natural 2.3 so it’s definitely time to implement this feature into Construct. On that note, an up coming service pack will add this feature automatically when generating against Adabas files. This will mean nothing has to be set to avoid redundant, duplicate reads of the data. Construct will automatically handle this (although all previously generate object browses will have to be regenerated to get the benefit of this).
Some further information:
All the variables found in the key PDA are used to start a fresh query. Because groups of rows are retrieved at anyone time the BROWSE OBJECT needs to remember state information based on the last call to the server; unless it’s starting a fresh query. If the USE-UNIQUE-ID flag is true and in the key PDA there is a value, say SMITH, in a key field, say BUSINESS-NAME, and 777 in the UNIQUE-ID then it is assumed that a fresh query is being started and the query should start at SMITH ISN number 777. From then on it is assumed (until otherwise told) that the query is continuing from where it last stopped (thus it resets the USE-UNIQUE-ID flag so it doesn’t start from ISN 777 again). One of the primary reasons for this feature is to allow the client code to scroll backwards by keeping track of the key values and ISNs from the top of a screen/page of data.
It’s good to know that the BROWSE OBJECTs will be using the STARTING WITH ISN = for adabas files soon. Of course, now it would be nice to know how soon and in what release and service pack this will be available. I want to know for my own sake as well as for my co-workers. Because there are some skeptics of the BROWSE OBJECT simply because of the re-reading possibility that they pose.
I understand why and how the USE-UNIQUE-ID is used in restarting a read and as you say “to allow the client code to scroll backwards”. That makes perfect sense.
Here’s the scenario that I don’t understand:
You set USE-UNIQUE-ID = TRUE and in the key PDA there is a value, say SMITH, in a key field, say BUSINESS-NAME, and 777 in the UNIQUE-ID. Then the first record returned will (or should) be SMITH with an isn 777. Perfect! The BROWSE-OBJECT resets USE-UNIQUE-ID before returning the record set. Still makes sense so far. Now I call the BROWSE-OBJECT a second time, without changing any values in the key pda. The BROWSE-OBJECT returns the exact same record set as the previous call because it ASSUMED a restart because #COMPARE-DATA.COMPARE-VALUES last input and current input are different. And they are differenct because, last input I wanted a restart with USE-UNIQUE-ID = TRUE and current input USE-UNIQUE-ID = FALSE because I wanted to continue where it left off. It looks like USE-UNIQUE-ID should NOT be part of the #COMPARE-DATA.COMPARE-DATA structure. Is that wrong or right? I take care of “the problem” simply by RESET #COMPARE-DATA.USE-UNIQUE-ID(#CURRENT) in the INITIALIZATIONS user exit and this way the current and last inputs are always equal by the time it gets to the CHECK-FOR-RESTART subroutine.
Right now, the fix is planned for Construct 511 patch level 1 (Construct 511 is included with Natural Business Services 511).
We are thinking about making the fix available for a future service pack of Construct 452 but right now this isn’t planned.
You make a good point about checking for a restart and we will make sure the comparison is done correctly when continuing a browse (and consider the value of USE-UNIQUE-ID).
I actually have an enhancement proposal with SAG right now to incorporate the STARTING WITH ISN = into BROWSE-OBJECTs. I made the enhancement request (of course stating we are Construct 4.5.2.8) shortly after my first posting for this subject and never had any replies.
I haven’t heard any news since it became an enhancement proposal.
It sure would be nice if it were to be included in a 4.5.2 service pack. After all, it is still going to be supported for another year or so I’ve been told.