Maybe you know the following sort of problem: A value of a very important field of an ADABAS-file was changed. But nobody knows who did it. The users are saying: “One of your many many programs did this change automatically. A human being would never type in such nonses.” Of course the IT have to check this. In most cases, it turned out to be one of the following reasons:
Typo of the user
Typo of the user
Typo of the user
Error in program
We think, it’s one of the reasons 1 - 3 ;). But we got no chance to proof it. We checked old backups of the Database, we used predict to find out all NATURAL-programs changing that field - without any success. To get rid of that problem in future, we have to log all changes on the field independent from all programs.
My idea was to read out the PLOG with ADAPLP and write all changes on that particular field into a separate logfile. But before I begin to write the regarding scripts/programs: Are there any better ways? How would you solve my problem?
on open-systems it seems to be a cheap and quick (?) solution, to use adaplp for analysing protection logs.
On IBM-Host we used the adasel-utility, to analyse the protection-log. But on Open-systems adasel is not available, nobody know’s why.
If you use adaplp, you must know, that software ag can (and will) change the output of adaplp without any notice. Actually we have a lot of problems, errors, coredumps and undocumented changes with adaplp on Adabas 5.1.3.02 (HP-UX IA64) with the ugly result that our program, that’s analyse the adaplp-output, will produce rubbish.
My suggestion is to use a replication tool instead of adaplp.
btw: how do you get the userid of the person, who changed the data? Is there a field in the fdt?
Why do you wrote the adaplp-analyser in visual-basic?
Unfortunaely it happened that the ADA51 ADAPLP had errors and different output than in v3.3, but this was not intended. We know that several customers are analyzing the ADAPLP output, and that changes in the ADAPLP output have big impact for them. We are currently preparing v5.1.4.01, and we hope that in this version all errors in this area are fixed, and the output is the same again as in v3.3.
What i would like to say is, that it is always a critical approach to analyse a (more or less flexible) “report” to collect data, instead using a well-defined data-structure. On IBM-Host we used adasel. why is adasel not available on Open-systems?
I (and maybe some of the users out there, who are using adaplp in this way) have a wish: let adaplp optionally create xml ;-)). Then we never have to care about the layout. an we have the opportunity to process the xml directly with natural…
Unfortunately we have only limited resources in Adabas development that we are not able to implement everything that is useful - we must set priorities, and can only implement features requested by many customers. I recommend you that you submit enhancement requests for features important for you - if there are enough other custmers with the same requirements we can implement them in one of the next versions.
Thanks for the information about ADABAS 5. But at the moment we need a quick solution …
ADAPLP prints out the ADABAS-user-id. And during system login, the “real” username and the ADABAS-user-id is written into a log-file.
Normally I would have done this on Unix-Side using a perl-interpreter. But we already keep our ADAPLPs on a Windows-machine. So it was easier for me to stay on windows-side.
