Posted: Sat Mar 12, 2005 9:57 am Post subject: data layer, architecture, idms and transactions
Hi,
Perhaps you are also using architectural programming principles. The general idea is a steering layer which is responsable for transaction handling, a business layer for business logic and a data layer for database access. A service layer takes care about requests from other subsystems. Other subsystems can send transactions which are handled by a kind of office: the message handler for that subsystem.
Now I work in the IDMS environment which I don't know that well. At the customers office, they start transactions in the data-layer. That is a big problem, because the true transaction is on a higher level. I wonder how other people are handling this. In IMS/DC DB2 environments, I never had this problem. DB2 takes care about begin- and end transactions. But... in IDMS you have to open a database by yourself. The business layer should not have any knowledge of the data layer, should only know about an interface.
Perhaps someone knows a smart way to open the databases at the moment that it is needed and a way to close them at the end of a transaction without putting the wrong dependencies between layers.
it is about COBOL and ADS and IDMS combined, online but also batch. Also using Architectural concepts, the general idea is to try to build modules that can be used for on-line and batch at the same time.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
