Our Natural Adabas Installation does not have PEEK. So we have prepared programs to browse few Adabas files. But the total number of Adabas files is huge. Is there any way we can prepare a single generalized program to be able to browse all files by passing just the file and descriptor names to it?
As I understand we cannot use variables containing file name or descriptor name in READ/FIND/HISTOGRAM. Actual file name (literal) has to be used. Is there any way to circumvent this problem?
It will be a good idea. Hadn’t thought about this…
I guess certain coding will be required to account for different file names and superdescriptors, and also the corresponding move statements for displaying the fields… for every file. However it will be better than having an altogether different program for each file, especially when they are in hundreds.
F I L E S - V E R S I O N - 2 - 09/26/10
File Name > EMPLOYEE Read Limit > 15
Super/Descriptor > PHYSICAL Password >
--------------------- Loop Processing - CRS/PF1 to Expand --------------------
------------ Heading -------------------- Field Name -------------------------
F1 F2 F3 F5 F6 F7 F8 Command:______________________________
Help LISTF Exit Vert Res Up Down F4 H/copy F10 Save F11 Read F12 Upd
Yes, in a way your suggestion was helpful. I did not mean to browse without a file name. I was thinking of something that will first give a list of file names. Then based on the file selected, it will provide a list of all the descriptors for that file. After we choose that, it would accept descriptor values and other search criteria to display all the fields.
But seems this cannot be done by one generic program. And even if such program is written, there will be lot of file specific stuff (as mentioned earlier) which will have to be updated each time a new file is added to the database.
Does the tool that you mentioned here work for all the files? And what if a new file is added to the database?
Yes, it won’t be a day task (at least for me) to achieve what you are after. It should involve a lot of FDT reading, programs,maps creation and other stuff. If you have time to spare , believe me you will learn a lot. Else there are tools available in market as suggested by Ralph!
Yes, our tool takes care of all the files including newly added. The provision it made for it.
The main motive of this post is to explore whether some time can be saved by creating just a single (though complicated) generalized utility to browse Adabas files that is independent of the number of Adabas files in the database, as against creating hundreds of simple programs to browse each Adabas file…
And to confirm my understanding of your statements -
It is possible, at least in principle, to create a sort of utility that will be independent of the number of files, and independent of the changes made to sub/super/descriptors later on.
If my understanding is correct, I would appreciate if you can provide some pointers on the same!
A fair number of in-house file browsers exist, but if their developers had asked for management’s permission before creating them, they would be far fewer in number. It will take many hours to create something that is generic, useable, and efficient, even for an expert-level developer. Your resources would be better spent on a supported vendor product.
The utility is single (many programs are involved though). It will be a nightmare to restrict it in a single complex program :evil: (seems that’s what you are looking for!).
Can you please elaborate this
I have shared one of the basic concepts that can be used and it’s upto you and team to proceed.
As I said earlier it’s not a day (or few) task. I agree with Ralph that it will take many hours. Check with your management if they wish a team to work on this (time) or prefer to spend some $$$ on a vendor product.
Yes, it is possible. Our shop has it developed in-house. Being said that I feel vendors must have seen this possibility and implemented it to develop a product for us (such as one you mentioned earlier!)
When you develop a new application do you test it against your production database?
Of course not.
So yes, you develop and test a browser against a test database. Of course, if you are just browsing and there will be no updates/deletes/adds, there are no real problems to worry about except tying up a production database.
To add some commentary to the thread.
Writing a browser is not conceptually difficult. Perhaps the easiest way to do this is the two step approach with a driver program that employs global variables to acquire information as to what report the user wants to see and a report program, with “ampersand variables” that actually generates the reports. It is VITAL that the driver program not RUN the report program unless the report program is guaranteed to compile and run. Otherwise you will have an end-user looking at a compiler error; not a pleasant thought.
There are two basic “flavors” of driver programs. One is very generic, the other is more specific. For example, in my driver program, I could ask the user to type the name of a file. If I do this, I now have to check to ensure there is a file with the specified name. Alternatively, I could show the user a list of files and have them select a file from the list (enter a number, put the cursor on a file name, to suggest only two ways to do this).
The first way (generic) is useful for computer staff who need to find data on a file. If they get a compiler error, they do not panic and can re-enter their search. The second way is most useful for end-users since if you do a good job designing the interface, they can never (okay, almost never) foul things up.
As someone noted, this is a good learning project. You will learn a lot about DDMs.