Plex 2E

All,  Just finished watching the recording of the   "Integrated Change Management for CA Plex using MKS Integrity for IBM i".  One thing that stood out, the idea of a new local model for each "change request/project".  While we're not an MKS shop, the "Model   Manager" piece is available seperately and looks as if it would simplify the creation of local models and provide for some nice auditing.  Currently,   we continue to use the same local model over and over, just curious as to when others create local models.  Charles

I'll create a new local model (by performing a "Save As") when trying some radical experiment or model refactoring, but only for the experiment.  I extract a new local on no set criteria.   I can see a formal process for ensuring a team standards compliance.

Is the moon blue?  That's about how often I create a new local. Or perhaps after a Plex Upgrade (which normally comes before the blue moon). Perhaps my experience is not that of more Plex heavy shops, but even when we were doing more Plex work I hardly ever created a new local...  Crispin.

Hi allI usually make short cycles for a given model; a week or less. In some cases, as soon as the group model is updated, I discard the local model. It comes from my own experience, because I have found sometimes differences among objects created locally and other models updated simultaneously. Local models maintains its own history, and it is better to start from a fresh and coordinated copy from the group model, than persisting in a local model which have a local history. Moreover, last year we have upgraded to 6.0, and have found inconsistences and corruption in models largely supported.There are an issue to take in account: bld file could be lost if overwritten. We use two approaches: copy & paste from old to new, or naming the same the new model. In this way, the bld file is not changed.Jorge Ubeda

Hi Charles  Where can I get hold of the recording of the "Integrated Change Management for CA Plex using MKS Integrity for IBM i". I am intersted in watching this recording.  Regards

http://mks.webex.com/mks/playback.php?FileName=http%3A//www.mks.com /downloads/CA_Plex_PM.wrf   Charles

We update locals into the group and create new locals for each application release. So, for applicaitons with monthly releases--once a month. Other applications less frequently. The idea is to have a group model version/level matching each release--so we can support both production break/fix and new development.  With multiple developers, local model updates have to be more frequent in order for them to share changes.  Local models can corrupt and you can lose everything in one. Not updating them for long periods of time is risky.  You need more local models (thus more frequent updates) when supporting multiple versions of the same application concurrently.

It is a little off topic, but I'd like to share how we manage Group Models and Local models.Putting group models on Windows shares works but updating and extracting can be painfully slow.Levels and Version are great, but not perfect.What if you "fork" or "accidently update" your group models?   How good is your backup scheme?We keep our group models on our workstation's local disk.   This configuration maximizes update and extract speed.   Well... fine, but how do your coworkers share each other's work?The Group models are actually in a Subversion "working copy".   Updating and extracting follow this script Update your working copy for the Subversion repository.   We use TortoiseSVN. "Lock" the repository with TortoiseSVN Perform a group model log in. Extract and update (maybe creating a new local model here J ) Close the group model Perform a "commit" of your subversion working copy.   This also "unlocks" the repository. Rinse and repeat There are several VERY COMPELLING features here Group model updates and extracts are as fast as can be made You have your Group Model saved in one place with EVERY POINT RECOVERABLE.   ALL of them.   Automatically. INCLUDING your previous work IN THE PLEX VERSION that your performed your work. Your project started at Plex 5.5, then you updated to 6.0, and now you are working in 6.1.   Your 5.5 group model is there, IN PLEX 5.5 FORM. EVERY Subversion commit is logged.   You know WHO and WHEN, and if they filled in a comment, WHY Subversion repositories can be hosted on a HTTP server, so it is able to be securely exposed on the Internet.   No VPN or Windows shares. Subversion is Enterprise grade SCM Subversion is fast becoming the most widely used SCM (a defacto standard) Subversion is under active open source development Subversion is FREE.   (TortoiseSVN is free too) For folk comfortable with svn on the command line, TortoiseSVN is not required.   I like GUI's.This is not perfect, but pretty darn good.   SVN commits and updates for a VERY LARGE group model are very fast on average Internet broadband connection.    I can perform group model updates and extracts just about anywhere.   Airports, Starbucks, 3G broadband...

Like some of the others have stated, we rarely create brand new local models.   Sometimes, we have problems with local models being corrupted or not matching the group model for some reason, but this is pretty rare.   We normally create new local models when we upgrade Plex, but I think sometimes I've just upgraded the local model I had.  I watched the same MKS webinar and I was trying to figure out if the Model Manager would really help us.   Developers do their own extracts and updates of the group model so this seemed to add more overhead.   The one thing it would help with is making sure everyone used the same configuration (variants, versions and levels) for the many group models that we have.   We have run into some scenarios where someone will generate a function as an internal and then the next person will develop it as an external (mainly RPG functions) which can make life interesting at times.  Dean Eshleman,MMA, Inc.