Re: vm/sp 5.5 living computer museum
On the late eighties DPS8 was a common mainframe in Spain and France.
In 1982, DPS6? was a lower level and in fact there were a 32 bits running GCOS6, and a low end 16 bit cpu with only 1 MB addressable without virtual memory, in other words, equal to a 8086 Intel, but a lot more expensive...
|
Re: vm/sp 5.5 living computer museum
Alex, More Info here:- ? ? for Info I was a “Systems Programme” on Honeywell L66 systems with GCOS 3 from around 1977 to 1985 when I moved onto VM/CMS on a 4381. First at Refuge Assurance where we had a L66/10 mostly running batch with some transaction processing. Almost all Cobol. Later at NERC Bidston at what was “The Institute of Tides and Coastal Oceanography” where it was almost all time sharing and Fortran. We had a L66/60 that was upgraded to DPS300 so basically a dual CPU L66. Very different systems… ? Dave ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Dave Wade via groups.io
Sent: 04 July 2020 13:09
To: [email protected]
Subject: Re: [h390-vm] vm/sp 5.5 living computer museum? Alex, ? Oh to be in Spain! ? I don’t think the DPS6 CPUs have any relationship to Multics. DPS6 was a new mini developed in Ireland I think with a 32bit word ? They are related to the DPS8. The original Multics CPU was derived from the GE600 CPU but heavily modified to provide protection rings and I believe virtual memory support. When Honeywell bought GE the GE600 was basically re-badged as the H6000 and core memory replaced with semi-conductor RAM The Multics version was re-badged the 6180 and some components changed.. I believe not that much of the 6000 CPU was left…. Later it the range was again re-badged L66 with the multics box being L68. The other Honeywell machines were named try and make them feel like a range, but in practice they weren’t. The DPS 8 was I believe “yet another re-badging of the same CPU” and a change of case. ? So I understand MULTICS includes some GECOS emulation and will run L66/DPS8 programs. ? Dave ? ? ? ? Hi Jim,
About Multics and Honeywell, do you know if GCOS8 of DPS8 and/or GCOS6 of DPS6 cpus from HONEYWELL BULL had any relation with Multics?
I worked as system programmer with GCOS6 in the 80s.
Thankyou.
Alex G
Barcelona
|
Re: vm/sp 5.5 living computer museum
Alex, ? Oh to be in Spain! ? I don’t think the DPS6 CPUs have any relationship to Multics. DPS6 was a new mini developed in Ireland I think with a 32bit word ? They are related to the DPS8. The original Multics CPU was derived from the GE600 CPU but heavily modified to provide protection rings and I believe virtual memory support. When Honeywell bought GE the GE600 was basically re-badged as the H6000 and core memory replaced with semi-conductor RAM The Multics version was re-badged the 6180 and some components changed.. I believe not that much of the 6000 CPU was left…. Later it the range was again re-badged L66 with the multics box being L68. The other Honeywell machines were named try and make them feel like a range, but in practice they weren’t. The DPS 8 was I believe “yet another re-badging of the same CPU” and a change of case. ? So I understand MULTICS includes some GECOS emulation and will run L66/DPS8 programs. ? Dave ? ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Alex Garcia via groups.io
Sent: 04 July 2020 12:41
To: [email protected]
Subject: Re: [h390-vm] vm/sp 5.5 living computer museum? Hi Jim,
About Multics and Honeywell, do you know if GCOS8 of DPS8 and/or GCOS6 of DPS6 cpus from HONEYWELL BULL had any relation with Multics?
I worked as system programmer with GCOS6 in the 80s.
Thankyou.
Alex G
Barcelona
|
Re: vm/sp 5.5 living computer museum
Hi Jim,
About Multics and Honeywell, do you know if GCOS8 of DPS8 and/or GCOS6 of DPS6 cpus from HONEYWELL BULL had any relation with Multics?
I worked as system programmer with GCOS6 in the 80s.
Thankyou.
Alex G
Barcelona
|
Re: vm/sp 5.5 living computer museum
On 7/3/20 7:41 PM, Joe Monk wrote:
thats not completely true...
[-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]
??
-+-? living
computers? museum + labs ? REMOTE ACCESS?
-+-
[-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]
[a]
multics
? ? ? ? ? ? Multics MR12.6f ? ? ? ? Honeywell 6180
[b]
toad-2?
? ? ? ? ? ? TOPS-20 7(110131)-1 ? ? XKL TOAD-2
[c]
lcm3b2?
? ? ? ? ? ? UNIX SVR3.2.3 ? ? ? ? ? AT&T 3B2/1000-70
[d]
cdc6500
? ? ? ? ? ? NOS 1.3 ? ? ? ? ? ? ? ? CDC-6500
[e]
lc? ?
? ? ? ? ? ? ? ITS ver 1648? ? ? ? ? ? KA/PDP-6 sn 4
[z]
bitzone
? ? ? ? ? ? NetBSD BBS? ? ? ? ? ? ? AMD64
(main)
Your choice?
(q to quit):?
So
... some systems are running there.
I (very cheerfully) stand corrected.
--
Drew Derbyshire
"mad, bad, and dangerous to know"
-- Lady Caroline Lamp, referring to Lord Byron
|
Re: vm/sp 5.5 living computer museum
On 7/3/2020 7:41 PM, Joe Monk wrote:
So
... some systems are running there.
Joe
The people I know aren't.
very sad.
Multics never answered.? That is a beautiful machine.?
It all would be great with the people there to run the place.
thanks
Jim
|
Re: vm/sp 5.5 living computer museum
thats not completely true...
[-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]
?? -+-? living computers? museum + labs ? REMOTE ACCESS? -+-
[-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]
[a] multics ? ? ? ? ? ? Multics MR12.6f ? ? ? ? Honeywell 6180
[b] toad-2? ? ? ? ? ? ? TOPS-20 7(110131)-1 ? ? XKL TOAD-2
[c] lcm3b2? ? ? ? ? ? ? UNIX SVR3.2.3 ? ? ? ? ? AT&T 3B2/1000-70
[d] cdc6500 ? ? ? ? ? ? NOS 1.3 ? ? ? ? ? ? ? ? CDC-6500
[e] lc? ? ? ? ? ? ? ? ? ITS ver 1648? ? ? ? ? ? KA/PDP-6 sn 4
[z] bitzone ? ? ? ? ? ? NetBSD BBS? ? ? ? ? ? ? AMD64
(main) Your choice? (q to quit):?
So ... some systems are running there.
Joe
On Fri, Jul 3, 2020 at 9:02 PM Dave McGuire < mcguire@...> wrote: On 7/3/20 9:57 AM, James Stephens wrote:
> The LCM went completely dark with the last staff locked out and
> permanently laid off on 7/1.
>
> Pretty much a funeral for it.? No word or indication about what Vulcan
> is doing with any such operation it didn't spin off with its own endowment.
>
> If other handling is any indication, the prognosis is grim.
>
> Wish Paul had had some words explicitly in his provisions for some of
> this.? His heirs seem to be acting like bean counters rather than
> looking after his and the heritage of these institutions.
? The passing of a person with money brings out the very worst of
humanity.? I've seen this with my own eyes, when only a little bit of
money was involved.? This was a LOT of money.
? Of course nobody knows what actually happened, but it really doesn't
look good, and it looks very familiar.
? ? ? ? ? ? ? -Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
|
Re: vm/sp 5.5 living computer museum
On 7/3/20 9:57 AM, James Stephens wrote: The LCM went completely dark with the last staff locked out and
permanently laid off on 7/1.
Pretty much a funeral for it.? No word or indication about what Vulcan
is doing with any such operation it didn't spin off with its own endowment.
If other handling is any indication, the prognosis is grim.
Wish Paul had had some words explicitly in his provisions for some of
this.? His heirs seem to be acting like bean counters rather than
looking after his and the heritage of these institutions. The passing of a person with money brings out the very worst of humanity. I've seen this with my own eyes, when only a little bit of money was involved. This was a LOT of money. Of course nobody knows what actually happened, but it really doesn't look good, and it looks very familiar. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
|
Re: vm/sp 5.5 living computer museum
". . .There are not many who remember They say a handful still survive To tell the world about The way the lights went out And keep the memory alive" -- Billy Joel On 7/3/20 6:57 AM, James Stephens wrote: The LCM went completely dark with the last staff locked out and permanently laid off on 7/1.
Pretty much a funeral for it.? No word or indication about what Vulcan is doing with any such operation it didn't spin off with its own endowment.
If other handling is any indication, the prognosis is grim.
Wish Paul had had some words explicitly in his provisions for some of this.? His heirs seem to be acting like bean counters rather than looking after his and the heritage of these institutions. ICYMI, the entire division is shut down including (the far better known and popular) Cinerama: The LCM+L IBM 4361 telnet connection was flaky the last two weeks of June, and as noted above there is no one left to kick it.? Sad, indeed. More importantly, I see that tty.livingcomputers.org is prompting for SSH passwords for the other (more reliable) systems' gateways.? That looks like an final explicit action to prevent vandalism. We can only hope the CHM, LSSM, or other someone else adopts some of the orphans. -ahd- p.s. (Possibly for the last time) yes, my usual LCM+L disclaimer applies. -- Drew Derbyshire "Why do I do this? Three reasons: the pay is good, the scenery changes, and they let me use explosives." -- "Armageddon"
|
Re: vm/sp 5.5 living computer museum
The LCM went completely dark with the last staff locked out and permanently laid off on 7/1.
Pretty much a funeral for it.? No word or indication about what Vulcan is doing with any such operation it didn't spin off with its own endowment.
If other handling is any indication, the prognosis is grim.
Wish Paul had had some words explicitly in his provisions for some of this.? His heirs seem to be acting like bean counters rather than looking after his and the heritage of these institutions.
toggle quoted message
Show quoted text
On 7/3/2020 4:40 AM, rvjansen@... wrote: Does anybody know? The 4361? Is it gone now? That would be a real shame.
搁别苍é.
|
Re: vm/sp 5.5 living computer museum
I believe it's offline during the pandemic.
toggle quoted message
Show quoted text
On 7/3/20 7:40 AM, rvjansen@... wrote: Does anybody know? The 4361? Is it gone now? That would be a real shame.
搁别苍é.
|
vm/sp 5.5 living computer museum
Does anybody know? The 4361? Is it gone now? That would be a real shame.
搁别苍é.
|
Re: VM/370 Hercules Optimisation
Drew,
A model 158 had an AP and an MP option.? With AP, you could get at least 6 MB of real main storage on there...? (ask me how I know this ...) ;-)?? (With a 158-MP, I think 8MB was the max.)
Also, VM/370 could be configured for an AP environment.? Unlike MVS, with a hierarchy of "locks" I think VM had just a single "global" lock that CP would acquire, as needed, when updating any of the CP control blocks, so that both CPUs did not try to update the same control blocks at the same time.
MVS 3.8J also fully supported both the AP and MP configurations of the 158 and 168, back in those days.
Folks who want to use more "cores" on modern processors running under Hercules-390 can emulate a 158-AP/MP, 168-AP/MP, or 3031/3033 AP/MP configuration, in the SYSGEN of VM/370 Rel.6 or MVS 3.8J.
Cheers,
Mark S. Waterbury
|
On Fri, Jun 26, 2020 at 10:12 PM, adriansutherland67 wrote:
4/ I have become amazed at the technical culture disconnect between those steeped in IBM lore and those not so lucky. Take the word reentrant. I have had many many debates ... if I had know what you guys meant was not writing to the code segment (an alien concept anyway) ... well lots of time would have been saved. I wonder how many other concepts have diverged and if anyone even knows this happens ...?
Not that I think the rexx symposium is a place to discuss technological culture ... but it probably is worth a blog post; my mind was wandering last night!
|
A few thoughts?
1/ I would of course be delighted to present with Bob, flattered.
2/ We have not achieved much yet ...
3/ in terms of VM/370 isn't the full screen stuff awesome!
4/ I have become amazed at the technical culture disconnect between those steeped in IBM lore and those not so lucky. Take the word reentrant. I have had many many debates ... if I had know what you guys meant was not writing to the code segment (an alien concept anyway) ... well lots of time would have been saved. I wonder how many other concepts have diverged and if anyone even knows this happens ...?
5/ As discussed, be careful ... I do intend to experiment with modernising rexx ... :-)
|
Hi Bob,
you would be surprised how many in the audience were on VM one time or another, or started out on VM and got to know Rexx there; and also, I see it as an opportunity to introduce the VM/370 system on Hercules to people who would certainly considering using it when the Rexx on it would be stable, or more stable than it is today. I’ll get back to you when the dates are fixed - should be soon now. Much appreciated!
best regards,
toggle quoted message
Show quoted text
On 26 Jun 2020, at 20:38, Bob Bolch < Bob@...> wrote:
Rene, I haven't been to a REXX Symposium since the ones here in RTP, NC. I would be glad to go over the CMS specific interfaces I am making for BREXX. I have no interest in portable interfaces not found on VM, because all my use will be on VM. Are system independant interfaces going to attract users on VM/370? I doubt it. I see value in being able to use tools built over the last 40 years, for existing VM users with collections of tools.? It doesn't seem like the current REXXLA group is using VM at all, from the list of presentations over the last few symposiums.? What I am implementing is Nucleus Extensions and Subcommand interfaces for general VM use. CMS BREXX can use those changes to: 1. Call REXX function packages in Assembler. I have the sample ? ? function packages from the IBM pubs running under test drivers.? 2. Complete the ADDRESS statement support to issue subcommands to ? ? any product implementing a subcom interface. BREXX can then be used ? ? to write macros for a product like an editor. 3. Complete the EXECCOMM REXX subcommand. Access to retrieve and update ? ? REXX variables from an external program allows EXECIO to be easily written.
Is a non-VM REXX audience really interested in these issues?? If so, I'm glad to discuss them in a session. Are the dates confirmed yet?
Bob Bolch?
? ?? I just flagged this as I was busy getting z/VM lpars to IPL after running for months since last year - the lpars, not me ;-)
I thought everything went rather well - when BREXX has the stream I/O functions, we should use those, however anachronistic these are for TSO and pre-ESA VM. We should try to pinpoint when these exactly popped up - they did not make the initial drop to Endicott and for example TSO never had them until Open Edition appeared; I heard 2.4 finally has them for TSO but I did not check yet.
Future pain when comparing them - sure. If it has these, they should be compatible to the IBM Rexx versions, no? But that does not need to be from the start.
There is a tradeoff with implementing function in C and staying compatible to IBM versions, and implementing in EXECCOM. C will probably be very portable over the platforms, while EXECCOM needs much more work to implement the same thing for all platforms - but prove me wrong on this. I hope we can be efficient in this, with a very well specced way of overriding a C implementation with a platform dependent one - so the people on VM can have what they want, but for example the people on Raspberry Pi still can have the C version - a bit like ooRexx also has an EXECIO but I need to check if that is implemented as external function at all.
What would be really cool if we can get to a compiler for Rexx tokenized code that implements these things in its runtime.
I had The Rexx Handbook many years ago but it probably was ‘borrowed’ somewhere down the line, I just received a new copy from Amazon and it is certainly a very worthwhile resource. It has chapters that delve into tokenizing and differences between the 5 IBM implementations of Rexx.
I added some testcases and stirred up some trouble. So I hope the quiet on this list does not mean we are less interested.
Adrian/Bob - would you be able to do 45 minute presentations on your work for the International Rexx Language Symposium (which for the first time in 30 years, will be entirely online)?
best regards,
搁别苍é On 23 Jun 2020, at 15:55, Bob Bolch < bob@...> wrote:
I have no objections to the LINEIN,?LINEOUT, CHARIN,CHAROUT stream I/O. Those were in VM/ESA 2.4 (and perhaps earlier) from 30 years ago.? I thought you were doing something more than that (not having seen any specification).
My mods for SUBCOM and NUCEXT?are almost ready, and I figured out an interface design for Brexx's EXECCOMM subcommand, so implementing?EXECIO and Rexx function packages shouldn't take long. As long as I can implement my preferred alternatives, I'm satisfied.
Bob
On Tue, Jun 23, 2020 at 9:30 AM adriansutherland67 < adrian@...> wrote: On Tue, Jun 23, 2020 at 12:06 PM, Bob Bolch wrote:
It leads people to produce CMS programs that only workin BREXX on VM/370, and not in REXX on later VM systems. Well - I too remember REXX on old school VM and as you imply it had no IO and you had to use EXECIO - so I understand your point and so I did some googling.
And I found that today (is z/VM 7.1 the latest and greatest?) REXX does implement the standard REXX IO functions that I was talking about - see?
I was surprised - and I predict future pain as people compare what I do with IBM's implementation {sigh}
In fact, I was planning to pretend that no one would miss or remember STREAM()!?
(Actually, and more seriously, BREXX has an implementation of it).
A
PS - Appreciate the point about add-ons - as you know it is on the old road-map! :-)
PPS - Presuming you don't care about the extra GCCLIB functions - I have never sensed you getting too worried about C90 standards ...
|
Rene, I haven't been to a REXX Symposium since the ones here in RTP, NC. I would be glad to go over the CMS specific interfaces I am making for BREXX. I have no interest in portable interfaces not found on VM, because all my use will be on VM. Are system independant interfaces going to attract users on VM/370? I doubt it. I see value in being able to use tools built over the last 40 years, for existing VM users with collections of tools.? It doesn't seem like the current REXXLA group is using VM at all, from the list of presentations over the last few symposiums.? What I am implementing is Nucleus Extensions and Subcommand interfaces for general VM use. CMS BREXX can use those changes to: 1. Call REXX function packages in Assembler. I have the sample ? ? function packages from the IBM pubs running under test drivers.? 2. Complete the ADDRESS statement support to issue subcommands to ? ? any product implementing a subcom interface. BREXX can then be used ? ? to write macros for a product like an editor. 3. Complete the EXECCOMM REXX subcommand. Access to retrieve and update ? ? REXX variables from an external program allows EXECIO to be easily written.
Is a non-VM REXX audience really interested in these issues?? If so, I'm glad to discuss them in a session. Are the dates confirmed yet?
Bob Bolch?
? ??
I just flagged this as I was busy getting z/VM lpars to IPL after running for months since last year - the lpars, not me ;-)
I thought everything went rather well - when BREXX has the stream I/O functions, we should use those, however anachronistic these are for TSO and pre-ESA VM. We should try to pinpoint when these exactly popped up - they did not make the initial drop to Endicott and for example TSO never had them until Open Edition appeared; I heard 2.4 finally has them for TSO but I did not check yet.
Future pain when comparing them - sure. If it has these, they should be compatible to the IBM Rexx versions, no? But that does not need to be from the start.
There is a tradeoff with implementing function in C and staying compatible to IBM versions, and implementing in EXECCOM. C will probably be very portable over the platforms, while EXECCOM needs much more work to implement the same thing for all platforms - but prove me wrong on this. I hope we can be efficient in this, with a very well specced way of overriding a C implementation with a platform dependent one - so the people on VM can have what they want, but for example the people on Raspberry Pi still can have the C version - a bit like ooRexx also has an EXECIO but I need to check if that is implemented as external function at all.
What would be really cool if we can get to a compiler for Rexx tokenized code that implements these things in its runtime.
I had The Rexx Handbook many years ago but it probably was ‘borrowed’ somewhere down the line, I just received a new copy from Amazon and it is certainly a very worthwhile resource. It has chapters that delve into tokenizing and differences between the 5 IBM implementations of Rexx.
I added some testcases and stirred up some trouble. So I hope the quiet on this list does not mean we are less interested.
Adrian/Bob - would you be able to do 45 minute presentations on your work for the International Rexx Language Symposium (which for the first time in 30 years, will be entirely online)?
best regards,
搁别苍é On 23 Jun 2020, at 15:55, Bob Bolch < bob@...> wrote:
I have no objections to the LINEIN,?LINEOUT, CHARIN,CHAROUT stream I/O. Those were in VM/ESA 2.4 (and perhaps earlier) from 30 years ago.? I thought you were doing something more than that (not having seen any specification).
My mods for SUBCOM and NUCEXT?are almost ready, and I figured out an interface design for Brexx's EXECCOMM subcommand, so implementing?EXECIO and Rexx function packages shouldn't take long. As long as I can implement my preferred alternatives, I'm satisfied.
Bob
On Tue, Jun 23, 2020 at 9:30 AM adriansutherland67 < adrian@...> wrote: On Tue, Jun 23, 2020 at 12:06 PM, Bob Bolch wrote:
It leads people to produce CMS programs that only workin BREXX on VM/370, and not in REXX on later VM systems. Well - I too remember REXX on old school VM and as you imply it had no IO and you had to use EXECIO - so I understand your point and so I did some googling.
And I found that today (is z/VM 7.1 the latest and greatest?) REXX does implement the standard REXX IO functions that I was talking about - see?
I was surprised - and I predict future pain as people compare what I do with IBM's implementation {sigh}
In fact, I was planning to pretend that no one would miss or remember STREAM()!?
(Actually, and more seriously, BREXX has an implementation of it).
A
PS - Appreciate the point about add-ons - as you know it is on the old road-map! :-)
PPS - Presuming you don't care about the extra GCCLIB functions - I have never sensed you getting too worried about C90 standards ...
|
I just flagged this as I was busy getting z/VM lpars to IPL after running for months since last year - the lpars, not me ;-)
I thought everything went rather well - when BREXX has the stream I/O functions, we should use those, however anachronistic these are for TSO and pre-ESA VM. We should try to pinpoint when these exactly popped up - they did not make the initial drop to Endicott and for example TSO never had them until Open Edition appeared; I heard 2.4 finally has them for TSO but I did not check yet.
Future pain when comparing them - sure. If it has these, they should be compatible to the IBM Rexx versions, no? But that does not need to be from the start.
There is a tradeoff with implementing function in C and staying compatible to IBM versions, and implementing in EXECCOM. C will probably be very portable over the platforms, while EXECCOM needs much more work to implement the same thing for all platforms - but prove me wrong on this. I hope we can be efficient in this, with a very well specced way of overriding a C implementation with a platform dependent one - so the people on VM can have what they want, but for example the people on Raspberry Pi still can have the C version - a bit like ooRexx also has an EXECIO but I need to check if that is implemented as external function at all.
What would be really cool if we can get to a compiler for Rexx tokenized code that implements these things in its runtime.
I had The Rexx Handbook many years ago but it probably was ‘borrowed’ somewhere down the line, I just received a new copy from Amazon and it is certainly a very worthwhile resource. It has chapters that delve into tokenizing and differences between the 5 IBM implementations of Rexx.
I added some testcases and stirred up some trouble. So I hope the quiet on this list does not mean we are less interested.
Adrian/Bob - would you be able to do 45 minute presentations on your work for the International Rexx Language Symposium (which for the first time in 30 years, will be entirely online)?
best regards,
搁别苍é
toggle quoted message
Show quoted text
On 23 Jun 2020, at 15:55, Bob Bolch < bob@...> wrote:
I have no objections to the LINEIN,?LINEOUT, CHARIN,CHAROUT stream I/O. Those were in VM/ESA 2.4 (and perhaps earlier) from 30 years ago.? I thought you were doing something more than that (not having seen any specification).
My mods for SUBCOM and NUCEXT?are almost ready, and I figured out an interface design for Brexx's EXECCOMM subcommand, so implementing?EXECIO and Rexx function packages shouldn't take long. As long as I can implement my preferred alternatives, I'm satisfied.
Bob
On Tue, Jun 23, 2020 at 9:30 AM adriansutherland67 < adrian@...> wrote: On Tue, Jun 23, 2020 at 12:06 PM, Bob Bolch wrote:
It leads people to produce CMS programs that only workin BREXX on VM/370, and not in REXX on later VM systems. Well - I too remember REXX on old school VM and as you imply it had no IO and you had to use EXECIO - so I understand your point and so I did some googling.
And I found that today (is z/VM 7.1 the latest and greatest?) REXX does implement the standard REXX IO functions that I was talking about - see?
I was surprised - and I predict future pain as people compare what I do with IBM's implementation {sigh}
In fact, I was planning to pretend that no one would miss or remember STREAM()!?
(Actually, and more seriously, BREXX has an implementation of it).
A
PS - Appreciate the point about add-ons - as you know it is on the old road-map! :-)
PPS - Presuming you don't care about the extra GCCLIB functions - I have never sensed you getting too worried about C90 standards ...
|
I have no objections to the LINEIN,?LINEOUT, CHARIN,CHAROUT stream I/O. Those were in VM/ESA 2.4 (and perhaps earlier) from 30 years ago.? I thought you were doing something more than that (not having seen any specification).
My mods for SUBCOM and NUCEXT?are almost ready, and I figured out an interface design for Brexx's EXECCOMM subcommand, so implementing?EXECIO and Rexx function packages shouldn't take long. As long as I can implement my preferred alternatives, I'm satisfied.
Bob
On Tue, Jun 23, 2020 at 9:30 AM adriansutherland67 < adrian@...> wrote: On Tue, Jun 23, 2020 at 12:06 PM, Bob Bolch wrote:
It leads people to produce CMS programs that only work
in BREXX on VM/370, and not in REXX on later VM systems.
Well - I too remember REXX on old school VM and as you imply it had no IO and you had to use EXECIO - so I understand your point and so I did some googling.
And I found that today (is z/VM 7.1 the latest and greatest?) REXX does implement the standard REXX IO functions that I was talking about - see?
I was surprised - and I predict future pain as people compare what I do with IBM's implementation {sigh}
In fact, I was planning to pretend that no one would miss or remember STREAM()!
(Actually, and more seriously, BREXX has an implementation of it).
A
PS - Appreciate the point about add-ons - as you know it is on the old road-map! :-)
PPS - Presuming you don't care about the extra GCCLIB functions - I have never sensed you getting too worried about C90 standards ...
|
On Tue, Jun 23, 2020 at 12:06 PM, Bob Bolch wrote:
It leads people to produce CMS programs that only work
in BREXX on VM/370, and not in REXX on later VM systems.
Well - I too remember REXX on old school VM and as you imply it had no IO and you had to use EXECIO - so I understand your point and so I did some googling.
And I found that today (is z/VM 7.1 the latest and greatest?) REXX does implement the standard REXX IO functions that I was talking about - see?
I was surprised - and I predict future pain as people compare what I do with IBM's implementation {sigh}
In fact, I was planning to pretend that no one would miss or remember STREAM()!
(Actually, and more seriously, BREXX has an implementation of it).
A
PS - Appreciate the point about add-ons - as you know it is on the old road-map! :-)
PPS - Presuming you don't care about the extra GCCLIB functions - I have never sensed you getting too worried about C90 standards ...
|
Dave McGuire
