[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

117.0. "Customization Management and CMS (Code Management System)" by UTROP2::LANGENBERG_C () Thu Feb 27 1992 15:54

    Hello,
    
    could someone shed some light on the following questions?
    
    In ALL-IN-1 V3.0 CMS is used for 2 options: MB and MBE.
    
    This means ALL-IN-1 uses a fraction of the functionality of CMS.
    
    Why are these options choosen and not the rest of the functionality of
    CMS?
    Are there any future plans to extend the CMS support (how do I dare
    asking this!)
    
    Any comments are welcomed!
    
    thanks,
    
    Clarie
T.RTitleUserPersonal
Name		DateLines
117.1CM+ and CMSSIOG::T_REDMONDThoughts of an Idle MindThu Feb 27 1992 16:3115
    There are no plans to extend the support of CMS as an alternative
    storage mechanism for CM+. We have looked at what work it will take and
    are confident that it can be done, but I have doubts that many
    customers would want to pay for it. If you have a customer that needs a
    tight (data sets etc.) integration between CMS and ALL-IN-1 then let me
    know and we'll talk business. On the other hand, if you want a loose
    integration between the two then use the INSTALL and EXECUTE functions,
    and the CMS shareable image.
    
    CM uses a CMS library for the merge options because we needed a product
    that can merge elements together. There is no other reason. If you
    don't have CMS then you can't use these options. The documentation
    makes this quite clear.
    
    Tony
117.2You can store your elements anywhere you likeFULMER::LAAHSTwo Cute Celts are better than oneFri Feb 28 1992 11:3831
    >CM uses a CMS library for the merge options because we needed a product
    >that can merge elements together. There is no other reason. If you
    >don't have CMS then you can't use these options. The documentation
    >makes this quite clear.
    
    If you don't have CMS then you can't use these options out of the box.
    However, if you have another product that can merge elements then you
    can change it so that it uses your code instead of CMS.
    
    As to using CMS as the underlying storage mechanism. The design of CM+
    makes it relatively simple to achieve this. Every option in CM+ is
    controlled via action routines so that we can handle many different
    element types. These action routines are just ALL-IN-1 scripts. 
    
    There are three crucial action routines which all others rely on. These
    are the GET_SOURCE , PUT_SOURCE and DELETE_SOURCE. So, for example when
    you edit a text element the GET_SOURCE is called to retrieve a
    development version and then the PUT_SOURCE is called to put the change
    element back to the development area. Text elements are merely stored
    on disk.
    
    Therefore if you wanted to store elements in CMS rather than just on
    disk (or, probably better store them on disk AND in CMS) then all you
    need do is to change the GET_SOURCE, PUT_SOURCE and DELETE_SOURCE to 
    retrieve elements from CMS rather than from disk.
    
    Take a look at OA$LIB:CM_GET_TEXT.SCP to get a feel for how this could
    be done.
    
    HTH,
    Kevin