In reference to http://en.wikipedia.org/wiki/CRUD

The CRUD pattern is most basic to information systems. It is a obvious thought that any file should be equipped with a CRUD based maintenance program. That is a program, or a collection of programs that can Add a record to a file (Create), Read that record back (Retrieve), Update some fields (Update) and Delete a record permanently (Delete).

The pattern is quite suited for an automated approach. Besides the field names of the file are different for any file, there is no change in the logic of the program.

In reference to http://en.wikipedia.org/wiki/ACID

Rule: any program action should be atomic, consistent, isolated and durable.

Well, what does this all mean? When your program is the single rununit in a single user system, there is probably no problem. But things get complicated when multiple users launch all kinds of run units and are expecting that the whole system is able to synchronize all actions.
And ACID requirements drill down to the persistence layer: storage, the file system, a database.

Any Business Information System will exhibit a standard assembly of components. To see this one should ignore the domain and go into birdseye view. We might call such assembly a Generic Architecture and embed this view in our System Development, especially for Cobol based Information Systems.

The design pattern originates from the seventies and enjoys accumulating interest nowadays. Maybe we do understand it better today.

Basically we approach everything as being a "system": it does something, consumes "signals" from the outside world and produces something. Another way to formulate IPO.



This pattern is quite useful when we consider the design of Information Systems. See it in action at http://enklare.wordpress.com/2011/02/28/the-b/

As long as we have computers, they need input which is manipulated to obtain some output. This transformation principle is not elitist to computers -as such-, because we find this all over in nature. For instance, a prism "manipulates" ordinary light to deliver a spectrum in a form we known as a rainbow. It does so by relatively bending the distinctive frequencies and making clear what is input and what is output. Critics may say that it is just a decomposition of the whole into "things" that were hidden in the whole.

Whatever. With computers the paradigm input - processing - output became clear. And since it has a long standing in physics and cybernetics, the principle is rediscovered in computing when the hardware became programmable by software: the IPO paradigm in the heart of Cybernetics is commonly known as the "Systems Approach".

One may encounter also the equivalent as in input - transformation - output: there is also a feedback component defined, which would either adjust the form, quantity or quality of the inputs needed, either is used to parameterize the Processing. It is not obvious what exactly is the case, but we know about feedback, don't we?

The Cobol language was intended as program text and followed a certain common text format. It contains DIVISION’s with SECTION’s. In text processing terms the entries could form a (virtual) Table Of Contents (TOC). Each SECTION was build from PARAGRAPH’s . The language format is furthermore based on SENTENCE’s (ending with a period) containing statements (separated by a optional comma).

In other words, a structure as familiar as a common text document. Doesn’t this fact invite to dive into the principles of text processing and common usances in that area? To my opinion it is at least worth the try.

Following topics should be explored: