Generic browsing

, , ,
1

Hi,

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?

Thanks!

2

This is not a built-in feature on the mainframe. Software AG has SuperNatural, and a few other vendors have PEEK-like products.

You can build a scaled-down version of a file browser using the INCLUDE statement. Refer to the “Copycode with Parameters” section of the INCLUDE statement in the Statements Manual.

3

Thanks Ralph!
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.

Thanks again, Ralph! Will see how it works…

4

Hi Flakes Rice,

A small example I can share is:

INPUT 'FILE TO BE BROWSED:' (CD=YE) +BROWSE-FILE(A32) (CD=RE) //
  'DESCRIPTOR:' (CD=YE) +DESCRIPTOR(A32) (CD=RE)
RUN 'BROWSEF'
END

BROWSEF

READ(10) &BROWSE-FILE BY &DESCRIPTOR
    WHERE &DESCRIPTOR NE ' '
  DISPLAY &DESCRIPTOR
*
END

Hope this helps.

5

Hi Ats,

This is similar to what Ralph suggested. We just tried this with a small example. And realised that there are lot of things that need to go with it.

  1. We should know the accurate name of the file and descriptor before browsing
  2. We can display only the descriptor
  3. If we need to display all the fields, we need to prepare a view
  4. For each file, we need to account for all descriptors, all field names and store the view of all files

Due to these factors, it does not become a generic program… which was the main motive.

6

Hi Flakes Rice,

It is true for either case INCLUDE or the example.

I am curious to know how it will browse without a file name? It can read without a key (in physical
sequence) and you should pass fields to be displayed. Even PEEK works in similar manner

I assumed that you will further work with the example provided to achieve your motive and shared a direction.

7

We have a tool developed with similar approach:

                        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   >  
Start >                                         
Value >                                        
      >                                       
      >                                       
      >                                       
--------------------- Loop Processing - CRS/PF1 to Expand --------------------
Before:                                                                    
Within:                                                                    
After :                                                                    
------------ Heading -------------------- Field Name -------------------------
     1                      DATE-OF-BIRTH
     2
     3 
     4
     5
     6
     7
 F1   F2    F3   F5   F6   F7   F8     Command:______________________________
Help LISTF Exit Vert  Res  Up  Down    F4 H/copy   F10 Save  F11 Read  F12 Upd
8

Hi Ats,

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?

9

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.

10

Hi Ats,

Sorry, I am bit confused…

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!

11

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.

12

Hi Flakes Rice,

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.

13

Further to your previous points:

Do you think we can browse without a correct file-name or associated view name provided?

Not true! We can display any field on a file (once a file is accessed by READ/FIND)

Not True! Reporting mode can help, you need to have a correct DDM name though

Point 1, 2 & 3 answers this.

14

Hi Ats,

I understand what you are saying.

Let`s ignore $$$ or effort spent or technical complexity for now. If anybody has done this earlier, we can surely give it a try. I just want to know the technical feasibility for this.

So that if it is clearly not possible, we can suggest the higher mgmt to go for a supported tool.

15

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!)

16

You might want to take a look at DFA here:

http://www.mlsoftware.org/

If you don’t need update access there is DFA Lite which is free. The only other restriction is that you can’t manually configure your display screens.

17

You could also take a look at SCC’s Natural Toolkit:
http://scctoolkit.atspace.com/
which contains a Browse program generator + much more …
and it is FREE :smiley:

18

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?

19

Before I try anything on this thread, can anyone please tell me how safe it is to do without messing up my database? Or do I have to make a backup on different POS systems?

20

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.

steve