The ISSUG Infobase contains archived postings from our on-line discussion forums. This index is for most of the 1998 postings. Nothing here may be quoted without the written permission of the author(s) of the original postings.

FAQ98 content: George Simpson

FAQ 98 - Section 4

#SUBJECT: Windows 98...
#BY : Ratnakar

I got Cool:gen 4.1 running on Windows 95. Now I am planning toupgrade my Windows 95 to Windows 98. Does it effect Cool:Gen 4.1software ?. If so, what can be done to make Cool:Gen 4.1 work forWindows 98.Any Suggestions ?With Regards,

RE: Windows 98...
#BY : webperson

I hate to state the obvious, but have you checked with Sterling? Do they formally support the toolset on W98? You realize that, if they haven't tested with W98, they will find it hard (and may, reasonably, refuse) to give you support?

My personal experience of 'upgrading' to W98 is that you get very little benefit and a lot of pain. The only safe way to approach it is to reformat your C drive and start from scratch (and even then some of your peripherals may stop working).

#SUBJECT: Cool:Gen Users on Windows 3.11
#BY : nick barney

Full Config:-

• Cool:Gen 4.1a code
• Cool:Gen 4.1a Client Manager
• Cool:Gen 4.1a Transaction Enabler
• Win 3.11 Client (connecting to Novel 3 Server for code)
• HP UX/10.20 Server with Oracle 7.3.4 Database

The symptom is that the client end hangs.

RE: Cool:Gen Users on Windows 3.11
#BY : Michael Tse

We're using CG41a Wfw311 client and CG41a Server, without problems, if we use a Microsoft Network.

BUT if we use Novell network then it is rather unpredictable. What we found was the Winsock from Novell Ver 4 is not fully compatible with Microsoft Winsock 1.1. We have soem workaround if you are interested.

IMHO, everyone should get away from WFW311 ASAP.

RE: Cool:Gen Users on Windows 3.11
#BY : Tineke Malan

We are using more or less the same combination of things on a Sequent box (Cool:Gen4.1a,Dynix 4.4, Oracle 7.3.4, Novell 4, Cool:gen4.1a Client Manager and Windows 3.1 clients). However we are running into problems with the Windows 3.1 clients, especially where there are more than one screen(transaction) following one another - Windows 3.1 just can't handle it. So, after much begging to management, we are upgrading the Windows 3.1 to Windows 95. The clients are still build for Windows 3.1, but it does run under Windows 95. Until every PC has been upgraded to Windows 95, we will use it like this. I hope this help! We could not get it to work any other way!

#SUBJECT: Hourglass Product and Y2K Testing
#BY : Mary Anne Harris

RE: Hourglass Product and Y2K Testing
#BY : e tennant

RE: Hourglass Product and Y2K Testing
#BY : Britt-Marie

Also take a look at PTF GEM4101 (issue 1067996). It changes the way date/time is handled within Cool:Gen.

#SUBJECT: Test tool for Cool:gen: SQA Robot
#BY : DCC

RE: Test tool for Cool:gen: SQA Robot
#BY : Keith Norris

#SUBJECT: Using Endevor to help manage CoolGen
#BY : vanst04

Is anyone currently using CA-Endevor to help manage CoolGen objects? We have a customer who is intersted in Endevor, but would like to discuss with a site who is already using Endevor to manage the components in CoolGen.

1) If you are, would you be interested in helping with a conference all to discuss the technical issues with CA?

2) If you are, would you also be willing to particpate in a conference call with the customer?

Please respond to vanst04@cai.com or call 716-249-3913

RE: Using Endevor to help manage CoolGen

#BY : Glenn Smyth

I have built and installed a Cool:gen to Endevor interface at two sites (DEETYA in Australia and Bank Of Ireland). They both now successfully use Endevor to manage Cool:gen components from their test environments forward (for productivity impact reasons not used in development environment but pmaybe thats one for the discussion). I would be willing to participate in such a discussion or I could contact one of the people at DEETYA or BOI if you like (though they wouldn't know the low-level technical details of the changes to the CE required).

RE: Using Endevor to help manage CoolGen
#BY : Darius Panahy

We at IET have developed a COOL:Gen model management and version control product called GuardIEn that automates the COOL:Gen specific processes like object migration and code generation. Some of our customers have Endevor to manage the source code, object code and production promotion steps and we have an automated interface to Endevor.

The advantage of using GuardIEn to perform the bridge to Endevor is that it takes care of the difficult tasks of ensuring that the COOL:Gen model management, impact analysis and code generation tasks are controlled and performed correctly and efficiently.

RE: Using Endevor to help manage CoolGen

#BY : Glenn Smyth

And the disadvantage is that you have now have two (or 3 ?) CM tools instead of one (GuardIEN sitting between Cool:gen and Endevor). We have had this discussion before and I (and the client sites I was at) have still to be convinced that GuardIEN adds any benefits where you already have Endevor (as opposed to instead of it, where I believe its client base mainly lies).

RE: Using Endevor to help manage CoolGen
#BY : Darius Panahy

Well, on this point we (and other happy GuardIEn sites) will have to disagree, but perhaps your view would be different if you had tried GuardIEn. I am sure you also enjoy developing custom COOL:Gen to Endevor interfaces for your customers. Our customers prefer to have a supported interface that is not reliant on specialist contractors, and they also get many other benefits from GuardIEn, notably automated object migrations, impact analysis and code generation.

RE: Using Endevor to help manage CoolGen
#BY : Glenn Smyth

Sorry Darius, I think you got the impression I was picking on the tool as a whole. I wasn't and I'm not trying to rob you of business. I have nothing against GuardIEn, I think it is great for sites that don't already have a CM tool like Endevor. I was only questioning its role as a bridge between Cool:gen and Endevor (and not that it doesn't work, just the overhead it adds). Horses for courses.

Yes I do enjoy building this type of interface, though this one is already built so no fun there :-), but I would never recommend (as I think you were hinting at) that a site build such an interface (even though this one is relatively simple) if an off-the-shelf product met their needs. FYI, I was the person who pointed out GuardIEn as an alternative for Cool:gen/Endevor integration to the last site I was at (in Ireland) and suggested they investigate it as it would be an on-going supported product.

RE: Using Endevor to help manage CoolGen
#BY : Darius Panahy

Thanks for your comments. In principle, I agree that one tool is better than several. However, I would like to try and explain the rational behind the GuardIEn to Endevor interface in a bit more detail since I feel that it is a justifiable approach.

The objectives for implementing a c.m. tool can be summarised as:

1) Security - protecting the integrity of the production applications, ensuring that there is guaranteed consistency between the application source code and the object code, that adequate backups are maintained, that changes are made in an audited and authorised manner, etc;

2) Productivity - automating as much of the process as possible so that it is efficient and quick;

3) Reliability - using automated tools to ensure that mistakes are not made, that a standard process is used to manage implementations, ensure that all the necessary steps are performed (compiles, links, binds, etc.

With COOL:Gen, the true source is the model and not the generated code. Endevor can only really take charge once the code has been generated, but this leaves many of the earlier stages (migration, change management, code generation, impact analysis, etc) to be managed as 'manual' steps. Since it is in these steps that most of the errors will be introduced, for example by forgetting to generate action blocks that call an AB whose import view has changed), it follows therefore that the input to Endevor will be flawed.

A further problem is in trying to ensure that the COOL:Gen models are kept in synchronisation with the various Endevor managed environments, so that when a package is promoted from one stage to the next, the associated object migrations are also performed.

Because GuardIEn has been designed specifically to work with COOL:Gen, it automates these COOL:Gen specific tasks resulting in error free implementations. Whilst it can also manage the back end steps like compiles, links, binds, production implementation, etc., where a customer has a library management tool like Endevor, we would recommend that this is used instead of GuardIEn.

Why? Because the production support team will not want to have to use multiple tools to manage the production code. They will have chosen Endevor because of its specific features and will naturally want to minimise the number of tools in use, which is your point.

By developing an automated interface between GuardIEn and Endevor, we are able to provide the COOL:Gen developers with a c.m. solution that

a) address the key issues that help them produce fast, error free implementations,

b) utilises the corporate standard c.m. tool for managing production code (ie, Endevor),

c) reduces the need for the developers to learn Endevor since GuardIEn takes care of the interface between them and finally

d) removes the need to develop customised interfaces from scratch since we will be supporting the interface.

We are developing this interface specifically at the request of existing Endevor users who have come to us because they are not satisfied with their current approaches, which tend to involve changes to the COOL:Gen CLISTs and manual effort on behalf of the developers. Whilst these approaches have been technically feasible, they have not addressed the quality and productivity issues mentioned above, and tend not to be liked too much by developers.

If you would like some more information on our approach, I would be happy to send you a document that outlines the interface design, and we would certainly welcome your feedback and suggestions in the light of your experiences with COOL:Gen and Endevor. Please do not stop contributing on this subject!

RE: Using Endevor to help manage CoolGen
#BY : Glenn Smyth

I have no doubt that GuardIEN meets all the objectives you have described. I suppose what I am suggesting is that it can be achieved without it. Please consider this as a development approach using just Cool:gen and Endevor. I believe it meets all the goals also:

1) Assigning objects and making changes :

This is done using standard Cool:gen facilities (subsets, code generation etc) from the development model. No overhead on developers at all, and no requirement to know either Endevor or GuardIEN. At this point you simply assign a developer(s) a change control number for their changes (if it is a very large project and you need to manage these then a simple Excel spreadsheet will do).

2) Identification of changed components :

The CE automatically does this for you (in fact I suspect the GuardIEN logic for listing the changed components is identical). Once they have completed and unit tested the work they simply run the when changed report for the userID(s) from when they started to when they finished. This will automatically identify all changed components AND automatically build an aggregate set to migrate them (which should be named with the change control number). No manual intervention required here (in fact it is even more automated than GuardIEN that requires them to then select from this list to build what ultimatly becomes the unit of migration). If they do need to modify the contents for any reason (this should be rare except to remove business systems that currently get erroneously added on occasion) then they use the modify aggregate set option, which is no different to the modify contents option provided with GuardIEN.

3) Move changes to test environment

Simply migrate using the aggregate set automatically created.

4) (Re-)generate affected components

Use intelligent re-generation (if the models are very large and there are performance concerns with starting this then these can be addressed by limiting scope to the date/time migration took place).

The modified clists will then add the generated source, NCAL, load etc etc (as required) into Endevor under a CCID set to the change control number. The Endevor generate processor can they be kicked off automatically (or alternatively you can define Endevor approval groups if you want more end user control over the environment so that the actual release is under user control (will GuardIEN handle this or will it continue to the next step and do the migrate even though the relaese is not actually there yet ???).

5) Moves to subsequent environments

These are done by Endevor (generate a move package to move all objects under a CCID). The Endevor move processor is modified to add a final step to trigger the Migrate of the previously created aggregate set from model to model (this covers all environments, with a Cool:gen model existing for all). Error hadling to backout Endevor move if migration fails can be added.

I have assumed in the above that the site chooses to have Endevor control all enviornments subsequent to and including test (and Cool:gen development). This boundary line can be drawn at any point on a site/project basis, e.g. it may make sense to begin at QA only.

That's it. If we return to the objectives and key issues you point out, I believe they are all (bar one) met by the above (as well as GuardIEN):

>>>1) Security - protecting the integrity of the production applications, ensuring that there is guaranteed consistency between the application source code and the object code, that adequate backups are maintained, that changes are made in an audited and authorised manner, etc;

All of these are met.

>>>2) Productivity - automating as much of the process as possible so that it is efficient and quick;

It is here I believe that the approach above goes one better than GuardIEN as there is no additional work (or tool knowledge) for the developer at all (except to note dates and times).

>>>3) Reliability - using automated tools to ensure that mistakes are not made, that a standard process is used to manage implementations, ensure that all the necessary steps are performed (compiles, links, binds, etc.

Again all of these issues are addressed.

>>>a) address the key issues that help them produce fast, error free implementations,

These issues are address in the main by fully utilising the power of the CE (automatic creation of aggregate sets, intelligent re-generation etc), features which GuardIEN has been clever enough to use/replicate.

>>>b) utilises the corporate standard c.m. tool for managing production code (ie, Endevor),

Yes.

>>>c) reduces the need for the developers to learn Endevor since GuardIEN takes care of the interface between them and finally

Yes, no knowledge of Endevor NOR GuardIEN required here either.

>>>d) removes the need to develop customised interfaces from scratch since we will be supporting the interface.

Well obviously this last one is not met (unless I ever get around to commercialising the interface) but is is a relatively simple piece of coding.

PS For sites that don't have Endevor I would (and have) strongly recommend(ed) GuardIEN.

PS2 I have run out of time (and Energy) to discuss CBD, but I believe the level of control GuardIEN imposes on migrations and the frequency with which they are required in a CBD world is an issue that needs to be addressed. Also non interface related changes (i.e. implementation only) would not easily be picked up and consequently automatic re-installation of affected consumers (in a static link world) would not happen.

#SUBJECT: Release Management
#BY : Glenn Morgan

Does anyone have experience with managing the development of multiple releases of the same system concurrently? Our project has three releases within four months. We are currently planning on using two development models, and we are trying to determine a best approach for keeping the two models in synch.

RE: Release Management
#BY : Darius Panahy

Our model management product GuardIEn contains a module to assist with the parallel development of multiple releases. One of the issues to be resolved is to reconcile changes made in one release with the next release. For example, if you apply a fix to an object in the Release 1 development model, you would want to ensure that the fix was also applied to Release 2, however you would not want to migrate the object to R2 if a substantial amount of work had been applied to that object in R2. If the object in R2 had not been changed though, you could migrate. There isn't sufficient information in the encyclopaedia to make this decision apart from a line by line comparison because the historical information is not retained in the encyclopaedia.

GuardIEn overcomes this by storing an object 'baseline' timestamp for each object, and by comparing the current timestamp against the baseline, it works out what objects can be migrated because they have not been changed in R2 and which ones need to be checked because they have been changed in R1 and R2.

Another issue is related to the management of re-work to the next release, especially where the re-work is complex. The GuardIEn Change Request/ Change Control facilities offer the ability to create re-work change requests to ensure that any re-work is performed in a structured way.

If you would like to know more about our support for parallel development, please visit our web site at www.iet.co.uk and also e-mail me direct and I would be happy to discuss this is more detail.

RE: Release Management
#BY : Glenn Morgan

How does your baseline timestamp differ from what is stored in the DHLOG/DHOBJ tables in the encyclopedia?

RE: Release Management
#BY : Darius Panahy

For the reasons described below, we do not use DHOBJ, and my understanding of it may not be accurate, but I believe the following to be true.

The main differences between GuardIEn baselines and use of DHOBJ are:

1) DHLOG and DHOBJ are not available on the CSE

2) DHLOG does not store object level history which is required for baselines

3) DHOBJ consumes a lot of disk space and many sites opt to switch off object history.

4) DHOBJ records when an object is changed, but this is not the same as the baseline. For example:

Case A - Change object in R1 and R2.

In this case, the timestamps are different and R2 differs from its true baseline. I can detect that the object has been changed by inspecting DHOBJ by looking for direct changes. However if the change was migrated in, then this might not be so easy because some migrates are OK when the object is re-baselined.

Case B - Change Object in R1, migrate to R2 then change in R1 again

If I change R1 and migrate to R2, then GuardIEn will re-baseline R2 so that its current timestamp equals the baseline. DHOBJ will store the migrate timestamp, which is not helpful for the parallel development work. If the object is changed again in R1, then DHOBJ would indicate that the object had been changed by migration. The question would then be, is it at baseline or not? Some migrates would be OK (ie, from R1 DEV) others not, (ie, from another model where some R2 changes had been made).

5) GuardIEn allows an object to be re-baselined if the changes in R2 are to be ignored.

In summary, the baseline in GuardIEn works for Host and CSE, does not require the storage of DHOBJ rows and addresses the issues of migration described above.

RE: Release Management
#BY : Glenn Smyth

DHLOG/DHOBJ can be turned off on a model by model basis but otherise would have the information. Either way the CE stores the last changed dates for source and object (the later only Composer 3 or later) in the standard DOBJ tables. These will be easier to access then the history tables. We used these to check to see if an object was changed and so could be migrated safely or not as per Darius description with no problems.

RE: Release Management
#BY : Glenn Morgan

I had done some looking at GuardIEn when I was assigned this problem, but it doesn't look like I'll have time on this project; the third release is due in January. And the project management has concluded that tail-gating is not safe, so this issue will be disappearing soon (sort of).

Actually, I am considering using the timestamps on both DOBJ and the DHLOG/DHOBJ tables as a safety check. If the timestamp on DOBJ were before the one on the history tables, then the object could be migrated safely. Otherwise, double-keying would be required. I developed a simple query against the history tables to retrieve the last migration timestamp for each action block in a model. It should be good enough as is, but I'll probably put a little more work into it if I have time.

Thanks to both of you for your advice. Anybody else have any experience in this area?

RE: Release Management
#BY : Glenn Smyth

I meant to compare the date on DOBJ in the later model (i.e. the one that is to be the target of the migration) with the date the model was created. If parallel development began on 1/1/98 and the model was created then that is all you need to compare against. If you are doing incremantal feeds then simply keep a note of the date each time the model is refreshed. If you want to do partial incremental feeds then you use the CHGBYMIG SESSION association to see the last date the object was the target of the migration (as opposed to the DIRCHGD SESSIOn object which has the date the objct was last chnaged in the model directly i.e. by a checkin).

What I am trying to say (badly) is that you do not need history or the source model to make the decision. The date last directly changed in the model compared to either date model created/date object last updated by migration will do fine.

Also, if the solution is to be generic (I see you are from a S/W house) then most large sites do not keep history data for very long. For example at DEETYA it was 30 days (and that was long). Three sites I have been at do not allow model history to be turned on.

#SUBJECT: Report Generators
#BY : Andy Bisby

Does anyone know of any, or can recommend generators that you've successfully used?

RE: Report Generators
#BY : DAVID MUELLER

There have been several threads about report generators posted here.

you can search the Infobase pages.

But in summary there are:

• Report Composer by CANAM software www.canamsoftware.com
• IRIS by IET www.iet.co.uk
• People have used Business Objects and Crystal Reports.

RE: Report Generators
#BY : ellist

Report composer does have a Cool:Gen version. We're using it & the users seem to be happy with the reports. You will need MS Access installed on the clients, since Report Composer "dumps" the report data into Access & then retrieves & formats it to create the reports.

RE: Report Generators
#BY : Koemeester

It's not necessary to have MS Access on your clients. When you install Report Composer on a developer machine you get an Access runtime version. By the way with Report Composer

you can create blockmode and GUI reports for several kind of platforms: MVS, VMS, Tandem, WindowsNT, Windows95, Win 3.11, Unix.

#SUBJECT: Using COOL:Gen and ErWin
#BY : Natja

Has anybody used COOL:Gen and ErWin (from logic works) together ?

RE: Using COOL:Gen and ErWin
#BY : Thomas Ochmann

The way I've done is read the Data Structure from the database to ErWin. In the other way I don't know, maybe BpWin with UML?? Just ask Logic Work in Hamburg, Germany.

RE: Using COOL:Gen and ErWin
#BY : Keith Hall

There are several approaches to making ERwin and COOL:Gen work together.It depends on what type of support you would need. For example, do you want this to be an ongoing support, or a simple conversion? Do you need bi-directional support, or just from Erwin to COOL:Gen?

Another important consideration is related to the underlying repository for ERwin. LogicWorks was recently purchased by Platinum. I would expect ERwin to move away from its current repository, ModelMart, to the Platinum Repository.In any case, here are several options: