By: Michael S (already5chosen.delete@this.yahoo.com), March 4, 2008 10:20 am
Room: Moderated Discussions
Dean Kent (dkent@realworldtech.com ) on 3/4/08 wrote:
---------------------------
>Michael S (already5chosen@yahoo.com) on 3/4/08 wrote:
>---------------------------
>>Still I am surprised that you didn't bolt your business logic on top of off-the-shelf
>>VCS product. E.g. on ClearCase which appears to be supported on MVS.
>
>This system was written back in 1996, or thereabouts, so such tools weren't available
>then, AFAIK. However, I just looked at ClearCase, and it doesn't indicate it runs on zOS (or MVS).
>
May be, I misinterpreted the following page:
http://www-306.ibm.com/software/awdtools/clearcase/features/index.html?S_CMP=wspace
For me it looks like MVS is supported although not necessarily to the same depth as *nix and Windows.
>I don't have a firm grasp on the 'distributed' model of source control, so I am
>not sure how it would fit into our process/environment.
>
According to my understanding, ClearCase architecture is client/server rather than distributed. So it should be possible to apply policies in centralized manner.
BTW, what about eating your own dogfood?
http://ca.com/us/products/product.aspx?ID=259
>When I proposed our current process to the developers at the time, most couldn't
>grasp it and thought it was 'stupid' (but it fixed the serious issues - so management
>went with it). Within a short time of actually using it, everyone so far has agreed
>it solves 99% of the problems and works better than any other solution (commercial
>or in-house) that they have used in this environment.
>
>I suspect our maintenance cycle is somewhat unique, as the vast majority of those
>I've spoken to continue to focus on the development process, thinking it is maintenance.
>But, as I said, I don't fully understand the model others here use (CVS, or whatever).
>
>Regards,
>Dean
CVS doesn't look like a good solution to the problems that you describe, primarily due to weak support for non-ascii files. SVN, on the other hand, could serve as a good base.
Custom process logic would be implemented via scripts, either in CLIST/REXX like you did it before or through python API. The main advantage over your current solution - you don't have to care about versioned storage under the hood. The second advantage - while most common tasks will be automated by your scripts, you can rely on built-in CLI client or your favorite 3rd party client for less common "manual" actions.
Of course, svn is not available officially under zOS and you likely don't want to depend on unofficial efforts, so the points above are moot.
---------------------------
>Michael S (already5chosen@yahoo.com) on 3/4/08 wrote:
>---------------------------
>>Still I am surprised that you didn't bolt your business logic on top of off-the-shelf
>>VCS product. E.g. on ClearCase which appears to be supported on MVS.
>
>This system was written back in 1996, or thereabouts, so such tools weren't available
>then, AFAIK. However, I just looked at ClearCase, and it doesn't indicate it runs on zOS (or MVS).
>
May be, I misinterpreted the following page:
http://www-306.ibm.com/software/awdtools/clearcase/features/index.html?S_CMP=wspace
For me it looks like MVS is supported although not necessarily to the same depth as *nix and Windows.
>I don't have a firm grasp on the 'distributed' model of source control, so I am
>not sure how it would fit into our process/environment.
>
According to my understanding, ClearCase architecture is client/server rather than distributed. So it should be possible to apply policies in centralized manner.
BTW, what about eating your own dogfood?
http://ca.com/us/products/product.aspx?ID=259
>When I proposed our current process to the developers at the time, most couldn't
>grasp it and thought it was 'stupid' (but it fixed the serious issues - so management
>went with it). Within a short time of actually using it, everyone so far has agreed
>it solves 99% of the problems and works better than any other solution (commercial
>or in-house) that they have used in this environment.
>
>I suspect our maintenance cycle is somewhat unique, as the vast majority of those
>I've spoken to continue to focus on the development process, thinking it is maintenance.
>But, as I said, I don't fully understand the model others here use (CVS, or whatever).
>
>Regards,
>Dean
CVS doesn't look like a good solution to the problems that you describe, primarily due to weak support for non-ascii files. SVN, on the other hand, could serve as a good base.
Custom process logic would be implemented via scripts, either in CLIST/REXX like you did it before or through python API. The main advantage over your current solution - you don't have to care about versioned storage under the hood. The second advantage - while most common tasks will be automated by your scripts, you can rely on built-in CLI client or your favorite 3rd party client for less common "manual" actions.
Of course, svn is not available officially under zOS and you likely don't want to depend on unofficial efforts, so the points above are moot.
Topic | Posted By | Date |
---|---|---|
Multicore is unlikely to be the ideal answer. | Anders Jensen | 2008/02/14 03:24 AM |
And the links.. | Anders Jensen | 2008/02/14 03:25 AM |
Disappointing.. | Linus Torvalds | 2008/02/14 09:17 AM |
Disappointing.. | Mark Roulo | 2008/02/14 10:03 AM |
LOL (NT) | Linus Torvalds | 2008/02/14 04:43 PM |
Disappointing.. | David Patterson | 2008/02/15 10:53 AM |
Disappointing.. | Linus Torvalds | 2008/02/15 04:01 PM |
Disappointing.. | anon | 2008/02/15 07:54 PM |
Disappointing.. | JasonB | 2008/02/19 06:45 PM |
Disappointing.. | Ilya Lipovsky | 2008/02/22 05:27 PM |
Disappointing.. | Scott Bolt | 2008/03/16 10:36 AM |
Need for new programming languages | Vincent Diepeveen | 2008/02/19 05:18 AM |
Need for new programming languages | Pete Wilson | 2008/02/24 10:41 AM |
Disappointing.. | Zan | 2008/02/25 09:52 PM |
Disappointing.. | Robert Myers | 2008/02/19 08:47 PM |
Disappointing.. | Fred Bosick | 2008/02/22 05:38 PM |
Disappointing.. | Robert Myers | 2008/03/01 12:17 PM |
The limits of single CPU speed are here. | John Nagle | 2008/03/14 09:55 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/15 12:02 AM |
The limits of single CPU speed are here. | slacker | 2008/03/15 07:08 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/17 12:47 AM |
The limits of single CPU speed are here. | slacker | 2008/03/17 09:04 AM |
And the links.. | Howard Chu | 2008/02/14 11:58 AM |
I take some of that back | Howard Chu | 2008/02/14 12:55 PM |
And the links.. | Jesper Frimann | 2008/02/14 01:02 PM |
And the links.. | Ilya Lipovsky | 2008/02/15 01:24 PM |
And the links.. | iz | 2008/02/17 09:55 AM |
And the links.. | JasonB | 2008/02/17 06:09 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 12:54 PM |
And the links.. | JasonB | 2008/02/18 09:34 PM |
And the links.. | Thiago Kurovski | 2008/02/19 06:01 PM |
And the links.. | iz | 2008/02/20 09:36 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 02:37 PM |
And the links.. | JasonB | 2008/02/20 05:28 PM |
And the links.. | JasonB | 2008/02/17 05:47 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 01:27 PM |
And the links.. | JasonB | 2008/02/18 09:00 PM |
And the links.. | JasonB | 2008/02/19 02:14 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 03:29 PM |
And the links.. | JasonB | 2008/02/20 05:14 PM |
And the links.. | Ilya Lipovsky | 2008/02/21 10:07 AM |
And the links.. | Howard Chu | 2008/02/14 12:16 PM |
And the links.. | Jukka Larja | 2008/02/15 02:00 AM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 10:41 AM |
Berkeley View on Parallelism | Howard Chu | 2008/02/15 11:49 AM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 02:48 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/17 04:42 PM |
Berkeley View on Parallelism | nick | 2008/02/17 08:15 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/18 03:23 PM |
Berkeley View on Parallelism | nick | 2008/02/18 09:03 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 12:39 AM |
Berkeley View on Parallelism | rcf | 2008/02/19 11:44 AM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 02:25 PM |
Average programmers | anon | 2008/02/18 11:40 AM |
Berkeley View on Parallelism | JasonB | 2008/02/15 07:02 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 07:02 PM |
Berkeley View on Parallelism | Dean Kent | 2008/02/15 07:07 PM |
Berkeley View on Parallelism | Ray | 2008/02/20 02:20 PM |
Berkeley View on Parallelism | JasonB | 2008/02/20 05:11 PM |
Berkeley View on Parallelism | FritzR | 2008/02/24 02:08 PM |
rubyinline, etc. | nordsieck | 2008/02/22 02:38 PM |
rubyinline, etc. | JasonB | 2008/02/23 04:53 AM |
rubyinline, etc. | nordsieck | 2008/03/02 12:40 AM |
rubyinline, etc. | Michael S | 2008/03/02 01:49 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 06:41 AM |
rubyinline, etc. | Michael S | 2008/03/02 07:19 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 07:30 AM |
rubyinline, etc. | JasonB | 2008/03/02 04:26 PM |
rubyinline, etc. | JasonB | 2008/03/02 05:01 PM |
rubyinline, etc. | Anonymous | 2008/03/03 01:11 AM |
rubyinline, etc. | JasonB | 2008/03/03 08:40 AM |
rubyinline, etc. | Foo_ | 2008/03/09 08:59 AM |
rubyinline, etc. | JasonB | 2008/03/10 12:12 AM |
rubyinline, etc. | Gabriele Svelto | 2008/03/10 01:22 AM |
rubyinline, etc. | JasonB | 2008/03/10 03:35 AM |
C++ for beginners | Michael S | 2008/03/10 04:16 AM |
C++ for beginners | JasonB | 2008/03/10 05:35 AM |
C++ | Michael S | 2008/03/10 03:55 AM |
rubyinline, etc. | Linus Torvalds | 2008/03/03 10:35 AM |
rubyinline, etc. | Dean Kent | 2008/03/03 01:35 PM |
rubyinline, etc. | JasonB | 2008/03/03 02:57 PM |
rubyinline, etc. | Dean Kent | 2008/03/03 07:10 PM |
rubyinline, etc. | Michael S | 2008/03/04 12:53 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 06:51 AM |
rubyinline, etc. | Michael S | 2008/03/04 07:29 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 07:53 AM |
rubyinline, etc. | Michael S | 2008/03/04 10:20 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 01:13 PM |
read it. thanks (NT) | Michael S | 2008/03/04 03:31 PM |
efficient HLL's | Patrik Hägglund | 2008/03/04 02:34 PM |
efficient HLL's | Wes Felter | 2008/03/04 08:33 PM |
efficient HLL's | Patrik Hägglund | 2008/03/05 12:23 AM |
efficient HLL's | Michael S | 2008/03/05 01:45 AM |
efficient HLL's | Wilco | 2008/03/05 04:34 PM |
efficient HLL's | Howard Chu | 2008/03/05 06:11 PM |
efficient HLL's | Wilco | 2008/03/06 01:27 PM |
efficient HLL's | anon | 2008/03/05 07:20 AM |
And the links.. | Groo | 2008/02/17 03:28 PM |
And the links.. | Vincent Diepeveen | 2008/02/18 01:33 AM |