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
Is anyone out
there using Cool:Gen 4.1 code with Cool:Gen 4.1a Client Manager and Win
3.11 Clients? We are currently testing this combination and are having some
problems although our Win 3.11 environment is somewhat customised.
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
We are using
a product called Hourglass Vs 4.1 to test for Y2K and are having difficultyretrieving
the date which is put into Hourglass. When we execute in the region where
Hourglass is active, we are continuing to get back current date even though
we are using the TIRDATX exit and the ASKTIME macro in that exit to retrieve
the date. I have used the HGCC transaction to set the date and the HGCV
transaction to insure that it is set correctly.I would like to talk to anyone
who has successfully used Hourglass with their CoolGen generated application.
Note: We are currently using CoolGen 4.1a for the HE and are running under
CICS vs 4.1.
RE: Hourglass
Product and Y2K Testing
#BY : e tennant
We have been
using TICTOC for this type of testing, and the sameproblem was found. The
reason is that these tools don't trap theassembler STCK (store clock) command.
We had to modify the sourcecode of TIRDAT2, adding a COPY statement. This
new version wasassembled and placed in a separate dataset from the normal
version.Code to be tested needs to be relinked to this new version.I suggest
you contact the Hourglass vendors to find out what changesthey require to
support STCK - and Sterling may have to provide youwith the source code.
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
Does anybody
have any experience with a capture and playback tool such as SQA Robot,used
for testing Cool:gen GUI-applications? If so, which method did you use to
uniquely identify window controls? As we've found out, the object names
entered by the programmer aren't recognized by SQA Robot. Alternative ways
of identifying controls, such as label names or IDs, are subject to change
and therefore appear not to be very useful as soon as you start testing
another version of the window.
RE: Test
tool for Cool:gen: SQA Robot
#BY : Keith Norris
Mercury interactive
say that they can do this with Win-Runner. I have not you tried this (yet)
though so its just hearsay from my part. Sterling uses Win-Runner but writes
the scripts themselves instead of using the record and playback method.
We then use window titles to identify the windows, maybe this will work
with SQA-Robot.
#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:
LogicWorks
has a Legacy CASE integration tool. I think there customers who have used
it with COOL:Gen. LogicWorks and Sterling have open Application Programming
Innterfaces (API's) to support metadata exchange. You may choose to build
customprograms to support your requirements. Several companies provide products
and services for metadata exchange. Our company, CASE Masters, has successfully
utilized the API's from both ERwin and Sterling to provide metadata exchange
capability. |