Re: Is Micro Focus doomed?

Russell wrote:
To several posters - WHICH language are you using now? It needs to be something that a Cobol programmer can respect, without breaking Vegas. something that can be used for Business logic, and maintained.

Russell,

I'd like to know too.

In fact, it really doesn't much matter which language. (I've referred to it before, I put Wang word processor macros together to help automate typing purchase orders for typists - not data entry clerks. I could also put those macros to work to read your file of purchase orders and produce a summary report, say some six lines by category. Beautifully typed, (Wang had the old style typewriter 'crescent shaped' set of keys which 'jumped up' and put the character image on the paper). Only one snag - you had to leave the machine on overnight to produce that report after some 8 hours processing :-). Literally you saw the documents on screen and the cursor trundling across each page, character by character as it followed the instructions in your macros. (Example - suppose all you were interested in was the $ total for the purchase order - starting at the very top of each document it worked its way down, character by character, until it got to your Total field - purely from vague memory, having got what you wanted you could then close that document and bring up the next).

But I think you might be in a plus, plus situation if your schooling first taught you COBOL. The formalized approach assists you in thinking in a business sense.

I don't think anything more up to date has come out since Thane's "Teach Yourself COBOL in 24 Hours". Given that you are interested in programming, then going through his book step by step gives you an easy coverage of the different topics. However like so many texts, while it does produce examples, it can't cover every contingency. For example, without checking the text, I don't know if Thane spelled out the difference between SEQUENTIAL and LINE SEQUENTIAL.

But given the basics, then actually getting into the real world and trying, you find you missing pieces.

So what I'm suggesting is, with that disciplined COBOL background, firstly familiarizing yourself with the new language you are using, and applying the COBOL common sense approach, ANY language should not be an obstacle to a COBOL programmer. (It doesn't much work out in the opposite direction - once tried to talk to some comp.lang.obj people about use of FACTORY in COBOL - firstly astounded that COBOL had OO and secondly they hadn't a bloody clue in understanding what I was asking).

I think that if you get into a specific language group the questions and answers, for the most part, tend to be resolved so far as that language is concerned.

Now impressions of comp.lang.obj - regulars who jump in giving advice in the abstract, sometimes with some suggested solutions in Java or C. The background of the regulars ? Are they academics, do they publish books to make money or do they *really* program to make a living - big question. I don't go there frequently, but viewing some of the questions asked and the answers given, I think, "What's the big deal ? That isn't a problem in OO COBOL which is just an extension, (modified concepts), of Procedural).

The one thing that can be said about those other Newsgroups is that they do stay on topic. Something titled "Is Micro Focus doomed ?" doesn't contain a reference to "Which Language are you using ?" :-). That's why I don't come here often, it gets too time consuming. But I agonize about Judson having to make a decision.

Now whether or not you stay a 'loyalist' to COBOL or jump off to C#, Java or Linux - that's your choice.

Jimmy
.

Relevant Pages

  • Re: COBOL format definitions?
    ... I'm not a COBOL programmer at all, but I am starting to work with data ... that was given to me with a COBOL field format listing. ... COBOL copybook to a SAS informat), but I would like to sound half-way ...
    (comp.lang.cobol)
  • COBOL format definitions?
    ... I'm not a COBOL programmer at all, but I am starting to work with data ... that was given to me with a COBOL field format listing. ...
    (comp.lang.cobol)
  • Re: COBOL compiler
    ... > Thus spake Ron Johnson: ... >> Instead of lots of small functions and a minimum of global variables, ... > of necessity used COBOL first does not make them a bad person. ... the Bad COBOL Programmer I worked with never did. ...
    (Debian-User)
  • RW needs reminder (was: Cross-language challenge (of POSSIBLE interest)
    ... "Robert Wagner" wrote in message ... This explains the failure of OO Cobol. ... > use OO Cobol than to find a Cobol programmer willing to use OO Cobol. ... for IBM mainframes) ...
    (comp.lang.cobol)
  • Re: Java compatibility issues (WAS: MF having issues?)
    ... Speaking of Cobol, I'm not a Cobol programmer - I've started from Algol-60, PL/I, Fortran, old HP Basic and a lot of different assemblers, then mostly went to C/C++. ... Even solely within Procedural code there are a tremendous number of features for manipulating text; add to that what one can do with OO and it becomes even more flexible - at least in my view. ... Unfortunately the COBOL community hasn't picked up on OO COBOL, which makes the topic academic - and probably in the long term it will have no more usefulness than the COBOL language in total. ...
    (comp.lang.cobol)