I am curious as to the plans for Natural to be fully functional in its communication to Adabas. For example, it would be nice to have a DELETE FILE action for any file that has pgmrefresh activated. This way programmes can stop writng programs with husge READ / DELETE loops. There are other possibilities as well, like STORE CHECKPOINT, READ / GET RECORD WITH HOLD so that programmers do not have to put fake UPDATES into the programs just so that this module has the right to put a record on hold, coupled with RELEASE RECORD ().
The point is obvious. Natural is the premier interface to your industrial strength database, and yet one can domore with direct calls than in Natural. This no longer makes any sense in 2005.[/b]
You would have a ‘DELETE FILE’ to do a refresh? I can support your proposal if you don’t mind calling it ‘REFRESH FILE’ instead. The ‘delete’ can make one assume the the file is physical deleted.
Mogens,
yes, you are absolutely correct. REFRESH FILE makes a whole lot more sense. I think I’ll sit down tonight and make a list of all the ones I would recommend, including this one.
Jim,
I understand that you would like the vendor to do this. But, you could easily write a NATURAL subprogram that accepts a DBID and FILE NUMBER and issues an E1 command using the ADABAS Direct Call facility.
The syntax could be CALLNAT ‘REFRSHFI’ #DBID#FNR.
If you don’t want to do it yourself and if Software AG won’t do it for you I’ll work up a price for you and I’ll do it. I’ll give you a really big discount off of the MSRP. I’ll only charge 15% of the MSRP per year for Maintenance, Support, and the development of new versions.
Wolfgang,
I can’t speak for everyone but I am not suggesting that these new commands be unrestricted. They need to be protected by something. NATURAL Security if installed; by password (or something else) if NSC is not installed. As far as the REFRESH FILE concept, Jim did mention that the file needs to be eligible for PGMREFRESH (set by DBA).
The point is obvious. Natural is the premier interface to your industrial strength database, and yet one can domore with direct calls than in Natural. This no longer makes any sense in 2005
Hi Jim;
Maybe we can discuss this at the Delaware Valley User Conference.
I know the analogy is not perfect, but would you want to give all Cobol/Fortran programmers a way to intersperse assembler code in their compiler level programs?
Going back in history, before Natural, there was Adamint. The beauty of Adamint was that the programmer could utilize direct calls without understanding them. The person who created the access modules was responsible for doing “smart stuff” when calling Adabas.
The vast majority (98% ??) of Natural programmers are not familiar with direct calls. What is worse is that a similar percentage is basically unfamiliar with how Adabas works. Would you want these programmers, without classes in Adabas, writing direct calls to Adabas? What a nightmare.
I agree with Jim that NATURAL could and should offer better integration with ADABAS functionality. I think it should remain at the same high syntax level that existing data base statements enjoy. Any security needs should be addressed by either NSC or ADABAS. One of my pet peeves over the years was the inability to use READ without invoking a processing loop. READ WORK ONCE is an extremely useful statement. I think it’s just as useful for ADABAS… READ ONCE anyone?
There is also room for improvement in ADABAS for managing usage. Access to functionality, identifying and terminating runaway users, prioritizing and governing heavy resource usage— it would be nice to have robust, native methods to manage these.
I think Wayne makes a good point that you can have it now if you’re willing to invest some time/money in rolling your own. Even if SAG agreed today to add a capability, it’s at least a year before you’ll see it in the product. And then who knows how long until you can install the upgrade and migrate your shop. I’ve found it better to extend NATURAL with local, reusable routines that hopefully can one day be replaced with native syntax. Except for the performance cost, isolating the extension in a subprogram is a good practice in my opinion.
Terrific topic to discuss at Del Val SAGGroup meeting!
Steve - I may be mistaken but I think Jim’s point is that direct calls should be unnecessary if their equivelants were available with Natural syntax. With proper security controls, I think this is a great idea!
