|
*INZSR is actually very useful for cycle programming. It's a useful function -- but it seems that, like me, a lot of programmers don't do much cycle code today. In todays world my problem is doing initialization and cleanup functions in a service program. (or, any NOMAIN module, I suppose) In about 25% of the service programs I write, each procedure starts out by calling an "initialize_me()" subprocedure. That's awkward to code, and I wish I didn't have to do it. What's worse... there's no procedure that gets called when the service program is ended, so I need to make sure that either things are cleaned up on a per-procedure call, or I need to have the program which uses my service program call a special "cleanup_me()" procedure. I think it would be INCREDIBLY useful to have procedure's that are automatically called when my service program is activated, and when it is deactivated. That would save me a lot of time coding around the problem. There are a lot of different resources that should be cleaned up. Open files are the most obvious thing, but aren't the only thing. Open stream files, memory allocations, sockets, data queues built on-the-fly, APIs like iconv() and GSKit which need to be initialized before use, and cleaned up before ending are all examples of places where this is useful. My suggestion for how this could be done would be to place an H-spec at the top of the program that specifies which procedure to call at activation, and which procedure to call at deactivation. Something like this: H NOMAIN ATSTART(my_startup_proc) ATEND(my_cleanup_proc) But, I'm not too picky about how it works... I'd just love to see something like this because *INZSR is completely useless when writing a service program or other NOMAIN module. and I spend perhaps 3/4 of my programming time writing service programs. I see a few other people have brought this up in the *INZSR thread as well, so I'm not alone in wanting this...
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.