Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- H390-Vm
- Messages
Search
|
Re: What is special about the 3066?
From a programming standpoint, the 3066 had different geometry (80x33), different set of buffer orders, and completely different CCWs, interrupts, and sense data. I think IBM only put software support in the operating systems was because the beast was THE system console. Nobody ever thought of it as being a "real" terminal that would run TSO or CICS... CMS was an exception but barely usable... Edit worked in terminal mode only as I recall... In my shop when we had the /168, the 3066 was only used during IPL and doing diagnostic work. In fact, the 168 console was stuck in a back corner of the computer room and all the real operation was done from a bank of real 3270s in the center
?
cheers,
William |
|
Re: Support for 3066 Graphic Terminal
The /168 console (like the 158 & later) didn't have very many blinky lights. As I recall, just the five above the Interrupt, Start, Stop, Load buttons.
?
So, the "not" microfiche viewer was the contraption to the left of the console that looked like a big dual-screen fiche viewer. One of the screens (as I recall, the left one) was an actual fiche viewer. The other one was the replacement for the blinky lights. It had two dials that would select row/.column in a matrix of display choices that would display (in lights behind the (lucite?) screen all the things lights should display -- PSW, regs, current address, etc. in addition to lots and lots of internal stuff...
?
Now that I think about it, the front part of the console must have had rotary switches and other buttons to do things like set the location counter, set address stop, etc... Address stop and Inst Step for sure because I remember having to come in on a Sunday afternoon to work with the CE to diagnose and fix a clock comparator bug that I had to stop the machine at a certain location in CP and step thru a few instructions after the CE had set a bunch of probes
?
Amazing what's lurking back in the dusty recesses in ones head
?
cheers, William |
|
How important are the "side modes" of EE like FSLIST and FSVIEW ? I did not care of these up to now. I have reworked EE focussed on XEDIT as it was in VM/SP 1 (that means no FILELIST, RDRLIST ...).
?
Actually I have a Proof of Concept to have several UI Elements controlled by a "view" ... which means "file" as there is only one view per file now. A repeatable macro PROFILER EE written in REXX can decide by checking filename and filetype to set PREFIX to OFF, LEFT or RIGHT and NUMBER to ON or OFF. This setting will be tied to this one view/file and will not be affected by other files in the ring.
?
I might have broken something in FSLIST, I have not done much research how FSLIST internally works.
?
Martin
? |
|
Re: Support for 3066 Graphic Terminal
toggle quoted message
Show quoted text
-----Original Message-----Not at all. There are many changes to DMKGRF bobbling around the net. If you re-write it then working out how to fit these changes in becomes challenging. Dave |
|
Re: Support for 3066 Graphic Terminal
Dave Wade wrote:
[...] I also don't see that using the non-base register instructionsYou don't?! Wow. Just... wow. The existing code relies on base registers.Which, when eliminated, would free up those registers for other uses. The problems occur because when you insert code you exceed theWhich, when replaced with relative instructions that don't need base registers, allows you to address anywhere from -128K to +128K from the current PSW (for the short form), or anywhere from -4GB to +4GB for the long form. You would probably need to replace a lot of code to get anyMore than likely, yes. But once done, you would NEVER again need to worry about blowing a base register. EVER. Your module, from then on, could grow as large as you would ever want. We're talking about a ONE TIME fix (modification/rewrite) here, to eliminate the base register problem ONCE AND FOR ALL. *Forever*. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@... |
|
Re: Support for 3066 Graphic Terminal
toggle quoted message
Show quoted text
-----Original Message-----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... Dave |
|
Re: What is special about the 3066?
On Mon, 23 Sept 2024 at 10:01, Doug Wegscheid via <dwegscheid=[email protected]> wrote:
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.
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. |
|
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,
toggle quoted message
Show quoted text
I would prefer not to do this as I believe it would stop VM/CE running on my P/390. Dave -----Original Message----- |
|
Re: XNET v1.4.1
On Sun, Sep 22, 2024 at 05:39 PM, Bob Polmanter wrote:
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. On Sun, Sep 22, 2024, 18:59 Fish Fish via <david.b.trout=[email protected]> wrote: I've been following this thread with interest, so allow me to offer what may be, while somewhat radical, a nevertheless viable solution: |
|
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@... |
|
Re: XNET v1.4.1
Mark,
?
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:
?
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.
? ?
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 ? 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:
? 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
? 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: 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:
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
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. |
Martin Scheffler
Mark A. Stevens
to navigate to use esc to dismiss