[TUHS] Bell COBOL Environment?

[TUHS] Bell COBOL Environment?

[segaloco via TUHS]

Reading through [1], there are documents offered by AT&T for the "Level II COBOL" system, which some further research indicates is a product from Convergent (same folks as the UNIX PC.)  There's also the LPI-COBOL which appears to be a Language Processor Inc. product.

Are these the earliest AT&T endorsed COBOL solutions for UNIX or were there other efforts either promoted by Bell or even perhaps developed locally that were in any use before this version?  Or otherwise is there any other family of ubiquitous UNIX COBOL tools that was in use in the 70s and early 80s, before the timeframe of this document?

Additionally is anyone aware of any surviving code or binaries of either of these or other, earlier efforts at COBOL on UNIX?  I have no goal for this information in mind yet, but just gathering details at this point.  Thanks all!

- Matt G.

[1] - http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf

[TUHS] Re: Bell COBOL Environment?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 4192 bytes --]

Matt - I never had direct (user) experience with it.  I saw a demo of LPI's
product at a trade show.  It might have run on Ultrix, but if it did, I
have no memory of it being in the test suite we used for releases. Also, I
do not remember if LPI-Colbol was attached to a specific DB implementation
or not.  In those days, there were a number of them besides Ingres -
Informix, IBM's DB2, and one that started with an S - which later was sold
to Microsoft to become SQL-server to name a few, and that may have been
part of it.  But there were bundled applications for different markets
(running a dentist's office, car dealership, store, restaurant, *etc*..)
that ran on small UNIX boxes and used those DBs.

What I remember was that only a few firms were offering Cobol for UNIX (I
think that IBM, DEC, DG, and maybe NCR had them from previous OSses), but
the new generation of UNIX boxes did not - although 3rd parties like LPI
sometimes offered them.  Since it looks like AT&T is naming it/offering it
with their product, that is another example of AT&T management missing the
market.  AT&T's management (Charlie Brown) was interested in going after
IBM and probably thought that Cobol was important if they sold to IBM shops.

The problem was that except for some really large 'Big Blue' places that
never bothered tossing out Cobol (like Wall Street and some insurance
companies --* i.e.* early IBM computer users), I always thought that
writing *new code in Cobol or trying to port old code *was not done that
often because the firms that were switching from Mainframes to UNIX were
generally tossing out their homegrown applications at the same time and
replacing the entire suite with something like SAP, BAAN, or Oracle
APS that were networked, well integrated into things like PCs, used ASCII,
*etc*. - *i.e*. using the replacement as the time to really upgrade their
entire back office and possibly moving away from Big Blue based - which was
not cost-effective (particularly for smaller firms).   Another point was
the Big 8 accounting firms started offering services that used the minis
and UNIX boxes with SAP/BAAN/Oracle APS).  Finally, I may miss remembering
WRT to LPR-Cobol, but it was similar to today's Java in that it compiled
into an interpreter.  Plus, the impression I always had was that it was not
designed for practical large-scale use or performance.

BTW: this is a different behavior from the scientific world.  From mini to
supercomputers, in most cases, scientific users could not toss out their
scientific computing tools and replace them with COTS alternatives (*i.e*.,
no firm like SAP, BAAN or Oracle providing "packaged" solutions for a bank
or business). But since most of the production apps being used came with
sources or the few that were commercial (Cadum, CATIA, Ansys *etc*..), it
was possible to recompile and move things - so people did or the IVSs did.
Even today, as one of my former colleagues put it, any sr computer system
manager that ignores Fortran will eventually get fired for incompetence as
it is still #1.
ᐧ
ᐧ

On Thu, Jul 13, 2023 at 3:02 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> Reading through [1], there are documents offered by AT&T for the "Level II
> COBOL" system, which some further research indicates is a product from
> Convergent (same folks as the UNIX PC.)  There's also the LPI-COBOL which
> appears to be a Language Processor Inc. product.
>
> Are these the earliest AT&T endorsed COBOL solutions for UNIX or were
> there other efforts either promoted by Bell or even perhaps developed
> locally that were in any use before this version?  Or otherwise is there
> any other family of ubiquitous UNIX COBOL tools that was in use in the 70s
> and early 80s, before the timeframe of this document?
>
> Additionally is anyone aware of any surviving code or binaries of either
> of these or other, earlier efforts at COBOL on UNIX?  I have no goal for
> this information in mind yet, but just gathering details at this point.
> Thanks all!
>
> - Matt G.
>
> [1] -
> http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf
>

[-- Attachment #2: Type: text/html, Size: 5836 bytes --]

[TUHS] Re: Bell COBOL Environment?

[Arrigo Triulzi via TUHS]

I have a bizarre memory of running COBOL on Microsoft/SCO Xenix System V porting and translating an application for petrol pumps, of all things, from English to Italian. The license for the software was photocopied and not from either Microsoft nor SCO (not that those licenses were original either… Italy in the ‘80s…).

Having said this I might have been using the Xenix box as a terminal into something else although I doubt it as my UUCP node and my terminal were not that PC. It was ages ago and I was traumatised by both COBOL and the application. 

[TUHS] Re: Bell COBOL Environment?

[Kenneth Goodwin]

[-- Attachment #1: Type: text/plain, Size: 4451 bytes --]

Would your S database perhaps be Sybase??

It is that era of time.

On Thu, Jul 13, 2023, 4:35 PM Clem Cole <clemc@ccc.com> wrote:

> Matt - I never had direct (user) experience with it.  I saw a demo of
> LPI's product at a trade show.  It might have run on Ultrix, but if it did,
> I have no memory of it being in the test suite we used for releases. Also,
> I do not remember if LPI-Colbol was attached to a specific DB
> implementation or not.  In those days, there were a number of them besides
> Ingres - Informix, IBM's DB2, and one that started with an S - which later
> was sold to Microsoft to become SQL-server to name a few, and that may have
> been part of it.  But there were bundled applications for different markets
> (running a dentist's office, car dealership, store, restaurant, *etc*..)
> that ran on small UNIX boxes and used those DBs.
>
> What I remember was that only a few firms were offering Cobol for UNIX (I
> think that IBM, DEC, DG, and maybe NCR had them from previous OSses), but
> the new generation of UNIX boxes did not - although 3rd parties like LPI
> sometimes offered them.  Since it looks like AT&T is naming it/offering it
> with their product, that is another example of AT&T management missing the
> market.  AT&T's management (Charlie Brown) was interested in going after
> IBM and probably thought that Cobol was important if they sold to IBM shops.
>
> The problem was that except for some really large 'Big Blue' places that
> never bothered tossing out Cobol (like Wall Street and some insurance
> companies --* i.e.* early IBM computer users), I always thought that
> writing *new code in Cobol or trying to port old code *was not done that
> often because the firms that were switching from Mainframes to UNIX were
> generally tossing out their homegrown applications at the same time and
> replacing the entire suite with something like SAP, BAAN, or Oracle
> APS that were networked, well integrated into things like PCs, used ASCII,
> *etc*. - *i.e*. using the replacement as the time to really upgrade their
> entire back office and possibly moving away from Big Blue based - which was
> not cost-effective (particularly for smaller firms).   Another point was
> the Big 8 accounting firms started offering services that used the minis
> and UNIX boxes with SAP/BAAN/Oracle APS).  Finally, I may miss remembering
> WRT to LPR-Cobol, but it was similar to today's Java in that it compiled
> into an interpreter.  Plus, the impression I always had was that it was not
> designed for practical large-scale use or performance.
>
> BTW: this is a different behavior from the scientific world.  From mini to
> supercomputers, in most cases, scientific users could not toss out their
> scientific computing tools and replace them with COTS alternatives (*i.e*.,
> no firm like SAP, BAAN or Oracle providing "packaged" solutions for a bank
> or business). But since most of the production apps being used came with
> sources or the few that were commercial (Cadum, CATIA, Ansys *etc*..), it
> was possible to recompile and move things - so people did or the IVSs did.
> Even today, as one of my former colleagues put it, any sr computer system
> manager that ignores Fortran will eventually get fired for incompetence as
> it is still #1.
> ᐧ
> ᐧ
>
> On Thu, Jul 13, 2023 at 3:02 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
>> Reading through [1], there are documents offered by AT&T for the "Level
>> II COBOL" system, which some further research indicates is a product from
>> Convergent (same folks as the UNIX PC.)  There's also the LPI-COBOL which
>> appears to be a Language Processor Inc. product.
>>
>> Are these the earliest AT&T endorsed COBOL solutions for UNIX or were
>> there other efforts either promoted by Bell or even perhaps developed
>> locally that were in any use before this version?  Or otherwise is there
>> any other family of ubiquitous UNIX COBOL tools that was in use in the 70s
>> and early 80s, before the timeframe of this document?
>>
>> Additionally is anyone aware of any surviving code or binaries of either
>> of these or other, earlier efforts at COBOL on UNIX?  I have no goal for
>> this information in mind yet, but just gathering details at this point.
>> Thanks all!
>>
>> - Matt G.
>>
>> [1] -
>> http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf
>>
>

[-- Attachment #2: Type: text/html, Size: 6297 bytes --]

[TUHS] Re: Bell COBOL Environment?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 4695 bytes --]

Yes. Thank you.

On Thu, Jul 13, 2023 at 5:41 PM Kenneth Goodwin <kennethgoodwin56@gmail.com>
wrote:

> Would your S database perhaps be Sybase??
>
> It is that era of time.
>
> On Thu, Jul 13, 2023, 4:35 PM Clem Cole <clemc@ccc.com> wrote:
>
>> Matt - I never had direct (user) experience with it.  I saw a demo of
>> LPI's product at a trade show.  It might have run on Ultrix, but if it did,
>> I have no memory of it being in the test suite we used for releases. Also,
>> I do not remember if LPI-Colbol was attached to a specific DB
>> implementation or not.  In those days, there were a number of them besides
>> Ingres - Informix, IBM's DB2, and one that started with an S - which later
>> was sold to Microsoft to become SQL-server to name a few, and that may have
>> been part of it.  But there were bundled applications for different markets
>> (running a dentist's office, car dealership, store, restaurant, *etc*..)
>> that ran on small UNIX boxes and used those DBs.
>>
>> What I remember was that only a few firms were offering Cobol for UNIX (I
>> think that IBM, DEC, DG, and maybe NCR had them from previous OSses), but
>> the new generation of UNIX boxes did not - although 3rd parties like LPI
>> sometimes offered them.  Since it looks like AT&T is naming it/offering it
>> with their product, that is another example of AT&T management missing the
>> market.  AT&T's management (Charlie Brown) was interested in going after
>> IBM and probably thought that Cobol was important if they sold to IBM shops.
>>
>> The problem was that except for some really large 'Big Blue' places that
>> never bothered tossing out Cobol (like Wall Street and some insurance
>> companies --* i.e.* early IBM computer users), I always thought that
>> writing *new code in Cobol or trying to port old code *was not done that
>> often because the firms that were switching from Mainframes to UNIX were
>> generally tossing out their homegrown applications at the same time and
>> replacing the entire suite with something like SAP, BAAN, or Oracle
>> APS that were networked, well integrated into things like PCs, used ASCII,
>> *etc*. - *i.e*. using the replacement as the time to really upgrade
>> their entire back office and possibly moving away from Big Blue based -
>> which was not cost-effective (particularly for smaller firms).   Another
>> point was the Big 8 accounting firms started offering services that used
>> the minis and UNIX boxes with SAP/BAAN/Oracle APS).  Finally, I may miss
>> remembering WRT to LPR-Cobol, but it was similar to today's Java in that it
>> compiled into an interpreter.  Plus, the impression I always had was that
>> it was not designed for practical large-scale use or performance.
>>
>> BTW: this is a different behavior from the scientific world.  From mini
>> to supercomputers, in most cases, scientific users could not toss out their
>> scientific computing tools and replace them with COTS alternatives (*i.e*.,
>> no firm like SAP, BAAN or Oracle providing "packaged" solutions for a bank
>> or business). But since most of the production apps being used came with
>> sources or the few that were commercial (Cadum, CATIA, Ansys *etc*..),
>> it was possible to recompile and move things - so people did or the IVSs
>> did.  Even today, as one of my former colleagues put it, any sr computer
>> system manager that ignores Fortran will eventually get fired for
>> incompetence as it is still #1.
>> ᐧ
>> ᐧ
>>
>> On Thu, Jul 13, 2023 at 3:02 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>>
>>> Reading through [1], there are documents offered by AT&T for the "Level
>>> II COBOL" system, which some further research indicates is a product from
>>> Convergent (same folks as the UNIX PC.)  There's also the LPI-COBOL which
>>> appears to be a Language Processor Inc. product.
>>>
>>> Are these the earliest AT&T endorsed COBOL solutions for UNIX or were
>>> there other efforts either promoted by Bell or even perhaps developed
>>> locally that were in any use before this version?  Or otherwise is there
>>> any other family of ubiquitous UNIX COBOL tools that was in use in the 70s
>>> and early 80s, before the timeframe of this document?
>>>
>>> Additionally is anyone aware of any surviving code or binaries of either
>>> of these or other, earlier efforts at COBOL on UNIX?  I have no goal for
>>> this information in mind yet, but just gathering details at this point.
>>> Thanks all!
>>>
>>> - Matt G.
>>>
>>> [1] -
>>> http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf
>>>
>> --
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 6874 bytes --]

[TUHS] Re: Bell COBOL Environment?

[KenUnix]

[-- Attachment #1: Type: text/plain, Size: 5035 bytes --]

Well if you guys use Linux you can always download open source "gnucobol"
to experiment with.

Ken


On Thu, Jul 13, 2023 at 7:02 PM Clem Cole <clemc@ccc.com> wrote:

> Yes. Thank you.
>
> On Thu, Jul 13, 2023 at 5:41 PM Kenneth Goodwin <
> kennethgoodwin56@gmail.com> wrote:
>
>> Would your S database perhaps be Sybase??
>>
>> It is that era of time.
>>
>> On Thu, Jul 13, 2023, 4:35 PM Clem Cole <clemc@ccc.com> wrote:
>>
>>> Matt - I never had direct (user) experience with it.  I saw a demo of
>>> LPI's product at a trade show.  It might have run on Ultrix, but if it did,
>>> I have no memory of it being in the test suite we used for releases. Also,
>>> I do not remember if LPI-Colbol was attached to a specific DB
>>> implementation or not.  In those days, there were a number of them besides
>>> Ingres - Informix, IBM's DB2, and one that started with an S - which later
>>> was sold to Microsoft to become SQL-server to name a few, and that may have
>>> been part of it.  But there were bundled applications for different markets
>>> (running a dentist's office, car dealership, store, restaurant, *etc*..)
>>> that ran on small UNIX boxes and used those DBs.
>>>
>>> What I remember was that only a few firms were offering Cobol for UNIX
>>> (I think that IBM, DEC, DG, and maybe NCR had them from previous OSses),
>>> but the new generation of UNIX boxes did not - although 3rd parties like
>>> LPI sometimes offered them.  Since it looks like AT&T is naming it/offering
>>> it with their product, that is another example of AT&T management missing
>>> the market.  AT&T's management (Charlie Brown) was interested in going
>>> after IBM and probably thought that Cobol was important if they sold to IBM
>>> shops.
>>>
>>> The problem was that except for some really large 'Big Blue' places that
>>> never bothered tossing out Cobol (like Wall Street and some insurance
>>> companies --* i.e.* early IBM computer users), I always thought that
>>> writing *new code in Cobol or trying to port old code *was not done
>>> that often because the firms that were switching from Mainframes to UNIX
>>> were generally tossing out their homegrown applications at the same time
>>> and replacing the entire suite with something like SAP, BAAN, or Oracle
>>> APS that were networked, well integrated into things like PCs, used ASCII,
>>> *etc*. - *i.e*. using the replacement as the time to really upgrade
>>> their entire back office and possibly moving away from Big Blue based -
>>> which was not cost-effective (particularly for smaller firms).   Another
>>> point was the Big 8 accounting firms started offering services that used
>>> the minis and UNIX boxes with SAP/BAAN/Oracle APS).  Finally, I may miss
>>> remembering WRT to LPR-Cobol, but it was similar to today's Java in that it
>>> compiled into an interpreter.  Plus, the impression I always had was that
>>> it was not designed for practical large-scale use or performance.
>>>
>>> BTW: this is a different behavior from the scientific world.  From mini
>>> to supercomputers, in most cases, scientific users could not toss out their
>>> scientific computing tools and replace them with COTS alternatives (
>>> *i.e*., no firm like SAP, BAAN or Oracle providing "packaged" solutions
>>> for a bank or business). But since most of the production apps being used
>>> came with sources or the few that were commercial (Cadum, CATIA, Ansys
>>> *etc*..), it was possible to recompile and move things - so people did
>>> or the IVSs did.  Even today, as one of my former colleagues put it, any sr
>>> computer system manager that ignores Fortran will eventually get fired for
>>> incompetence as it is still #1.
>>> ᐧ
>>> ᐧ
>>>
>>> On Thu, Jul 13, 2023 at 3:02 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>>>
>>>> Reading through [1], there are documents offered by AT&T for the "Level
>>>> II COBOL" system, which some further research indicates is a product from
>>>> Convergent (same folks as the UNIX PC.)  There's also the LPI-COBOL which
>>>> appears to be a Language Processor Inc. product.
>>>>
>>>> Are these the earliest AT&T endorsed COBOL solutions for UNIX or were
>>>> there other efforts either promoted by Bell or even perhaps developed
>>>> locally that were in any use before this version?  Or otherwise is there
>>>> any other family of ubiquitous UNIX COBOL tools that was in use in the 70s
>>>> and early 80s, before the timeframe of this document?
>>>>
>>>> Additionally is anyone aware of any surviving code or binaries of
>>>> either of these or other, earlier efforts at COBOL on UNIX?  I have no goal
>>>> for this information in mind yet, but just gathering details at this
>>>> point.  Thanks all!
>>>>
>>>> - Matt G.
>>>>
>>>> [1] -
>>>> http://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf
>>>>
>>> --
> Sent from a handheld expect more typos than usual
>


-- 
End of line
JOB TERMINATED -->> Okey Dokey, OK Boss

[-- Attachment #2: Type: text/html, Size: 7672 bytes --]

[TUHS] Re: Bell COBOL Environment?

[Jon Forrest]

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

You’re thinking of Sybase. That’s where the name “SqlServer” came from. Sybase sold a source code license to Microsoft that included the right to use the name.

(I was a developer at Sybase in the VMS group in the late 1980s and early 1990s)

Jon 

Sent from my iPhone

> On Jul 13, 2023, at 1:35 PM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> Matt - I never had direct (user) experience with it.  Ireleases. Also, I do not remember if LPI-Colbol was attached to a specific DB implementation or not.  In those days, there were a number of them besides Ingres - Informix, IBM's DB2, and one that started with an S - which later was sold to Microsoft to become SQL-server to name a few, and that may have been part of it. 

[-- Attachment #2: Type: text/html, Size: 1170 bytes --]

[TUHS] Re: Bell COBOL Environment?

[segaloco via TUHS]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

The conclusion I'm coming to from what has been said thus far is that people who were moving from COBOL and the mainframe world to UNIX didn't have as much of a need for COBOL. Since that transition often involved change in enough other aspects of an operation, moving to UNIX with the same COBOL applications just wasn't the path to success for most folks, as opposed to folks deeply invested in FORTRAN. Would that be a fair characterization?

Thanks for the feedback by the way, one of the matters I'm trying to suss out is what a typical COBOL environment on UNIX would've looked like back when, and what it sounds like is a COBOL environment on UNIX was anything but typical.

- Matt G.
------- Original Message -------
On Thursday, July 13th, 2023 at 2:42 PM, Jon Forrest <nobozo@gmail.com> wrote:

> You’re thinking of Sybase. That’s where the name “SqlServer” came from. Sybase sold a source code license to Microsoft that included the right to use the name.
>
> (I was a developer at Sybase in the VMS group in the late 1980s and early 1990s)
>
> Jon
>
> Sent from my iPhone
>
>> On Jul 13, 2023, at 1:35 PM, Clem Cole <clemc@ccc.com> wrote:
>
>> 
>> Matt - I never had direct (user) experience with it. Ireleases. Also, I do not remember if LPI-Colbol was attached to a specific DB implementation or not. In those days, there were a number of them besides Ingres - Informix, IBM's DB2, and one that started with an S - which later was sold to Microsoft to become SQL-server to name a few, and that may have been part of it.

[-- Attachment #2: Type: text/html, Size: 2445 bytes --]

[TUHS] Re: Bell COBOL Environment?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]

Yes. And the need for COBOL also was mirrored in the micro world of the
time (at least the early 80s). Every micro with enough power seemed to have
a COBOL, but all of the offerings dried up before long because although
COBOL was a 'no brainer must have' for business, selling it into this new
market proved to be too hard. At least that's the impression I was left
with at the time, and also what the professors that taught my 'language
survey' course said about it...  You can take the raw code, but the
underlying environment and services just weren't there, so the raw code
turned out to be useless most of the time (I also got some $ re-writing a
few hundred lines of COBOL business logic for a local business that found
that easier for a company that had, as luck would have it, a PDP-11
database written in FORTRAN running on RT-11 or RSTS/E).

Warner

On Thu, Jul 13, 2023 at 4:36 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> The conclusion I'm coming to from what has been said thus far is that
> people who were moving from COBOL and the mainframe world to UNIX didn't
> have as much of a need for COBOL.  Since that transition often involved
> change in enough other aspects of an operation, moving to UNIX with the
> same COBOL applications just wasn't the path to success for most folks, as
> opposed to folks deeply invested in FORTRAN.  Would that be a fair
> characterization?
>
> Thanks for the feedback by the way, one of the matters I'm trying to suss
> out is what a typical COBOL environment on UNIX would've looked like back
> when, and what it sounds like is a COBOL environment on UNIX was anything
> but typical.
>
> - Matt G.
> ------- Original Message -------
> On Thursday, July 13th, 2023 at 2:42 PM, Jon Forrest <nobozo@gmail.com>
> wrote:
>
> You’re thinking of Sybase. That’s where the name “SqlServer” came from.
> Sybase sold a source code license to Microsoft that included the right to
> use the name.
>
> (I was a developer at Sybase in the VMS group in the late 1980s and early
> 1990s)
>
> Jon
>
> Sent from my iPhone
>
> On Jul 13, 2023, at 1:35 PM, Clem Cole <clemc@ccc.com> wrote:
>
> 
> Matt - I never had direct (user) experience with it.  Ireleases. Also, I
> do not remember if LPI-Colbol was attached to a specific DB implementation
> or not.  In those days, there were a number of them besides Ingres -
> Informix, IBM's DB2, and one that started with an S - which later was sold
> to Microsoft to become SQL-server to name a few, and that may have been
> part of it.
>
>
>

[-- Attachment #2: Type: text/html, Size: 3707 bytes --]

[TUHS] Re: Bell COBOL Environment?

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 3234 bytes --]

Fortune Systems sold COBOL-74 along with a bunch of business applications. Don't recall who we got it from. There was also SIBOL (from an Irish company) that could run thousands DIBOL programs  under Unix (DIBOL was DEC's own business oriented language).

Speaking of Fortune, I recently stumbled upon this short clip where Stanley Kubrick (in 1983) says he wants a Fortune Computer for Christmas because it runs the most advanced operating system: Unix! 

https://www.youtube.com/watch?v=54hrLTpsO5g

> On Jul 13, 2023, at 4:20 PM, Warner Losh <imp@bsdimp.com> wrote:
> 
> Yes. And the need for COBOL also was mirrored in the micro world of the time (at least the early 80s). Every micro with enough power seemed to have a COBOL, but all of the offerings dried up before long because although COBOL was a 'no brainer must have' for business, selling it into this new market proved to be too hard. At least that's the impression I was left with at the time, and also what the professors that taught my 'language survey' course said about it...  You can take the raw code, but the underlying environment and services just weren't there, so the raw code turned out to be useless most of the time (I also got some $ re-writing a few hundred lines of COBOL business logic for a local business that found that easier for a company that had, as luck would have it, a PDP-11 database written in FORTRAN running on RT-11 or RSTS/E).
> 
> Warner
> 
> On Thu, Jul 13, 2023 at 4:36 PM segaloco via TUHS <tuhs@tuhs.org <mailto:tuhs@tuhs.org>> wrote:
>> The conclusion I'm coming to from what has been said thus far is that people who were moving from COBOL and the mainframe world to UNIX didn't have as much of a need for COBOL.  Since that transition often involved change in enough other aspects of an operation, moving to UNIX with the same COBOL applications just wasn't the path to success for most folks, as opposed to folks deeply invested in FORTRAN.  Would that be a fair characterization?
>> 
>> Thanks for the feedback by the way, one of the matters I'm trying to suss out is what a typical COBOL environment on UNIX would've looked like back when, and what it sounds like is a COBOL environment on UNIX was anything but typical.
>> 
>> - Matt G.
>> ------- Original Message -------
>> On Thursday, July 13th, 2023 at 2:42 PM, Jon Forrest <nobozo@gmail.com <mailto:nobozo@gmail.com>> wrote:
>> 
>>> You’re thinking of Sybase. That’s where the name “SqlServer” came from. Sybase sold a source code license to Microsoft that included the right to use the name.
>>> 
>>> (I was a developer at Sybase in the VMS group in the late 1980s and early 1990s)
>>> 
>>> Jon 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Jul 13, 2023, at 1:35 PM, Clem Cole <clemc@ccc.com <mailto:clemc@ccc.com>> wrote:
>>>> 
>>>> 
>>>> Matt - I never had direct (user) experience with it.  Ireleases. Also, I do not remember if LPI-Colbol was attached to a specific DB implementation or not.  In those days, there were a number of them besides Ingres - Informix, IBM's DB2, and one that started with an S - which later was sold to Microsoft to become SQL-server to name a few, and that may have been part of it. 
>> 


[-- Attachment #2: Type: text/html, Size: 4828 bytes --]

[TUHS] Re: Bell COBOL Environment?

[Alan D. Salewski]

On Thu, Jul 13, 2023, at 20:20, Bakul Shah wrote:
[...]
>
> Speaking of Fortune, I recently stumbled upon this short clip where 
> Stanley Kubrick (in 1983) says he wants a Fortune Computer for 
> Christmas because it runs the most advanced operating system: Unix! 
>
> https://www.youtube.com/watch?v=54hrLTpsO5g

That's a great clip, Bakul; thanks for sharing it.
-Al


-- 
a l a n   d.   s a l e w s k i
ads@salewski.email
salewski@att.net
https://github.com/salewski

[TUHS] Re: Bell COBOL Environment?

[David Arnold]

> On 14 Jul 2023, at 08:36, segaloco via TUHS <tuhs@tuhs.org> wrote:

…

> Since that transition often involved change in enough other aspects of an operation, moving to UNIX with the same COBOL applications just wasn't the path to success for most folks,

I think that’s fair, and certainly true of the COBOL system I knew (late 80s).

For us, a move to Unix would have been a complete re-architect, re-code, and replacement of basically all hardware.   3270 terminals, LU6.2 networking, CICS transaction monitor, ISAM datasets, all the batch jobs and their JCL, to say nothing of the two (redundant) 3090’s and the sea of DASD, monster printers, etc.  The retraining or replacement of staff would have been overwhelming as well. 

The closest I could get was writing some CICS transactions in C, but it wasn’t worth the uphill battle.

The only solution was to be acquired by a more modern company and throw the lot out!




d

[TUHS] Re: Bell COBOL Environment?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

Below

On Thu, Jul 13, 2023 at 6:36 PM segaloco <segaloco@protonmail.com> wrote:

> The conclusion I'm coming to from what has been said thus far is that
> people who were moving from COBOL and the mainframe world to UNIX didn't
> have as much of a need for COBOL.  Since that transition often involved
> change in enough other aspects of an operation, moving to UNIX with the
> same COBOL applications just wasn't the path to success for most folks, as
> opposed to folks deeply invested in FORTRAN.  Would that be a fair
> characterization?
>


Yes. That was certainly my experience.

>
> Thanks for the feedback by the way, one of the matters I'm trying to suss
> out is what a typical COBOL environment on UNIX would've looked like back
> when, and what it sounds like is a COBOL environment on UNIX was anything
> but typical.
>
I think that is fair.  There were likely multiple reasons why that path
started must likely because Unix was rooted in the CS research and the
engineering communities which was pretty far from what traditional
production Business/COBOL shops did at the time.  By the time business
folks started to notice Unix other economic changes had appeared also such
as firms like SAP/BAAN/Oracle, plus Im not sure the big8 in those days
could spell Unix so business folks didn’t have a reason to pay attention.

Clem

>
> - Matt G.
> ------- Original Message -------
>
> On Thursday, July 13th, 2023 at 2:42 PM, Jon Forrest <nobozo@gmail.com>
> wrote:
>
> You’re thinking of Sybase. That’s where the name “SqlServer” came from.
> Sybase sold a source code license to Microsoft that included the right to
> use the name.
>
> (I was a developer at Sybase in the VMS group in the late 1980s and early
> 1990s)
>
> Jon
>
> Sent from my iPhone
>
> On Jul 13, 2023, at 1:35 PM, Clem Cole <clemc@ccc.com> wrote:
>
> 
> Matt - I never had direct (user) experience with it.  Ireleases. Also, I
> do not remember if LPI-Colbol was attached to a specific DB implementation
> or not.  In those days, there were a number of them besides Ingres -
> Informix, IBM's DB2, and one that started with an S - which later was sold
> to Microsoft to become SQL-server to name a few, and that may have been
> part of it.
>
>
> --
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 4042 bytes --]

[TUHS] Re: Bell COBOL Environment?

[Dan Cross]

On Thu, Jul 13, 2023 at 6:36 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
> The conclusion I'm coming to from what has been said thus far is that people who were moving from COBOL and the mainframe world to UNIX didn't have as much of a need for COBOL.  Since that transition often involved change in enough other aspects of an operation, moving to UNIX with the same COBOL applications just wasn't the path to success for most folks, as opposed to folks deeply invested in FORTRAN.  Would that be a fair characterization?

Echoing what others have said, that seems reasonable to me. Don't tell
the mainframe infosec folks about this; they get really touchy about
defending COBOL's honor for some reason I don't quite understand.

> Thanks for the feedback by the way, one of the matters I'm trying to suss out is what a typical COBOL environment on UNIX would've looked like back when, and what it sounds like is a COBOL environment on UNIX was anything but typical.

A way to think about COBOL is that it's like a DSL for business
transaction processing, but is itself a small part of the overall
offering. In the mainframe world, it's often intimately tied to things
like CICS, ISAM, VTAM and 3270 access methods, SNA, and so on, and in
that sense the language itself is a rather small part of the
ecosystem. Transferring everything into a new environment (e.g., on
Unix) raises a lot of questions about the surrounding technologies and
their non-availability, and ultimately just having the language by
itself isn't terribly useful if you don't have all the other stuff as
well.

Also, COBOL is just a terrible language.

        - Dan C.

[TUHS] Re: Bell COBOL Environment?

[Paul Ruizendaal via TUHS]

> Reading through [1], there are documents offered by AT&T for the "Level II COBOL" system, which some further research indicates is a product from Convergent (same folks as the UNIX PC.)  There's also the LPI-COBOL which appears to be a Language Processor Inc. product.

Ryan-McFarland comes to mind: in my recollection they were the leading Cobol on small machines in the early 80’s. Ryan-McFarland’s predecessor company Digitek was contracted to do the PL/I compiler for Multics, but failed. It seems they later did Bell Labs PL/I (says https://en.wikipedia.org/wiki/Digitek). I think they did a Unix version of their Cobol in the mid/late 80’s as well.

A few years ago I tried to find out more about RM-Cobol as it existed in the late 70’s and early 80’s, but with little success. As a product it survived till the present day under the ownership of Micro-Focus and most web mentions are for more recent versions.

It would seem to me that compilers on machines with small memories and word sizes in the 60’s, 70’s and even 80’s tended to compile to a virtual machine / intermediate code -- sometimes with the option to compile to native from there. Think BCPL and o-code, Pascal and p-code, the Amsterdam Compiler Kit and m-code, the Microsoft “revenue bomb” p-code C compiler, etc. According to the above Wikipedia article RM-Cobol used the same approach. I did once see the source for another 80’s Cobol compiler and it compiled to a virtual machine with 60-bit words.

By the way, I loved the recent posts on B and NB. THUS at its best!