'Dave Wade' dave.g4ugm@gmail.com [H390-MVS]
2018-02-08 11:33:17 UTC
Paul,
I think started working on the software in 1986 but it was already at V2 when I joined the team, so at least couple of years before GCC was started. The aim of the project was to provide portable networking software for use on UK Universities computers.
At that time UK Universities generally had a central computing facility that was government funded so all comments about logic, sense and options go out of the window. In order to get the money, the computer vendor had to provide some features that government mandated. One of these was a Fortran-77 compiler, the other was X.25 Networking coloured book protocols.
https://en.wikipedia.org/wiki/Coloured_Book_protocols
These were a set of protocols for terminal access, file transfer, e-mail and "job transfer and manipulation". They were meant to be interim protocols to bridge the gap while manufacturers provided the equivalent OSI protocols, which of course never happened, as despite the EU trying to mandate them for EU funded projects they went the same way as OS/2 and folks adopted the US dominated TCP/IP stack as it worked. Any way as the governments procurement agency mandated Fortran77 we used that. It was the only compiler guaranteed to be on all of the target market machines. They did look long and hard at "C" but at that time there were a number of issues with the availability of "C". The "defacto" "C" compiler at that time was the Bell Labs "Portable C" but it wasn't available to commercial sites and Salford had aspirations to sell to commerce. The VM/CMS port didn't integrate well with other CMS applications and the alternative was SAS C which was expensive. We had SAS c at NERC (see below) and it wasn't very popular.
Salford got into this business as they had bought some PR1ME Computers and as part of the deal Pr1me paid Salford to develop the necessary X.25 software.
In the end Salford also ported a Fortran 77 compiler to Pr1me as the systems were benchmarked on the Pr1me Fortran 66 compiler, and when Pr1me Fortran77 was released it was a "dog". Some history is here:-
http://www.silverfrost.com/53/ftn77_personal_edition.aspx
(note they also developed a "C" compiler for student use...)
I think that as this as all interim code the UK Joint Network Team (JNT) who managed this and provided the Janet network put in some money as well
https://en.wikipedia.org/wiki/JANET
The software was ported to a number of architectures, including S/370 and VM/CMS. Around this time UK government policy had recently changed from mandating UK computer hardware to an open policy. IBM who had to some extent been frozen out of the market, were keen to re-engage and paid Salford to port the software to VM/CMS. They arranged for them to have time on a 4341 (I think) in their IBM Customer Demonstration Centre and provided an X25 link, and a Series/1 which had a Channel Adaptor connected to the 43xx. I am not sure who wrote the S/1 software, but that talked across the channel to an assembler program called SUCOMMS which ran as disconnected VM. This was basically an X.25 switch. Applications talked to it via IUCV. The coloured books were provided by a huge Fortran program, SPCP that also ran in disconnected VM. This provided Mail, File Transfer, and Job Transfer, but the latter was little used on VM. There were user programs that ran in users CMS machine that communicated with SPCP via SUCOMMS to send and receive MAIL and queue file and job transfers. Yes File Transfer was a queued batch task. Typically, sites had one network link at 9600bps so work could be slow.
The SPPC was a nightmare. There was a macro processor that one ran on the "MAIN" program that simplified the coding to a certain extent. There were lots of include files. Low level network was done in assembler routines... It was often used as a "torture Test" by universities for their Fortran compilers.
I got involved as I had been the systems programmer on an IBM VM/CMS machine at NERC Wallingford (near Oxford).
http://www.nerc.ac.uk/
and had installed the Salford software there and had worked on Coloured Book software (written in "B") on the NERC Honeywell at Bidston.
https://en.wikipedia.org/wiki/Central_Computer_and_Telecommunications_Agency
and spent several years working on this software
Dave
I think started working on the software in 1986 but it was already at V2 when I joined the team, so at least couple of years before GCC was started. The aim of the project was to provide portable networking software for use on UK Universities computers.
At that time UK Universities generally had a central computing facility that was government funded so all comments about logic, sense and options go out of the window. In order to get the money, the computer vendor had to provide some features that government mandated. One of these was a Fortran-77 compiler, the other was X.25 Networking coloured book protocols.
https://en.wikipedia.org/wiki/Coloured_Book_protocols
These were a set of protocols for terminal access, file transfer, e-mail and "job transfer and manipulation". They were meant to be interim protocols to bridge the gap while manufacturers provided the equivalent OSI protocols, which of course never happened, as despite the EU trying to mandate them for EU funded projects they went the same way as OS/2 and folks adopted the US dominated TCP/IP stack as it worked. Any way as the governments procurement agency mandated Fortran77 we used that. It was the only compiler guaranteed to be on all of the target market machines. They did look long and hard at "C" but at that time there were a number of issues with the availability of "C". The "defacto" "C" compiler at that time was the Bell Labs "Portable C" but it wasn't available to commercial sites and Salford had aspirations to sell to commerce. The VM/CMS port didn't integrate well with other CMS applications and the alternative was SAS C which was expensive. We had SAS c at NERC (see below) and it wasn't very popular.
Salford got into this business as they had bought some PR1ME Computers and as part of the deal Pr1me paid Salford to develop the necessary X.25 software.
In the end Salford also ported a Fortran 77 compiler to Pr1me as the systems were benchmarked on the Pr1me Fortran 66 compiler, and when Pr1me Fortran77 was released it was a "dog". Some history is here:-
http://www.silverfrost.com/53/ftn77_personal_edition.aspx
(note they also developed a "C" compiler for student use...)
I think that as this as all interim code the UK Joint Network Team (JNT) who managed this and provided the Janet network put in some money as well
https://en.wikipedia.org/wiki/JANET
The software was ported to a number of architectures, including S/370 and VM/CMS. Around this time UK government policy had recently changed from mandating UK computer hardware to an open policy. IBM who had to some extent been frozen out of the market, were keen to re-engage and paid Salford to port the software to VM/CMS. They arranged for them to have time on a 4341 (I think) in their IBM Customer Demonstration Centre and provided an X25 link, and a Series/1 which had a Channel Adaptor connected to the 43xx. I am not sure who wrote the S/1 software, but that talked across the channel to an assembler program called SUCOMMS which ran as disconnected VM. This was basically an X.25 switch. Applications talked to it via IUCV. The coloured books were provided by a huge Fortran program, SPCP that also ran in disconnected VM. This provided Mail, File Transfer, and Job Transfer, but the latter was little used on VM. There were user programs that ran in users CMS machine that communicated with SPCP via SUCOMMS to send and receive MAIL and queue file and job transfers. Yes File Transfer was a queued batch task. Typically, sites had one network link at 9600bps so work could be slow.
The SPPC was a nightmare. There was a macro processor that one ran on the "MAIN" program that simplified the coding to a certain extent. There were lots of include files. Low level network was done in assembler routines... It was often used as a "torture Test" by universities for their Fortran compilers.
I got involved as I had been the systems programmer on an IBM VM/CMS machine at NERC Wallingford (near Oxford).
http://www.nerc.ac.uk/
and had installed the Salford software there and had worked on Coloured Book software (written in "B") on the NERC Honeywell at Bidston.
https://en.wikipedia.org/wiki/Central_Computer_and_Telecommunications_Agency
and spent several years working on this software
Dave
-----Original Message-----
Sent: 08 February 2018 01:11
Subject: RE: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion
Hi Dave.
What year did you write in Fortran because of the unavailability of C?
I wonder what things would have looked like if GCC had been ported earlier.
BFN. Paul.
Paul,
The original writer probably didn't have "C" available. I maintained code in
FORTRAN and Assembler that did a similar thing over x.25 networks because
many Universities did not have a Mainframe "C" compiler.
I bet its all in assembler. If it uses a TCP/IP network then which tcp/ip
interface does it use (I think there are at least three).
What security interfaces does it use? Does it interface to RACF? Sounds
really nasty...
Whats at the other end?
Dave
does the S/370 assembler component of that do?
processing based on that, how were you hoping that a S/370 translator would
S/370 assembler should have been written in in the first place, to solve this >
exact problem you are facing.
em: quarta-feira, 7 de fevereiro de 2018 13:58 > Para: H390-
Re: RES: RES: RES: [H390-MVS] Re: Unysis conversion > > > > > Can you tell
me the nature of the S/370 code that > is supposedly running 24 hours/day?
It's clearly > not a batch job if that's the case. Is it a CICS > application?
Written in S/370 assembler???
code and produce an output > file. Note that you can execute an IEFBR14 >
in about 5 seconds, ie that's how long it > takes to IPL MVS on a PC.
as you could always compile > your main (C?) application into S/370 instead
of > Unisys to provide a standalone load module.
whether this is an issue or not.
Re: RES: RES: [H390-MVS] Re: Unysis conversion > > Ask the user why
running compiled S/370 code > on the production machine is OK, but running
script that is available > as part of the MVS/380 project?
------------------------------------
------------------------------------
Yahoo Groups Links
Sent: 08 February 2018 01:11
Subject: RE: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion
Hi Dave.
What year did you write in Fortran because of the unavailability of C?
I wonder what things would have looked like if GCC had been ported earlier.
BFN. Paul.
Paul,
The original writer probably didn't have "C" available. I maintained code in
FORTRAN and Assembler that did a similar thing over x.25 networks because
many Universities did not have a Mainframe "C" compiler.
I bet its all in assembler. If it uses a TCP/IP network then which tcp/ip
interface does it use (I think there are at least three).
What security interfaces does it use? Does it interface to RACF? Sounds
really nasty...
Whats at the other end?
Dave
-----Original Message-----
Re: RES: RES: RES: RES: [H390-MVS] Re: Unysis conversion > > And whatdoes the S/370 assembler component of that do?
If the S/370 assembler currently does an OPEN of DDNAME SYSUT1, and >
checks the DCB information to see if it is F/V/U and then does various >processing based on that, how were you hoping that a S/370 translator would
translate that code to be suitable for Unisys?
And how many lines of S/370 assembler are we talking about? It may be >
simpler to write replacement code in C, which is possibly what the original >And how many lines of S/370 assembler are we talking about? It may be >
S/370 assembler should have been written in in the first place, to solve this >
exact problem you are facing.
You're in with a shot at porting C code, but there's a dearth of options
when > it comes to 370 assembler.BFN. Paul.
The sw to run is like an improved FTP server and must be available to >
send/receive files anytime, among other functionalities > > > > De: H390-The sw to run is like an improved FTP server and must be available to >
em: quarta-feira, 7 de fevereiro de 2018 13:58 > Para: H390-
Re: RES: RES: RES: [H390-MVS] Re: Unysis conversion > > > > > Can you tell
me the nature of the S/370 code that > is supposedly running 24 hours/day?
It's clearly > not a batch job if that's the case. Is it a CICS > application?
Written in S/370 assembler???
If it's part of an application suite, you can just > execute a script whenever
you need this > functionality. The script will start MVS and > run your S/370code and produce an output > file. Note that you can execute an IEFBR14 >
in about 5 seconds, ie that's how long it > takes to IPL MVS on a PC.
How many separate S/370 programs and
source files are involved?
If it's an S/370 routine to calculate "pi" or > something, then Hercules isn't
of much use > to you. Although even then, it's still not out > of the questionsource files are involved?
If it's an S/370 routine to calculate "pi" or > something, then Hercules isn't
as you could always compile > your main (C?) application into S/370 instead
of > Unisys to provide a standalone load module.
Sure, it won't be as fast as having the application > written all in C so that
you can produce Unisys > code, but it depends on your exact application >whether this is an issue or not.
BFN. Paul.
Another interesting point of view.
But the sw will be up and running 24 hours/day > > > De: H390-
Enviada em: quarta-feira, 7 de fevereiro de 2018 13:30 > Para: H390-Another interesting point of view.
But the sw will be up and running 24 hours/day > > > De: H390-
Re: RES: RES: [H390-MVS] Re: Unysis conversion > > Ask the user why
running compiled S/370 code > on the production machine is OK, but running
compiled C code on the production machine is > not OK.
Source code for both is probably available > (definitely available for
Hercules) so maybe > he doesn't understand what Hercules is.Source code for both is probably available > (definitely available for
Does he understand that he doesn't need > to actually operate Hercules,
it can all be > set up to start and terminate automatically?Unless there's some sort of Hercules bug, > anyway (occasionally a batch
run will fail > for me).Also, Hercules can probably be compiled > into Unisys assembler which is
presumably > allowed.BFN. Paul.
Very interesting,
however the user doesnât want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs > > De: H390-
quarta-feira, 7 de fevereiro de 2018 12:08 > Para: H390-Very interesting,
however the user doesnât want to run Hercules in his production machine.
ThatÂŽs why I have to convert the programs > > De: H390-
Assunto: Re: RES: [H390-MVS] Re: Unysis conversion > > ---In H390-
Running Hercules under Unisys *is* a real > Unisys environment, isn't it?In fact Iâd like to run my MVS sw in an Unisys real environment > >
Is the code time-critical that you can't afford > the Hercules overhead?
Is the MVS code batch or TSO?
If it is batch, are you aware that you can > automatically start Hercules, run
an MVS > job, transfer the output file, all automatically > using the "runmvs"Is the MVS code batch or TSO?
If it is batch, are you aware that you can > automatically start Hercules, run
script that is available > as part of the MVS/380 project?
Depending on your requirements there is > also Jason Winter's code to
provide host > file access that may enter the discussion.BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links
------------------------------------------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links
------------------------------------
------------------------------------
Yahoo Groups Links