COBOL Compiler for Windows - cobol

This is a discussion on COBOL Compiler for Windows - cobol ; "Graham Hobbs" <ghobbs@cdpwise.net> wrote in message news:nb3h141500phmuq82nj3buhtmo5ibr3sfp@4ax.com... > Hello, > Thanks for the responses. Learning all the time. > Not only 'not like the price', 'havent got the money'. > Hercules! For me, a whole new line of research, maybe ...

+ Reply to Thread
Page 3 of 10 FirstFirst 1 2 3 4 5 ... LastLast
Results 21 to 30 of 100

COBOL Compiler for Windows

  1. Default Re: COBOL Compiler for Windows



    "Graham Hobbs" <ghobbs@cdpwise.net> wrote in message
    news:nb3h141500phmuq82nj3buhtmo5ibr3sfp@4ax.com...
    > Hello,
    > Thanks for the responses. Learning all the time.
    > Not only 'not like the price', 'havent got the money'.
    > Hercules! For me, a whole new line of research, maybe later.
    > MF not MS, sorry.
    > Pete, thanks for the history.
    > Bill Klein asked for more explanation so ..
    >
    > Bill,
    > Am retired so have no EMPLOYER and cost is a serious factor especially
    > for a project that today might be dubious saleability.


    Ah, Glasshopper, truly the journey is often more important than the
    destination... :-)

    >
    > Until a year ago I had an old IBM compiler (VA Cobol V2.2) that runs
    > on an old laptop under Windows NT plus DB2 V7.2, CICS for Windows 3.1
    > and VSAM KSDS via Pervasive's bTrieve, all 1990's vintage. On this
    > laptop I'm developing a software package written in batch Cobol that
    > generates Cobol/CICS programs (dinosaurial as it may seem, have gone
    > too far to stop). The package is aimed at any platform that runs CICS,
    > especially these days it seems, z/OS.
    >
    > So the V2.2 compiler I have performs two functions, a) compile/produce
    > executables of the batch pgms of my software, b) compile/produce
    > executables for the online Cobol/CICS pgms that my software generates.
    >
    > The old NT laptop grew old, slow and full so I bought a new one. It
    > won't accept NT so I opted for Windows XP. My CICS and DB2 work fine
    > thereon. The Cobol fails horribly and no fixes available.


    Graham, have you tried running the compiler in "compatibility mode" on XP?

    Right click the icon you use to run COBOL. (If you are running it from a
    command line, create a shortcut to it and place that on your desktop so you
    have an icon.) A drop down menu opens up. The bottom option is "Properties".
    Click this and then click the "Compatibility" tab. You will find an option
    there to run your application (in this case, your COBOL compiler) in NT
    compatibility mode. XP creates an environment to run the application, that
    emulates whichever environment you select.

    It doesn't always work, but it usually does...

    >
    > Today the XP laptop has NT running under Microsoft's Virtual PC thus
    > some of my development can continue on the NT side.
    >
    > But the ultimate intent is to email pgms between myself and clients.
    > Technically this must be done on the XP side while compilations etc
    > must be done on the NT side - is labour intensive and 'almost'
    > impractical.
    >
    > Thus the need for a free/cheap XP Cobol compiler that accepts CICS and
    > DB2 commands and produces working executables - in essence goodbye NT.
    >
    > As you said mainframe emulators are expensive (unless my government
    > will give me a grant :-000)))(still choice 1), PWD might be amenable
    > (choice 2), a Cobol compiler NT to XP fix was available (choice 3),
    > whatelse?.
    >
    > So In contacting the group, I am really looking at the 'whatelse'
    > scenario. Hope that better explains my situation.
    > Any help appreciated. Thanks
    > Graham


    I sincerely wish you luck with your enterprise.

    Anything that generates code gets my vote :-)

    Let us know how you get on.

    Pete.
    --
    "I used to write COBOL...now I can do anything."

    <previous snipped>



  2. Default Re: COBOL Compiler for Windows

    On Thu, 1 May 2008 10:55:04 +1200, "Pete Dashwood"
    <dashwood@removethis.enternet.co.nz> wrote:

    >
    >
    >"Graham Hobbs" <ghobbs@cdpwise.net> wrote in message
    >news:nb3h141500phmuq82nj3buhtmo5ibr3sfp@4ax.com...
    >> Hello,
    >> Thanks for the responses. Learning all the time.
    >> Not only 'not like the price', 'havent got the money'.
    >> Hercules! For me, a whole new line of research, maybe later.
    >> MF not MS, sorry.
    >> Pete, thanks for the history.
    >> Bill Klein asked for more explanation so ..
    >>
    >> Bill,
    >> Am retired so have no EMPLOYER and cost is a serious factor especially
    >> for a project that today might be dubious saleability.

    >
    >Ah, Glasshopper, truly the journey is often more important than the
    >destination... :-)
    >
    >>
    >> Until a year ago I had an old IBM compiler (VA Cobol V2.2) that runs
    >> on an old laptop under Windows NT plus DB2 V7.2, CICS for Windows 3.1
    >> and VSAM KSDS via Pervasive's bTrieve, all 1990's vintage. On this
    >> laptop I'm developing a software package written in batch Cobol that
    >> generates Cobol/CICS programs (dinosaurial as it may seem, have gone
    >> too far to stop). The package is aimed at any platform that runs CICS,
    >> especially these days it seems, z/OS.
    >>
    >> So the V2.2 compiler I have performs two functions, a) compile/produce
    >> executables of the batch pgms of my software, b) compile/produce
    >> executables for the online Cobol/CICS pgms that my software generates.
    >>
    >> The old NT laptop grew old, slow and full so I bought a new one. It
    >> won't accept NT so I opted for Windows XP. My CICS and DB2 work fine
    >> thereon. The Cobol fails horribly and no fixes available.

    >
    >Graham, have you tried running the compiler in "compatibility mode" on XP?
    >
    >Right click the icon you use to run COBOL. (If you are running it from a
    >command line, create a shortcut to it and place that on your desktop so you
    >have an icon.) A drop down menu opens up. The bottom option is "Properties".
    >Click this and then click the "Compatibility" tab. You will find an option
    >there to run your application (in this case, your COBOL compiler) in NT
    >compatibility mode. XP creates an environment to run the application, that
    >emulates whichever environment you select.
    >
    >It doesn't always work, but it usually does...


    It didn't.

    Not only that, but later found out that installing the Cobol software
    on XP destroyed access to XP Help. I didn't hang around long enough to
    see what else got shafted. Had to reload the OS.

    1990's VA Cobol is a very nice virus for XP but I dont thionk either
    IBM or MS had this in mind:-)

    But thanks for the thought.
    >>
    >> Today the XP laptop has NT running under Microsoft's Virtual PC thus
    >> some of my development can continue on the NT side.
    >>
    >> But the ultimate intent is to email pgms between myself and clients.
    >> Technically this must be done on the XP side while compilations etc
    >> must be done on the NT side - is labour intensive and 'almost'
    >> impractical.
    >>
    >> Thus the need for a free/cheap XP Cobol compiler that accepts CICS and
    >> DB2 commands and produces working executables - in essence goodbye NT.
    >>
    >> As you said mainframe emulators are expensive (unless my government
    >> will give me a grant :-000)))(still choice 1), PWD might be amenable
    >> (choice 2), a Cobol compiler NT to XP fix was available (choice 3),
    >> whatelse?.
    >>
    >> So In contacting the group, I am really looking at the 'whatelse'
    >> scenario. Hope that better explains my situation.
    >> Any help appreciated. Thanks
    >> Graham

    >
    >I sincerely wish you luck with your enterprise.
    >
    >Anything that generates code gets my vote :-)
    >
    >Let us know how you get on.
    >
    >Pete.


    ** Posted from http://www.teranews.com **

  3. Default Re: COBOL Compiler for Windows


    "Graham Hobbs" <ghobbs@cdpwise.net> wrote in message
    news:nb3h141500phmuq82nj3buhtmo5ibr3sfp@4ax.com...
    > Hello,
    > Thanks for the responses. Learning all the time.
    > Not only 'not like the price', 'havent got the money'.
    > Hercules! For me, a whole new line of research, maybe later.
    > MF not MS, sorry.
    > Pete, thanks for the history.
    > Bill Klein asked for more explanation so ..
    >
    > Bill,
    > Am retired so have no EMPLOYER and cost is a serious factor especially
    > for a project that today might be dubious saleability.
    >
    > Until a year ago I had an old IBM compiler (VA Cobol V2.2) that runs
    > on an old laptop under Windows NT plus DB2 V7.2, CICS for Windows 3.1
    > and VSAM KSDS via Pervasive's bTrieve, all 1990's vintage. On this
    > laptop I'm developing a software package written in batch Cobol that
    > generates Cobol/CICS programs (dinosaurial as it may seem, have gone
    > too far to stop). The package is aimed at any platform that runs CICS,
    > especially these days it seems, z/OS.
    >
    > So the V2.2 compiler I have performs two functions, a) compile/produce
    > executables of the batch pgms of my software, b) compile/produce
    > executables for the online Cobol/CICS pgms that my software generates.
    >
    > The old NT laptop grew old, slow and full so I bought a new one. It
    > won't accept NT so I opted for Windows XP. My CICS and DB2 work fine
    > thereon. The Cobol fails horribly and no fixes available.
    >
    > Today the XP laptop has NT running under Microsoft's Virtual PC thus
    > some of my development can continue on the NT side.
    >
    > But the ultimate intent is to email pgms between myself and clients.
    > Technically this must be done on the XP side while compilations etc
    > must be done on the NT side - is labour intensive and 'almost'
    > impractical.
    >
    > Thus the need for a free/cheap XP Cobol compiler that accepts CICS and
    > DB2 commands and produces working executables - in essence goodbye NT.
    >
    > As you said mainframe emulators are expensive (unless my government
    > will give me a grant :-000)))(still choice 1), PWD might be amenable
    > (choice 2), a Cobol compiler NT to XP fix was available (choice 3),
    > whatelse?.
    >
    > So In contacting the group, I am really looking at the 'whatelse'
    > scenario. Hope that better explains my situation.
    > Any help appreciated. Thanks
    > Graham



    How about using MS Virtual PC 2007 or VMware etc and running NT uder that?

    See: http://www.pcmag.com/article2/0,2817,2099563,00.asp



  4. Default Re: COBOL Compiler for Windows

    On Wed, 30 Apr 2008 19:01:36 +0100, Frederico Fonseca
    <real-email-in-msg-spam@email.com> wrote:

    >On Wed, 30 Apr 2008 11:30:08 -0400, Graham Hobbs <ghobbs@cdpwise.net>
    >wrote:
    >
    >>Hello,
    >>Thanks for the responses. Learning all the time.
    >>Not only 'not like the price', 'havent got the money'.
    >>Hercules! For me, a whole new line of research, maybe later.
    >>MF not MS, sorry.
    >>Pete, thanks for the history.
    >>Bill Klein asked for more explanation so ..
    >>
    >>Bill,
    >>Am retired so have no EMPLOYER and cost is a serious factor especially
    >>for a project that today might be dubious saleability.
    >>
    >>Until a year ago I had an old IBM compiler (VA Cobol V2.2) that runs
    >>on an old laptop under Windows NT plus DB2 V7.2, CICS for Windows 3.1
    >>and VSAM KSDS via Pervasive's bTrieve, all 1990's vintage. On this
    >>laptop I'm developing a software package written in batch Cobol that
    >>generates Cobol/CICS programs (dinosaurial as it may seem, have gone
    >>too far to stop). The package is aimed at any platform that runs CICS,
    >>especially these days it seems, z/OS.
    >>
    >>So the V2.2 compiler I have performs two functions, a) compile/produce
    >>executables of the batch pgms of my software, b) compile/produce
    >>executables for the online Cobol/CICS pgms that my software generates.
    >>
    >>The old NT laptop grew old, slow and full so I bought a new one. It
    >>won't accept NT so I opted for Windows XP. My CICS and DB2 work fine
    >>thereon. The Cobol fails horribly and no fixes available.
    >>
    >>Today the XP laptop has NT running under Microsoft's Virtual PC thus
    >>some of my development can continue on the NT side.
    >>
    >>But the ultimate intent is to email pgms between myself and clients.
    >>Technically this must be done on the XP side while compilations etc
    >>must be done on the NT side - is labour intensive and 'almost'
    >>impractical.
    >>
    >>Thus the need for a free/cheap XP Cobol compiler that accepts CICS and
    >>DB2 commands and produces working executables - in essence goodbye NT.
    >>
    >>As you said mainframe emulators are expensive (unless my government
    >>will give me a grant :-000)))(still choice 1), PWD might be amenable
    >>(choice 2), a Cobol compiler NT to XP fix was available (choice 3),
    >>whatelse?.
    >>
    >>So In contacting the group, I am really looking at the 'whatelse'
    >>scenario. Hope that better explains my situation.
    >>Any help appreciated. Thanks
    >>Graham
    >>

    >Have you looked at
    >http://www-1.ibm.com/support/docview...id=swg21104993
    >
    >Not sure if this relates to your problem, as you havent specified it.
    >
    >
    >I can't test it myself as I dont have VA COBOL. If this is a free
    >version, then I would not mind testing it myself if you wish and
    >supply it to me.
    >
    >
    >
    >Frederico Fonseca
    >ema il: frederico_fonseca at syssoft-int.com


    Hello Frederico,

    Thanks for your help.

    I tried that website a long time ago, besides trying Pete Dashwood's
    suggestion of compatability mode.Neither worked for reasons I cant
    fully remember but certainly included, install OK, compile OK, pgm
    execution gave Dr Watsin stuff (EVERY pgm).

    It was never free, I got Cobol & CICS for $2200 way back then and
    while I'd love for you to try it, you'd be very unhappy if what
    happens is what I think will happen which is ..

    After the install XP's Help and Support feature ceased working; click
    on it and nothing happens. My retail dealer and I proved it. How could
    you ever know whatelse VA Cobol had done to the OS.And is Help &
    Support just the tip of the iceberg?

    ** Posted from http://www.teranews.com **

  5. Default Re: COBOL Compiler for Windows

    On Wed, 30 Apr 2008 19:47:25 -0400, "Charles Hottel"
    <chottel@earthlink.net> wrote:

    >
    >"Graham Hobbs" <ghobbs@cdpwise.net> wrote in message
    >news:nb3h141500phmuq82nj3buhtmo5ibr3sfp@4ax.com...
    >> Hello,
    >> Thanks for the responses. Learning all the time.
    >> Not only 'not like the price', 'havent got the money'.
    >> Hercules! For me, a whole new line of research, maybe later.
    >> MF not MS, sorry.
    >> Pete, thanks for the history.
    >> Bill Klein asked for more explanation so ..
    >>
    >> Bill,
    >> Am retired so have no EMPLOYER and cost is a serious factor especially
    >> for a project that today might be dubious saleability.
    >>
    >> Until a year ago I had an old IBM compiler (VA Cobol V2.2) that runs
    >> on an old laptop under Windows NT plus DB2 V7.2, CICS for Windows 3.1
    >> and VSAM KSDS via Pervasive's bTrieve, all 1990's vintage. On this
    >> laptop I'm developing a software package written in batch Cobol that
    >> generates Cobol/CICS programs (dinosaurial as it may seem, have gone
    >> too far to stop). The package is aimed at any platform that runs CICS,
    >> especially these days it seems, z/OS.
    >>
    >> So the V2.2 compiler I have performs two functions, a) compile/produce
    >> executables of the batch pgms of my software, b) compile/produce
    >> executables for the online Cobol/CICS pgms that my software generates.
    >>
    >> The old NT laptop grew old, slow and full so I bought a new one. It
    >> won't accept NT so I opted for Windows XP. My CICS and DB2 work fine
    >> thereon. The Cobol fails horribly and no fixes available.
    >>
    >> Today the XP laptop has NT running under Microsoft's Virtual PC thus
    >> some of my development can continue on the NT side.
    >>
    >> But the ultimate intent is to email pgms between myself and clients.
    >> Technically this must be done on the XP side while compilations etc
    >> must be done on the NT side - is labour intensive and 'almost'
    >> impractical.
    >>
    >> Thus the need for a free/cheap XP Cobol compiler that accepts CICS and
    >> DB2 commands and produces working executables - in essence goodbye NT.
    >>
    >> As you said mainframe emulators are expensive (unless my government
    >> will give me a grant :-000)))(still choice 1), PWD might be amenable
    >> (choice 2), a Cobol compiler NT to XP fix was available (choice 3),
    >> whatelse?.
    >>
    >> So In contacting the group, I am really looking at the 'whatelse'
    >> scenario. Hope that better explains my situation.
    >> Any help appreciated. Thanks
    >> Graham

    >
    >
    >How about using MS Virtual PC 2007 or VMware etc and running NT uder that?
    >
    >See: http://www.pcmag.com/article2/0,2817,2099563,00.asp
    >

    Charles
    I do exactly that right now via Virtual PC but my 'project' is too
    severely handicapped to continue this way. My NT CICS is 10 years old
    and doesn't have the CICS Web features, CTG, etc I will eventually
    need.
    Cheers
    Graham
    ** Posted from http://www.teranews.com **

  6. Default Re: COBOL Compiler for Windows

    On Wed, 30 Apr 2008 10:58:52 -0600, Howard Brazee <howard@brazee.net> wrote:

    >On Thu, 1 May 2008 02:56:51 +1200, "Pete Dashwood"
    ><dashwood@removethis.enternet.co.nz> wrote:
    >
    >>> It's not free, though. It's not even cheap. Emulating the mainframe
    >>> operating environment is not trivial.

    >>
    >>Sure it is.
    >>
    >>But the people who want it are used to paying through the nose so why
    >>disappoint them?
    >>
    >>One day the mainframe world will wake up to the fact that they have a
    >>choice. There WAS a time when mainframe hardware was the only game in town
    >>and vendors (both hardware and software) could charge anything they liked.

    >
    >Why should they worry about emulating the mainframe environment on a
    >PC?
    >
    >The future of mainframes is as a component in the system. It will be
    >the database full of security rules and powerful behind-the-scenes
    >action. There is no reason to duplicate real data on PCs (security
    >audits will make sure we don't), nor to create allowable test data.
    >The DBAs and systems people will handle that component, just as the
    >network people handle the routers and ports.


    Unix database servers are already doing the same, cheaper.

    For example, Sabre (airline reservations, Travelocity) cut its total expenses 50% when it
    switched from mainframe to Unix. It handles 15,000 transactions per second. The database
    resides on 17 HP S86000 boxes (now obsolete).

    For example, US telephone networks run entirely on Unix machines. About 10 servers handle
    200,000 transactions (calls) per second. Each transaction creates at least one database
    row.

    For example, PULSE, the largest ATM/EFT clearing system in the US, runs entirely on Unix
    servers.

    "The base zSeries 990-332 machine, without disk and memory, costs around $15 million. If
    you had to beef it up with an appropriate amount of memory and disk, the mainframe
    hardware might cost $30 million. If you have to add monthly software fees for three years
    to this machine, it is probably on the order of $50 million for this machine over three
    years, including maintenance. Mainframes don't have list prices--which used to be against
    the law for IBM--so it is hard to say for sure. Even if you assume a 50 percent discount,
    after adding in the software costs, you are talking about $55 per TPM. That's a 10 to 1
    price premium. And it will get worse as the Power6 and Power7 generations roll out, unless
    IBM consolidates the zSeries into one of these future Power-based servers. And that is why
    many people believe IBM will do just that, as it has already done with its proprietary
    OS/400-based servers."

    http://www.itjungle.com/tug/tug120204-story02.html

  7. Default Re: COBOL Compiler for Windows

    On Thu, 1 May 2008 10:39:46 +1200 "Pete Dashwood"
    <dashwood@removethis.enternet.co.nz> wrote:

    :>Most people consider these factors to be unique to mainframes:

    :>1. Huge processing power.
    :>2. Stability and security.
    :>3. Traditional proven development methodology, perfect for batch processing.

    :>To obtain these benefits, many sites are happy to pay the much higher costs
    :>of hardware/software and the support teams necessary to keep them running.
    :>(They have been conditioned to over years by vendors, ever since the days
    :>when the mainframe was the only game in town.) But I think it is being
    :>questioned now.

    :>The latest top end Network servers can compete very favourably on point 1.
    :>And even though the price of mainframes has fallen, the servers are much
    :>cheaper and can be more easily configured and reconfigured and redeployed in
    :>ways to suit the Business.

    You have to define "huge processing power". Many chips run faster than those
    on mainframes.

    They can parallel process huge amounts of data.

    :>Point 2 is largely an illusion. Certainly, there are no viruses on
    :>mainframes, but there will be once they are opened up to the network; it is
    :>only a matter of time. (No, I don't have mainframe virus writing on my
    :>"TODO" list, but it would be an "interesting" exercise... :-)).

    Spoken like a true PC expert, who has no problem with reboots. So much so,
    that they do it multiple times a day.

    Point two is really 5 9s.

    The reliability of mainframes and their components are such that failures can
    be tolerated with fallover, so that the end users are not even aware that a
    component has failed.

    Mainframes regularly run months without rebooting. And that is with CPU 95%+
    busy much of the time.

    Point three is so meaningless that it isn't even worth addressing.

    --
    Binyamin Dissen <bdissen@dissensoftware.com>
    http://www.dissensoftware.com

    Director, Dissen Software, Bar & Grill - Israel


    Should you use the mailblocks package and expect a response from me,
    you should preauthorize the dissensoftware.com domain.

    I very rarely bother responding to challenge/response systems,
    especially those from irresponsible companies.

  8. Default Re: COBOL Compiler for Windows

    On Apr 28, 12:31 pm, amir <ahsha...@gmail.com> wrote:
    > Dear All,
    > I am looking for a Free COBOL IDE and Compiler for Windows XP.
    > Regards,



    You can use Open Cobol (compiled on cygwin) and using UltraEdit or
    Notepad++ for viewing your code.

    You can also create a editor using synedit component with your
    'specific' common word used by cobol.

    Kr,
    gilles

  9. Default Re: COBOL Compiler for Windows



    "Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
    news:iu0j14p6qu5vcaj726itutemuaimqvpta8@4ax.com...
    > On Thu, 1 May 2008 10:39:46 +1200 "Pete Dashwood"
    > <dashwood@removethis.enternet.co.nz> wrote:
    >
    > :>Most people consider these factors to be unique to mainframes:
    >
    > :>1. Huge processing power.
    > :>2. Stability and security.
    > :>3. Traditional proven development methodology, perfect for batch
    > processing.
    >
    > :>To obtain these benefits, many sites are happy to pay the much higher
    > costs
    > :>of hardware/software and the support teams necessary to keep them
    > running.
    > :>(They have been conditioned to over years by vendors, ever since the
    > days
    > :>when the mainframe was the only game in town.) But I think it is being
    > :>questioned now.
    >
    > :>The latest top end Network servers can compete very favourably on point
    > 1.
    > :>And even though the price of mainframes has fallen, the servers are much
    > :>cheaper and can be more easily configured and reconfigured and
    > redeployed in
    > :>ways to suit the Business.
    >
    > You have to define "huge processing power". Many chips run faster than
    > those
    > on mainframes.


    Thank you. That was my point.
    >
    > They can parallel process huge amounts of data.
    >


    Yes, they can.

    > :>Point 2 is largely an illusion. Certainly, there are no viruses on
    > :>mainframes, but there will be once they are opened up to the network; it
    > is
    > :>only a matter of time. (No, I don't have mainframe virus writing on my
    > :>"TODO" list, but it would be an "interesting" exercise... :-)).
    >
    > Spoken like a true PC expert, who has no problem with reboots. So much so,
    > that they do it multiple times a day.


    I have a Win 98 SE machine that runs 24/7. It was last rebooted 3 months
    ago. The Notebook I am writing this on (Win XP SP2) has not been booted for
    6 days (it hibernates between uses).

    The last commercial site I was managing had multiple 8 processor Xeons and
    they were cold booted twice during the year I was there.

    The last IBM mainframe system I worked on (admittedly a long time ago now),
    was rebooted every Monday morning after Preventive Maintenance.

    While I don't claim to be a PC expert, I certainly have no problem with
    rebooting ANY computer system if it needs it.


    >
    > Point two is really 5 9s.


    45...? :-)
    >
    > The reliability of mainframes and their components are such that failures
    > can
    > be tolerated with fallover, so that the end users are not even aware that
    > a
    > component has failed.


    The same is easily achievable with network servers also.
    >
    > Mainframes regularly run months without rebooting. And that is with CPU
    > 95%+
    > busy much of the time.


    So do certain networks. Your point?
    >
    > Point three is so meaningless that it isn't even worth addressing.
    >


    No, probably not. Batch processing will be redundant within your lifetime.

    So will mainframes (as we currently understand the term). The boundaries are
    becoming more and more blurred; in the end, the great mainframe con will be
    recognised for what it is, and cost effectiveness will simply win the day.

    Pete.
    --
    "I used to write COBOL...now I can do anything."



  10. Default Re: COBOL Compiler for Windows

    In article <67thq5F2p8o04U1@mid.individual.net>,
    Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

    [snip]

    >No, probably not. Batch processing will be redundant within your lifetime.


    Mr Dashwood, leaving aside the myriad of legislated requirements for batch
    reporting - and The Law, in some parts of the world, is rather gastropodic
    in its rate of change - what would a demonstration of this assertion look
    like?

    'All right, I'm dead now and folks still need batch!'

    DD


+ Reply to Thread
Page 3 of 10 FirstFirst 1 2 3 4 5 ... LastLast