Re: Support for 3066 Graphic Terminal
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Fish Fish via
groups.io
Sent: 23 September 2024 15:22
To: [email protected]
Subject: Re: [h390-vm] Support for 3066 Graphic Terminal
Dave Wade wrote:
Fish,
I would prefer not to do this as I believe it would stop VM/CE running
on my P/390.
Dave Yes, you're right: it would.
Oh well. Just a thought. I also don't see that using the non-base register instructions help a lot. The existing code relies on base registers. The problems occur because when you insert code you exceed the range of the base registers. You would probably need to replace a lot of code to get any benefit...
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
Dave
|
Re: What is special about the 3066?
On Mon, 23 Sept 2024 at 10:01, Doug Wegscheid via <dwegscheid= [email protected]> wrote:
What was unique about the 3066? I understand it was the integrated console for the /165 and /168, but what unique programming considerations were there for it? I see that some of the standalone utilities couldn't be used with it.
It was interesting from both the hardware and software points of view. I understand that the hardware was based on a stripped down 2250 with no actual graphics capability. Nonetheless it was a vector device, and indeed you could clearly see that the characters were "drawn" rather than being dot-matrix/raster. But somewhere in the middle was some kind of character-to-vector converter, and the driving software had no direct access to the vector stuff.
From the software POV it is a straightforward screen with character addressibilily. IIRC you can't just write to it without specifying where the first character is to go, and to read you have to first set the point to read from - hence the non-support by various standalone programs expecting a printer or line-mode console interface.
I couldn't find any information on it in Bitsavers (other than reference to not being able to use the 3066 with some of the standalone utilities). Yeah... I remember around 1974 that one of our sysprogs dug up the info and modified the then HASP II V3 on MVT to correctly write the $ HASP SYSTEM CATASTROPHIC ERROR message to the 3066 rather than to a 1403 printer that nobody ever noticed until a lot of running around trying to figure out what was wrong had taken place. I'm pretty sure the only actual doc is in the FETOMs and such, though it's possible there is some in the 165 (and 168) Operating Procedures, which don't seem to exist online though there are plenty of references to them.
And of course the way anyone has figured out how to deal with this device in "recent" years is by reading the code that does support it in VM (CP and I think CMS EDIT (maybe that was a user mod?)), OS/360 and descendants MVT/MVS/VS1 (that is essentially DIDOCS), and maybe TSS. To my knowledge there was never any kind of application support in the OS/360 line of products, e.g. TSO. And for good reason, given that there is only one such device per mainframe (maybe two for a 168/MP), so it's kind of the world's most expensive personal computer.
Tony H.
|
Re: Support for 3066 Graphic Terminal
Dave Wade wrote: Fish,
I would prefer not to do this as I believe it would stop VM/CE
running on my P/390.
Dave Yes, you're right: it would. Oh well. Just a thought. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
What is special about the 3066?
Not wanting to highjack the "[h390-vm] Support for 3066 Graphic Terminal" thread.
What was unique about the 3066? I understand it was the integrated console for the /165 and /168, but what unique programming considerations were there for it? I see that some of the standalone utilities couldn't be used with it.
I couldn't find any information on it in Bitsavers (other than reference to not being able to use the 3066 with some of the standalone utilities).
|
Re: Support for 3066 Graphic Terminal
Fish,
I would prefer not to do this as I believe it would stop VM/CE running on my P/390.
Dave
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Fish Fish via
groups.io
Sent: 23 September 2024 00:59
To: [email protected]
Subject: Re: [h390-vm] Support for 3066 Graphic Terminal
I've been following this thread with interest, so allow me to offer what may be,
while somewhat radical, a nevertheless viable solution:
Require your Hercules control file to have a "FACILITY ENABLE
HERC_370_EXTENSION" statement (after your "ARCHLVL 370" statement), and
then change your code to use "Branch Relative" instructions instead:
A704 Branch_Relative_on_Condition
A705 Branch_Relative_and_Save
A706 Branch_Relative_on_Count
84 Branch_Relative_on_Index_High
85 Branch_Relative_on_Index_Low_or_Equal
which, as you may or may not know, do not require any base register at all.
* S/370 Backport of select ESA/390 and z/Architecture instructions
390/hyperion/blob/master/readme/README.S37X.md
Note too, that Hercules's 370 Extension also gives you gives you access to many
other very handy instructions as well (such as the "Immediate" instructions). For
the complete list, see:
*
390/hyperion/blob/f7d2360a9a06de6248eaf953eb621712fd4e6168/facility.c#
L4176-L4361
As I said, it IS admittedly a rather radical approach (and would never work on
real hardware of course; only on Hercules), but it IS nevertheless a possible
solution to consider.
After all, not requiring ANY base register AT ALL would allow your module to be
as big as you would need it to be! (and would free that register to be used for
something else!)
Just something I thought I'd throw out there.
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
On Sun, Sep 22, 2024 at 05:39 PM, Bob Polmanter wrote:
0. Don't clear the stack, but read it, so when you IPL XNET you could stack D NODES and D TASKS to show up in your spooled console?
XNET doesn't run under CMS; it takes over the virtual machine and runs natively immediately after launching.? How about instead if the XNET CONFIG file allowed commands to be placed there that would be executed upon start up?? Note that there wouldn't be much shown or revealed by these commands if the CTCs are not yet connected and no one has yet DIALed to XNET.
?
?
1. SMSG capability, so I could SMSG D NODES and get the response back.
2. A restart capability, via SMSG? to reconnect systems when a failure happens.
Interesting ideas; I hadn't thought about the SMSG feature.? I'll look into these solutions for winter projects.
?
If you tackle the SMSG, then we wouldn't need commands in the CONFIG, as AUTOLOG1 or OPERATOR or ... could just SMSG the command to get the results, especially if there was a SLEEP to allow time for connections to stabilize.
?
?... Mark S.
|
Re: Support for 3066 Graphic Terminal
Hello,
How about following IBM and splitting the module into two?
Just a thought.
I've been following this thread with interest, so allow me to offer what may be, while somewhat radical, a nevertheless viable solution:
Require your Hercules control file to have a "FACILITY ENABLE HERC_370_EXTENSION" statement (after your "ARCHLVL 370" statement), and then change your code to use "Branch Relative" instructions instead:
? ? A704? Branch_Relative_on_Condition
? ? A705? Branch_Relative_and_Save
? ? A706? Branch_Relative_on_Count
? ? 84? ? Branch_Relative_on_Index_High
? ? 85? ? Branch_Relative_on_Index_Low_or_Equal
which, as you may or may not know, do not require any base register at all.
? * S/370 Backport of select ESA/390 and z/Architecture instructions
? ?
Note too, that Hercules's 370 Extension also gives you gives you access to many other very handy instructions as well (such as the "Immediate" instructions). For the complete list, see:
? *
As I said, it IS admittedly a rather radical approach (and would never work on real hardware of course; only on Hercules), but it IS nevertheless a possible solution to consider.
After all, not requiring ANY base register AT ALL would allow your module to be as big as you would need it to be! (and would free that register to be used for something else!)
Just something I thought I'd throw out there.
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
Re: Support for 3066 Graphic Terminal
I've been following this thread with interest, so allow me to offer what may be, while somewhat radical, a nevertheless viable solution:
Require your Hercules control file to have a "FACILITY ENABLE HERC_370_EXTENSION" statement (after your "ARCHLVL 370" statement), and then change your code to use "Branch Relative" instructions instead:
A704 Branch_Relative_on_Condition
A705 Branch_Relative_and_Save
A706 Branch_Relative_on_Count
84 Branch_Relative_on_Index_High
85 Branch_Relative_on_Index_Low_or_Equal
which, as you may or may not know, do not require any base register at all.
* S/370 Backport of select ESA/390 and z/Architecture instructions
Note too, that Hercules's 370 Extension also gives you gives you access to many other very handy instructions as well (such as the "Immediate" instructions). For the complete list, see:
*
As I said, it IS admittedly a rather radical approach (and would never work on real hardware of course; only on Hercules), but it IS nevertheless a possible solution to consider.
After all, not requiring ANY base register AT ALL would allow your module to be as big as you would need it to be! (and would free that register to be used for something else!)
Just something I thought I'd throw out there.
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
Mark,
?
Does the lack of a "heartbeat" help or hinder? I don't know. I have kept my two KVMs up and running for 8 days, and sessions dialed to/through each XNET, and it doesn't drop.
?
What I did discover, is if one VM system goes down, planned or otherwise, you can not reestablish the XNET connections without re-IPLing the XNET on the surviving machine.
?
I tried to use the V cuu ACT/INACT to reestablish the connections, but that didn't work. Is it supposed to?
Having a heartbeat really wouldn't help matters much for detecting that a system on the other side has gone away.? The main problem is really the nature of CTCE devices on Hercules.? When one side goes down and Hercules is stopped and restarted, the state of the CTCE device is lost.? XNET on the side that remained up doesn't understand the state of the CTC as it sees it; it thinks it was left the way it was last used.? Understand that if this were a real CTC device on real S/370 hardware back in the day, this would be basically channel cables between two separate CPUs and a small bit of controller hardware logic.? If one CPU crashes, the state of the CTC remains unchanged.? What Hercules/CTCE does when it goes down is essentially the same as disconnecting the channel cables from the real CTC and powering down the CTC control logic, and restarting/reconnecting later.? The original state of the device was lost.? That does not typically happen with real CTCs; they were physically connected 24/7.
?
If you know that you are going to shut down one side deliberately, you should issue a V cuu,INACT on the side that will be remaining active.? Then shut down the intended system.? Once the shut down system is restarted and XNET is started, you should be able to issue V cuu,ACT on the side that stayed up.? None of this helps for an unplanned shutdown however.
?
I suppose a new command is needed to force reinitialization of the CTC and the connection for these situations, because V? INACT/ACT won't work in such cases.
?
Regarding your other suggestions:
?
0. Don't clear the stack, but read it, so when you IPL XNET you could stack D NODES and D TASKS to show up in your spooled console?
XNET doesn't run under CMS; it takes over the virtual machine and runs natively immediately after launching.? How about instead if the XNET CONFIG file allowed commands to be placed there that would be executed upon start up?? Note that there wouldn't be much shown or revealed by these commands if the CTCs are not yet connected and no one has yet DIALed to XNET.
?
?
1. SMSG capability, so I could SMSG D NODES and get the response back.
2. A restart capability, via SMSG? to reconnect systems when a failure happens.
Interesting ideas; I hadn't thought about the SMSG feature.? I'll look into these solutions for winter projects.
?
Regards,
Bob
?
?
|
Re: Support for 3066 Graphic Terminal
Tony, If you look at the link I sent to the VMSHARE archives :- ?
? it saves about 500 bytes, which is significant in CP terms¡. .. yes there is code that tests for 3066 in some other modules DMKCPx ?for example, but if non are generated this code won¡¯t get exercised. ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Tony Harminc via groups.io
Sent: 22 September 2024 22:19
To: [email protected]
Subject: Re: [h390-vm] Support for 3066 Graphic Terminal? On Sun, 22 Sept 2024 at 03:15, William Denton via <williamedenton=[email protected]> wrote: Would anyone have any heartache about deleting support for the 3066 terminal (370/168 console)??? I have mixed personal experiences with the device but, as far as I can see, there in not a single 168 still under power and no emulators address the 3066 quirks. As an aside, sitting at that console with its "not" microfiche viewer was quite something... but its keyboard was crap.
Some shops made a hardware mod to support the ENTER (or maybe it was CR) key as, well, an ENTER key. The 3066 as it came? required the operator to hit the separate and very klunky But... nostalgia aside, I would like to open up some addressability in DMKGRF for other things I am working on... namely dynamic screen sizes.
I would be somewhat unhappy to see the 3066 code removed. Surely it can't be all that big...? For many years I've had an "I'll do it when I'm retired" project in mind to produce either a 3066 terminal emulator itself or the necessary Hercules code to make a suitably configured TN3270 session appear like a 3066 to the host, but of course if there's no mainframe code to drive it then there's little point. So I guess this is also nostalgia, and I may well never get to it, but I still don't like the idea of removing device support. On the details, surely there is some 3066 code and tables elsewhere in CP? Would you also remove that? If not, how would things behave?
|
Re: Support for 3066 Graphic Terminal
On Sun, 22 Sept 2024 at 17:19, Tony Harminc < tharminc@...> wrote: [...] > Some shops made a hardware mod to support the ENTER (or maybe it was CR) key as, well, an ENTER key. The 3066 as it came? required the operator to hit the separate and very klunky
Sorry - hit ENTER (heh) too soon. There was a pushbutton switch much the shape, size, and physical feel of those used for all manner of things on IBM hardware - the LOAD/START/etc. keys, and those on things like 1403 printers that was the 3066 console ENTER key just to the right of the keyboard. But the keyboard also had a typewriter-like built-in ordinary ENTER or CR or NL key that, IIRC, did nothing, and could be adapted to actually work.
Unfortunately all the pictures of the 3066 at bitsavers are poorly scanned, and I can't find anything with a clear picture or diagram of the keyboard and surrounding space.
Tony H.
|
Re: Support for 3066 Graphic Terminal
On Sun, 22 Sept 2024 at 03:15, William Denton via <williamedenton= [email protected]> wrote: Would anyone have any heartache about deleting support for the 3066 terminal (370/168 console)???
?
I have mixed personal experiences with the device but, as far as I can see, there in not a single 168 still under power and no emulators address the 3066 quirks. As an aside, sitting at that console with its "not" microfiche viewer was quite something... but its keyboard was crap.
Some shops made a hardware mod to support the ENTER (or maybe it was CR) key as, well, an ENTER key. The 3066 as it came? required the operator to hit the separate and very klunky
?
But... nostalgia aside, I would like to open up some addressability in DMKGRF for other things I am working on... namely dynamic screen sizes.
?
Thoughts?
I would be somewhat unhappy to see the 3066 code removed. Surely it can't be all that big...? For many years I've had an "I'll do it when I'm retired" project in mind to produce either a 3066 terminal emulator itself or the necessary Hercules code to make a suitably configured TN3270 session appear like a 3066 to the host, but of course if there's no mainframe code to drive it then there's little point.
So I guess this is also nostalgia, and I may well never get to it, but I still don't like the idea of removing device support.
On the details, surely there is some 3066 code and tables elsewhere in CP? Would you also remove that? If not, how would things behave?
Tony H.
|
Re: Reserving Modification Numbers
On Sun, Sep 22, 2024 at 04:52 AM, Dave Wade wrote:
So to assist in this I have created some pages in the Wiki
Nicely done and THANK YOU!
?
?... Mark S.
|
Re: Support for 3066 Graphic Terminal
On Sun, Sep 22, 2024 at 12:17 PM, rvjansen@... wrote:
[...] for reasons beyond my comprehension of VM/370 EE actually works very well; outside of that the status indicator keeps displaying somewhere in the middle and it would be great if it could behave a bit more like modern VM.
I have played around with the ZOC TN3270 emulator, EE V1.2.5. could handle 200 columns and 81 lines at first glance. There were warning messages on exit about memory overwrites though. I have seen many hard coded limits in the EE sources, this has to be reworked if (or when ?) multiple logical screens are introduced.
?
Martin
|
Re: Support for 3066 Graphic Terminal
If this leads to dynamic screen sizes I am all for it. I already run it with a large screen size (c3270 localhost:3270 -model 3279-5 -oversize 159x48 -defaultfgbg) and the works quite nicely - for reasons beyond my comprehension of VM/370 EE actually works very well; outside of that the status indicator keeps displaying somewhere in the middle and it would be great if it could behave a bit more like modern VM.
But more importantly: now I need to know what a "not" microfiche viewer is. I know about, and at various time got seasick from the microfiche viewers at university, but I do not remember ever operating a "not" microfiche viewer.
best regards,
¸é±ð²Ô¨¦.
toggle quoted message
Show quoted text
Would anyone have any heartache about deleting support for the 3066 terminal (370/168 console)????
I have mixed personal experiences with the device but, as far as I can see, there in not a single 168 still under power and no emulators address the 3066 quirks. As an aside, sitting at that console with its "not" microfiche viewer was quite something... but its keyboard was crap.?
But... nostalgia aside, I would like to open up some addressability in DMKGRF for other things I am working on... namely dynamic screen sizes.?
Thoughts??
|
Re: Support for 3066 Graphic Terminal
Bertram, Addressability and space in DMKGRF always was a problem. Well in 1985 at least one site removed the 3066 support. ?
? the suggestion of adding an extra base register was considered and discarded. I think at some point in SP IBM split the module.. ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Bertram Moshier via groups.io
Sent: 22 September 2024 10:22
To: [email protected]
Subject: Re: [h390-vm] Support for 3066 Graphic Terminal? Hello,
I dislike removing support from the product, but I'm not against removing 3066 console support.? Just some questions.
?When did IBM remove support for the 3066?
Is it possible to add an additional register for addressability?
How did IBM handle the addressability issue for DMKGRF?
As I said, I'm not against removing the support for the 3066 console, but the future does concern me.? I suspect there will be other changes in the?future for DMKGRF, and removing device support won't be the solution.? Maybe adding a register now is a consideration.?
Thank you.
On Sun, Sep 22, 2024, 02:15 William Denton via <williamedenton=[email protected]> wrote:
Would anyone have any heartache about deleting support for the 3066 terminal (370/168 console)????
I have mixed personal experiences with the device but, as far as I can see, there in not a single 168 still under power and no emulators address the 3066 quirks. As an aside, sitting at that console with its "not" microfiche viewer was quite something... but its keyboard was crap.?
But... nostalgia aside, I would like to open up some addressability in DMKGRF for other things I am working on... namely dynamic screen sizes.?
Thoughts??
Cheers, William
|
Reserving Modification Numbers
Beloved Members,
?
Sorry to impose upon your day of rest and relaxation, but subsequent to the discussion on Modification Numbers, and prompted by todays note on DMKGRF I am reminded that most developers felt changing modification numbers was a BAD idea, and would like to be able to reserve numbers for your modifications in advance.
So to assist in this I have created some pages in the Wiki
?
?
as :-
?
?
and
?
?
where you can reserve numbers. If there are any clashes please let me know.?
?
Dave G4UGM
?
|
Re: Support for 3066 Graphic Terminal
Hello,
I dislike removing support from the product, but I'm not against removing 3066 console support.? Just some questions.
?When did IBM remove support for the 3066?
Is it possible to add an additional register for addressability?
How did IBM handle the addressability issue for DMKGRF?
As I said, I'm not against removing the support for the 3066 console, but the future does concern me.? I suspect there will be other changes in the?future for DMKGRF, and removing device support won't be the solution.? Maybe adding a register now is a consideration.?
Thank you.
On Sun, Sep 22, 2024, 02:15 William Denton via <williamedenton= [email protected]> wrote: Would anyone have any heartache about deleting support for the 3066 terminal (370/168 console)???? I have mixed personal experiences with the device but, as far as I can see, there in not a single 168 still under power and no emulators address the 3066 quirks. As an aside, sitting at that console with its "not" microfiche viewer was quite something... but its keyboard was crap.? But... nostalgia aside, I would like to open up some addressability in DMKGRF for other things I am working on... namely dynamic screen sizes.? Thoughts?? Cheers, William
|
Support for 3066 Graphic Terminal
Would anyone have any heartache about deleting support for the 3066 terminal (370/168 console)???
?
I have mixed personal experiences with the device but, as far as I can see, there in not a single 168 still under power and no emulators address the 3066 quirks. As an aside, sitting at that console with its "not" microfiche viewer was quite something... but its keyboard was crap.
?
But... nostalgia aside, I would like to open up some addressability in DMKGRF for other things I am working on... namely dynamic screen sizes.
?
Thoughts?
?
cheers, William
|
On Sat, Aug 17, 2024 at 07:11 PM, Gregg Levine wrote:
I see that Mark. There's a good reason waiting for it. What say that
when all of this is settled, and you've got the two systems seeing
each other, can you present all of this as a good example of
documentation?
I've written down my experiences as a How-To. I will post that in the Files section.
?
?... Mark S.
|
Mark A. Stevens
Martin Scheffler
