The GET is not required. You determine its need based on the data. To be updated, a record must be placed in the Hold Queue. As such, the record is locked and may not be updated concurrently by other users. In your first example, each record processed by the GET is placed on hold. In the second example, each record read is placed on hold. This is determined by the label reference on the UPDATE statement.
If 75-100% of the records on the file are to be updated, then I would consider an additional GET as unnecessary overhead. The few records which are not updated (but held anyway) are inconsequential compared to the cost of the GET commands.
If 50-75% of the records are updated, and they are spread evenly in the file, then I would still update the READ, but I would add *COUNTER to the ET limit, as in
IF #ET-COUNT > 100
or *COUNTER (RD.) > 1000
The reason for *COUNTER is to estimate the time between ETs. The DBAs set several Adabas timers. If sequential ETs are not executed within the allotted time, the program ABENDs. Often, developers are uninformed of these timer values. A rule of thumb is to guesstimate how many records you can process in 15 minutes (a reasonable and typical timer setting) at peak processing times. My example, above, is for 1,000 records. Then the ETs occur after 100 records, or within 15 minutes, whichever comes first.
If less than 50% of the records are to be updated, then use a GET. This limits how many records are unavailable for update by concurrent processes. Be sure to check the #ET-COUNT and *COUNTER fields for each loop iteration, not just for each update.
Also, remember to avoid ACCEPT and REJECT within update loops, as they don’t allow your IF #ET-COUNT statement to execute in a timely fashion.
The goal is to reduce unnecessary Adabas commands (GET and ET), while limiting negative impact on other processes and avoiding program ABENDs.