depending on the shop and from a developer perspective only there is really no difference between Natural DB2 and Natural Adabas - ok so you do a SELECT instead of a FIND/READ/HISTOGRAM but that’s really minor. You check it the same way and stow it the same way. and it will execute fine without any additional steps.
The comes the bind part: that can vary shop to shop as to whether developers even get to do that. Here where I work it is very rare that a module gets bound for any kind of testing so the code runs dynamic in all environemnts except pre-production and production itself and binding is a part of the automated migration system.
In certain circumstances a developer may get access to an option that allows for a module to be bound in a testing environment but that is rare.
True - but I’m casting thru the parts of my memory going back 10+ years now - my understanding was that there were performance considerations in using FIND/READ rather than SELECT or was it that you had less control over what access path was chosen; not that you have that much control with DB2 anyway.
Also, at least until recently, neither the UNION nor the JOIN concept was available with FIND/READ though I believe that now is different but I’ve not done Adabas for quite a few years.