Very nice. Back in the day, IMS DC was similar to TSO under MVT, trying to multitask too many users in a small space, not unlike seeing how many clowns fit in a Volkswagen Beetle.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Roberts, John J Sent: Monday, October 22, 2012 5:10 PM To: [email protected] Subject: Re: Donald Knuth and The Art of Computer Programming - was RE: Book Enquiry >Ah, but unless you implemented the CICS fences for the storage pieces, it must >have been a bear when the apps started over-running memory. If I can recall correctly, we did a few things to address this problem: (1) We forced the minimum allocation to be 256 bytes. So small buffer overruns didn't do any damage. (2) We simulated duplicate CICS Storage Accounting Areas (SAA) so that we could detect storage corruption. (3) Our app was all Assembly Code, linked as reentrant. So program storage was all in protected storage. (4) Application developers were provided with an extensive set of library subroutines and Macros to invoke them. So their opportunity for storage mayhem was greatly controlled. (5) We had a strict System Testing regimen. Very few damaging bugs made it into production. Of course, the problem of storage corruption was the Achilles Heel of CICS for much of the 70's. But it was the price you had to pay if you needed the performance. The Bank had looked at IMS-DC as an alternative, but my recollection is that only with the very limited Fast Path option that came out in the late 70's was this platform capable of a transaction rate even close to CICS/VS. John ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
