Re: "Waterloo Tapes" in H390-VM group's Files area
I imagine from a real tape which came with the tapes used to build the original system. From what I remember, and it's a fuzzy memory, the process was that each site that received a copy agreed to make two copies for other sites. So most sites had a copy of the tape.
Dave
But where did Bob Abele get his copy from?? :-/
|
Re: "Waterloo Tapes" in H390-VM group's Files area
On Thu, Jan 12, 2023 at 07:37 PM, Mark Waterbury wrote:
But where did Bob Abele get his copy from?? :-/
Does anyone know if Bob Abele is still around to ask? My GUESS is he got it from the University of Waterloo, since they are identical. [xmas@vm370dev tapes]$ diff abele_waterloo.aws WATERLOO6.aws[xmas@vm370dev tapes]$ diff abele_waterloo.aws WATERLOO5.awsBinary files abele_waterloo.aws and WATERLOO5.aws differ[xmas@vm370dev tapes]$ An aside, in reading the abstract documentation on WATERLOO6.aws? ... M1086V00CIA MODS ... it points to RELEASE6 MEMO, which starts out like this. FSVIEW: RELEASE6 MEMO D1???????????????? Lines 1-39/45 F80[1-79]? FSVIEW V1.2.5We have several large mods that other installations have implemented.? Forus to give away code, we must place it in the public domain.? Hence, wetend to send a file to Waterloo only once, and send updates directly tothose few installations that we know are running the code.? Our currentsubmissions include: ...
As David F goes through each, there doesn't seem to be any changes to the CIA modifications since Release 5. The new mod included in WATERLOO6, is CLASSIFY. Though he doesn't say so in the memo, TAPEMON is on the WATERLOO5.aws tape.
FSVIEW: UW5 ABSTRACT T2?????????? Lines 1170-1208/1268 F80[1-79]? FSVIEW V1.2.5
M1122V00TAPEMON-- The tape monitor system is a real-time program operating in
the? VM/370 environment which receives and processes user requests for tape
drives and mounts.? It was designed to 1) enhance data security for tapes on th
VM/370 Interactive system, 2) provide an equitable and efficient system for
allocating tape drives, 3) reduce VM operator (VMOP) involvement in assigning
tape drives to users, and 4) reduce tape management software (TMS) operator
involvement in handling tape mount requests.? This modification requires
M1112V00PROC and M1121V00MARCO on this tape.--Ron Hooper, CIA, Tel. (703)
351-6078,? January 26, 1979.
NUMBER OF BLOCKS REQUIRED: 0000581
It may not be the absolute latest, but it appears this will be the best we can get.
I Hope This Helps
?... Mark S.
|
Re: "Waterloo Tapes" in H390-VM group's Files area
But where did Bob Abele get his copy from?? :-/
|
Re: "Waterloo Tapes" in H390-VM group's Files area
On Mon, Dec 26, 2022 at 03:13 AM, Dave Wade wrote:
Fish
I think I know where these came from, but I am away with my family so can't check. I'll let you all know when I am back
Dave
WATERLOO6.7z is identical (binary comparison on the uncompressed file) as Bob Abele's waterloo.aws tape. So that one can be credited to Bob? ?... Mark S.
|
Re: Hercules VM TCPIP - current situation?
Drew, The original code used VMCF which does exist in VM/370 so that isn¡¯t a problem. I suspect there is no source for WISCNET available. I would love to be proved wrong¡ .. transporting non-vm code to vm does not always end happily ¡. Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Drew Derbyshire
Sent: 12 January 2023 22:48
To: [email protected]
Subject: Re: [h390-vm] Hercules VM TCPIP - current situation?? On Wed, Jan 11, 2023 at 01:33 PM, Bob Bolch wrote: VMCE is based on nearly 50 year old code. IBM introduced TCPIP support years later. That IBM TCPIP code depends on facilities that were not added to VM until much later.?
VM/370 R6 PLC 17 is ~ 1980 code; TCP/IP was running at (for example) at Clarkson University in 1986.? That's not?a huge?gap; I think the primary thing missing was IUCV, but you might be to use VMCF if IUCV has not been backported to VM/CE. On Wed, Jan 11, 2023 at 10:24 PM, Bernd Oppolzer wrote: the original VM TCP/IP was written in IBMs Pascal/VS, AFAIK.
If the source code of this product could be found somewhere, I could?imagine it would be possible?to compile it with my current version of New Stanford Pascal without or?with minor changes.
If someone out there has access to the original TCP/IP source code for?VM and wants to test this,?feel free to contact me offline for discussion and support.
Any IBM TCP/IP program is a Licensed Program Product and can't be blithely redistributed in source or object. Same for the header files. So don't bother. Three legal alternatives one could consider: - IBM TCP/IP originally was based on WISCNET (); is there a pre-PP of WISCNET archive out there?
- Look for BSD network kernels, especially those ported to foreign platforms.
VM specific network adapter and client VMCF/IUCV support would have to be written. - KNET was a TCP/IP competitor from Spartacus/Fibronics. Perhaps they released their code to the public domain.
-ahd-
|
Re: Hercules VM TCPIP - current situation?
On Wed, Jan 11, 2023 at 01:33 PM, Bob Bolch wrote:
VMCE is based on nearly 50 year old code. IBM introduced TCPIP support years later. That IBM TCPIP code depends on facilities that were not added to VM until much later.?
VM/370 R6 PLC 17 is ~ 1980 code; TCP/IP was running at (for example) at Clarkson University in 1986.? That's not?a huge?gap; I think the primary thing missing was IUCV, but you might be to use VMCF if IUCV has not been backported to VM/CE.
On Wed, Jan 11, 2023 at 10:24 PM, Bernd Oppolzer wrote:
the original VM TCP/IP was written in IBMs Pascal/VS, AFAIK.
If the source code of this product could be found somewhere, I could?imagine it would be possible?to compile it with my current version of New Stanford Pascal without or?with minor changes.
If someone out there has access to the original TCP/IP source code for?VM and wants to test this,?feel free to contact me offline for discussion and support.
Any IBM TCP/IP program is a Licensed Program Product and can't be blithely redistributed in source or object. Same for the header files. So don't bother.
Three legal alternatives one could consider:
- IBM TCP/IP originally was based on WISCNET (); is there a pre-PP of WISCNET archive out there?
- Look for BSD network kernels, especially those ported to foreign platforms.
VM specific network adapter and client VMCF/IUCV support would have to be written.
- KNET was a TCP/IP competitor from Spartacus/Fibronics. Perhaps they released their code to the public domain.
-ahd-
|
Re: Hercules VM TCPIP - current situation?
On Thu, 12 Jan 2023 at 01:24, Bernd Oppolzer via groups.io <berndoppolzer@...> wrote: the original VM TCP/IP was written in IBMs Pascal/VS, AFAIK.
If the source code of this product could be found somewhere, I could
imagine it would be possible
to compile it with my current version of New Stanford Pascal without or
with minor changes.
If someone out there has access to the original TCP/IP source code for
VM and wants to test this,
feel free to contact me offline for discussion and support. I doubt the source code was ever published. The original VM TCP/IP ("FAL") was at a time after IBM's Object Code Only (OCO) policy was already established, and although a lot of the VM assembler code remained available in source, virtually everything written in high level languages (PL/X, C, and Pascal) was never shipped with source. I would be happy to be proven wrong! Tony H.
|
Re: Hercules VM TCPIP - current situation?
FWIW:
the original VM TCP/IP was written in IBMs Pascal/VS, AFAIK.
If the source code of this product could be found somewhere, I could imagine it would be possible
to compile it with my current version of New Stanford Pascal without or with minor changes.
If someone out there has access to the original TCP/IP source code for VM and wants to test this,
feel free to contact me offline for discussion and support.
New Stanford Pascal compiler website:
Thank you, kind regards
Bernd
Am 12.01.2023 um 03:57 schrieb Fish Fish:
toggle quoted message
Show quoted text
Rob wrote:
I've downloaded and successfully run CE1.2. I would like to
get it Internet connected.
I've found some advice ()
that involves routing through virtual networks within the host
machine. I've also found a comment somewhere (that I cannot find
again) that seemed to say using QETH in bridge mode (Layer2)
could be made to work. I don't know what you saw and where (some IBM documentation perhaps?), but if it was VM related, it was more than likely referring to z/VM, a much more modern z/Architecture version of VM which does indeed support networking with QETH (i.e. OSA) devices in Layer 2 (or Layer 3!) mode.
As Bob pointed out in his reply however, the VM that is usually discussed here in this group is VM/CE ("Community Edition"), which is a community modified/enhanced/supported version of VM/370, a very old version of VM that does not have any TCP/IP support at all as far a I know.
HTH
|
Re: Hercules VM TCPIP - current situation?
Rob wrote: I've downloaded and successfully run CE1.2. I would like to
get it Internet connected.
I've found some advice ()
that involves routing through virtual networks within the host
machine. I've also found a comment somewhere (that I cannot find
again) that seemed to say using QETH in bridge mode (Layer2)
could be made to work. I don't know what you saw and where (some IBM documentation perhaps?), but if it was VM related, it was more than likely referring to z/VM, a much more modern z/Architecture version of VM which does indeed support networking with QETH (i.e. OSA) devices in Layer 2 (or Layer 3!) mode. As Bob pointed out in his reply however, the VM that is usually discussed here in this group is VM/CE ("Community Edition"), which is a community modified/enhanced/supported version of VM/370, a very old version of VM that does not have any TCP/IP support at all as far a I know. HTH -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Re: Hercules VM TCPIP - current situation?
On 1/11/23 18:00, robballantyne3@... wrote: ? ?That makes perfect sense.? I seem to have missed that part of the document I referenced that lists: VSE, VM/ESA, and LinuxS/390 as the Hercules guests that you might want to configure networking for. But if you DO end up needing to configure TCP/IP under VM/ESA, I have done that several times, and can assist if needed. It's also the same IP stack as is used under OS/390, and the configuration is very much the same. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
|
Re: Hercules VM TCPIP - current situation?
Hi Bob,?
? ?That makes perfect sense.? I seem to have missed that part of the document I referenced that lists: VSE, VM/ESA, and LinuxS/390 as the Hercules guests that you might want to configure networking for.
Thanks!
Rob
|
Re: Hercules VM TCPIP - current situation?
Hi Rob,
VMCE is based on nearly 50 year old code. IBM introduced TCPIP support years later. That IBM TCPIP code depends on facilities that were not added to VM until much later.?
Best regards, Bob Bolch
Hi,
? I've downloaded and successfully run CE1.2.? I would like to get it Internet connected.
? I've found some advice () that involves routing through virtual networks within the host machine.? I've also found a comment somewhere (that I cannot find again) that seemed to say using QETH in bridge mode (Layer2) could be made to work.? I'm perhaps jumping to a conclusion here but I'm wondering if that meant that this configuration would permit the VM "host" to appear as a secondary IP on the Linux host system's ethernet adapter (with a 2nd MAC address, I'm also guessing).? Maybe I'm misunderstanding what was meant about that comment.
? Is this possible?? Has anyone done it?? Are there any written instructions?? ?I've searched the various mail groups to no avail.
? I understand UNIX/Networking but I'm a VM newbie.
Thanks!
Rob
|
Hercules VM TCPIP - current situation?
Hi,
? I've downloaded and successfully run CE1.2.? I would like to get it Internet connected.
? I've found some advice () that involves routing through virtual networks within the host machine.? I've also found a comment somewhere (that I cannot find again) that seemed to say using QETH in bridge mode (Layer2) could be made to work.? I'm perhaps jumping to a conclusion here but I'm wondering if that meant that this configuration would permit the VM "host" to appear as a secondary IP on the Linux host system's ethernet adapter (with a 2nd MAC address, I'm also guessing).? Maybe I'm misunderstanding what was meant about that comment.
? Is this possible?? Has anyone done it?? Are there any written instructions?? ?I've searched the various mail groups to no avail.
? I understand UNIX/Networking but I'm a VM newbie.
Thanks!
Rob
|
Re: DMSIPT143T ADDESSING EXCEPTION OCCURRED AT F2A6FC IN SYSTEM ROUTINE EXEC, RE-IPL CMS
Hello,
>>? I've read the later replies on this thread, but >>? couldn't help thinking that >>? it would have been useful if you'd told us if >> the program actually ran >> at all, and if so, how far it got.
First let me apologize to everyone for writing two confusing messages.
The DMSIPT143T occurred when I first ran the program.
The other error occurred ONLY AFTER I ADDED:
trace 'e'
To the program.? I added the trace 'e' to help determine how far the program got and specifically where it failed.
IMHO, calling a non-existing program should not cause CMS to terminate and require a reipl of CMS.
Additional having trace 'e' should not cause REXX to die as it did.
In both cases a better way of dealing with the error is needed.
I hope I helped clarify the two messages.? Again I apologize for the. Misunderstanding of the two messages.? The first was for the DMSIPT error. The second for adding trace 'e'.
Thank you.
On Tue, Jan 10, 2023, 15:01 Jeremy Nicoll < yahgrp87@...> wrote: On Fri, 6 Jan 2023, at 02:48, Bertram Moshier wrote:
> Hello,
>
> I'm getting DMSIPT143T on a very simple REXX program.
>
> DMSIPT143T ADDESSING EXCEPTION OCCURRED AT F2A6FC IN SYSTEM ROUTINE EXEC,
> RE-IPL CMS.
> CP ENTERED; DISABLED WAIT PSW '00020000 40F8B75E'
I've read the later replies on this thread, but couldn't help thinking that
it would have been useful if you'd told us if the program actually ran
at all, and if so, how far it got.
Wouldn't one at least possibly expect this program to fail at some
point, when a exceeds the maximum value of an integer at whatever
the "numeric digits" value is?
Also, I question the wisdom of
? rc = syssleep(1)
as it conflates the normal use of "rc" (to represent the return
code from an issued command) with the returned value from
a function.
> The REXX program is:
>
> /* */
>? ? ? if RxFuncQuery( 'SysLoadFuncs' ) <> 0 then
>? ? ? ? ? do
>? ? ? ? ? ? ?call RxFuncAdd 'SysLoadFuncs', 'REXXUTIL', 'SysLoadFuncs'
>? ? ? ? ? ? ?call SysLoadFuncs
>? ? ? ? ?end
> a = 0
> do forever
>? ?a = a + 1
>? ?say a
>? ?if a//20 = 0 then do
>? ? ?'cls'
>? ? ?rc = syssleep(1)
>? ? ?end
>? ?end
--
Jeremy Nicoll - my opinions are my own.
|
Re: DMSIPT143T ADDESSING EXCEPTION OCCURRED AT F2A6FC IN SYSTEM ROUTINE EXEC, RE-IPL CMS
I got far enough on tracing this program to see that it us failing during REXX initialization. No program statements have run yet. The interpreter is trying to reference uninitialized storage. I just started on this, so I am not very far along yet. Bob Bolch
On Tue, Jan 10, 2023, 4:01 PM Jeremy Nicoll < yahgrp87@...> wrote: On Fri, 6 Jan 2023, at 02:48, Bertram Moshier wrote:
> Hello,
>
> I'm getting DMSIPT143T on a very simple REXX program.
>
> DMSIPT143T ADDESSING EXCEPTION OCCURRED AT F2A6FC IN SYSTEM ROUTINE EXEC,
> RE-IPL CMS.
> CP ENTERED; DISABLED WAIT PSW '00020000 40F8B75E'
I've read the later replies on this thread, but couldn't help thinking that
it would have been useful if you'd told us if the program actually ran
at all, and if so, how far it got.
Wouldn't one at least possibly expect this program to fail at some
point, when a exceeds the maximum value of an integer at whatever
the "numeric digits" value is?
Also, I question the wisdom of
? rc = syssleep(1)
as it conflates the normal use of "rc" (to represent the return
code from an issued command) with the returned value from
a function.
> The REXX program is:
>
> /* */
>? ? ? if RxFuncQuery( 'SysLoadFuncs' ) <> 0 then
>? ? ? ? ? do
>? ? ? ? ? ? ?call RxFuncAdd 'SysLoadFuncs', 'REXXUTIL', 'SysLoadFuncs'
>? ? ? ? ? ? ?call SysLoadFuncs
>? ? ? ? ?end
> a = 0
> do forever
>? ?a = a + 1
>? ?say a
>? ?if a//20 = 0 then do
>? ? ?'cls'
>? ? ?rc = syssleep(1)
>? ? ?end
>? ?end
--
Jeremy Nicoll - my opinions are my own.
|
Re: DMSIPT143T ADDESSING EXCEPTION OCCURRED AT F2A6FC IN SYSTEM ROUTINE EXEC, RE-IPL CMS
On Fri, 6 Jan 2023, at 02:48, Bertram Moshier wrote: Hello,
I'm getting DMSIPT143T on a very simple REXX program.
DMSIPT143T ADDESSING EXCEPTION OCCURRED AT F2A6FC IN SYSTEM ROUTINE EXEC,
RE-IPL CMS.
CP ENTERED; DISABLED WAIT PSW '00020000 40F8B75E' I've read the later replies on this thread, but couldn't help thinking that it would have been useful if you'd told us if the program actually ran at all, and if so, how far it got. Wouldn't one at least possibly expect this program to fail at some point, when a exceeds the maximum value of an integer at whatever the "numeric digits" value is? Also, I question the wisdom of rc = syssleep(1) as it conflates the normal use of "rc" (to represent the return code from an issued command) with the returned value from a function. The REXX program is:
/* */
if RxFuncQuery( 'SysLoadFuncs' ) <> 0 then
do
call RxFuncAdd 'SysLoadFuncs', 'REXXUTIL', 'SysLoadFuncs'
call SysLoadFuncs
end
a = 0
do forever
a = a + 1
say a
if a//20 = 0 then do
'cls'
rc = syssleep(1)
end
end -- Jeremy Nicoll - my opinions are my own.
|
I posted a fix to add TRACE ON FAILURE support to BREXX for CMS 1.1.2 See the issue entry at:? to obtain the test fix. Please provide feedback if you?can test this fix. Bob Bolch.
No, I just added the symptom to the open issue for SIGNAL processing.? Bob
Are you opening a ticket for this issue?
On Wed, Jan 4, 2023, 08:17 Bob Bolch < Bob@...> wrote: It looks like SIGNAL ON ERROR doesn't work correctly either.? It is not being signaled when a CMS command gets a non-zero RC.?
?
======================== TEST EXEC
/* */? ? ? ? ? ? ? ? ? ? ? ??
ADDRESS ''? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ?
SIGNAL ON ERROR? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
'ACCESS 333 Z'? ? ? ? ? ? ? ?
EXIT RC? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
ERROR: SAY 'ERROR SIGNALLED'?
===========================
Currently returns:
test2? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
DMSACC113S 'Z (333) ' NOT ATTACHED?
Ready(00100); T=0.02/0.02 10:03:18?
===========================
Should return:
test2? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
DMSACC113S 'Z (333) ' NOT ATTACHED? ? ?
? ? ?6 *-* 'ACCESS 333 Z'? ? ? ? ? ? ??
? ? ? ?+++ RC(100) +++? ? ? ? ? ? ? ? ?
ERROR signalled? ? ? ? ? ? ? ? ? ? ? ??
Ready(00016); T=0.02/0.02 10:03:05? ? ?
?
|
On Mon, Jan 9, 2023 at 12:33 PM, Bob Polmanter wrote:
Since it is so easy to get the system restored from a backup, why not try?
Oh I already tried it Bob, and I even explain to other people on the channel how to do it on VM/370 CE. :-) Regular 3270 logon and dial don't seem to be affected indeed. I just thought knowledgeable people here like you and many others could provide more information (or reassurance) regarding ignoring those fixes. I felt they fixed problems, so ignoring them would leave the problems there. However, it could be that what is fixed has nothing to do with 3270 connections or is of no (serious) consequence when the system runs under Hercules (like Dave suggested). One last point intrigues me. I don't know who came out with the idea of ignoring those fixes to make the 2703 connections work with UTS, but then again how did he figure that out (since the memos are missing)? Anyway, thanks to all here. Cheers, Rene FERLAND, Montreal
|
Hi Rene,
If you are comfortable building a CP nucleus, I'd suggest that you simply try it yourself.? If you back up your disk images before you bring up your system in order to make the change, it is easy to get back and there is no risk.
Simply make a copy of DMKCNS AUXR60 to your A-disk and edit it and comment out the fixes in question.? Then reassemble DMKCNS the CP way? (using VMFASM), and rebuild the CP nucleus and then re-ipl.? I can't provide specific instructions since I don't know what system version you are using and things have been changed around lately.
I'd say with reasonable confidence that the system will be fine if you comment out those fixes, if for no other reason than before the PUT tapes that introduced those fixes into DMKCNS, they simply were not there in the first place, before those tapes appeared back in the day.? It is not a guarantee of course, but you have someone saying that commenting them out resolves the problem.? Since it is so easy to get the system restored from a backup, why not try?
Regards,
Bob (the other one)
|
On Mon, Jan 9, 2023 at 04:28 AM, Bob Bolch wrote:
Any pointers would be appreciated. I would need to understand the issue more completely,
before I? would remove any IBM PTFs from the VMCE distribution.?
Hi Bob,
?
If by "discussion forum" you mean the Moshix Discord channel, then the topic was discussed in the #uts-unix room (under Spare Computer Room group):
?
https://discord.com/channels/423767742546575361/871957791923920967
?
around December, 19th:
?
https://discord.com/channels/423767742546575361/871957791923920967/1054463813556121660
?
The original "starting" message there was:
?
"It is in fact possible to get ASCII terminals mode working with UTS, but it is only line-at-a-time, half duplex. ?Which really sucks. ?You need 2703 emulation, which Hercules does fine, but you also need a patch to CP to prevent it from a pointer chasing bug. If someone can remind me of the MAINT password, I could show my UTS config."
?
To be clear, I am not asking you to include the modifications in the next release of VM/370 CE, I am just wondering about the possible side effects of them.
?
CHeers,
?
Rene FERLAND, Montreal
|
Mark A. Stevens
Dave McGuire
Jeremy Nicoll
Ren¨¦ Ferland