D
dbeavon
Guest
We have some legacy code in an ABL / CHUI environment , and I have one particularly widely used procedure which is : Is normally only one part of a larger encompasing transaction (may have an outer transaction scope in a calling procedure) the procedure has no output error parameters (ie. no way of normally signaling errors and notifying callers) the enclosing environment does not support Structured Error Handling the callers don't use "RUN xyz NO-ERROR" or check ON ERROR conditions (ie. fairly standard stuff for legacy ABL programming) And now, many years down the road, we discover some rare form of data corruption from the procedure and we decide it's better that the ABL client should die on occasion than to corrupt our data. Without revisiting the design of the code from square one, how can we go about that (rolling back and dying)? My initial thought was to pick between QUIT and STOP. Since QUIT actually commits data, that leaves me with STOP. But according to the docs, STOP seems to be trappable and may not always cause the ABL client to die. So now I'm thinking I shouldn't use either QUIT or STOP. My next thought is to use the OS and kill myself with the following: kill -SIGHUP 12345 http://knowledgebase.progress.com/articles/Article/P133912 According to the docs, this behaves in ABL like an untrappable STOP. Any thoughts? Is there a more straightforward approach to rolling back and dying in an ABL client?
Continue reading...
Continue reading...