Re: OO in Batch (Was: Program ID)
From: Peter E. C. Dashwood (dashwood_at_enternet.co.nz)
Date: 06/29/04
- Next message: Chuck Stevens: "Re: Method to force keeping of source"
- Previous message: docdwarf_at_panix.com: "Re: In answer to RW - again (was: Sorts (revised)"
- In reply to: Paul Raulerson: "Re: OO in Batch (Was: Program ID)"
- Next in thread: PAUL RAULERSON: "Re: OO in Batch (Was: Program ID)"
- Reply: PAUL RAULERSON: "Re: OO in Batch (Was: Program ID)"
- Reply: Joe Zitzelberger: "Re: OO in Batch (Was: Program ID)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 28 Jun 2004 16:27:10 -0700
Hi Paul,
thanks for posting something we can seriously disagree about <G>.
Reading your post was like a time warp and made the hairs on the back
of my neck stand up (that's about the only place I have any remaining
these days...<G>).
I remember having these exact same arguments in 1969. Spooky.
It's not that I'm anti-Assembler (I write it (or "wrote" it) for both
the Intel platform and the mainframe. It's just that I remember WHY
the World moved away from it.
If nothing else, your post made me think about those arguments again.
(BTW, there are some web sites dedicated to assembler programming on
both the Intel and mainframe platforms, so you are certainly not
alone. Furthermore, your Company has taken a business decision based,
apparently, on the cost of a COBOL compiler. I have to wonder who did
the sums... Any kind of long term cash flow, with maintenance,
portability, availability of staff, time to debug, and the loss of
vendor options, factored into it would show that it might be cheaper
(in the long run), to bite the bullet and buy the compiler...)
Anyway, some specific responses below, and thanks for a good response
to Robert's also excellent post.
"Paul Raulerson" <pkraulerson@verizon.net> wrote in message news:<qfUDc.11252$DT5.5646@nwrddc03.gnilink.net>...
> Assembler does not take 3x the time to write that most people think, and if the target
> platform is a mainframe (or even an Intel platform) it is pretty portable indeed.
Oh no it isn't... It is portable to another mainframe of the same
type and you are now locked in to that supplier. Always supposing you
can find people to write it and maintain it for you. (You can always
outsource this, of course but the rates for IBM assembler guys (most
of whom moved into Systems Programming years ago) are at least double
what it costs to get COBOL people.)
On the Intel platform you are at the mercy of low level API calls
which vary with every release of the OS. If you go the whole hog and
decide not to use system services, then your company should question
what business it is in.
And, even if you use macro assembler and cut and paste most of your
"modules" it still takes a lot more time than writing it in COBOL. (I
won't say "3x" because I haven't done specific quantification, but I
know from my own experience that it definitely takes longer to develop
even small assembler modules, than it does to do them in a high level
language. The degree of research required and the attention to detail
is MUCH greater. It isn't ALL about MVI this or MVC that; that's just
a small part of it.
> In addition, a good HLASM programmer can write code as quickly as a COBOL
> programmer, and the code will be just about as understandable (with comments :)
>
So why did everybody move away from Assembler back in the 60s? The
whole world got it wrong? One of the reasons for the acceptability of
COBOL was that it was SELF documenting (or is when you write it
properly). The equivalent in assembler requires a comment on every
line. That takes time.
> In the old days, you could pretty much do a one to one comparison of COBOL
> with Assembler - and indeed many folks used the COBOL compiler to learn assembler.
> Nowadays, we just teach people.
>
NOBODY in my experience ever used the COBOL compiler to learn
Assembler. Assembler programmers already knew Assembler (and were
dragged kicking and screaming into COBOL) and new programmers learned
COBOL without NEEDING to learn Asssembler. Sure, after a couple of
years some of them became interested in the generated code and this
led to acquiring some Assembler knowledge, but knowing the various
formats and Opcodes of the most generated (by COBOL) instructions does
NOT make an Assembler programmer.
> We choose HLASM syntax because it is both more understandable and more powerful
> than the AT&T syntax used by the GNU toolset. In addition, GAS syntax is meant
> to process compiler output, while HLASM is meant to be used by humans.
>
Can't comment as I have no experience in this area. I believe Robert
suggested in his original mail that an Open source solution might be
appropriate. If your response is that Assembler is "more
understandable" then I have to ask: "More understandable than what?"
Is one form of Assembler more understandable than another? If you are
concerned with readability, why use Assembler at all?
> MOVE A TO MYVAR vs. MVI MYVAR,C'A' is still pretty much one to one.
>
Yes it is. But there is a lot more "baggage" to Assembler programming
than that.
> To read from a file, for instance, you use the CLIB routines or SVC calls. I think
> SVC 3 is read, so the code would be:
>
> LHI R2,FILEDES UNIX FD IN R2
> LA R3,INBUFAD ADDRESS OF BUFFER TO READ INTO
> LHI R4,50 READ UP TO 50 CHARS
> SVC 3
> ST R2,RC STORE RETURN CODE
>
> That equates to rc=read(FILEDES, &INBUF, 50). You can see that the logic is
> of course, identical. The composition is slightly more wordy, but the programmer
> still has to consider the same 5 issues.
>
You are arguing against your own case here... It isn't "slightly more
wordy" it is MUCH more wordy. And the meaning of the words is not
immediately obvious, although I agree it is well coded and the
comments are good.
What happens when a future release of the OS implements SVC 3 in a
slightly different way? Can't happen? I wish...
> It beats the heck out of paying say, 180K for compiler and runtime rights on a system
> just to be able to say
>
> READ IN-FILE-RECORD
>
Being able to issue a READ statement is not the sole justification for
using COBOL, but if you believe that, then I can understand the
climate in which this surprising decision was taken.
Whether a compiler is worth the price or not cannot be considered in
isolation. You do a thorough business case and factor in all the
things I mentioned above. It also depends on the budget for your IT
department. Maybe the company simply can't afford to use a mainframe.
I cannot (and do not) believe that writing your critical applications
in Assembler is a cheaper long term solution than writing them in
COBOL or another High Level language. What other options were
considered before deciding on Assembler? Why not move to Java? It
would be more intelligible and would provide more options in terms of
platform portability.
> That is a pure dollars and cents type of thing though. A technical second choice.
>
> Intel Assembler under Linux is slightly more complex, but not much. Just have to deal
> with those nutcase Intel registers. Note though, that Linux uses the Intel registers pretty
> much like GPR's.
>
Yeah, right... Wait until you have written some Intel Assembler before
deciding ITSA...
Summing up:
In this day and age, to move towards application development (as
opposed to system programming) in Assembler Language has to be
questioned strongly. What exactly are the special and particular
business factors that led to this? Was independent advice sought, or
did the vendor take a few people to lunch and extol the virtues of an
"efficient platform"? (That has you locked in to them forever...) How
comprehensively were the options examined?
While I respect the right of every company to manage their business
and take the decisions they see fit, moving back to the 1960s has to
be seriously questioned.
What's next?
Flared pants, marijuana, and acid rock? (Hey, I just realised how they
made the decision...<G>)
Pete.
>
> -Paul
>
>
>
> "Robert Wagner" <robert.deletethis@wagner.net> wrote in message news:40dff3c5.246088688@news.optonline.net...
> > "PAUL RAULERSON" <pkraulerson@verizon.net> wrote:
> >
> > ><grin> I do new development in COBOL. I've just decided not to do so with
> > >the current
> > >Microfocus or AcuCOBOL products, mostly because I am annoyed with their
> > >idea of what
> > >a fair price is.
> >
> > We all are. As I've said, it's a supply/demand. If demand for Cobol was
> > comparable to C# or Java, MF could sell compilers for $100 too.
> >
> > How many dot-Net developers do you think are interested in Cobol? My unsupported
> > guess would be few. I've not seen a job ad asking for that skill.
> >
> > >RM Cobol here in Austin seems to understand that well, and
> > >I think the next
> > >major project I have to do on a PC I will strongly consider doing with their
> > >product.
> >
> > I'd consider Fujitsu before RM. I'm surprised RM is still in business.
> >
> > >As a consequence, when deploying under Linux on the mainframe, we are using
> > >HLASM. Works
> > >great, much less cost, and runs like greased lightening.
> >
> > Why not GCC? It's the best compiler ever written. Assembly language takes three
> > times as long to write and isn't portable.
- Next message: Chuck Stevens: "Re: Method to force keeping of source"
- Previous message: docdwarf_at_panix.com: "Re: In answer to RW - again (was: Sorts (revised)"
- In reply to: Paul Raulerson: "Re: OO in Batch (Was: Program ID)"
- Next in thread: PAUL RAULERSON: "Re: OO in Batch (Was: Program ID)"
- Reply: PAUL RAULERSON: "Re: OO in Batch (Was: Program ID)"
- Reply: Joe Zitzelberger: "Re: OO in Batch (Was: Program ID)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
