Microfocus COBOL 3.2.43 (16bit)
in [Cobol]
|
From: ozzy.kopec on 27 Dec 2006 10:10 Ron wrote: > "UK-Contractor42" <lawrence.foster(a)uk.zurich.com> wrote: > > >One of my current contract tasks is to put a old, vulnerable > >application based on 16bit code on a firmer footing by researching, > >documenting and testing changes to it. > >Build architecture is Windows NT4 SP4, Microfocus COBOL 3.2.43, > > Is that even working, today? MF COBOL 3.2 wasn't Y2K compliant. > > -- ========== Version 3.2.20 L2.5 revision 000 on my end. Running in straight DOS on Win 95 machines, a few others in a DOS box under W2K. No problems dealing with Y2K. Now, when I tried to access a 8GB file on a server, that be a different story.
From: Vivian on 29 Dec 2006 12:54 We had trouble installing MicroFocus 3.2 after the year 2000, so we always assumed the install was the "reason" it wasn't year 2000 compliant. As a result, we did our last release in 16-bit that year (2000), and moved to a newer version of MicroFocus. So, how "recent" is the "recent" experience you're asking about? I still have a complete set of the 3.2 manuals, they were hardcopies at the time. I still, occasionally, reference them, because the basic Cobol features and functions really haven't changed. We moved to 32-bit simply by changing our MicroFocus compiler. There weren't any code changes needed. So, I wonder, why would you stay with the 16-bit application if you could have a 32 bit version simply by recompiling? Is there something in the code that is keeping you at 16 bit? Why not use the 32 bit MicroFocus compiler? Rick Smith wrote: > "Ron" <ron(a)address.below> wrote in message > news:rgqlo29nie1i2sqp9r6famo2tu5d0ekad7(a)4ax.com... > > "UK-Contractor42" <lawrence.foster(a)uk.zurich.com> wrote: > > > > >One of my current contract tasks is to put a old, vulnerable > > >application based on 16bit code on a firmer footing by researching, > > >documenting and testing changes to it. > > >Build architecture is Windows NT4 SP4, Microfocus COBOL 3.2.43, > > > > Is that even working, today? MF COBOL 3.2 wasn't Y2K compliant. > > Micro Focus did not, to the best of my knowledge, > state why it was not Y2K-compliant. It might have > something so rare as an attempt to install the system > beginning before the end of day 31 Dec 1999 with > completion of the installation early 1 Jan 2000 might > have failed. > > I have been using 3.2 since mid-1994 with no > Y2K-problems and all users of the application I > modified went though the year change with no > Y2K-problems.
From: HeyBub on 29 Dec 2006 20:20
Vivian wrote: > We had trouble installing MicroFocus 3.2 after the year 2000, so we > always assumed the install was the "reason" it wasn't year 2000 > compliant. As a result, we did our last release in 16-bit that year > (2000), and moved to a newer version of MicroFocus. So, how "recent" > is the "recent" experience you're asking about? I still have a > complete set of the 3.2 manuals, they were hardcopies at the time. I > still, occasionally, reference them, because the basic Cobol features > and functions really haven't changed. > > We moved to 32-bit simply by changing our MicroFocus compiler. There > weren't any code changes needed. So, I wonder, why would you stay > with the 16-bit application if you could have a 32 bit version simply > by recompiling? Is there something in the code that is keeping you > at 16 bit? Why not use the 32 bit MicroFocus compiler? 'Cause the 32-bit version costs bags and bags of bucks plus wheel-barrow loads of money for each runtime? |