Hi,
as far as I know it is not possible in IBM-mainframe COBOL to overwrite working-storage and damage a procedure/instruction-area but I agree you can get a S0C1 of it... perhaps some FD stuff can be touched.
I know that some programmers in old-basic environments did just that: write some machine-code in storage and activate it with a kind of call.
To Claudeb: you don't want to experience those complex problems because it can be extremely difficult to solve them.
In Slade's example if the field other-ws-data is important to decide what kind of processing has to be done and the calling program continues to do the wrong things, it can be difficult to determine that all the problems are only caused by an unexpected change of other-ws-data by the called module. You can imagine that people don't expect this to happen and are looking for other things.
If you have subscriptors which are overwritten in this way, the wrong element of a table will be processed or some elements will not be processed at all. If the program has run and your conclusion is that some elements of the table are not processed, you will probably search for wrong logic in increasing the subscriptor ... but you will never find it in the calling program because there is nothing wrong there.....
I saw people spending more than a week together trying to solve problems like this. It is very convenient to be asked to help them, knowing for sure that you shouldn't look for all the normal things - because they did those kind of searching - and that their main problem is that they are having difficulties to defeat the original assumptions while you get the credits for solving the problem in a short time. Looking for unmeant changes of important fields or even creating defensive working-storage area's can help you.
If a good program works ok for a long time and suddenly it is not functioning anymore, look if some of the called modules are changed.
By the way, it can be convenient to define an extra filler in the interface area because if called modules are used by more and more programs and if you want to change something, it is convenient not to have to change all the calling programs.
There are lots of books written about COBOL and how to develop programs but you never see one that tells you about all the problems and how to prevent them, what defensive programming is all about, what good mainainable concepts are, things like that but also about all the dirty tricks you can do if you are in a hurry and you want to force things to work, translated directly from Dutch to English you can call them crowbar techniques... But I don't know the right word for that.... Do you?
If a sponsor stands up to finance this new book....
I hope this is helpful.
With Friendly Regards,
Crox
