<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: I have seen the future, and its name is COBOL</title>
	<atom:link href="http://www.pathf.com/blogs/2007/10/i-have-seen-the/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/</link>
	<description>Running commentary about agile development, user experience design and Ajax.</description>
	<pubDate>Mon, 01 Dec 2008 21:22:58 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: yakijy</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-294</link>
		<dc:creator>yakijy</dc:creator>
		<pubDate>Tue, 01 Jan 2008 15:50:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-294</guid>
		<description>&lt;p&gt;At my first job at CN&#038;W, I had 5 job duties. I was Programmer, Analyst (a separate job now called Business Analyst), Tester (a separate job now called QA Tester), Documentation, Production Support (a separate job now called Support Engineer). &lt;br /&gt;
The best way to hold down IT costs would be to have the programmer do ALL these tasks, under the direction of a manager WHO ACTUALLY HAS DONE PROGRAMMING. You can't believe how many managers are NON-TECHNICAL. Your manager should be a go-to person, who has more knowledge than the developer, not just a chart maker. Nowadays the analysis is done in the US, the programming done in India, the QA done in the US, the support done in India, the documentation not done anywhere. Information technology is a bloated, inefficient PIG nowadays - blame MANAGEMENT. You have 5 separate parts pulling a program in 5 different directions. &lt;br /&gt;
A truly competent programmer/analyst, which is what my title used to be, can save the company a LOT of money.&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>At my first job at CN&#038;W, I had 5 job duties. I was Programmer, Analyst (a separate job now called Business Analyst), Tester (a separate job now called QA Tester), Documentation, Production Support (a separate job now called Support Engineer). <br />
The best way to hold down IT costs would be to have the programmer do ALL these tasks, under the direction of a manager WHO ACTUALLY HAS DONE PROGRAMMING. You can&#8217;t believe how many managers are NON-TECHNICAL. Your manager should be a go-to person, who has more knowledge than the developer, not just a chart maker. Nowadays the analysis is done in the US, the programming done in India, the QA done in the US, the support done in India, the documentation not done anywhere. Information technology is a bloated, inefficient PIG nowadays - blame MANAGEMENT. You have 5 separate parts pulling a program in 5 different directions. <br />
A truly competent programmer/analyst, which is what my title used to be, can save the company a LOT of money.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kajdo</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-293</link>
		<dc:creator>kajdo</dc:creator>
		<pubDate>Thu, 11 Oct 2007 03:26:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-293</guid>
		<description>&lt;p&gt;@Gryph0n &#038; Rick&lt;/p&gt;

&lt;p&gt;very interesting comments ... could you give me some more information abt. your environment ... right now i started to write my master-thesis  with the "workingtitle" Cobol meets J2EE and i would really be interested in your point of view you can contact me via &lt;a href="http://www.contactify.com/eb813" rel="nofollow"&gt;http://www.contactify.com/eb813&lt;/a&gt;&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>@Gryph0n &#038; Rick</p>
<p>very interesting comments &#8230; could you give me some more information abt. your environment &#8230; right now i started to write my master-thesis  with the &#8220;workingtitle&#8221; Cobol meets J2EE and i would really be interested in your point of view you can contact me via <a href="http://www.contactify.com/eb813" rel="nofollow">http://www.contactify.com/eb813</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gryph0n</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-292</link>
		<dc:creator>Gryph0n</dc:creator>
		<pubDate>Fri, 05 Oct 2007 22:11:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-292</guid>
		<description>&lt;p&gt;I work on C/C++ apps running on HP-UX PA-RISC boxes that interface with "legacy" mainframe/COBOL systems. I cannot accept that mainframe systems are faster than modern systems. The reasons why the mainframes are around at my place are:&lt;br /&gt;
1&gt;The business logic implemented in these systems are either not or poorly documented. It would take ages to get back documented business logic from the existing codebase&lt;br /&gt;
2&gt;The company doesnt want to throw away the investments it made in these systems and go with new-fad C++/Java/Ruby replacements because the existing systems are "good enough" and there wouldnt be sufficient ROI&lt;/p&gt;

&lt;p&gt;Modern Midrange(Sun,HPUX,AIX_)/PC environments can run in circles around these mainframe systems.&lt;/p&gt;

&lt;p&gt;All said, I do believe that the mainframes are much more reliable environments (No crashing/Restarting etc) than the Midrange/PC environments&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I work on C/C++ apps running on HP-UX PA-RISC boxes that interface with &#8220;legacy&#8221; mainframe/COBOL systems. I cannot accept that mainframe systems are faster than modern systems. The reasons why the mainframes are around at my place are:<br />
1>The business logic implemented in these systems are either not or poorly documented. It would take ages to get back documented business logic from the existing codebase<br />
2>The company doesnt want to throw away the investments it made in these systems and go with new-fad C++/Java/Ruby replacements because the existing systems are &#8220;good enough&#8221; and there wouldnt be sufficient ROI</p>
<p>Modern Midrange(Sun,HPUX,AIX_)/PC environments can run in circles around these mainframe systems.</p>
<p>All said, I do believe that the mainframes are much more reliable environments (No crashing/Restarting etc) than the Midrange/PC environments</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rick</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-291</link>
		<dc:creator>Rick</dc:creator>
		<pubDate>Fri, 05 Oct 2007 02:20:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-291</guid>
		<description>&lt;p&gt;Hi all,&lt;/p&gt;

&lt;p&gt;No, I'm sorry to say I don't believe COBOL is faster than big distributed environments.  I was a COBOL/CICS programmer for the first 6 years of my career (11 years ago) and currently work for a company that does really massive batch processing.  We used to do it on the mainframe-- in ASSEMBLER, no less, but have since switched to a big grid of Linux machines.  It's much faster, believe me.&lt;/p&gt;

&lt;p&gt;BTW, the grid mostly runs C++ and CORBA stuff....  For parallelism, look over tools like Abinitio and Data Stage.  These offer pipeline and partition parallelism, with a reasonable development environment.&lt;/p&gt;

&lt;p&gt;My .02 worth...&lt;/p&gt;

&lt;p&gt;Best Regards,&lt;/p&gt;

&lt;p&gt;Rick&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hi all,</p>
<p>No, I&#8217;m sorry to say I don&#8217;t believe COBOL is faster than big distributed environments.  I was a COBOL/CICS programmer for the first 6 years of my career (11 years ago) and currently work for a company that does really massive batch processing.  We used to do it on the mainframe&#8211; in ASSEMBLER, no less, but have since switched to a big grid of Linux machines.  It&#8217;s much faster, believe me.</p>
<p>BTW, the grid mostly runs C++ and CORBA stuff&#8230;.  For parallelism, look over tools like Abinitio and Data Stage.  These offer pipeline and partition parallelism, with a reasonable development environment.</p>
<p>My .02 worth&#8230;</p>
<p>Best Regards,</p>
<p>Rick</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kajdo</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-290</link>
		<dc:creator>kajdo</dc:creator>
		<pubDate>Thu, 04 Oct 2007 23:40:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-290</guid>
		<description>&lt;p&gt;sorry the previous post was regarding john's comment not henry's ...&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>sorry the previous post was regarding john&#8217;s comment not henry&#8217;s &#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kajdo</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-289</link>
		<dc:creator>kajdo</dc:creator>
		<pubDate>Thu, 04 Oct 2007 23:37:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-289</guid>
		<description>&lt;p&gt;@Henry&lt;/p&gt;

&lt;p&gt;i don't have statistics at hand but if you work in/for such a company just compare the response time of a user command ...&lt;/p&gt;

&lt;p&gt;just try to update a table using the java-frontend with a cmp/bmp in the db-layer and compare it with the same command using a cics-transaction - you'll be surprised how much time it takes just to dig through all of the j2ee layers to do the update and once again to present the result - i think you don't need scientific statistics to prove the efficiency of the cics-version&lt;/p&gt;

&lt;p&gt;never tried to code a java-batch but i think if there is something like a vm on the host - it's also clear that this would take longer to interpret than a cobol written batch job (at least cobol was designed for exactly that reason - making as much db operations as possible in a minimum of time) ... btw. a usage of a vm on the host would also need lots of resources i think&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>@Henry</p>
<p>i don&#8217;t have statistics at hand but if you work in/for such a company just compare the response time of a user command &#8230;</p>
<p>just try to update a table using the java-frontend with a cmp/bmp in the db-layer and compare it with the same command using a cics-transaction - you&#8217;ll be surprised how much time it takes just to dig through all of the j2ee layers to do the update and once again to present the result - i think you don&#8217;t need scientific statistics to prove the efficiency of the cics-version</p>
<p>never tried to code a java-batch but i think if there is something like a vm on the host - it&#8217;s also clear that this would take longer to interpret than a cobol written batch job (at least cobol was designed for exactly that reason - making as much db operations as possible in a minimum of time) &#8230; btw. a usage of a vm on the host would also need lots of resources i think</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Dillard</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-288</link>
		<dc:creator>Brian Dillard</dc:creator>
		<pubDate>Thu, 04 Oct 2007 22:07:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-288</guid>
		<description>&lt;p&gt;@Adam: I'd love to hear how you got involved in writing COBOL, whether you studied it at university or learned on the job, etc.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>@Adam: I&#8217;d love to hear how you got involved in writing COBOL, whether you studied it at university or learned on the job, etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adam U.</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-287</link>
		<dc:creator>Adam U.</dc:creator>
		<pubDate>Thu, 04 Oct 2007 21:45:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-287</guid>
		<description>&lt;p&gt;I'm one of the few people I know under 30 who actually writes Cobol for a living. I'm an ERP programmer, the whole thing is written in Cobol, there is no question that this language is here to stay. However, I'm spending a significant amount of time learning Java. Why? Simple, Cobol isn't fun to code in. Java is "the new Cobol", it will be around forever too, but at least it's a more powerful language.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I&#8217;m one of the few people I know under 30 who actually writes Cobol for a living. I&#8217;m an ERP programmer, the whole thing is written in Cobol, there is no question that this language is here to stay. However, I&#8217;m spending a significant amount of time learning Java. Why? Simple, Cobol isn&#8217;t fun to code in. Java is &#8220;the new Cobol&#8221;, it will be around forever too, but at least it&#8217;s a more powerful language.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-286</link>
		<dc:creator>John</dc:creator>
		<pubDate>Thu, 04 Oct 2007 20:03:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-286</guid>
		<description>&lt;p&gt;"COBOL code can still process millions of transactions a day in a fraction of the time it would take to do it in Java"&lt;/p&gt;

&lt;p&gt;That's completely untrue.  Care to backup your argument with statistics?  I work for a vendor that supplies systems to financial institutions (COBOL backend/Java frontend), and your comments do not coincide with my experience.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>&#8220;COBOL code can still process millions of transactions a day in a fraction of the time it would take to do it in Java&#8221;</p>
<p>That&#8217;s completely untrue.  Care to backup your argument with statistics?  I work for a vendor that supplies systems to financial institutions (COBOL backend/Java frontend), and your comments do not coincide with my experience.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Henry</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-285</link>
		<dc:creator>Henry</dc:creator>
		<pubDate>Thu, 04 Oct 2007 18:50:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-285</guid>
		<description>&lt;p&gt;is COBOL really in demand? If so, I'll go learn it.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>is COBOL really in demand? If so, I&#8217;ll go learn it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: navot</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-284</link>
		<dc:creator>navot</dc:creator>
		<pubDate>Thu, 04 Oct 2007 17:25:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-284</guid>
		<description>&lt;p&gt;i quite agree, see this one.somtimes going backwards is really fast forwarding. I would like to draw your attention to another alternative which is a paradigm shift for AJAX front ends. One should be aware that I am not, and do not pretend to be objective, never the less I believe that one can judge for himself. Visual WebGui is an open source rapid application development framework for graphic user interfaces of IT web applications. VWG replaces the obsolete paradigms of ASP.NET in both design-time and run-time which were designed for developing sites, with WinForms methodologies, which were designed for developing applications. Thus enabling designer that was designed for application interfaces (WinForms designer) instead of a word documents (ASP.NET designer). This provides the developer with an extremely efficient way to design interfaces using drag and drop instead of hand coding HTML Worth a look at www.visualwebgui.com&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>i quite agree, see this one.somtimes going backwards is really fast forwarding. I would like to draw your attention to another alternative which is a paradigm shift for AJAX front ends. One should be aware that I am not, and do not pretend to be objective, never the less I believe that one can judge for himself. Visual WebGui is an open source rapid application development framework for graphic user interfaces of IT web applications. VWG replaces the obsolete paradigms of ASP.NET in both design-time and run-time which were designed for developing sites, with WinForms methodologies, which were designed for developing applications. Thus enabling designer that was designed for application interfaces (WinForms designer) instead of a word documents (ASP.NET designer). This provides the developer with an extremely efficient way to design interfaces using drag and drop instead of hand coding HTML Worth a look at <a href="http://www.visualwebgui.com" rel="nofollow">http://www.visualwebgui.com</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kajdo</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-283</link>
		<dc:creator>kajdo</dc:creator>
		<pubDate>Thu, 04 Oct 2007 05:10:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-283</guid>
		<description>&lt;p&gt;@tony&lt;/p&gt;

&lt;p&gt;i think you misunderstand the term batch processing regarding cobol on mainframes ... &lt;/p&gt;

&lt;p&gt;it just describes a batch program which runs without any user involvement. you can have hundreds+ of those programs running at the same time and everyone can handle millions of database operations in just a fraction of the time a c# or c++ could be able to do.&lt;/p&gt;

&lt;p&gt;[quote]I guess old timers are always blind to new truths.[/quote] ... i would say most of the programmers today don't want to realize that there are still some specific areas where "old technology" can do a better job than "new technology" ...&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>@tony</p>
<p>i think you misunderstand the term batch processing regarding cobol on mainframes &#8230; </p>
<p>it just describes a batch program which runs without any user involvement. you can have hundreds+ of those programs running at the same time and everyone can handle millions of database operations in just a fraction of the time a c# or c++ could be able to do.</p>
<p>[quote]I guess old timers are always blind to new truths.[/quote] &#8230; i would say most of the programmers today don&#8217;t want to realize that there are still some specific areas where &#8220;old technology&#8221; can do a better job than &#8220;new technology&#8221; &#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jos</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-282</link>
		<dc:creator>jos</dc:creator>
		<pubDate>Wed, 03 Oct 2007 23:01:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-282</guid>
		<description>&lt;p&gt;COBOL faster than java (or c# or c++ or any other modern languages) ???&lt;br /&gt;
How can it be ? does cobol supports massive threading, parallel programming, transactional cache and so on ?&lt;br /&gt;
Batch (sequential) processing is far from be as efficient as parallel processing. I guess old timers are always blind to new truths.&lt;br /&gt;
Changing one's programming habit is hard and old myths are still strong. Cobol is not good for the needs of today.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>COBOL faster than java (or c# or c++ or any other modern languages) ???<br />
How can it be ? does cobol supports massive threading, parallel programming, transactional cache and so on ?<br />
Batch (sequential) processing is far from be as efficient as parallel processing. I guess old timers are always blind to new truths.<br />
Changing one&#8217;s programming habit is hard and old myths are still strong. Cobol is not good for the needs of today.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tony</title>
		<link>http://www.pathf.com/blogs/2007/10/i-have-seen-the/#comment-281</link>
		<dc:creator>Tony</dc:creator>
		<pubDate>Wed, 03 Oct 2007 22:04:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.pathf.com/blogs/?p=234#comment-281</guid>
		<description>&lt;p&gt;Thank you for this commentary. This perspective should be shared as often as possible. &lt;/p&gt;

&lt;p&gt;I work with IT and software development but I also function in the environmental engineering domain. In both domains people (including myself) get enamored with the "latest." &lt;/p&gt;

&lt;p&gt;Today, soil removal (literally digging up and transporting contaminated soil off site) is, in many cases, more effective and cheaper than the latest vaporizing, bio "solution." &lt;/p&gt;

&lt;p&gt;I've been dazzled by PHP only to learn later that a C plus approach would have saved money and would have crunched the data probably 50 times faster, with out breaking. &lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Thank you for this commentary. This perspective should be shared as often as possible. </p>
<p>I work with IT and software development but I also function in the environmental engineering domain. In both domains people (including myself) get enamored with the &#8220;latest.&#8221; </p>
<p>Today, soil removal (literally digging up and transporting contaminated soil off site) is, in many cases, more effective and cheaper than the latest vaporizing, bio &#8220;solution.&#8221; </p>
<p>I&#8217;ve been dazzled by PHP only to learn later that a C plus approach would have saved money and would have crunched the data probably 50 times faster, with out breaking. </p>
]]></content:encoded>
	</item>
</channel>
</rss>
