info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Veryant isCOBOL
278 views
Skip to first unread message
pete dashwood
Dec 8, 2017, 6:10:33 PM12/8/17
to
I was looking at some docs on isCOBOL.
It is interesting.
I understood that they generated Java from COBOL, but that may have been
a flawed understanding.
Does anybody here have any experience with this product?
Pete.
--
I used to write COBOL; now I can do anything...
It is interesting.
I understood that they generated Java from COBOL, but that may have been
a flawed understanding.
Does anybody here have any experience with this product?
Pete.
--
I used to write COBOL; now I can do anything...
Robert Wessel
Dec 8, 2017, 6:35:51 PM12/8/17
to
On Sat, 9 Dec 2017 12:10:29 +1300, pete dashwood
<dash...@enternet.co.nz> wrote:
>I was looking at some docs on isCOBOL.
>
>It is interesting.
>
>I understood that they generated Java from COBOL, but that may have been
>a flawed understanding.
>
>Does anybody here have any experience with this product?
I've no experience, but my understanding is that they generate Java
<dash...@enternet.co.nz> wrote:
>I was looking at some docs on isCOBOL.
>
>It is interesting.
>
>I understood that they generated Java from COBOL, but that may have been
>a flawed understanding.
>
>Does anybody here have any experience with this product?
Bytecode, not Java. Many other language implementations do the same,
of course. Microfocus does the same, and they support MSIL (.NET) and
native targets as well.
Greg Wallace
Dec 8, 2017, 11:15:44 PM12/8/17
to
About 10 years ago, I did a trial conversion of some typical AcuCobol programs and they worked. I had the option of keeping AcuCobol Vision files so that saved a data conversion.
My understanding is that it converts to Java and runs on the Java runtime system. I also heard that IsCobol picked some talented AcuCobol people around the time that MicroFocus was taking over AcuCobol. That means their AcuCobol migration is pretty good.
It is a bit expensive like some other COBOLs and each user needs runtime licensing. I don’t mind paying $1,000’s for a complier and annual mtce but runtime costs grate on me.
The drawback for me is that it didn’t support AcuCobol’s CGI method for interactive web programs and one had to change to Java Servlets and that was going to be a bit of work. So cost plus work meant I didn’t proceed.
I looked at Fujitsu Cobol which has no runtime fees and supports the CGI method but it is inferior to AcuCobol (more code) and requires more work.
A bigger question was whether to rewrite in another language and I did experimental work with Java but again did not proceed so I am still with AcuCobol. The AcuCobol Vision ISAM file system has been totally reliable.
Greg
pete dashwood
Dec 11, 2017, 5:44:16 PM12/11/17
to
Generating Java bytecode rather than native code would provide easier
cross-platform development, I guess.
Generating Java source from COBOL makes no sense at all.
gre...@aceway.net
Dec 11, 2017, 8:50:36 PM12/11/17
to
see http://support.veryant.com/products/iscobol/faq.php?type=all
and search for source
I found this:
The isCOBOL Compiler converts COBOL source code to Java source code behind-the-scenes.
I gather it compiles to Java Bytecode which is transportable to OS with the appropriate runtime which interprets it to executable code. AcuCobol has been doing this bytecode with runtime before Java became popular. I think it was called intermediate code early on.
Greg
pete dashwood
Dec 11, 2017, 10:07:36 PM12/11/17
to
On 9/12/2017 5:15 PM, Greg Wallace wrote:
> On Saturday, 9 December 2017 09:10:33 UTC+10, pete dashwood wrote:
>> I was looking at some docs on isCOBOL.
>>
>> It is interesting.
>>
>> I understood that they generated Java from COBOL, but that may have been
>> a flawed understanding.
>>
>> Does anybody here have any experience with this product?
>>
>> Pete.
>> --
>> I used to write COBOL; now I can do anything...
>
> AcuCobol to IsCobol 20171209
>
> About 10 years ago, I did a trial conversion of some typical AcuCobol programs and they worked. I had the option of keeping AcuCobol Vision files so that saved a data conversion.
From what Robert said about Java bytecode generation, there would be no
> On Saturday, 9 December 2017 09:10:33 UTC+10, pete dashwood wrote:
>> I was looking at some docs on isCOBOL.
>>
>> It is interesting.
>>
>> I understood that they generated Java from COBOL, but that may have been
>> a flawed understanding.
>>
>> Does anybody here have any experience with this product?
>>
>> Pete.
>> --
>> I used to write COBOL; now I can do anything...
>
> AcuCobol to IsCobol 20171209
>
> About 10 years ago, I did a trial conversion of some typical AcuCobol programs and they worked. I had the option of keeping AcuCobol Vision files so that saved a data conversion.
reason to expect it not to work.
>
> My understanding is that it converts to Java and runs on the Java runtime system.
I thought that was the case, but I think Robert's explanation makes much
> My understanding is that it converts to Java and runs on the Java runtime system.
more sense.
I also heard that IsCobol picked some talented AcuCobol people around
the time that MicroFocus was taking over AcuCobol. That means their
AcuCobol migration is pretty good.
>
> It is a bit expensive like some other COBOLs and each user needs runtime licensing. I don’t mind paying $1,000’s for a complier and annual mtce but runtime costs grate on me.
I have severe reservations about paying $1000s for a compiler when I can
> It is a bit expensive like some other COBOLs and each user needs runtime licensing. I don’t mind paying $1,000’s for a complier and annual mtce but runtime costs grate on me.
get an equivalent for FREE... (If I want .NET, and I do..., I'd have to
be crazy to buy a COBOL compiler for it when I can simply download C#,
watch a few free videos, and get productive very quickly, with online
support from a community of millions...)
It is mainly emotional attachment and laziness and inertia about
expanding a skill set that keeps people in COBOL... OK, there is the
need to maintain what you have also, but I see a gradual transition
taking care of that.
>
> The drawback for me is that it didn’t support AcuCobol’s CGI method for interactive web programs and one had to change to Java Servlets and that was going to be a bit of work. So cost plus work meant I didn’t proceed.
CGI is a pretty obsolete Web Technology nowadays. I remember doing some
> The drawback for me is that it didn’t support AcuCobol’s CGI method for interactive web programs and one had to change to Java Servlets and that was going to be a bit of work. So cost plus work meant I didn’t proceed.
web pages with COBOL CGI back in the last century, but these days I use
ASP.Net and compiled C# code-behinds, mainly because the tools are
better than using Dreamweaver (IMO). (The whole of the current PRIMA web
site - primacomputing.co.nz - is built with that technology... Other
people use other things... I guess it comes down to what you are
comfortable with. COBOL CGI worked perfectly well.
>
> I looked at Fujitsu Cobol which has no runtime fees and supports the CGI method but it is inferior to AcuCobol (more code) and requires more work.
never used AcuCOBOL so I'll take your word for it.
>
> A bigger question was whether to rewrite in another language and I did experimental work with Java but again did not proceed so I am still with AcuCobol. The AcuCobol Vision ISAM file system has been totally reliable.
Again, if you are happy with something there may be little point in
> A bigger question was whether to rewrite in another language and I did experimental work with Java but again did not proceed so I am still with AcuCobol. The AcuCobol Vision ISAM file system has been totally reliable.
changing it.
I have outlined WHY you need Objects and Layers (which are not well
supported by procedural code like COBOL) for interactive applications
running on a desktop or web page, at:
https://primacomputing.co.nz/PRIMAMetro/ObjectsAndLayers.aspx
pete dashwood
Dec 11, 2017, 10:11:14 PM12/11/17
to
This looks like a clumsy way to get platform independence to me...
Robert Wessel
Dec 11, 2017, 10:21:16 PM12/11/17
to
On Tue, 12 Dec 2017 16:11:10 +1300, pete dashwood
Compiling to another language has a long history. Fortran used to be
a popular target, C is very common these days, you also see a fair bit
of C++ and Java. GnuCobol (nee OpenCobol) compiles to C, for another
topical example.
As Greg pointed out, I was clearly wrong about the approach Veryant
takes.
a popular target, C is very common these days, you also see a fair bit
of C++ and Java. GnuCobol (nee OpenCobol) compiles to C, for another
topical example.
As Greg pointed out, I was clearly wrong about the approach Veryant
takes.
Vince Coen
Dec 12, 2017, 12:43:59 PM12/12/17
to
Hello gregweb!
Tuesday December 12 2017 01:50, you wrote to All:
> I found this:
> The isCOBOL Compiler converts COBOL source code to Java source code
> behind-the-scenes.
> I gather it compiles to Java Bytecode which is transportable to OS
> with the appropriate runtime which interprets it to executable code.
> AcuCobol has been doing this bytecode with runtime before Java became
> popular. I think it was called intermediate code early on.
If fact the first Cobol compiler to use this method of generating an
int (intermediary) language that is executed by the runtime tool is MF
Cobol (CIS Cobol as the first formal release into PCDos and later windows
3.1. The Workbench series also used int coding but the bootstrap method
was discontinued as far as I remember, around this time.
These compilers were bootstrap compilers and the this method at least on
paper allows the same int code to be run on any hardware.
For those that do not know the term 'bootstrap' the first compiler had
very, very few instruction/verbs and other facilities but was used to
create the next level Cobol compiler and so on.
It worked even if the compiler was not very effective in code generation.
Vince
Tuesday December 12 2017 01:50, you wrote to All:
> I found this:
> The isCOBOL Compiler converts COBOL source code to Java source code
> behind-the-scenes.
> I gather it compiles to Java Bytecode which is transportable to OS
> with the appropriate runtime which interprets it to executable code.
> AcuCobol has been doing this bytecode with runtime before Java became
> popular. I think it was called intermediate code early on.
int (intermediary) language that is executed by the runtime tool is MF
Cobol (CIS Cobol as the first formal release into PCDos and later windows
3.1. The Workbench series also used int coding but the bootstrap method
was discontinued as far as I remember, around this time.
These compilers were bootstrap compilers and the this method at least on
paper allows the same int code to be run on any hardware.
For those that do not know the term 'bootstrap' the first compiler had
very, very few instruction/verbs and other facilities but was used to
create the next level Cobol compiler and so on.
It worked even if the compiler was not very effective in code generation.
Vince
docd...@panix.com
Dec 12, 2017, 1:01:10 PM12/12/17
to
In article <15130...@f1.n250.z2.fidonet.ftn>,
newfangled 720K floppy disks... I gotta throw more stuff out.
DD
Vince Coen <VBC...@gmail.com> wrote:
>Hello gregweb!
>
>Tuesday December 12 2017 01:50, you wrote to All:
>
> > I found this:
> > The isCOBOL Compiler converts COBOL source code to Java source code
> > behind-the-scenes.
>
> > I gather it compiles to Java Bytecode which is transportable to OS
> > with the appropriate runtime which interprets it to executable code.
> > AcuCobol has been doing this bytecode with runtime before Java became
> > popular. I think it was called intermediate code early on.
>
>If fact the first Cobol compiler to use this method of generating an
>int (intermediary) language that is executed by the runtime tool is MF
>Cobol (CIS Cobol as the first formal release into PCDos and later windows
>3.1. The Workbench series also used int coding but the bootstrap method
>was discontinued as far as I remember, around this time.
I think I have a version of Microfocus that fits on two of those
>Hello gregweb!
>
>Tuesday December 12 2017 01:50, you wrote to All:
>
> > I found this:
> > The isCOBOL Compiler converts COBOL source code to Java source code
> > behind-the-scenes.
>
> > I gather it compiles to Java Bytecode which is transportable to OS
> > with the appropriate runtime which interprets it to executable code.
> > AcuCobol has been doing this bytecode with runtime before Java became
> > popular. I think it was called intermediate code early on.
>
>If fact the first Cobol compiler to use this method of generating an
>int (intermediary) language that is executed by the runtime tool is MF
>Cobol (CIS Cobol as the first formal release into PCDos and later windows
>3.1. The Workbench series also used int coding but the bootstrap method
>was discontinued as far as I remember, around this time.
newfangled 720K floppy disks... I gotta throw more stuff out.
DD
Richard
Dec 12, 2017, 4:54:54 PM12/12/17
to
On Wednesday, December 13, 2017 at 6:43:59 AM UTC+13, Vince Coen wrote:
> If fact the first Cobol compiler to use this method of generating an
> int (intermediary) language that is executed by the runtime tool is MF
> Cobol (CIS Cobol as the first formal release into PCDos and later windows
> 3.1. The Workbench series also used int coding but the bootstrap method
> was discontinued as far as I remember, around this time.
Before there was a Microfocus there was 'ICL Dataskill 1500 COBOL'. This compiled and ran on the ICL 1500 series computer -ex Singer/Cogar machines (I have some here). The manual that I have is 2nd edition dated December 1977.
> If fact the first Cobol compiler to use this method of generating an
> int (intermediary) language that is executed by the runtime tool is MF
> Cobol (CIS Cobol as the first formal release into PCDos and later windows
> 3.1. The Workbench series also used int coding but the bootstrap method
> was discontinued as far as I remember, around this time.
My understanding is that the two authors of this left ICL Reading and formed Microfocus in the same city.
CIS COBOL was well before PC-DOS, it was released in 1978 for CP/M and slightly later for multiuser MP/M-2. It also had an ICL DRS-20 version, the replacement for the 1500 series.
RM COBOL, around the same time, also compiled to a [different] byte code for portability reasons, this was copied by ACCU.
Byte code of various types was quite common in the 1970s or even earlier. Forth compiled to a type of byte code, UCSD Pascal (along with Modula2 and Fortran) used p-code, as did many other Pascals.
Richard
Dec 12, 2017, 5:13:47 PM12/12/17
to
On Tuesday, December 12, 2017 at 4:21:16 PM UTC+13, robert...@yahoo.com wrote:
> Compiling to another language has a long history. Fortran used to be
> a popular target, C is very common these days, you also see a fair bit
> of C++ and Java. GnuCobol (nee OpenCobol) compiles to C, for another
> topical example.
Many years ago, decades probably, Datamation did a survey on languages identifying what type of work developers were doing. It turned out that COBOL programmers spent most of their time doing 'maintenance' while C programmers were mostly involved with 'new development'.
> Compiling to another language has a long history. Fortran used to be
> a popular target, C is very common these days, you also see a fair bit
> of C++ and Java. GnuCobol (nee OpenCobol) compiles to C, for another
> topical example.
The argument then became: Write in C (or C++, Java, etc) and you will need to waste less time on maintenance and develop more new applications.
Of course the types of applications were quite different. COBOL is mainly used for business and the 'maintenance' is changing the programs to match the changes that the businesses make* on an on-going basis. Writing these sort of applications in C or Java merely results in the same level of 'maintenance', but it may be recorded as 'new development' if they write new classes that inherit from existing classes but override the old methods with new ones that match the latest business logic.
* Pricing structure, discounts, taxes, distribution methods, ...
Richard
Dec 12, 2017, 5:29:52 PM12/12/17
to
On Wednesday, December 13, 2017 at 6:43:59 AM UTC+13, Vince Coen wrote:
> If fact the first Cobol compiler to use this method of generating an
> int (intermediary) language that is executed by the runtime tool is MF
> Cobol (CIS Cobol as the first formal release into PCDos
Microsoft also had its own COBOL compiler that compiled to some form of intermediate code. This was released in 1978 for CP/M and much later for PC/MS-DOS. It was never developed beyond single-user and later Microsoft COBOLs were rebranded Microfocus ones.
> int (intermediary) language that is executed by the runtime tool is MF
> Cobol (CIS Cobol as the first formal release into PCDos
Vince Coen
Dec 12, 2017, 7:21:25 PM12/12/17
to
Hello Richard!
Tuesday December 12 2017 21:54, Richard wrote to All:
> On Wednesday, December 13, 2017 at 6:43:59 AM UTC+13, Vince Coen
> wrote:
DRS and there was also the unit edit kit based around DEC 8 & 11 that had
some varient of the MF early compiler/s. Coming to think about that I still
have some of the Cobol code for password control with a last update of 86.
> CIS COBOL was well before PC-DOS, it was released in 1978 for CP/M and
> slightly later for multiuser MP/M-2. It also had an ICL DRS-20
> version, the replacement for the 1500 series.
Memory may well be playing me up should have said as you pointed out
CPM/MPM etc as I ran LPE reformed into MPI that distributed DR products
throughtout Europe and beyond (any where outside the USA) and later MF & MS
products although this did start up around 1976.
> RM COBOL, around the same time, also compiled to a [different] byte
> code for portability reasons, this was copied by ACCU.
> Byte code of various types was quite common in the 1970s or even
> earlier. Forth compiled to a type of byte code, UCSD Pascal (along
> with Modula2 and Fortran) used p-code, as did many other Pascals.
Talking of the ICT1500 I still remember having to wait for time on a 1900
so did some work on 1500 putting a compile through that took all day
running on a four tape system.
Needless to say I did not hang aroung waiting - and now I remember the
site (G. Wimpey and Co) but for an exact date would have to look at my old
CV assuming I did not compress that period.
Vince
Tuesday December 12 2017 21:54, Richard wrote to All:
> On Wednesday, December 13, 2017 at 6:43:59 AM UTC+13, Vince Coen
> wrote:
>> If fact the first Cobol compiler to use this method of generating an
>> int (intermediary) language that is executed by the runtime tool is
>> MF Cobol (CIS Cobol as the first formal release into PCDos and later
>> windows 3.1. The Workbench series also used int coding but the
>> bootstrap method was discontinued as far as I remember, around this
>> time.
>> int (intermediary) language that is executed by the runtime tool is
>> MF Cobol (CIS Cobol as the first formal release into PCDos and later
>> windows 3.1. The Workbench series also used int coding but the
>> bootstrap method was discontinued as far as I remember, around this
>> time.
> Before there was a Microfocus there was 'ICL Dataskill 1500 COBOL'.
> This compiled and ran on the ICL 1500 series computer -ex Singer/Cogar
> machines (I have some here). The manual that I have is 2nd edition
> dated December 1977.
> My understanding is that the two authors of this left ICL Reading and
> formed Microfocus in the same city.
Yes, you have refreshed my memory and I remember using Cobol on 1500 and
> This compiled and ran on the ICL 1500 series computer -ex Singer/Cogar
> machines (I have some here). The manual that I have is 2nd edition
> dated December 1977.
> My understanding is that the two authors of this left ICL Reading and
> formed Microfocus in the same city.
DRS and there was also the unit edit kit based around DEC 8 & 11 that had
some varient of the MF early compiler/s. Coming to think about that I still
have some of the Cobol code for password control with a last update of 86.
> CIS COBOL was well before PC-DOS, it was released in 1978 for CP/M and
> slightly later for multiuser MP/M-2. It also had an ICL DRS-20
> version, the replacement for the 1500 series.
CPM/MPM etc as I ran LPE reformed into MPI that distributed DR products
throughtout Europe and beyond (any where outside the USA) and later MF & MS
products although this did start up around 1976.
> RM COBOL, around the same time, also compiled to a [different] byte
> code for portability reasons, this was copied by ACCU.
> Byte code of various types was quite common in the 1970s or even
> earlier. Forth compiled to a type of byte code, UCSD Pascal (along
> with Modula2 and Fortran) used p-code, as did many other Pascals.
so did some work on 1500 putting a compile through that took all day
running on a four tape system.
Needless to say I did not hang aroung waiting - and now I remember the
site (G. Wimpey and Co) but for an exact date would have to look at my old
CV assuming I did not compress that period.
Vince
Vince Coen
Dec 13, 2017, 7:05:47 PM12/13/17
to
Hello Richard!
Tuesday December 12 2017 22:29, Richard wrote to All:
> On Wednesday, December 13, 2017 at 6:43:59 AM UTC+13, Vince Coen
> wrote:
the CIS Cobol group or the early workbench one but of a same I (and my
wife) downsized last year and I through out a lot of dead wood include
floppies of one size and another which included Workbench v3.3/4 Cis Cobol
and MF Cobol.
However I suspect I still have the zip.d files for some of them around my
file system as I seem to recall finding a few of CPM and v2/4 pcdos/msdos
series sets and may well not have deleted them all.
No, I really have no user for them as I run under Linux for over 10 years
since giving up on OS/2 when IBM did.
Vince
Tuesday December 12 2017 22:29, Richard wrote to All:
> On Wednesday, December 13, 2017 at 6:43:59 AM UTC+13, Vince Coen
> wrote:
>> If fact the first Cobol compiler to use this method of generating an
>> int (intermediary) language that is executed by the runtime tool is
>> MF Cobol (CIS Cobol as the first formal release into PCDos
>> int (intermediary) language that is executed by the runtime tool is
>> MF Cobol (CIS Cobol as the first formal release into PCDos
> Microsoft also had its own COBOL compiler that compiled to some form
> of intermediate code. This was released in 1978 for CP/M and much
> later for PC/MS-DOS. It was never developed beyond single-user and
> later Microsoft COBOLs were rebranded Microfocus ones.
Yep, the MF rebrand was the v4 series but cannot remember if it was one of
> of intermediate code. This was released in 1978 for CP/M and much
> later for PC/MS-DOS. It was never developed beyond single-user and
> later Microsoft COBOLs were rebranded Microfocus ones.
the CIS Cobol group or the early workbench one but of a same I (and my
wife) downsized last year and I through out a lot of dead wood include
floppies of one size and another which included Workbench v3.3/4 Cis Cobol
and MF Cobol.
However I suspect I still have the zip.d files for some of them around my
file system as I seem to recall finding a few of CPM and v2/4 pcdos/msdos
series sets and may well not have deleted them all.
No, I really have no user for them as I run under Linux for over 10 years
since giving up on OS/2 when IBM did.
Vince
Richard
Dec 14, 2017, 7:26:45 PM12/14/17
to
On Wednesday, December 13, 2017 at 1:21:25 PM UTC+13, Vince Coen wrote:
>
> Talking of the ICT1500 I still remember having to wait for time on a 1900
> so did some work on 1500 putting a compile through that took all day
> running on a four tape system.
The ICT 1500 and the ICL 1500 were completely different things. The ICT 1500 was a mainframe in the early 60s. The ICL 1500 series were networked desktop computers that were originally made by Cogar Corporation which were part of Singer Computers when ICL bought them. The 1503 had a disk drive of 2.5 Mbyte or perhaps 5Mbyte. The 1501 was the size of a large typewriter (but no printing) with a couple of mini-tapes, a small screen and keyboard, connected by network to a 1503.
>
> Talking of the ICT1500 I still remember having to wait for time on a 1900
> so did some work on 1500 putting a compile through that took all day
> running on a four tape system.
When the DR20 was built (in New York in the the ex-Cogar factory) the initial processor board was 'Retained Mode' and emulated a 1500. Later the 'Native Mode' 8085AH2 powered processor board was released. Both processors ran CIS COBOL but the Retained Mode was pathetically slow, especially on DISPLAY.
I still have some DRS20 machines and spares here (and also DRS300 and PC2, Quattro, etc, even a Clan3).
Richard
Dec 14, 2017, 7:43:23 PM12/14/17
to
On Thursday, December 14, 2017 at 1:05:47 PM UTC+13, Vince Coen wrote:
> Yep, the MF rebrand was the v4 series but cannot remember if it was one of
> the CIS Cobol group or the early workbench one but of a same
MS COBOL V4.x and V5.x were rebranded MF COBOL/2 which were after CIS and Level 2 COBOL but before Workbench.
> Yep, the MF rebrand was the v4 series but cannot remember if it was one of
> the CIS Cobol group or the early workbench one but of a same
> No, I really have no user for them as I run under Linux for over 10 years
> since giving up on OS/2 when IBM did.
Vince Coen
Dec 15, 2017, 8:02:49 PM12/15/17
to
<o68m2d562kcddb14h...@4ax.com>
<f98g1t...@mid.individual.net>
<9aa50e79-6b13-4449...@googlegroups.com>
<15130...@f1.n250.z2.fidonet.ftn> <5f0c52a5-1b51-4c30-9e53-90c13aa9d
Hello Richard!
Friday December 15 2017 00:26, Richard wrote to All:
> On Wednesday, December 13, 2017 at 1:21:25 PM UTC+13, Vince Coen
was a Mag tape based system (well it was at G. Wimpey) with a small core
but do not remember any other details as I used it but for a week or so
when doing some maintainance on a Cobol program or two.
> When the DR20 was built (in New York in the the ex-Cogar factory) the
> initial processor board was 'Retained Mode' and emulated a 1500. Later
> the 'Native Mode' 8085AH2 powered processor board was released. Both
> processors ran CIS COBOL but the Retained Mode was pathetically slow,
> especially on DISPLAY.
> I still have some DRS20 machines and spares here (and also DRS300 and
> PC2, Quattro, etc, even a Clan3).
I will pass if only its a long way :)
However if you know of a working :
ICL 2900 or 3900 series systems making use of the fujitsu PC base for VME I
woul like to get one up and running if nothing else than so students and
some of us old ICL people can have a play remotely.
I could afford to run the PC versions but not a 3 phase orange box however
there is a 2966 at Bletchley Park sort of running but not the hard drives
as the engineer who is trying to get it operational is using a PC type hard
drive SCSI may be ?, but not running VME.
Any way its way too big to fit in my garage.
Vince
<f98g1t...@mid.individual.net>
<9aa50e79-6b13-4449...@googlegroups.com>
<15130...@f1.n250.z2.fidonet.ftn> <5f0c52a5-1b51-4c30-9e53-90c13aa9d
Hello Richard!
Friday December 15 2017 00:26, Richard wrote to All:
> On Wednesday, December 13, 2017 at 1:21:25 PM UTC+13, Vince Coen
> wrote:
>>
>> Talking of the ICT1500 I still remember having to wait for time on a
>> 1900 so did some work on 1500 putting a compile through that took
>> all day running on a four tape system.
> The ICT 1500 and the ICL 1500 were completely different things. The
> ICT 1500 was a mainframe in the early 60s. The ICL 1500 series were
> networked desktop computers that were originally made by Cogar
> Corporation which were part of Singer Computers when ICL bought them.
> The 1503 had a disk drive of 2.5 Mbyte or perhaps 5Mbyte. The 1501 was
> the size of a large typewriter (but no printing) with a couple of
> mini-tapes, a small screen and keyboard, connected by network to a
> 1503.
Yes I was referring to the mainframe that preceded ICT 1900 series and this
>>
>> Talking of the ICT1500 I still remember having to wait for time on a
>> 1900 so did some work on 1500 putting a compile through that took
>> all day running on a four tape system.
> The ICT 1500 and the ICL 1500 were completely different things. The
> ICT 1500 was a mainframe in the early 60s. The ICL 1500 series were
> networked desktop computers that were originally made by Cogar
> Corporation which were part of Singer Computers when ICL bought them.
> The 1503 had a disk drive of 2.5 Mbyte or perhaps 5Mbyte. The 1501 was
> the size of a large typewriter (but no printing) with a couple of
> mini-tapes, a small screen and keyboard, connected by network to a
> 1503.
was a Mag tape based system (well it was at G. Wimpey) with a small core
but do not remember any other details as I used it but for a week or so
when doing some maintainance on a Cobol program or two.
> When the DR20 was built (in New York in the the ex-Cogar factory) the
> initial processor board was 'Retained Mode' and emulated a 1500. Later
> the 'Native Mode' 8085AH2 powered processor board was released. Both
> processors ran CIS COBOL but the Retained Mode was pathetically slow,
> especially on DISPLAY.
> I still have some DRS20 machines and spares here (and also DRS300 and
> PC2, Quattro, etc, even a Clan3).
However if you know of a working :
ICL 2900 or 3900 series systems making use of the fujitsu PC base for VME I
woul like to get one up and running if nothing else than so students and
some of us old ICL people can have a play remotely.
I could afford to run the PC versions but not a 3 phase orange box however
there is a 2966 at Bletchley Park sort of running but not the hard drives
as the engineer who is trying to get it operational is using a PC type hard
drive SCSI may be ?, but not running VME.
Any way its way too big to fit in my garage.
Vince
0 new messages