InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comMon, 20 May 2013 19:42:50 GMT20http://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxMy first encounter with a Computer was an IBM 1130, I was a student at a nearby College and the Computer was at the University. We went there one night as a special visit. We typed in our Birth Date and it old us our Day of the Week that we were born. Magic Stuff.This was 1975.I really only got into Computers when I discovered that they could play games and print out Soft-Porn.DavidFri, 08 Mar 2013 22:18:30 GMTDavid Connhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxHeh!!! My first software was in Physics, I was trying to aim for a payload specialist spot on the Shuttle.It was to calculate the charge of the electron using the Millikan Oil Drop experiment.. I got it to 19 decimal places..!!!Later the physicist wrote an equation up on the board, turned around and said something about it. I didn't understand either him or the board.So, I changed my major that day!;-)JimWed, 27 Feb 2013 10:03:09 GMTagnew-1142997http://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Eric M Russell (2/26/2013)[/b][hr][quote][b]Miles Neale (2/26/2013)[/b][hr][quote][b]Dave62 (2/26/2013)[/b][hr][quote][b]Miles Neale (2/25/2013)[/b][hr]Dave,Would you suggest developing a massive new system that is PC friendly in COBOL? ... [/quote]Definitely not.I do .NET development and SQL Server development/administration. The last company I worked for had a lot of COBOL running on an AS400. We would leave the COBOL alone as long as it was running fine and didn't need anything new added. As soon as maintenance issues or new features came up we would work on a conversion path.We had no need, interest, or time to bother with re-writing it just for the sake of changing the language.[/quote]Dave,I think that you and I are on common ground. Don't fix what isn't broken.Thanks...[/quote]I agree that most of these legacy COBOL processes should be left in place unless there is a return on investment to re-write them. When it comes to batch processing flat files, I guess COBOL is state of the art, if that's the limit of your current data processing needs. For many organizations, going from COBOL to a relational SQL database wouldn't be just an upgrade of programming code, but also an upgrade of the hardware, OS, and staff as well. Likewise, I've got a 2002 mini-van that was paid for several years back. It gets 15 MPG, drips oil, and one of the sliding doors doesn't work right, but I have no plans to replace it with a new $$,$$$ hybrid until the thing stops running. Especially since I'm not the family member who drives it every day. ;-)[/quote]As I mentioned before, I was developing COBOL using SQL databases (DEC Rdb) 25 years ago, so I don't think there is anything about SQL that forces you to abandon COBOL. There are a lot of mainframe applications that use COBOL to access SQL (DB2 and Oracle) databases. In theory, there is nothing preventing development of COBOL to access SQL Server databases.There are plenty of good reasons to move away from COBOL, especially for new development, but most of the reasons you have posted just show a lack of understanding of the technology.Tue, 26 Feb 2013 17:21:17 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Miles Neale (2/26/2013)[/b][hr][quote][b]Dave62 (2/26/2013)[/b][hr][quote][b]Miles Neale (2/25/2013)[/b][hr]Dave,Would you suggest developing a massive new system that is PC friendly in COBOL? ... [/quote]Definitely not.I do .NET development and SQL Server development/administration. The last company I worked for had a lot of COBOL running on an AS400. We would leave the COBOL alone as long as it was running fine and didn't need anything new added. As soon as maintenance issues or new features came up we would work on a conversion path.We had no need, interest, or time to bother with re-writing it just for the sake of changing the language.[/quote]Dave,I think that you and I are on common ground. Don't fix what isn't broken.Thanks...[/quote]I agree that most of these legacy COBOL processes should be left in place unless there is a return on investment to re-write them. When it comes to batch processing flat files, I guess COBOL is state of the art, if that's the limit of your current data processing needs. For many organizations, going from COBOL to a relational SQL database wouldn't be just an upgrade of programming code, but also an upgrade of the hardware, OS, and staff as well. Likewise, I've got a 2002 mini-van that was paid for several years back. It gets 15 MPG, drips oil, and one of the sliding doors doesn't work right, but I have no plans to replace it with a new $$,$$$ hybrid until the thing stops running. Especially since I'm not the family member who drives it every day. ;-)Tue, 26 Feb 2013 10:25:50 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Dave62 (2/26/2013)[/b][hr][quote][b]Miles Neale (2/25/2013)[/b][hr]Dave,Would you suggest developing a massive new system that is PC friendly in COBOL? ... [/quote]Definitely not.I do .NET development and SQL Server development/administration. The last company I worked for had a lot of COBOL running on an AS400. We would leave the COBOL alone as long as it was running fine and didn't need anything new added. As soon as maintenance issues or new features came up we would work on a conversion path.We had no need, interest, or time to bother with re-writing it just for the sake of changing the language.[/quote]Dave,I think that you and I are on common ground. Don't fix what isn't broken.Thanks...Tue, 26 Feb 2013 09:54:05 GMTMiles Nealehttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Miles Neale (2/25/2013)[/b][hr]Dave,Would you suggest developing a massive new system that is PC friendly in COBOL? ... [/quote]Definitely not.I do .NET development and SQL Server development/administration. The last company I worked for had a lot of COBOL running on an AS400. We would leave the COBOL alone as long as it was running fine and didn't need anything new added. As soon as maintenance issues or new features came up we would work on a conversion path.We had no need, interest, or time to bother with re-writing it just for the sake of changing the language.Tue, 26 Feb 2013 06:29:17 GMTDave62http://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Dave62 (2/25/2013)[/b][hr][quote][b]Eric M Russell (2/25/2013)[/b][hr]COBOL is obsolete in the same way that VHS tapes, the Latin language, and muzzle loaded rilfes are obsolete. Of course it's still widely in use, and still works the way it was originally intended, just like all those other things.[/quote]The point remains that there is wisdom in not re-writing an entire application for no other reason than to change the language.Those who understand this still have COBOL applications working well today.Those who don't understand it waste time and money re-inventing the wheel. :hehe:[/quote]Dave,Would you suggest developing a massive new system that is PC friendly in COBOL? You see I do not believe COBOL is obsolete, but I do believe that it is "contained" for the most part and that most new development will be in a non-COBOL platform.Yes I have written COBOL, three mainframe versions and AS-400 to boot. Have not touched it for almost 17 years. And some if it still runs well. But all new is in something else.M.Mon, 25 Feb 2013 14:59:50 GMTMiles Nealehttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxDitto on the TI-99/4a!..and much the same experience as the OP...writing small programs to solve algebra and physics problems. I even bought the Extended Basic cartridge but the cassette interface went out, and I never really got to use it. I still have the console, joysticks, and all the cartridges. I assume it would still work if I plugged it up. Does anyone remember the Scott Adams Adventure games? :-)Mon, 25 Feb 2013 14:38:33 GMTKenneth J. Moorehttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Eric M Russell (2/25/2013)[/b][hr]COBOL is obsolete in the same way that VHS tapes, the Latin language, and muzzle loaded rilfes are obsolete. Of course it's still widely in use, and still works the way it was originally intended, just like all those other things.[/quote]The point remains that there is wisdom in not re-writing an entire application for no other reason than to change the language.Those who understand this still have COBOL applications working well today.Those who don't understand it waste time and money re-inventing the wheel. :hehe:Mon, 25 Feb 2013 13:11:04 GMTDave62http://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]pdanes (2/22/2013)[/b][hr]It's not obsolete if it still does the job it was designed to do. I've written my share of FORTRAN, RPG, COBOL and who knows what else over the years. No idea if any of it is still running somewhere, but if so, great! There are plenty of tasks that need attention, without inventing silly make-work like replacing fully functional existing code.Things are only obsolete if they can no longer perform their assigned function. COBOL does not fit that definition by any stretch of the imagination.There are shops that develop new applications in COBOL today, and do an enormous amount of useful work. Just because it doesn't fit someone's idea of 'the latest and greatest' doesn't mean it's a bad idea to use it.[/quote]COBOL is obsolete in the same way that VHS tapes, the Latin language, and muzzle loaded rilfes are obsolete. Of course it's still widely in use, and still works the way it was originally intended, just like all those other things.Mon, 25 Feb 2013 12:59:52 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxStill a lot of great responses coming in. But I haven't seen a direct response to the fascinating question by Michael Valentine Jones:[quote]Are there any set based languages besides SQL?[/quote]These two sound like possible candidates, but I am very curious to hear from people who have more expert knowledge on this topic.[u][url=http://readwrite.com/2011/07/01/new-set-based-programming-language-bandicoot]http://readwrite.com/2011/07/01/new-set-based-programming-language-bandicoot[/url][/u][u][url=http://en.wikipedia.org/wiki/Claire_%28programming_language%29]http://en.wikipedia.org/wiki/Claire_%28programming_language%29[/url][/u]- webrunnerMon, 25 Feb 2013 11:44:00 GMTwebrunnerhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Carla Wilson-484785 (2/22/2013)[/b][hr]LOL! Does anyone remember APL, "A Programming Language"? That's what hooked me in 1975, because it was an interactive terminal (keyboard, no CRT) back when all the other computer programming classes at my university were key-punched cards with overnight processing. I used it to write some interactive basic statistics tutorials for the statistics class I had just taken (probability and permutations versus combinations).[/quote]Speaking of interactive, odd languages, I had quite a fascination with Forth. Basically reverse notation stack oriented environment, with a wonderful (dangerous) interaction between interpreter, compiler and application. Statements and functions could be immediate, or could be designated to come into play during compile/interpretation functions. The application could actually modify the interpreter and the compiler during runtime! With great power comes great responsibility.Mon, 25 Feb 2013 11:08:05 GMTjay-hhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]pdanes (2/22/2013)[/b][hr]It's not obsolete if it still does the job it was designed to do. I've written my share of FORTRAN, RPG, COBOL and who knows what else over the years. No idea if any of it is still running somewhere, but if so, great! There are plenty of tasks that need attention, without inventing silly make-work like replacing fully functional existing code.Things are only obsolete if they can no longer perform their assigned function. COBOL does not fit that definition by any stretch of the imagination.There are shops that develop new applications in COBOL today, and do an enormous amount of useful work. Just because it doesn't fit someone's idea of 'the latest and greatest' doesn't mean it's a bad idea to use it.[/quote]I agree, and as long as the thing does not change from what it was originally designed to do, then that is absolutely correct. However, as we all know, systems change over time. New enhancements/functionality are either made or required. That is just technology moving forward. Once those enhancements require a capability not currently in legacy PL's like FORTRAN and COBOL, that is when those systems must be upgraded or converted. Obsolute? No, but maybe in dire need of a 21st century face lift? Maybe.:-DMon, 25 Feb 2013 11:01:16 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Steve Jones - SSC Editor (2/25/2013)[/b][hr][quote][b]Carla Wilson-484785 (2/22/2013)[/b][hr]LOL! Does anyone remember APL, "A Programming Language"? That's what hooked me in 1975, because it was an interactive terminal (keyboard, no CRT) back when all the other computer programming classes at my university were key-punched cards with overnight processing. I used it to write some interactive basic statistics tutorials for the statistics class I had just taken (probability and permutations versus combinations).[/quote]Was this the "right to left" execution of instructions for math/stats? I took a language like that in college. Hated it, but then again, I never like matrix math and lots of that was involved in our course.[/quote]Ha! Yes - I had forgotten about that... It was kind of like using pipes in reverse.Mon, 25 Feb 2013 10:47:39 GMTCarla Wilson-484785http://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Carla Wilson-484785 (2/22/2013)[/b][hr]LOL! Does anyone remember APL, "A Programming Language"? That's what hooked me in 1975, because it was an interactive terminal (keyboard, no CRT) back when all the other computer programming classes at my university were key-punched cards with overnight processing. I used it to write some interactive basic statistics tutorials for the statistics class I had just taken (probability and permutations versus combinations).[/quote]Was this the "right to left" execution of instructions for math/stats? I took a language like that in college. Hated it, but then again, I never like matrix math and lots of that was involved in our course.Mon, 25 Feb 2013 10:16:55 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]bitbucket-25253 (2/23/2013)[/b][hr]I read the previous comments, and except for a very few, posted by us "oldtimers" which bought back memories of my first programming tasks in 1960. (Hard to believe that was some 53 years ago) Using the now ancient IBM 1401 and a language known as "AUTOCODER". [/quote]Ron, The real first code I wrote after absolute was in SPS on a 1620 where we did have variables but had to manage all the registers and locations while dealing with strings. I was familiar with 1401 Autocoder but did not write production code in it. In the 80's I worked with a fellow who wrote the math tables for the Autocoder processor. The stories he told were amazing. One thing I remember was the cost in code it took both in SPS and in Autocoder to write something to disk. There was no SQL and in same cases no index to the data, and before ISAM using the Direct Access Method was costly but at the time a miracle that it could be done. Thank you for bringing up the 1401. The memories of people and environments are wonderful.Mon, 25 Feb 2013 10:00:51 GMTMiles Nealehttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxWhat inspired me was family history. I began tracing my family genealogy back in the early 80's and soon had reams of paper filled with data. Knew I couldn't grow to much without being overwhelmed with 3-ring binders, so decided to build a program to house the data. As the genealogy branched and grew, so did the sophistication of my early databases. By the early 90's, I knew more about databases (and my family!) than any else I knew, so changed careers and became a database programmer. Today, everything is on SQL Servers and served up on the web. As databases go, the application is small, but as family genealogies go it's very, very large (over 13,000 entries) and still growing. What started with a 5-volume series of books with 600 pages of genealogies today would span over 5000 pages and could not realistically be published again. Thank goodness for the web!Mon, 25 Feb 2013 06:38:33 GMTMichael Shorkeyhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxLogo!Go little Turtle, go![url=http://en.wikipedia.org/wiki/Logo_(programming_language)]Here's a link for those who don't know what I am on about :)[/url]Sun, 24 Feb 2013 20:29:43 GMTDavid in .AUhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxI got hooked on computers when I took my first programming class in college - a required course as part of the EE stuff I was doing at the time. My first computer was a Radio Shack TRS-80, where I wrote BASIC programs (to tape!). But the first piece of true software that really evolved things (for me) was when I got my Apple //c and was using AppleWorks.Ahh, how things have changed since then.Sat, 23 Feb 2013 17:07:56 GMTWayneShttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxI read the previous comments, and except for a very few, posted by us "oldtimers" which bought back memories of my first programming tasks in 1960. (Hard to believe that was some 53 years ago) Using the now ancient IBM 1401 and a language known as "AUTOCODER". Autocoder was basically an assembly language. We could not utilize variables, but had to store data in specific memory locations, and to a programmer a ream of paper listing memory locations and what value was in that location was an indispensable tool. The IBM 1401 at that time was, I think rightfully so, designed to handle business data, such as item warehouse location, number of units available, unit price, so that it could be used to reduce quantity in inventory, recall the price per item so as to generate a invoice for the customer. My first task was to attempt to solve engineering problems using a business orientated language. Enough of that, it was to me fascinating, since the only way I did have to solve an engineering problem was a mechanical calculator, input the starting value, pull the hand crank to store the value, enter the operation by depressing the proper key to (add, or subtract, or divide) then input the next value and pull the hand crank.... hand record the result of the calculation, and then continue, hours of endless work to solve the simplest of engineering calculations. And so I started with autocoder, and at the height of my frustrations using autocode, IBM announced a new computer language FORTRAN. A language designed for engineering calculations and loadable on a 1401 computer. Happy days ... oh those so happy days (hindsight). But the result was a strong desire to learn more about programming and how to use it as an engineering tool. Thank goodness that desire to learn remains with me until this day, and I look upon things such as relational databases as a wonderful tool.Sat, 23 Feb 2013 07:27:02 GMTbitbucket-25253http://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxLOL! Does anyone remember APL, "A Programming Language"? That's what hooked me in 1975, because it was an interactive terminal (keyboard, no CRT) back when all the other computer programming classes at my university were key-punched cards with overnight processing. I used it to write some interactive basic statistics tutorials for the statistics class I had just taken (probability and permutations versus combinations).Fri, 22 Feb 2013 16:45:57 GMTCarla Wilson-484785http://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Eric M Russell (2/22/2013)[/b][hr][quote][b]Michael Valentine Jones (2/22/2013)[/b][hr][quote][b]Eric M Russell (2/22/2013)[/b][hr][quote][b]Michael Valentine Jones (2/22/2013)[/b][hr]I don’t see how this list could be complete without mentioning COBOL.From the 1960s until about 1990 it was the language of choice for business programming with implementations on every major OS.There are tremendous number of applications written in COBOL still running.It might not be flashy, sexy, object-oriented, etc. but it continues to be a workhorse.[/quote]COBOL can use indexed sequential files, but it still only does row by row cursor style batch processing. I guess it's a work horse on a big mainframe. When I attended university back in late 80's and early 90's, the database related courses were centered around COBOL. However, since then I've never been exposed to COBOL professionally except as part of a Y2K conversion where I had to port an AS400 based inventory system to SQL Server, copying tables and re-writing COBOL procedures as T-SQL. So I know how to read COBOL, but fortunately never had to develop with it.[/quote]COBOL can use SQL calls to various RDMS, depending on the environment, COBOL version, RDMS API, etc.I am not sure if I know of any procedural language that does anything except row by row processing. Are there any set based languages besides SQL?[/quote]That's right, RDMS and SQL made ISAM and COBOL obsolete 20 years ago.[/quote]SQL did not make COBOL obsolete, since SQL is not a front-end tool and not really a replacement for COBOL.I wrote plenty of COBOL programs that accessed SQL RDMS databases (DEC RDB, not SQL Server) 25 years ago.Fri, 22 Feb 2013 15:36:19 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]pdanes (2/22/2013)[/b][ There are plenty of tasks that need attention, without inventing silly make-work like replacing fully functional existing code.[/quote]Absolutely agree! If it works, requires no maintenance, and you are not moving platforms, leave it alone. We have some COBOL programs that have been running daily for over 12 years with no maintenance done to them. That's not common, but it does exist. Back in the day, I wrote my share of COBOL on mainframes and AS/400. AS/400 even had (has?) embedded SQL that you can get some benefit of set based operations, but many people would still write it as a cursor so the procedural flow was still the same. Fri, 22 Feb 2013 15:19:14 GMTJoe Johnson-482549http://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxIt's not obsolete if it still does the job it was designed to do. I've written my share of FORTRAN, RPG, COBOL and who knows what else over the years. No idea if any of it is still running somewhere, but if so, great! There are plenty of tasks that need attention, without inventing silly make-work like replacing fully functional existing code.Things are only obsolete if they can no longer perform their assigned function. COBOL does not fit that definition by any stretch of the imagination.There are shops that develop new applications in COBOL today, and do an enormous amount of useful work. Just because it doesn't fit someone's idea of 'the latest and greatest' doesn't mean it's a bad idea to use it.Fri, 22 Feb 2013 14:48:49 GMTpdaneshttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Eric M Russell (2/22/2013)[/b]That's right, RDMS and SQL made ISAM and COBOL obsolete 20 years ago.[/quote]Problem is that it might take another few decades to replace all the COBOL code. It really was the workhorse of the industry for a long time and we wrote a ton of it. Fri, 22 Feb 2013 14:31:01 GMTMiles Nealehttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Michael Valentine Jones (2/22/2013)[/b][hr][quote][b]Eric M Russell (2/22/2013)[/b][hr][quote][b]Michael Valentine Jones (2/22/2013)[/b][hr]I don’t see how this list could be complete without mentioning COBOL.From the 1960s until about 1990 it was the language of choice for business programming with implementations on every major OS.There are tremendous number of applications written in COBOL still running.It might not be flashy, sexy, object-oriented, etc. but it continues to be a workhorse.[/quote]COBOL can use indexed sequential files, but it still only does row by row cursor style batch processing. I guess it's a work horse on a big mainframe. When I attended university back in late 80's and early 90's, the database related courses were centered around COBOL. However, since then I've never been exposed to COBOL professionally except as part of a Y2K conversion where I had to port an AS400 based inventory system to SQL Server, copying tables and re-writing COBOL procedures as T-SQL. So I know how to read COBOL, but fortunately never had to develop with it.[/quote]COBOL can use SQL calls to various RDMS, depending on the environment, COBOL version, RDMS API, etc.I am not sure if I know of any procedural language that does anything except row by row processing. Are there any set based languages besides SQL?[/quote]That's right, RDMS and SQL made ISAM and COBOL obsolete 20 years ago.Fri, 22 Feb 2013 12:34:39 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxFirst computer I wanted was a SOL. It was a blue box with a keyboard. I seem to recall it had a wood sides. My parents wouldn't let me get it so the next year I snuck out and bought a TRS-80 Model 1 at 15. I remember upgrading it to a floppy then a double sided floppy (76k of storage). Old shugard drive. They offered a computer class in high school but they wouldn't let me take it. I also spent lots of time programming TI calculators until I found out the math teacher was tricking me into learning math at the same time! Loads of fun. I used to try and disassemble the games when I couldn't solve them, everyonce in while I got lucky.Fri, 22 Feb 2013 12:32:33 GMTJohn Hanrahanhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxMy 1st was also a VIC-20 -- which is [i]nothing[/i] like the C=64 I eventually upgraded to, Eric! ;-) A BASIC manual and then a 6502 Assembler manual was what I lived on, writing animated musical (erm, "beeping") birthday cards for my family in the former and a disk directory prorgam that fit in the 1541 floppy drive's 2K of RAM in the latter. When I could get a hold of a BYTE magazine, I would spend hours typing in the hex code programs to play the half-way decent game it generated.After turning "pro" with the COBOL programming thing, I was able to afford an Amiga 500 and I moved from programming my computers to integrating software and hardware on them. I still have one of my A500s and the 1200 that followed. The way they managed libraries and devices dynamically should make any Windows programmer jealous. I need to fire up my WinUAE before going back to my databases now...Man, that was back when this stuff was [i]fun[/i]. I think the Arduino is as close as I've gotten to that same feeling in today's computing.RichFri, 22 Feb 2013 12:32:21 GMTrichj-826679http://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Eric M Russell (2/22/2013)[/b][hr][quote][b]Michael Valentine Jones (2/22/2013)[/b][hr]I don’t see how this list could be complete without mentioning COBOL.From the 1960s until about 1990 it was the language of choice for business programming with implementations on every major OS.There are tremendous number of applications written in COBOL still running.It might not be flashy, sexy, object-oriented, etc. but it continues to be a workhorse.[/quote]COBOL can use indexed sequential files, but it still only does row by row cursor style batch processing. I guess it's a work horse on a big mainframe. When I attended university back in late 80's and early 90's, the database related courses were centered around COBOL. However, since then I've never been exposed to COBOL professionally except as part of a Y2K conversion where I had to port an AS400 based inventory system to SQL Server, copying tables and re-writing COBOL procedures as T-SQL. So I know how to read COBOL, but fortunately never had to develop with it.[/quote]COBOL can use SQL calls to various RDMS, depending on the environment, COBOL version, RDMS API, etc.I am not sure if I know of any procedural language that does anything except row by row processing. Are there any set based languages besides SQL?Fri, 22 Feb 2013 12:11:33 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Michael Valentine Jones (2/22/2013)[/b][hr]I don’t see how this list could be complete without mentioning COBOL.From the 1960s until about 1990 it was the language of choice for business programming with implementations on every major OS.There are tremendous number of applications written in COBOL still running.It might not be flashy, sexy, object-oriented, etc. but it continues to be a workhorse.[/quote]COBOL can use indexed sequential files, but it still only does row by row cursor style batch processing. I guess it's a work horse on a big mainframe. When I attended university back in late 80's and early 90's, the database related courses were centered around COBOL. However, since then I've never been exposed to COBOL professionally except as part of a Y2K conversion where I had to port an AS400 based inventory system to SQL Server, copying tables and re-writing COBOL procedures as T-SQL. So I know how to read COBOL, but fortunately never had to develop with it.Fri, 22 Feb 2013 11:34:09 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]pdanes (2/22/2013)[/b][hr]Bill Wehnert - The Tom Swift books (I had a set, too) weren't written by Asimov. [url]http://en.wikipedia.org/wiki/Tom_Swift[/url]... My first experience with computing hardware was mechanical Marchant calculators, in the university physics labs where my father taught. ...[/quote]Which reminds me, I have one of these, which my dad (a machine designer) purchased new when I was a child in the 60s. It's a wondrous piece of machineryhttp://www.vcalc.net/cu.htmFri, 22 Feb 2013 11:07:43 GMTjay-hhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Rod Early (2/22/2013)[/b][hr]I got a TI-99/4A computer in 1982 when I was a sophomore in high school...[/quote]I also started with the TI-99/4A, I was in 7th grade at the time though. Lots of memories writing BASIC on that. I don't envy you reprogramming the ASCII characters for Greek, I remember I had tried to make real lowwer case letters instead of just small capitals amongst other things, and had the Hex to bits conversions memorized.The software though that got me interested more in the database side of things was in my first real job when I started using FoxPro for DOS. Yes I had database classes in college that worked with Sybase but those didn't quite grab my imagination the way FoxPro did because we didn't build any front end for the database in college. FoxPro allowed access to the data by SQL or by lowwer level commands. I learned alot about databases from utilizing both, including my preferred way of "pivoting" data using the IIF() function of FoxPro in a SQL query, which I translated to DECODE() function when I learned Oracle, which I translated to CASE in SQL Server.Fri, 22 Feb 2013 11:02:05 GMTChris Harshmanhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]pdanes (2/22/2013)[/b][hr]Bill Wehnert - The Tom Swift books (I had a set, too) weren't written by Asimov. [url]http://en.wikipedia.org/wiki/Tom_Swift[/url]I've been a gadget-geek all my life, since I was a little kid, dismantling mom's vacuum cleaner to see what made all the noise (and then getting in trouble for not putting it back together - once I learned what was inside, I was no longer interested). My first experience with computing hardware was mechanical Marchant calculators, in the university physics labs where my father taught. Then came an electronic calculator with a CRT display a couple of inches square, about the size of a large typewriter and weighing considerably more. It could add, subtract, multiply, divide and remember one number. No square root. The first experience with real programming was a beginning Fortran course, at the university again, after a Vietnam-era tour in the Marine Corps. Univac 9300, 32KB of magnetic core memory, punched 80-column card input - the university's sole computer. Everything in the school ran on it, and students were given one run per day, in the evening, to hand in their deck of cards. Next morning, you could pick up your card deck and however many sheets of paper your job had generated, and go troubleshoot it. That evening, you could try again. If there was too much stuff for the operator to fit it all in, you had to wait until the next day. Sometimes, if the operator was feeling generous and the workload was light, you could persuade him to run a few things during lunch hour.Even under such primitive conditions, once I discovered what those machines could do, I was hooked and have been at it ever since.[/quote]As a young child, I liked to play with my dad's old punch cards from the grad school courses he was taking at the time. Student access to the mainframe worked the same way as pdanes described - turn in your cards for your once-daily run, check back the next day for results. My dad got about as emotional as he ever gets describing the frustration of working for hours on a program, picking up "error" results, then spending hours more poring over the cards to find the one errant punch.Fri, 22 Feb 2013 10:54:09 GMTwolfkilljhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxThe first software that impressed me and caused me to consider entering the field was the Apollo Guidance Computer functionality. The AGC became famous as the computer or set of computers that performed the navigation etc... for the Apollo 11 Lunar Landing and other activities. The functionality of the computer was so advanced for the time that it boggled the minds of geeks across the globe. That was in 69 when science fiction became reality.I started programming in 1971 and since then I have programmed on multiple platforms, in 15 - 20 different computer languages and have loved every bit of it. Programming and data are still fascinating me today, and every program, research project, or even report is an adventure. Fri, 22 Feb 2013 10:04:44 GMTMiles Nealehttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxBill Wehnert - The Tom Swift books (I had a set, too) weren't written by Asimov. [url]http://en.wikipedia.org/wiki/Tom_Swift[/url]I've been a gadget-geek all my life, since I was a little kid, dismantling mom's vacuum cleaner to see what made all the noise (and then getting in trouble for not putting it back together - once I learned what was inside, I was no longer interested). My first experience with computing hardware was mechanical Marchant calculators, in the university physics labs where my father taught. Then came an electronic calculator with a CRT display a couple of inches square, about the size of a large typewriter and weighing considerably more. It could add, subtract, multiply, divide and remember one number. No square root. The first experience with real programming was a beginning Fortran course, at the university again, after a Vietnam-era tour in the Marine Corps. Univac 9300, 32KB of magnetic core memory, punched 80-column card input - the university's sole computer. Everything in the school ran on it, and students were given one run per day, in the evening, to hand in their deck of cards. Next morning, you could pick up your card deck and however many sheets of paper your job had generated, and go troubleshoot it. That evening, you could try again. If there was too much stuff for the operator to fit it all in, you had to wait until the next day. Sometimes, if the operator was feeling generous and the workload was light, you could persuade him to run a few things during lunch hour.Even under such primitive conditions, once I discovered what those machines could do, I was hooked and have been at it ever since.Fri, 22 Feb 2013 09:53:09 GMTpdaneshttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxfor as long as I remember, I have always liked to tinker and build things. I have found that working with computers is just a natural extention of this. The first computers I had encountered where a trs 80 in high school and Burroughs equipment in college. But what really inpired me was building my 1st application for job tracking (in Basic on an IBM PC running P-CODE) and it was usable and helped people work more efficiently.I sometime wish the days were still that simple :-)Fri, 22 Feb 2013 09:28:37 GMTEd Salvahttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Dave62 (2/22/2013)[/b][hr][quote][b]Eric M Russell (2/22/2013)[/b][hr]I think the average age for database developers and sysadmins must be like 40. Maybe a few years more for sysadmins.[/quote]I hear you. It seems like they just keep getting younger and younger... :hehe:[/quote]Hold up...I need to adjust my hearing aids. :-PIn my defense - this whole "IT" thing was a second career for me.Fri, 22 Feb 2013 09:24:57 GMTbatgirlhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Eric M Russell (2/22/2013)[/b][hr]I think the average age for database developers and sysadmins must be like 40. Maybe a few years more for sysadmins.[/quote]I hear you. It seems like they just keep getting younger and younger... :hehe:Fri, 22 Feb 2013 09:22:08 GMTDave62http://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspxI think the average age for database developers and sysadmins must be like 40. Maybe a few years more for sysadmins.Fri, 22 Feb 2013 09:17:18 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic1422888-263-1.aspx[quote][b]Paulo A. Nascimento (2/22/2013)[/b][hr]No doubt, the BASIC interpreter that came with my first 8-bit home computer, the Atari 800 XL.[/quote]Atari 800XL - w00t! This was the first computer that my family owned. I had gotten hooked on computers with the Apple II series, but there was no way I could have convinced my folks to shell out the big bucks for one of those. I was so excited when they brought home the 800XL with a data cassette drive and a flywheel printer that I was happy to overlook the goofiness of "TV\Computer" switch that connected it to the 12-inch black-and-white TV that served as a monitor. It's interesting to remember how quickly the wait for programs to load and save from cassette tape began to annoy me, though!Fri, 22 Feb 2013 08:54:21 GMTwolfkillj