Re: Pete Dashwood

Pete Dashwood wrote:
"SeaSideSam" <Sam@xxxxxxxx> wrote in message news:1c587$48dde0be$6214c5e7$14321@xxxxxxxxxxxxx


The amount of COBOL that remains would depend on how much you were able (or willing) to refactor in step 3. I'm working on a project at the moment where we expect to refactor around 80% of the code. If the code is well written, it isn't difficult to refactor. The whole idea is not to "cling to COBOL", it is to move on, but not lose your existing investment. By step 4 everyone will have been trained in C# (which is much quicker to write than COBOL, mainly because the IDE (VS 2008) virtually writes it for you with Intellisense), and the new development will be new components in new languages (python, Ruby, C#, VB.NET, and so on. The language doesn't really matter, although some languages are better than others for certain tasks. What really matters are the objects. These are the building blocks of your business. Glueing them together is not only fun, it is also profitable. Being able to include legacy COBOL with the new stuff and have it all run seamlessly together, is a big deal.

To my mind the most important word you used in the above paragraph was INTELLISENSE. What programming has to be about, regardless of language, is TOOLS and even more TOOLS.

Maybe not quite 'Intellisense' although very close, some tools I was familiar with :-

- Converting one COBOL compiler's files to another COBOL compiler format. UGGH ! How many times has this one come up on clc ? Back in MF DOS days I needed to get RM/COBOL (obsolete version now) across to MF.
They produced a book on conversion not just RM, but many of the other compilers around at the time. User-wise you were prompted for a copyfile or a source containing the file, plus enter the filename you wanted to convert. Stand-alone program - hey presto you got your results; not difficult to copy/paste from their source to make a suite of programs so you automatically generated 10 or more files into MF format in one run.
Worth bearing in mind I'm talking about some 700 file sets accumulated over a 10 - 15 year period. There were some 10 file formats with a file set for each oil/gas plant being dealt with. Assume I was bit/byte oriented, which I'm not, how long would that have taken me to produce ?

- MF ESQL - I would call it 'Intellisense'. Yes I got the intro to DBMS from you but how to be sure I got it right the first time. As you know at your recommendation I used MS Access, but the following applies to all popular DBs. Register the ODBC drivers you are using and ESQL pops up a treeview, a line per ODBC. Expand the treeview and select which application you want; further expansion to show the tables applicable. Now you zero in on a particular table.

For starters you can generate a copy file with SQL/COBOL/Null field formats, for the particular table.

You can select one-by-one the individual SQL executes that you want. From the table format you select which fields are appropriate then hit a 'go' button and your SQL statement is displayed on the screen. Now here's the nifty bit; without compiling you can run the query from ESQL and check out results to ensure the files you selected give the correct answers. You wont get syntax errors but of course you could have included or excluded pertinent fields. Satisfied it works you now copy/paste the SQL statements into your COBOL source.

Now old hands at SQL might observe they don't need this tool, they worked it out a decade ago. But for the newcomer making that switch from COBOL files to SQL - it is a dream and incredibly quick when you have familiarized yourself with the tool.

- GUI Tools - not quite sure how yours worked in FJ, but my own guess, the current version of MF Dialog System is a winner. There's a prepackaged set of source for each individual control, requiring you to design/paint the dialog box, code additions/exceptions in dialog code and then compile. I don't need to tell you this in detail because it can't be far removed from when you were using Dialog System in DOS days. I say it's successful because there are very low volumes in the MF Forum asking about it. I'm guessing users have reached a comfort zone with the product; alternatively having got NE Version 4 or 5 they may have switched to dotNet and possibly use VB.

- GUI Tools - MF Dialog Editor, the one I used. Sure, use icons to dropdown into your Dialog design, but you then get involved in a lot of coding per dialog - so after much effort I wrote a generic MyDialog
to create a dialog using any controls and response to Windows events. This is back when you and I were first figuring out OO, so this was not a five minute exercise. IF ONLY MF had 'Intellisense-itised' it there may have been considerably more people using this approach - OO-wise far more flexible than Dialog Editor. Of course, that's a hindsight observation after the event and every technology has a progression.

As to the word 'Intellisense'; Thane didn't use that word but brought our attention to the concept, either here in clc or softwaresimple. He was the J4 rep for Fujitsu at the time. He mentioned this feature, (presumably, acting on behalf of FJ he had insight as to what the dotNet model would be). 'X' = Visual Studio, could prompt you with methods. Sounded interesting, but I let it pass, because I had a separate file which I could bring up with all methods applicable to a particular class - but although very comprehensive, it was somewhat laborious .

Then our buddy Will Price covered 'Intellisense' with his book on MF and dotNet. Subsequently you enthused about Intellisense and its application. Go for it !

As I wrote above, technology is a progression, regardless of whether or not we are talking about computing, automobiles or food preparation/packaging. Each new idea/innovation is a compliment to previous technology and enhances it. It's by no means exhausted and the Intellisense approach will be/and must be expanded in IT beyond what we can currently dream about.

Just as an afterthought back in the 70s/80s, akin to what I described above abouut SQL - would have been quite neat if COBOL could have generated COBOL file (methods) Paragraphs based on prompts as to what you wanted to do with a particular copyfile ? I'm assuming invidual vendors would do this. Oh my gawd, not the Standards Committee - imagine what they would do with this simple idea !

As a futurist you look to the days when you can cobble together components to produce the results you want without intervention. Well yes and no - if some smart ass produces components to create web pages - he'd better be damn sure it covers EVERY authorised web page vendor - so that it will function with IE, Firefox, Opera, etc., etc. :-). My utter distaste is where I see you and Richard having to delve into the software for what it will actually do; granted you said it was 'interpretation'. But bearing in mind that young lady who zeroed in on a problem of yours, that implies specialization. Perhaps that's necessary - but assuming cottage industry computing grows, individuals finish up as 'Jack of all trades, master of none'. The buzzword 'Intellisense' has to produce a progression.

My use of the word 'authorised' - an example. There are some 6 packages which will handle personal income tax in Canada, some quite simple and others more detailed. Go to the Revenue Canada site and those six vendors' names appear with an imprimatur from Revenue Canada. Their software has to pass stringent tests from RC so that they will accept printed or webbed returns from the applications. (User-wise - Snail-mail returns will get any refunds back, but zipping your return via the Internet - you money is back in less than 10-14 days). I've forgotten the number but Internet submissions of Personal Income Tax in Canada are quite high - don't hold me to it - but I think at least 60%.

Jimmy
.

Quantcast