Home > Archive > Cobol > May 2007 > Cobol News - Microfocus and AcuCOBOL
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Cobol News - Microfocus and AcuCOBOL
|
|
|
| In COBOL news in the past w , MicroFocus announced the ACTION
program for helping spur COBOL education. The NetExpress 5.0 Personal
Edition can now be downloaded for Free from their Website.
MicroFocus also has acquired AcuCorp.
| |
| Arnold Trembley 2007-05-05, 3:55 am |
|
Thane wrote:
> In COBOL news in the past w, MicroFocus announced the ACTION
> program for helping spur COBOL education. The NetExpress 5.0 Personal
> Edition can now be downloaded for Free from their Website.
>
> MicroFocus also has acquired AcuCorp.
>
Thane, can you provide a URL?
I checked here:
http://www.microfocus.com/products/NetExpress/index.asp
But I can't find any way to download NetExpress 5.0 Personal edition.
--
http://arnold.trembley.home.att.net/
| |
|
|
| Michael Russell 2007-05-05, 3:55 am |
| Top post.
Certainly is, Arnold - thanks for this.
185MB on its way ....
Michael
Arnold Trembley wrote:
> Perhaps this is the URL for the free download?
>
> http://www.microfocus.com/Resources.../shop/index.asp
>
>
> Thane wrote:
>
>
| |
| Rene_Surop 2007-05-05, 9:55 pm |
| >[color=darkred]
> http://www.microfocus.com/Resources.../shop/index.asp
>
> Thane wrote:
>
This is the best offer you could get from Microfocus... I will check
this out for sure.
Thanks for sharing the information. Due to the numerous pages of
Microfocus has on their site, this is a solid gift for programmers out
there who really wanted to learn Microfocus product strength... and of
course COBOL in general.
| |
| Davide Grandi 2007-05-05, 9:55 pm |
| Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
[color=darkred]
> Perhaps this is the URL for the free download?
>
> http://www.microfocus.com/Resources.../shop/index.asp
>
>
> Thane wrote:
>
Thank-you very much for the news.
.... 6 minutes remaining for the download.
Best regards,
Davide
--
Ing. Davide Grandi
davide.grandi@mclink.it
| |
| William M. Klein 2007-05-06, 3:55 am |
| Did everyone see the footnote that says,
"*The compiler creates an executable file from up to 2200 lines of COBOL source
code."
--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Russell" <Michael.Russell@msn.com> wrote in message
news:MtCdnZhWqo6zoKHbnZ2dnUVZ8tSdnZ2d@pi
pex.net...[color=darkred]
> Top post.
>
> Certainly is, Arnold - thanks for this.
> 185MB on its way ....
>
> Michael
> Arnold Trembley wrote:
| |
|
| William M. Klein wrote:
> Did everyone see the footnote that says,
>
> "*The compiler creates an executable file from up to 2200 lines of COBOL source
> code."
>
That just enforces modularity... ;)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Wolfgang Dephoff 2007-05-06, 3:55 am |
| LX-i wrote:
> William M. Klein wrote:
>
> That just enforces modularity... ;)
>
>
When you carefully read the readme file, you read:
"You are limited to 2200 lines of procedural code in each source file"
I think, that this means a "Procedure division" of up to 2200 lines, all
other divisions are not "procedural code". Am I right ?
Wolfgang Dephoff
| |
| Pete Dashwood 2007-05-06, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:1oc%h.265046$c62.228514@fe07.news.easynews.com...
> Did everyone see the footnote that says,
>
> "*The compiler creates an executable file from up to 2200 lines of COBOL
> source code."
>
Gee, I'm really queueing up to get a 185MB download of a crippled compiler
for an obsolete language that requires me to pay run time fees for anything
I write in it...
Is it me?...
Pete.
> Bill Klein
> wmklein <at> ix.netcom.com
> "Michael Russell" <Michael.Russell@msn.com> wrote in message
> news:MtCdnZhWqo6zoKHbnZ2dnUVZ8tSdnZ2d@pi
pex.net...
>
>
| |
|
| Wolfgang Dephoff wrote:
> LX-i wrote:
> When you carefully read the readme file, you read:
>
> "You are limited to 2200 lines of procedural code in each source file"
>
> I think, that this means a "Procedure division" of up to 2200 lines, all
> other divisions are not "procedural code". Am I right ?
I don't know - the quote says COBOL source code. The devil is always in
the details - do "COPY"s count?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Colin Campbell 2007-05-06, 6:55 pm |
| Pete Dashwood wrote:
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:1oc%h.265046$c62.228514@fe07.news.easynews.com...
>
>
> Gee, I'm really queueing up to get a 185MB download of a crippled compiler
> for an obsolete language that requires me to pay run time fees for anything
> I write in it...
>
> Is it me?...
>
> Pete.
>
Almost undoubtedly, YES! <g>
(The "obsolete language" part is a bit unkind. I know the organization
I retired from is still writing new COBOL programs, as well as
maintaining thousands of existing ones. Of course, 99.9% of the code
executes on an IBM mainframe....)[color=darkred]
>
| |
|
| Thane wrote:
> In COBOL news in the past w, MicroFocus announced the ACTION
> program for helping spur COBOL education. The NetExpress 5.0 Personal
> Edition can now be downloaded for Free from their Website.
I have a question for you - can COBOL files be used as code-behind files
for ASP.NET applications, or would one need to use COBOL to create their
..NET DLL files, and wrap these calls with C# or VB.NET?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Pete Dashwood 2007-05-07, 9:55 pm |
|
"Colin Campbell" <cmcampb@adelphia.net> wrote in message
news:463e4cf9$0$8983$4c368faf@roadrunner
.com...
> Pete Dashwood wrote:
> Almost undoubtedly, YES! <g>
OK, Colin, thanks for qualifying your response... :-)
>
> (The "obsolete language" part is a bit unkind.
No, it isn't. It is a simple statement of fact. (How much longer it will
still be arguable remains to be seen; I don't think we'll be having this
discussion in 2015...)
I know people who still make lace by hand; that doesn't mean their process
for doing so isn't obsolete.
Your old Company may well still be using COBOL, and maybe they'll never move
to the Internet, in which case it doesn't matter too much whether they
continue using COBOL. Eventually, if that is really the case, they'll either
find themselves overrun by their competitors, or sales will drop to the
point where the cost of continung COBOL committment is more than they can
afford.
The Network has inherited the Earth; COBOL does not cope well with the
network, the result is inevitable. (OO COBOL actually copes very well with
the Network, but it can't compete with the other OO languages on price,
toolsets, or infrastructure.C# and Java both leave it gasping, and they are
free...)
10 - 15 years or so ago, if the COBOL community had embraced OO, the
language might have had a chance of still being viable. They didn't, it
isn't. Now it is far too late. The people who need to use OO (and that's
everyone who intends to use the Net) won't use COBOL, or even OO COBOL,
because they have infinitely better tools, IDEs, and languages to write
stuff in, they are not hit with run time fees for what they develop, and
they don't have to pay thousands of dollars for a compiler, or more
thousands for training.
Simple Darwinism; fail to adapt, get replaced by a species that did. COBOL
is obsolete, in the same sense that Neanderthals were obsolete once Homo
Sapiens arrived.
I'm not saying it to be unkind (I actually love COBOL, and wrote it for
nearly 40 years... I'm just realistic enough to recognise the situation.)
I'm currently converting OO COBOL components to C#, wrapping other COBOL
components in C#, writing new stuff as web services in C#, and finding life
is much easier.
>I know the organization I retired from is still writing new COBOL programs,
>as well as maintaining thousands of existing ones. Of course, 99.9% of the
>code executes on an IBM mainframe....)
Sure. I wonder what percentage of it will do so by 2015 (my publicly
predicted date for the end of COBOL as a serious development language)?
Pete
| |
| Pete Dashwood 2007-05-07, 9:55 pm |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:gfudnS4TPYwbWaPbnZ2dnUVZ_u3inZ2d@co
mcast.com...
> Thane wrote:
>
> I have a question for you - can COBOL files be used as code-behind files
> for ASP.NET applications, or would one need to use COBOL to create their
> .NET DLL files, and wrap these calls with C# or VB.NET?
>
>
I have a question, too...
Assuming the above IS possible, if I write a web service in NetExpress COBOL
and run it on my own Web Server, where do I stand with regard to run time
fees?
I have not distributed the application to a specific individual or
organization, there is only ONE copy of it in existence, yet EVERYONE can
access and use it...Am I expected to pay for every hit on my service?
Pete.
| |
| donald tees 2007-05-07, 9:55 pm |
| Pete Dashwood wrote:
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:gfudnS4TPYwbWaPbnZ2dnUVZ_u3inZ2d@co
mcast.com...
> I have a question, too...
>
> Assuming the above IS possible, if I write a web service in NetExpress COBOL
> and run it on my own Web Server, where do I stand with regard to run time
> fees?
>
> I have not distributed the application to a specific individual or
> organization, there is only ONE copy of it in existence, yet EVERYONE can
> access and use it...Am I expected to pay for every hit on my service?
>
> Pete.
>
>
I have yet another question.
Can the compiled code be *linked* with no restrictions? As someone
said, a limit on source code lines simply enforces modularity if all the
modules can be linked. However, MS uses pseudo code. If the
restriction is on the number of lines that can be run at execution time,
then the limit is far more restrictive.
Donald
| |
| Rene_Surop 2007-05-07, 9:55 pm |
| >
> Assuming the above IS possible, if I write a web service in NetExpress COBOL
> and run it on my own Web Server, where do I stand with regard to run time
> fees?
>
> I have not distributed the application to a specific individual or
> organization, there is only ONE copy of it in existence, yet EVERYONE can
> access and use it...Am I expected to pay for every hit on my service?
>
> Pete.
Good question Pete.
However, Microfocus is always ahead when talking about licensing fees.
Web Services or wrapped Microfocus Cobol COM objects tied to your web
server need an Application Server runtime license.... well, what I
knew is that is it capable of handling 10users (at the start/first
buy). So basically if your Web Server is expecting to hit as much
users it can process, you have to buy "additional" licensing fees for
additional users. I do not know how are they controlling the whole
thing... but you have to pay a hefty runtime fees for your hefty user
hits. There is always a quick response for Microfocus on this issue.
The question here is, if at first you're licensed to 10users.... how
will it treat your 11th, 12th, 13th or so users at the back-end? Would
there be a queue?
Rene Surop
| |
|
| Pete Dashwood wrote:
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:gfudnS4TPYwbWaPbnZ2dnUVZ_u3inZ2d@co
mcast.com...
> I have a question, too...
>
> Assuming the above IS possible, if I write a web service in NetExpress COBOL
> and run it on my own Web Server, where do I stand with regard to run time
> fees?
Since the "runtime" is in the CLR, I don't see where MF has a dog in
that fight... :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Pete Dashwood 2007-05-07, 9:55 pm |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:ar6dnY3iIMfwSqLbnZ2dnUVZ_trinZ2d@co
mcast.com...
> Pete Dashwood wrote:
>
> Since the "runtime" is in the CLR, I don't see where MF has a dog in that
> fight... :)
I don't think this is a Dot Net Version, Daniel, although I could be wrong.
If it is indeed generating MSIL for JITing into CLR, then the runtime thing
is simply a non event. I can't see how they can charge any runtime fee for
that.
My question was based on needing to wrap their runtime so it can run as
unmanaged code in a DotNET environment.
Pete.
| |
| Alistair 2007-05-08, 6:55 pm |
| On 7 May, 14:48, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
>
> Simple Darwinism; fail to adapt, get replaced by a species that did.
Yes, but even Darwin had different explanations for the how and why
before he hit upon the final edition of the Origin of the Species.
> COBOL
> is obsolete, in the same sense that Neanderthals were obsolete once Homo
> Sapiens arrived.
Homo sapiens assimilated the Homo neanderthalensis just as the Borg
will assimilate us when they get here.
| |
| Pete Dashwood 2007-05-08, 6:55 pm |
|
"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1178651347.798594.117310@u30g2000hsc.googlegroups.com...
> On 7 May, 14:48, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
> Yes, but even Darwin had different explanations for the how and why
> before he hit upon the final edition of the Origin of the Species.
>
>
> Homo sapiens assimilated the Homo neanderthalensis just as the Borg
> will assimilate us when they get here.
>
>
And just as modern languages are assimilating the domain that was once
COBOL's.
Pete.
| |
| adestrup@gmail.com 2007-05-09, 3:55 am |
|
Pete Dashwood ha scritto:
> "Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
> news:1178651347.798594.117310@u30g2000hsc.googlegroups.com...
> And just as modern languages are assimilating the domain that was once
> COBOL's.
>
> Pete.
| |
| adestrup@gmail.com 2007-05-09, 3:55 am |
| Do you really think that C# or VB.NET are the languages of the future?
Twenty years ago I read the same things about C, C++ and VB but that
didn't happen!
What I wrote twenty years ago using VB should be almost completely
rewritten in VB.NET, without any real advantage: nothing changes from
a user's point of view, apart the need of a bigger machine, and a lot
of serious problems for the programmer.
What I wrote in COBOL twenty years ago can stay there with minor
changes, again: nothing changes from a user's point of view but, for
the programmer ... a big difference!
Apart the durability of your code there's another question which I
think shoud be considered: complexity and readability of code.
Considering a serious application (2.000 to 3.000 programs and hudreds
of thousand of code lines) I think that C#/VB/VB.NET readability and
complexity is far more difficult to maintain than COBOL.
COBOL is certainly very old in its structure; it's OO features, where
present, are not much appreciated and used by programmers; it's
graphical interface, where it exists, is not always easy to be
implemented; etc., etc.
That's all true! But I wouldn't prefer C# or VB.NET just because thier
features are easier to be implemented: what happens if MS decides to
come out with C## or VB#.NET? What about the readability of hunfreds
of thousand of code lines? What about a new ADO#.NET or things like
these?
| |
| Pete Dashwood 2007-05-09, 7:55 am |
|
<adestrup@gmail.com> wrote in message
news:1178693192.699748.101870@e65g2000hsc.googlegroups.com...
> Do you really think that C# or VB.NET are the languages of the future?
>
No, I think they are the languages of today.
It isn't about languages; it is about changing perceptions of data
processing and how information is shared and utilised. It is about a
different model and a different paradigm from procedural coding.
> Twenty years ago I read the same things about C, C++ and VB but that
> didn't happen!
Must have been wrong then... :-)
>
> What I wrote twenty years ago using VB should be almost completely
> rewritten in VB.NET, without any real advantage: nothing changes from
> a user's point of view, apart the need of a bigger machine, and a lot
> of serious problems for the programmer.
>
If nothing changes from a User's point of view then either your business is
very static or your understanding of cyber technology is very narrow. Either
way, your users are not being well served.
I disagree strongly about problems for the programmer. Today's tool set is
infinitely better than yesterday's, the languages are more efficient and
quicker and easier to write, it is almost impossible to code incorrectly
thanks to features like Intellisense, and all you have to focus on is the
logic you require. Modern software development is more like assembling LEGO
than coding a line by line solution. How is that more problematic for the
programmer?
> What I wrote in COBOL twenty years ago can stay there with minor
> changes, again: nothing changes from a user's point of view but, for
> the programmer ... a big difference!
>
Well, if the business you are in has remained static for twenty years, then
I won't argue with you. What I will say is, it is exceptional. Most
businesses need to adapt to an increasingly competitive and dynamic market
place. Fundamental to this is the rapid exchange and sharing of information
and that is why the Internet has changed the way we live and do business.
Companies that can get by without being affected are probably in niche
markets where there is not so much competition.
> Apart the durability of your code there's another question which I
> think shoud be considered: complexity and readability of code.
> Considering a serious application (2.000 to 3.000 programs and hudreds
> of thousand of code lines) I think that C#/VB/VB.NET readability and
> complexity is far more difficult to maintain than COBOL.
There is no need to maintain code at all if you opt for an object oriented,
component-based approach. I've covered this in depth here and elsewhere, on
other occasions. It is a hard concept for COBOL people to grasp.. Objects
are encapsulated and re-used. They should NOT be maintained. That is one
major difference between the OO and Procedural paradigms. It is too much to
go into here, but if you are still thinking in terms of maintaining source
code then there's little point me pursuing this.
COBOL was/is ideally suited to a procedural paradigm where source code and
the ease of maintenance of it is everything. That is not the modern idiom.
Some sites DO maintain Classes and and tinker constantly with their Java or
whatever. I don't recommend this approach and I have seen it fail in several
shops.
For my own part, I don't maintain the C# I write. It does what it does; new
functionality comes along, it inherits what is there already and extends it.
The existing source, once it is debugged and performing according to
specification does not get changed. Internals of Class libraries do not get
maintained on my watch.
>
> COBOL is certainly very old in its structure; it's OO features, where
> present, are not much appreciated and used by programmers; it's
> graphical interface, where it exists, is not always easy to be
> implemented; etc., etc.
>
> That's all true! But I wouldn't prefer C# or VB.NET just because thier
> features are easier to be implemented: what happens if MS decides to
> come out with C## or VB#.NET? What about the readability of hunfreds
> of thousand of code lines? What about a new ADO#.NET or things like
> these?
>
No problem. Classes and objects remain the same. The 80,000 or so classes
that constitute Dot NET remain the same. There may be some new ones, there
may be some new interfaces, there may be some extensions that inherit
previous methods, properties, and events, but you can bet that your code
will continue to work. Not only in MicroSoft, but on any other platforms
that implement the FCL also. (I have C# code that has run on Linux, just to
see if it would... :-))
First of all there aren't hundreds of thousands of lines of code (that you
can/must manipulate), and even if there were, that code is invoking methods
and propertiers of Classes that you don't write or maintain. They are
pieces of encapsulated functionality (functions, if you like) that you
simply glue together. (or break apart and re-use). The days of sacred source
code ruling everything are over. That was COBOL. Today, the object code
embodied in a Class Library is what matters and you won't have source for it
(unless it is your own library which you wrote yourself, of course), will
never need to have source for it, and couldn't amend it if you wanted to.
The actual source is of purely academic interest; the FUNCTIONALITY is
everything. You don't worry about the source of your Operating System, yet
you use the Classes and Objects embodied in it every day. You expect them to
work, and they do. As specified. The same is true for the Dot NET Framework.
There is no comparison between traditional procedural COBOL and a modern OO
language like C# or Java. They are different paradigms, meeting different
criteria. You might as well compare oranges and submarines...
Pete.
| |
| Rene_Surop 2007-05-10, 7:55 am |
| On May 9, 7:38 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
>
> There is no need to maintain code at all if you opt for an object oriented,
> component-based approach. I've covered this in depth here and elsewhere, on
> other occasions. It is a hard concept for COBOL people to grasp.. Objects
> are encapsulated and re-used.
>
> For my own part, I don't maintain the C# I write. It does what it does; new
> functionality comes along, it inherits what is there already and extends it.
> The existing source, once it is debugged and performing according to
> specification does not get changed. Internals of Class libraries do not get
> maintained on my watch.
>
> No problem. Classes and objects remain the same. The 80,000 or so classes
> that constitute Dot NET remain the same. There may be some new ones, there
> may be some new interfaces, there may be some extensions that inherit
> previous methods, properties, and events, but you can bet that your code
> will continue to work. Not only in MicroSoft, but on any other platforms
> that implement the FCL also. (I have C# code that has run on Linux, just to
> see if it would... :-))
>
Really Pete.
I'm a C++ programmer as well.... and coded some of sub-modules in C++,
but I still maintain it up to now. What I think is that if "new"
business process change, apparently your code changes. Even OO code
for that matter because we have to add additional parameters to thos
already coded OO application.
Haven't you tried looking at the size (in Kb) of MSVCRT.DLL module? It
did change from time to time.
| |
| Pete Dashwood 2007-05-10, 7:55 am |
|
"Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
news:1178767753.307905.221640@w5g2000hsg.googlegroups.com...
> On May 9, 7:38 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> Really Pete.
>
> I'm a C++ programmer as well.... and coded some of sub-modules in C++,
> but I still maintain it up to now. What I think is that if "new"
> business process change, apparently your code changes.
What I think is that you wrote COBOL before you wrote C++.
(This is not a criticism and is not meant to be disparaging).
> Even OO code
> for that matter because we have to add additional parameters to thos
> already coded OO application.
I don't; I use Getters and Setters and don't pass parameters, for the most
part. This means interfaces don't change.
The whole point of Object Orientation is to use objects. Objects should be
encapsulated. Mine are.
It is all very arguable and I'm sick of arguing it here, so I wont. :-)
(there have been heated debates in the OO community about use of getters and
setters; opinion is divided. I use what works for me, and I have not
maintained code for about 5 years now, despite enhancing existing live
systems.)
What I will say, is that if you code in an Object Oriented language and
still maintain code, then you are not getting all of the benefits you could
be from such an approach. All you have done is transfer an existing mind set
to a new platform.
I reckon (based on 40 years experience around the world) that most of the
errors in live systems are caused by maintaining them. If you push me I'd
say at least 85%. Sometimes knock on errors are introduced by maintenance,
that are so subtle they take considerabloe time to manifest themselves.
Often changes are introduced under pressure and stress, without being
thoroughly thought through and without being fully regression tested. Often
the person or persons making the change are not the people who wrote the
original code and don't have the benefit of the background understanding
that developers acquire by working for months/years on a system. When
systems are developed they are designed and tested thoroughly, and, for the
most part, on day one they work. It is when it needs "just this one small
change" that the trouble starts...
Systems that don't require maintenance don't require regression testing
either. Encapsulated functionality CANNOT be changed by the introduction of
change elsewhere. Everything that used to work, still works, because it
hasn't been changed. Only the new classes/methods/properties need to be
tested.
A component based approach to system engineering permits this. You don't
strip an engine down because a new starter motor was fitted.
Sure, I know it's heresy... (at least, it is to COBOL people) so burn me :-)
>
> Haven't you tried looking at the size (in Kb) of MSVCRT.DLL module? It
> did change from time to time.
>
A library size can change because new methods/properties/events are added.
Anyway, I take no responsibility for what MicroSoft do with their software
:-).
Pete.
| |
| Alistair 2007-05-10, 7:55 am |
| On 10 May, 10:42, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> I reckon (based on 40 years experience around the world) that most of the
> errors in live systems are caused by maintaining them. If you push me I'd
> say at least 85%. Sometimes knock on errors are introduced by maintenance,
> that are so subtle they take considerabloe time to manifest themselves.
Personally, I'd say that 100% of errors are caused by users wanting
systems developed and/or changed. Seriously, though, in my experience,
the majority of errors that I have encountered were created at
development/enhancement time and only a small number of errors were
introduced by maintenance work post-implementation.
> Often changes are introduced under pressure and stress, without being
> thoroughly thought through and without being fully regression tested.
True, more often than not. Often, new developments are implemented
without being adequately tested or even without being tested at all (I
remember one developer who said that he ran out of budget and put the
system live untested and anyway, wasn't it the role of the support
team to be called out in the night to fix bugs?)
> Often
> the person or persons making the change are not the people who wrote the
> original code and don't have the benefit of the background understanding
> that developers acquire by working for months/years on a system.
More often than not I would say that those who enhance/maintain
systems are rarely the saps who wrote the rubbish in the first place
(I spent the best part of 7 years enhancing/maintaining systems on a
mainframe support team where I was the only original developer and it
was obvious how little the development team knew of the systems by the
fact that they came running to me every time they had to change a line
of code to make certain that they were doing the right thing.
Effectively spending my budget doing their job).
> When
> systems are developed they are designed and tested thoroughly,
BOLLOCKS! No offence intended just I wish to express succinctly how
much I disagree with that statement (I refer you to my comments
above).
> and, for the
> most part, on day one they work.
For the most part? So, for a significant part, they don't work upon
implementation? Isn't development a cloud cuckoo-land ivory tower if
it can not produce working code?
> It is when it needs "just this one small
> change" that the trouble starts...
It is true that enhancements and maintenance can introduce errors.
This is documented as a known fact in numerous places and is drummed
into all trainees (isn't it?). However, I doubt if the introduced
error rate for maintenance or enhancements is any worse than the error
rate for green-field developments.
>
> Systems that don't require maintenance don't require regression testing
> either.
Systems that don't require computer code to be designed/written/tested/
implemented don't require regression testing either. I presume that
you mean that your much vaunted OO development source doesn't need
regression testing.
> Encapsulated functionality CANNOT be changed by the introduction of
> change elsewhere. Everything that used to work, still works, because it
> hasn't been changed. Only the new classes/methods/properties need to be
> tested.
What happens when developer A codes OO source to handle file A and
then developer B gets tasked with generalising the code to cater for
all file types, etc.?
>
> A component based approach to system engineering permits this. You don't
> strip an engine down because a new starter motor was fitted.
But you would replace the starter motor if it wasn't beefy enough to
turn the engine over.
>
> Sure, I know it's heresy... (at least, it is to COBOL people) so burn me :-)
A pleasure. When are you coming to the UK? Bugger! I just remembered
the witchcraft laws were repealed a little while ago.
>
>
>
>
> A library size can change because new methods/properties/events are added.
> Anyway, I take no responsibility for what MicroSoft do with their software
> :-).
Very wise, that would give us two reasons to burn you at the stake.
| |
| Michael Mattias 2007-05-10, 9:55 pm |
| "Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1178798582.549183.180370@q75g2000hsh.googlegroups.com...
> On 10 May, 10:42, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
> Personally, I'd say that 100% of errors are caused by users wanting
> systems developed and/or changed. Seriously, though, in my experience,
> the majority of errors that I have encountered were created at
> development/enhancement time and only a small number of errors were
> introduced by maintenance work post-implementation.
Don't forget what I consider the root cause of "maintenance-time errors" :
failure to originally design and code the application with "future
maintenance" as a criteria.
e.g, "Let's just get it working for now, we'll make a permanent fix later."
Except, "later" never happens until "next enhancement" when the exact same
thing happens. And the cycle continues.
Sometimes after 'enough' changes you just have to bite the bullet and
re-write from scratch; but creating the software originally and doing
ongning maintenance with an eye toward *future* maintenance can
dramatically the extend the "pre-write" life of the application.
MCM
| |
| Rene_Surop 2007-05-10, 9:55 pm |
| On May 10, 2:42 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
>
> A library size can change because new methods/properties/events are added.
> Anyway, I take no responsibility for what MicroSoft do with their software
> :-).
Well, that's it.... and you should be even wondering why Microsoft is
still maintaining (oops, enhancing) their old OO code.
New methods/properties/events are part of "new business process" is
it? That is what I meant by "maintenance" thingy. Apparently, (if you
really are an OO programmer) previous methods need not to be
changed... that's the concept of OO is it? And that point is taken.
When it is deployed and into production.... then it is "assumed" that
it is fully 100% functional. And again that point is taken in OO
programming.
But still you need maintenance.... to enhance it, and even worst...
look at the other method in the OO code that you need encapsulate in
your new method. Well, inheritance is provided anyway in OO right?...
so as an OO programmer, you don't have to reinvent the wheel but
instead use the existing OO methods.
Who doesn't do maintenance nowadays? Even your Ferrari need one.
| |
| Vince Coen 2007-05-10, 9:55 pm |
| Hello Arnold!
05 May 07 03:24, Arnold Trembley wrote to All:
AT> Perhaps this is the URL for the free download?
AT> http://www.microfocus.com/Resources...c/shop/index.as
AT> p
AT> Thane wrote:
[color=darkred]
Attempting to install this package I notice that it requires MS Visual Studio
2005. I have now installed MS Visual Express but the NetExpress installer
does not like it and it insists on having visual studio present.
Any one know a way around this as I cannot afford to buy VS full product?
Vince
| |
| William M. Klein 2007-05-10, 9:55 pm |
| My understanding was that the free (personal) version did NOT requires Visual
Studio - but that was because you would use the "traditional" interface rather
than the VS interface.
*IF* you have the "full-blown" Visual Studio (already), then the free Micro
Focus product will work with it.
***
What happens when you try and use the "traditional" Micro Focus interface with
the free version that you down-loaded?
--
Bill Klein
wmklein <at> ix.netcom.com
"Vince Coen" <VBCoenDespawn@btconnect.com> wrote in message
news:1178819354@f609.n257.z2.fidonet.ftn...
> Hello Arnold!
>
> 05 May 07 03:24, Arnold Trembley wrote to All:
>
> AT> Perhaps this is the URL for the free download?
>
> AT> http://www.microfocus.com/Resources...c/shop/index.as
> AT> p
>
>
> AT> Thane wrote:
>
>
> Attempting to install this package I notice that it requires MS Visual Studio
> 2005. I have now installed MS Visual Express but the NetExpress installer
> does not like it and it insists on having visual studio present.
>
> Any one know a way around this as I cannot afford to buy VS full product?
>
>
> Vince
>
>
| |
| Pete Dashwood 2007-05-11, 6:55 pm |
|
"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1178798582.549183.180370@q75g2000hsh.googlegroups.com...
> On 10 May, 10:42, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
> Personally, I'd say that 100% of errors are caused by users wanting
> systems developed and/or changed. Seriously, though, in my experience,
> the majority of errors that I have encountered were created at
> development/enhancement time and only a small number of errors were
> introduced by maintenance work post-implementation.
>
>
> True, more often than not. Often, new developments are implemented
> without being adequately tested or even without being tested at all (I
> remember one developer who said that he ran out of budget and put the
> system live untested and anyway, wasn't it the role of the support
> team to be called out in the night to fix bugs?)
>
>
> More often than not I would say that those who enhance/maintain
> systems are rarely the saps who wrote the rubbish in the first place
> (I spent the best part of 7 years enhancing/maintaining systems on a
> mainframe support team where I was the only original developer and it
> was obvious how little the development team knew of the systems by the
> fact that they came running to me every time they had to change a line
> of code to make certain that they were doing the right thing.
> Effectively spending my budget doing their job).
>
>
> BOLLOCKS! No offence intended just I wish to express succinctly how
> much I disagree with that statement (I refer you to my comments
> above).
No offence taken :-) A fine old Saxon epithet I use myself from time to
time...
Unfortunately (or fortunately, depending on your POV), I have decided not to
argue this as I really don't have time and it doesn't matter anyway.
Besides, I doubt that minds are likely to be changed :-)
Obviously, the opinions expressed by me are based on my experience. That
experience is broad, but certainly not infallible. If you are used to
working in places where systems are rushed into production and not designed
and developed properly, then I sympathise. In most of the roles I perform,
part of responsibility for that deployment rests with me, so I tend to
ensure it is done properly.
>
>
> For the most part? So, for a significant part, they don't work upon
> implementation? Isn't development a cloud cuckoo-land ivory tower if
> it can not produce working code?
Yes. You might ask yourself why you'd want to be part of it :-)
>
>
> It is true that enhancements and maintenance can introduce errors.
> This is documented as a known fact in numerous places and is drummed
> into all trainees (isn't it?). However, I doubt if the introduced
> error rate for maintenance or enhancements is any worse than the error
> rate for green-field developments.
>
It is in my experience... There is budget and spotlight on developing
systems; enhancing and changing them is very much a poor relation, relegated
to the dead of night very often and with little acknowledgement. All too
often, a thankless task.
>
> Systems that don't require computer code to be designed/written/tested/
> implemented don't require regression testing either. I presume that
> you mean that your much vaunted OO development source doesn't need
> regression testing.
Yes, your presumption is accurate :-)
>
>
> What happens when developer A codes OO source to handle file A and
> then developer B gets tasked with generalising the code to cater for
> all file types, etc.?
Doesn't happen. Developer A wrote a class to handle file A. If it could be
generalised he would have done so. If not, then any new requirements to
access similar files can inherit from class A where appropriate, or will
require a new class if not. What DOESN'T happen is for someone to tinker
with Class A in the hope of changing it's functionality. Class A has not
changed; the applications which use it don't need to change.
>
>
> But you would replace the starter motor if it wasn't beefy enough to
> turn the engine over.
Sure. Either way you don't strip the engine down. That was my point.
>
>
> A pleasure. When are you coming to the UK? Bugger! I just remembered
> the witchcraft laws were repealed a little while ago.
>
I'll be deciding at the end of this month... I'll be the one coming through
Heathrow in the pointy hat... :-)
[color=darkred]
>
> Very wise, that would give us two reasons to burn you at the stake.
>
>
Pete.
| |
|
| In article <5akdn1F2pfa6pU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:f21d9t$o1q$1@reader2.panix.com...
>
>Not a gambit, a simple statement of fact. I wish I had more time to spend
>here; I don't.
Of course, of course... it should have been obvious.
[smip]
>
>As mentioned by someone else previously.... BOLLOCKS!
Mr Dashwood, my memory is, admittedly, porous... but I believe this very
topic has been discussed previously and that was not your response.
>
>Yes and no. It certainly didn't go in where I was working, but I beleive it
>did in other places.
So... what you were working on you know did not... but you have a belief
about places you did not work.
[snip]
>If you are suggesting that systems should always be implemented, even when
>circumstances change, that is a very hard position to defend.
That is not what I intended to suggest at all, Mr Dashwood.
[snip]
>Certainly, it has not been my experience that systems NORMALLY get
>cancelled.
And something outside of your experience is to be met with a capitalised
Anglo-Saxon term indicating disbelief? Moderately provincial, perhaps.
>
>
>
>Hobby horse time again? Excuse me while I snooze...zzzzzzzzzzzzzzzzzzzzz
Fainting has been seen as a response to a situation too threatening to
deal with... perhaps snoozing might, as well.
>[snipped tedious, cynical rehash of ideas that have been done to death here
>many times]
Mr Dashwood, you relate your experiences, I relate mine... are you saying
that the situation I proposed, the one you could not bear to consider and
had to excise, does not exist?
>Oh very droll... having a bad period are we?
Just pointing out a bit of imprecision in the language, Mr Dashwood... 'in
the pointy hat' can refer to either 'I' or 'Heathrow'. Let me offer my
apologies for being excessively subtle.
DD
| |
| Alistair 2007-05-13, 6:55 pm |
| On 6 May, 08:22, Wolfgang Dephoff <w.deph...@dephoff.com> wrote:
> LX-i wrote:
>
>
>
> When you carefully read the readme file, you read:
>
> "You are limited to 2200 lines of procedural code in each source file"
>
> I think, that this means a "Procedure division" of up to 2200 lines, all
> other divisions are not "procedural code". Am I right ?
>
> Wolfgang Dephoff
I once examined program sizes for a site where I worked and found that
the majority of programs were less than 2000 lines (procedure) in
size. So the procedure code restriction should not be a problem.
To be trite about it (and use a management-ism that PD would be proud
of),
I see no problems, only opportunities.
| |
| Alistair 2007-05-13, 6:55 pm |
| On 12 May, 00:48, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> <docdw...@panix.com> wrote in messagenews:f21d9t$o1q$1@reader2.panix.com...
>
> As mentioned by someone else previously.... BOLLOCKS!
When quoting others, please make proper attribution.
| |
| Vince Coen 2007-05-13, 6:55 pm |
| Hello Rene_Surop!
11 May 07 07:26, Rene_Surop wrote to All:
[color=darkred]
RS> Try to install the downloaded setup again. But this time when the
RS> installation modules are displayed, DO NOT select the .NET support
RS> module. Here are the steps:
Thanks, that cracked it.
Now to try running NE without getting fatal error messages.
Vince
| |
| James J. Gavan 2007-05-13, 6:55 pm |
| Vince Coen wrote:
> Hello Rene_Surop!
>
> 11 May 07 07:26, Rene_Surop wrote to All:
>
>
>
> RS> Try to install the downloaded setup again. But this time when the
> RS> installation modules are displayed, DO NOT select the .NET support
> RS> module. Here are the steps:
>
> Thanks, that cracked it.
>
> Now to try running NE without getting fatal error messages.
To try and avoid those fatal errors, take a look at Exception Handling.
I doubt Personal Addition has its own on-line manuals; they are probably
the same as the standard set for N/E V 5.0.
Jimmy
| |
| James J. Gavan 2007-05-13, 6:55 pm |
| James J. Gavan wrote:
> Vince Coen wrote:
>
>
>
> To try and avoid those fatal errors, take a look at Exception Handling.
> I doubt Personal Addition has its own on-line manuals; they are probably
> the same as the standard set for N/E V 5.0.
>
> Jimmy
Oops ! 'Personal Addition' ? I guess I was thinking 'phonetically' :-)
| |
| Alistair 2007-05-15, 6:55 pm |
| On 14 May, 01:27, "Vince Coen" <VBCoenDesp...@btconnect.com> wrote:
> Hello Rene_Surop!
>
> 11 May 07 07:26, Rene_Surop wrote to All:
>
>
> RS> Try to install the downloaded setup again. But this time when the
> RS> installation modules are displayed, DO NOT select the .NET support
> RS> module. Here are the steps:
>
> Thanks, that cracked it.
>
> Now to try running NE without getting fatal error messages.
>
> Vince
Vince: did you get a work order number and serial number to be entered
at install time? I'm still waiting for mine (enraged email sent to MF
as yet no reply received).
| |
| Vince Coen 2007-05-16, 7:55 am |
| Mime-Version: 1.0
Content-Type: text/plain; charset=cp437
Content-Transfer-Encoding: 8bit
X-Newsreader: GoldED+ 1.1.5 (Linux 2.6.17-14mdv i686)
X-FTN-CHRS: LATIN-1 2
X-FTN-MSGID: 2:257/609@fidonet 464adbec
X-FTN-PID: GED+LNX 1.1.5
REPLY: w5g2000hsg.googlegroups.com 966215d0
Sender: "Vince Coen" <VBCoenDespawn@btconnect.com>
X-FTN-AREA: COMP.LANG.COBOL
X-FTN-TID: MBSE-FIDO 0.91.1 (GNU/Linux-i386)
X-FTN-SEEN-BY: 257/0 3 609
X-FTN-PATH: 257/609
Cache-Post-Path: ntop.griffin.com!unknown@213.177.251.130.adsl.griffin.net.uk
X-Cache: nntpcache 3.0.2 (see http://www.nntpcache.com/)
X-Complaints-To: abuse@supernews.com
Lines: 16
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:164671
Hello Alistair!
15 May 07 10:49, Alistair wrote to All:
[color=darkred]
A> Vince: did you get a work order number and serial number to be entered
A> at install time? I'm still waiting for mine (enraged email sent to MF
A> as yet no reply received).
Nope only got the email confirming order but I had downloaded the s/w anyway.
Vince
| |
| Alistair 2007-05-16, 6:55 pm |
| On 16 May, 19:23, "Vince Coen" <VBCoenDesp...@btconnect.com> wrote:
> Hello Alistair!
>
> 15 May 07 10:49, Alistair wrote to All:
>
>
> A> Vince: did you get a work order number and serial number to be entered
> A> at install time? I'm still waiting for mine (enraged email sent to MF
> A> as yet no reply received).
>
> Nope only got the email confirming order but I had downloaded the s/w anyway.
>
> Vince
If it worked for you then I shall give it another go.
| |
|
|
| Alistair 2007-05-17, 6:55 pm |
| On 11 May, 04:11, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> "Alistair" <alist...@ld50macca.demon.co.uk> wrote in message
>
>
> No offence taken :-) A fine old Saxon epithet I use myself from time to
> time...
>
Not bad for a blue-arsed Pict, eh?
| |
| Alistair 2007-05-17, 6:55 pm |
| On 16 May, 15:00, Alistair <alist...@ld50macca.demon.co.uk> wrote:
> On 16 May, 19:23, "Vince Coen" <VBCoenDesp...@btconnect.com> wrote:
>
>
>
>
>
>
>
> If it worked for you then I shall give it another go.
Just to let people know: despite the readme being useless and the
licence screen stating that a Works Order Number and a Serial Number
are required to get a full Licence number, they aren't required at
all.
| |
| James J. Gavan 2007-05-17, 6:55 pm |
| Alistair wrote:
> On 16 May, 15:00, Alistair <alist...@ld50macca.demon.co.uk> wrote:
>
>
>
> Just to let people know: despite the readme being useless and the
> licence screen stating that a Works Order Number and a Serial Number
> are required to get a full Licence number, they aren't required at
> all.
>
So now you've got it downloaded what are you going to do with it, (a)
Procedural, (b) OO COBOL without .Net or (c) OO COBOL and .Net ?
Did you ever get a second-hand copy of Arranga/Coyle from amazon.com for
about $20 ?
As stated previously, they , (Arranga/Coyle), have a small application
trying to address as many OO features as possible. (It is an in-house
library application for corporate staff to borrow books and videos, and
you pay fines if returns are late back). To simplify comprehension they
did the following :-
- No GUIs or Screen Section - substituted straight ANSI displays
- File records are held in W/S Data Tables
Unfortunately a lot of typing involved, (I never had luck getting either
author to produce the diskette containing their source). Type it up and
it should work fine in V 5.0 without .Net. With .Net the *first* change
is that you rename FACTORY to read STATIC.
If you go .Net route, can't help you much without I also download the
Personal Edition - but of course I would then need to buy Visual Studio,
plus get a handle on the 'system.calls' associated with C#, and learn C#.
Now if you want to type the source as is, (brave man :-) ) - leave out
the comment statements, so that it runs solely in an OO COBOL
environment, pass me the stuff as a zip file and I'll spruce it up,
(dropping a lot of the 'red tape', which makes it more readable), plus I
could add COBOL files/SQL Tables or both (?) to replace the W/S Data
Tables. The ANSI displays could be turned into Screen Section or a
simple GUI set.
If you get it working in OO COBOL without .Net then it shouldn't be a
major change to dabble and switch it to .Net later, using .BASIC say to
replace Screen Section or GUI classes.
You've got bugger all else to do - so start typing :-)
Jimmy
|
|
|
|
|