Infobase Section 5

	HOME FAQ Contents Part 1 Part 2 Part 3 Part 4 you are here Part 6 Part 7 Part 8 Part 9 Part 10 Part 11 Part 12	The ISSUG Infobase contains archived postings from our on-line discussion forums. Nothing here may be quoted without the written permission of the author(s) of the original postings. The Infobase is organised into 12 sections concerning different topics. FAQ content: Ram Malladi,/font>

Part 5: Model Management 5.1) Model management general questions 5.2) Model Management for various countries 5.3) How to get a list of action blocks that use a specific RI? 5.4) What is the best approach to split-up models? 5.1) Model management general questions Paul Willems Dated : 28 March, 1997 at 12:26 Subject: Model management general questions Recently we have decided to use just one model for all our applications. During the making of all the processes and procedures surrounding this method we came up several possible theoretical problems. For instance the magnitude of one of the models (it has 388481 objects, 70 Mb of generated executables and a 23 Mb checkout.trn). We are curious if anybody up until now has considered the same approach and if so: what were the reasons for proceeding or canceling it? Has anyone any practical experience with this? We are working with Composer 3 on a 5.3.1 CSE server (upgrading to Composer 3 in the near future). ======== Samir mathur, Dated : 31 March, 1997 at 09:29 Subject: Re: Model management general questions I think its good idea to keep one model per application. Advantages : - - for better performance(you can tune it easily), you can logically reorg model (db2 table), - Easy to take backup (quick). - Distribute users to different models (less contention during subsetting. Disadvantage - Lot of model management (resources?) If you are interested I can send more details about this subject ==== Paul Willems, Dated : 02 April, 1997 at 08:01 Subject: Re: Model management general questions Thanks for responding, but we are trying to do quite the opposite. We are making just one model which contains several applications. Every application is constructed in its own business system and is separated as an extract during development. The general idea behind this is: - to keep the development overlap to a minimum. - to have just one datamodel for the entire company. As for your advantages, - We are using Oracle. - Every night we make backups of all models (extracts) in development. It takes about an hour per model. - We run a nightbatch for all developer's download requests to keep the downloads during the day to a minimum. During the day we can have three downloads of three different extracts at the same time. For us these advantages are no reason to keep several models instead of just the one. Paul ==== Didier Marichal, Dated : 02 April, 1997 at 13:06 Subject: Re: Model management general questions We are also making a study to migrate from several models to one big business model. The biggest problems, depending on the model management rules, will be the heavy up- and downloads (are not needed in our strategy, we create development models from definied subsets), backup and restore, export to the public interface (important for us because we use it to populate out repository). However the biggest problem with one model will be: 'will the developer find his/her way among all the objects?'. As with smaller models everything was well defined and rather small in scale. Up till now we are still going ahead with the planning, although we are looking at the possibility to create 3 to 4 'big' business models (currently 70), to minimize the overhead of the things mentioned above. ==== Doug Michael, Dated : 02 April, 1997 at 22:14 Subject: Re: Model management general questions Having worked with both the huge corporate model approach and the one model per system approach I am definitely of the view that in a large organisation there is a happy medium somewhere between the two. Both 'extreme' approaches have considerable disadvantages, some of which have been mentioned by the other posters, and a little bit of compromise can bring big benefits. In the late 80s and early 90s we were all talking corporate data and huge models but many projects failed because of the Development Coordination problems which eventually brought things grinding to a halt. Emphasis shifted to RAD and getting applications out quickly but a lot of the benefits of the IEF and the IE methodology with regard to data sharing and co-ordination tended to get lost. BAA-sized data models are my recommendation, with ideally no more than 5 systems developed from each. Probably also 2 levels of data sharing - the true 'corporate' entities shared across the BAA models and the entities shared only within the BAA scope. Of course if you're into CBD and encapsulation, etc you have to start thinking about component interfaces and the breaking of relationships etc and this might affect your strategy. -Doug Doug Michael Rainier Software ==== Martin Cleminshaw, Dated : 03 April, 1997 at 13:43 Subject: Re: Model management general questions Hi, We are using a single model development strategy because of the amount of re-use that exists between our applications. The development model is not large in terms of number of objects, (about 1 million at the moment) but maybe one should factor this up to take into account the degree of re-use. Our main problems are - Limiting the number of affected users during subset expansion -workaround with some guidelines. - Limiting checkout size - we have put many cabs into dlls, this means that once a body of common cabs has been put into dlls then they no longer have to be dragged up and down with the procedure steps - you subset procedure step with default expansion to get the pstep code but dont expand to get all used cabs. - Cant check out the whole model - mainframe delete can help but this is no panacea - this is a problem. - Checkout time - allocate more db2 buffers. - Cant upload into a model that has a download running. this is a headache but c.e. is not too good with concurrent upload and download unless you have implemented db2 version 4 type 2 indexes. - As a developer you are worried each time you make a significant change to an object your work mates get the change at your next upload. So how do you keep a 'safe' version of your old object while making changes that you may want to undo . Use the dll concept, developers should not be generating code that is owned by others. Never delete atributes from cab interfaces, only add. - Model corruptions have widespread impact - requires that you have resources to fix it quickly. Very seldom that corruptions are widespread. - Regular model copies are necessary to ensure that the spread of object id's is as contiguous as possible. Object id's occur in many indexes and if a model contains a wide spread of these then there are potential performance problems (balance this with the need for change history which can get destroyed when new objects are created). The benefits with one model are - change impact analysis - accessibility to the 'full picture' via sql query - less model management overhead (this can be a big one - consider a model with 500 widely used cabs that are under development - id each cab changes 5 times this is a potential worst case of 2500 migrations each to a common model and then to a project model. Each migration requiring check-in of target subsets. But there must be a compromise here somewhere. regards, Martin. ==== Chris Uttley, Dated : 09 April, 1997 at 13:18 Subject: Re: Model management general questions Just to throw a loop into things, our strategy here at MCM is to build applications using small component models. We are building a health services application that will be comprised of 17 separate components, each of which will have 3 models (a USER MODEL, which contains the client and server procedures but no ERD. An IMPLEMENTATION model, which contains all the database access action blocks and the ERD. And a specification model, which is used to migrate 'stub' action blocks (import/export views only) to other USER models.) Up to about 7 months ago, I was a big fan of the mega model approach, even to the point of having only one business system. But now that I've applied the Component Based Development approach, I think its a better way to go. TI puts out lots of information regarding CBD if your interested. We also run an ORACLE CSE. With all the smaller models, we don't have to worry about subsetting or CSE performance very much. However, there is obviously a tradeoff because we do have to do adoptions/migrations, but not as much as you might think. Pulling together the corporate data model is also more involved, since each component has its own ERD and the relationships across models are not explicitly defined. ==== Steve Thomas, Dated : 09 April, 1997 at 23:03 Subject: Re: Model management general questions I agree with you on the model approach. You need to be reasonable about sizing the models, so they aren't unwieldy, but you need common models for interoperability and sharing. We do them at BAA size also. But, to give us a conceptual view of the business and where everything fits, we do a "mini-isp" model for our enterprise model. Not much detail, maybe central entity types and primitive functions at the lowest. Not useful for building anything, but a great organizational tool to keep it all in perspective. We've used this approach for 8 years now, and clients seem to like it. And it works. Steve Thomas SPT Enterprises, Inc. ==== steve thomas, Dated : 11 April, 1997 at 17:15 Subject: Re: Model management general questions For development, the one-mode-per-application, or maybe a bit broader and make it application area, is ok. For analysis, which is much broader still, you need a model per business area, which will likely encompass many applications areas. The cut down, small scoped approach is quite tactical, and if the higher, broader level of analysis is done earlier, then it works. If this application-level model is the first one, you sacrifice significant understanding of the business, and limit the stability and reusability of the model. 5.2) Model Management for various countries George Lional Nimroth Dharmaraj, Dated : 15 October, 1997 at 03:06 Subject: Model Management for Various Countries. Currently We are developing a Mutual Fund System for Asia pacific Region. Asia Pacific Version of Model has to undergo some changes ie Change Business Functionality for Some specific Country. We have currently 9 nine countries to support in Asia Pacific Version. We like to have one Core Functionality Model as Parent and Country Specfic Model as Children with Added Functionlaity or Changes. We like hear a good Approach towards maintain and Control the Model changes. Is the CBD approach is more suitable with Composer 3 or CoolGen. Kindly give your valuable suggestions to handle this situtaion. Thanks and Best Regards G.Lional ======== Glenn Smyth Dated : 16 October, 1997 at 10:50 Subject: Re: Model Management for Various Countries. CBD would certainly make this easier but the model management will still be a significant overhead. I can send you a paper I wrote on how to do this if you send me your e-mail address (though the papoer talks about different logic for different platforms rather than areas the same approach is applicable. However there is a neater solution where you could still use just a single model and dynamically call the different business logic at runtime. I have just posted a reponse to another query on how to execute different business logic at runtime. See that response for more info. ======== Roger Eaton Dated : 25 November, 1997 at 22:33 Subject: Re: Model Management for Various Countries. I manager the Development Support group at Universal Underwriters Group, Overland Park, KS, USA. If it's not too much bother, I'd like a copy of your paper. Thank you. 5.3) How to get a list of action blocks that use a specific RI? Tim Whelan, Dated : 12 September, 1997 at 10:16 Subject: RI Trigger to Action Block link Does anybody know how to get a list of Action Blocks that use a specific RI Trigger. Thanks ======== Carsten Olsen / Maersk Data, Dated : 12 September, 1997 at 10:44 Subject: Re: RI Trigger to Action Block link The SQL below (for host-encyclopedia) will not give you exactly what you are asking for, but maybe it can be a help. For each PAD-statement, that in the generated code will expand into a call to a RI-trigger, the following is listed: * Actionblock name * Object-id of PAD-statement * Statement-type (Transfer, Disassociate or Delete) Example: MODEL_NAME = COMPOSER INSTALL MODEL 7.0.A8 ------------------------------------- Report ------------- Actionblock Object Statement ---------------------------------------------------------- DELETE_DEPARTMENT 2080902969 Delete DELETE_DIVISION 2080903014 Delete DELETE_EMPLOYEE 2080902970 Delete DELETE_PROJECT 2080902971 Delete DELETE_TEAM 2080902972 Delete MODIFY_DEPARTMENT 2080903147 Transfer MODIFY_DIVISION 2080903205 Transfer MODIFY_EMPLOYEE 2080903197 Transfer MODIFY_PROJECT 2080903228 Transfer SQL: SELECT DISTINCT P.PROP_CHAR_VAL, H.OBJ_ID, OT_OBJ_NAME FROM .DMDL A, .DOBJ H, .DASC G, .DASC F, .DASC D, .DPRP P, .DASC C, .DOBJ B, .SOBJ WHERE A.MODEL_NAME = '&MODEL_NAME' AND H.OBJ_MODEL_ID = A.MODEL_ID AND H.OBJ_TYPE_CODE = 27 AND OT_OBJ_CODE = H.OBJ_TYPE_CODE AND OT_RELEASE = '5.0.A1' AND H.OBJ_ID = G.ASSOC_TO_OBJ_ID AND G.ASSOC_TYPE_CODE = 3 AND G.ASSOC_FROM_OBJ_ID = F.ASSOC_TO_OBJ_ID AND F.ASSOC_TYPE_CODE = 36 AND D.ASSOC_TO_OBJ_ID = F.ASSOC_FROM_OBJ_ID AND D.ASSOC_TYPE_CODE IN (25,31,26) AND C.ASSOC_TO_OBJ_ID = D.ASSOC_FROM_OBJ_ID AND C.ASSOC_TYPE_CODE = 88 AND C.ASSOC_FROM_OBJ_ID = B.OBJ_ID AND B.OBJ_TYPE_CODE IN (21,23) AND P.PROP_OBJ_ID = B.OBJ_ID AND P.PROP_TYPE_CODE = 224 UNION SELECT DISTINCT P2.PROP_CHAR_VAL, H2.OBJ_ID, OT_OBJ_NAME FROM .DMDL A2, .DOBJ B2, .DASC C2, .DASC D2, .DASC F2, .DOBJ H2, .DASC J2, .DASC I2, .DPRP P2, .SOBJ WHERE A2.MODEL_NAME = '&MODEL_NAME' AND H2.OBJ_MODEL_ID = A2.MODEL_ID AND H2.OBJ_TYPE_CODE IN (39,40) AND OT_OBJ_CODE = H2.OBJ_TYPE_CODE AND OT_RELEASE = '5.0.A1' AND I2.ASSOC_FROM_OBJ_ID = H2.OBJ_ID AND I2.ASSOC_TYPE_CODE = 6 AND J2.ASSOC_TO_OBJ_ID = I2.ASSOC_TO_OBJ_ID AND J2.ASSOC_TYPE_CODE = 76 AND J2.ASSOC_FROM_OBJ_ID = F2.ASSOC_TO_OBJ_ID AND F2.ASSOC_TYPE_CODE = 36 AND D2.ASSOC_TO_OBJ_ID = F2.ASSOC_FROM_OBJ_ID AND D2.ASSOC_TYPE_CODE IN (26,31,25) AND C2.ASSOC_TO_OBJ_ID = D2.ASSOC_FROM_OBJ_ID AND C2.ASSOC_TYPE_CODE = 88 AND C2.ASSOC_FROM_OBJ_ID = B2.OBJ_ID AND B2.OBJ_TYPE_CODE IN (21,23) AND P2.PROP_OBJ_ID = B2.OBJ_ID AND P2.PROP_TYPE_CODE = 224 5.4) What is the best approach to split-up models? Paul Willems, Dated : 23 December, 1997 at 14:43 Subject: Splitting up models We are working with a big model (CSE, Oracle and Composer 3). Our problem is, that it is no longer possible to download it in full, so that we can generate the whole model overnight. The problem itself is the maximum number of views, which exceeds the count of 65.000 objects of one type. We can work with various subjects, but we do not want that. We like the idea of splitting up the model, its getting too large anyway. So the question is: 1. What is the best approach on splitting up models? Subsetting and generating a new model? Migration? Extracts? 2. What are the things we have to take into account? Datamodel management, RI triggers, externals, common action blocks, etc. Has anyone experience on the subject? Regards, Paul ======== Martin Cleminshaw, Dated : 24 December, 1997 at 10:15 Subject: Re: Splitting up models Hi, There are a few options here but specific answers require knowledge of your application architecture. Could you perhaps give some details ? 1. Have you adopted a component based architecture with a high degree of reuse of common cabs? 2. If you have a large number of cabs that are re-used are they now fully developed and stable. 3. Do you have a business system structure implemented in the model ?. 4. Have you considered making use of a tool to turn your cabs into dlls. That get's around having to check out procedure steps with full expansion in order to get loadmodules to install correctly. Some things to look out for when going to a new model; 1. Make sure new entities are always created in the same model and migrated to the other models, or name your ri triggers yourself. This is because member names for ri triggers are created when the entity is created and if they are created in separate models they can have duplicate names. So one model should be the source of all new entities. 2. One model should manage all data objects too as you dont want inconsistent ri - so gen ri only from one model. 3. I'm not sure you have the facility 'create model from subset' on the CSE but if you do it may suffer the same problem as the CE in that a subset does not have all the default objects present - it's quite possible to create a corrupt model from subset on the CE. 4. Procedure steps that flow across models require care. Where a procedure step exists in two models it helps to only ever generate it from one of the models. (this goes for cabs too if you use the DLL concept). That may mean some new working methods. There are many other things to consider but start with these. Basically though you buy improved check-in and check-out services when you split a model. You also get the ability to check out the whole model. You lose the migration efforts that go into keeping the models in step. You also lose not being able to do change impact analysis in a single place. If code gen is your only concern you should be able to subset in such a way that you generate all your client psteps in one subset and all your server psteps in another. On the CE making the subset type = system test preserves the integrity of all the link flows. But let me know some details and perhaps I can be more specific, regards, Martin. ======== Rod Maxwell, Dated : 24 December, 1997 at 19:12 Subject: Re: Splitting up models In reviewing Martin's comments, I have one concern... which just may be terminology. He states that due to missing default objects, the Host Encyclopedia can create a corrupted model when you use Create Model from Subset. I've been using the encyclopedia since version 3.1 (1988) and have never had a corrupt model resulting from this operation. In my terminology, a corrupt model means either the model or some of its contents cannot be used due to a database error such as a missing mandatory association. In my view, this is not possible as a result of a create model from subset, barring a bug in the code. However, it is easy to have an incomplete model, whose use is therefore constrained by lack of objects that are missing due to an erroneous subset definition. Model management and version control is a very involved topic, with many consultants who specialize in the field. I would strongly recommend that if your shop has never considered these questions, or the larger topic of Development Coordination, you should look for outside assistance to ensure you get a good solution. 6.15) How to pass command line parameters to UNIX batch?