Fish-Git
commented
2 years ago A not unreasonable suggestion! I'll add it to the list and we'll see if maybe we can get that taken care of for you in a future release. Thanks.
Closed joemonk64 closed 2 years ago
Fish-Git
commented
2 years ago A not unreasonable suggestion! I'll add it to the list and we'll see if maybe we can get that taken care of for you in a future release. Thanks.
atncsj6h
commented
2 years ago Since there is no constraint on the order of the statements in the Hercules config file, the implementation would NOT be simple and not worth the effort (IMO ).
On the ARCHLVL command: rescan the device table to check for allowed/not allowed devices???
But , remember... on z/OS version 1, the power-on architecture must be set to ESAME. The switch to z/Arch occurs during the system IPL.
And what about all the other older device types???
enrico
joemonk64
commented
2 years ago Since IBM has announced that z14 and above is zArch only (no ESA/390), why not have a zArch only version of hercules, that only supports valid zArch devices? I mean, what architectural improvements are there really to be made at this point in 370/XA/390?
Joe
joemonk64
commented
2 years ago But , remember... on z/OS version 1, the power-on architecture must be set to ESAME. The switch to z/Arch occurs during the system IPL.
On z/OS v 1.11 and lower this is true. It is not true for z/OS version 1.12 and 1.13, which can IPL in z/Arch mode.
Joe
Fish-Git
commented
2 years ago The 1052 or 3215 are not valid devices on z/Arch.
Do you have evidence (proof) of this? 1052 and 3215 devices are such simple devices, I have a hard time believing that they can't be used on 64-bit z/Architecture hardware.
Now if your claim was that modern z/Architecture operating systems (such as e.g. z/OS) no longer support such devices, that would be different. An operating system is free to support or not support whatever devices it chooses.
But "z/Arch" is not an operating system. It's a hardware architecture. Why can't such devices be used on z/Arch hardware? Neither the 1052 nor the 3215 device is CPU hardware architecture dependent. The only thing devices care about are the CCW commands that are issued to it. So why can't a 1052 or 3215 be used on z/Arch hardware?
I think I'm going to have to reject this request.
I'll leave it open for a few days to allow for further discussion, but upon further reflection (thought), your request doesn't make any sense.
Sorry!
joemonk64
commented
2 years ago Yep, sure do...
"Introduction to the Support Element A Support Element is a dedicated workstation that is used for monitoring and operating a system. If you have experience using other systems, you may have used a processor console, support processor, or a similarly named workstation to monitor and operate them.
This system is an integrated Support Element, that is, the Support Element is located inside the same frame that the system is located. An alternate Support Element is also provided to give you the option to switch from your primary Support Element to your alternate Support Element if hardware problems occur.
The IBM Z (Z) and IBM LinuxONE (LinuxONE) systems operate only in logically partitioned mode.
A Hardware Management Console is required for monitoring and operating systems with integrated Support Elements."
"Establishing a Support Element console session from a Hardware Management Console
A Hardware Management Console must be used for monitoring and operating systems with integrated Support Elements.
Ordinarily, you should use the Hardware Management Console to monitor status and perform tasks for the systems defined to it. Only the Hardware Management Console can be used for monitoring and operating multiple systems; using it is more efficient than using each system's Support Element console individually
Fish-Git
commented
2 years ago Q: And what, pray tell, does what you quoted have to do with 1052 and/or 3215 device support? A: Nothing!
The Hercules equivalent of a "integrated Support Element" that allows you to control the operating system is a "SYSG" device.
The Hercules equivalent to a Hardware Management Console (HMC) is the main Hercules window, oftentimes referred to as the Hercules "panel" (i.e. the screen or terminal session where you enter Hercules commands from and where you see Hercules messages).
Neither has anything whatsoever to do with 1052 and/or 3215 devices.
Fish-Git
commented
2 years ago p.s. Your link to whatever IBM reference manual you were quoting from requires logging in to an IBM account to view. Can you at least let us know what the manual (publication) number of it is?
Fish-Git
commented
2 years ago I received the following from a fellow developer with experience in this area:
This subject needs to be squashed. Feel free to appropriately redact and add to the following…
Ignoring the “architectural improvements” clause, as many improvements can still be made, a clarification to Joe’s point would be to extend the ARCH statement:
ARCHLVL architecture [Strict|Relaxed]Joe also is mistaken as I regularly use “old” device support in z-mode, as do a few others that I know.
(Fish): Include me in amongst such individuals.
It is only when one is running one of the newer restricted license-mode operating systems that the devices have been removed from support, as has been done over the history of the OS platforms that can run under Hercules. This is not a zArch only issue.
All of this becomes problematic as we are not into specific machine emulation.
(Fish): And I think this is they key point: Hercules does not (and IMHO should not) attempt to emulate any particular machine. It attempts to emulate a given architecture, not any specific machine or set of machines.
For the definition of STRICT, which instructions are to be included/excluded? So we need to redefine:
ARCHLVL architecture [IOStrict|IORelaxed]While this is a possible place for the specification, it is IO related, not CPU related. A new configuration statement would have to be added:
ARCHIO [Strict|Relaxed]But then which I/O architecture is to be followed? What about zPDT? Or PC/370? And others? XA-mode support is neither S/370 mode nor is it z/Arch mode. XA mode machines exist that don’t support B&T/OEMI channels. There are those that run OEMI devices via ESCON converters via FICON converters. Rather ugly, not officially supported, and only works for some devices. But it is done by all too many sites. This is why the Hercules developers intentionally do not restrict which devices can be specified for which architecture. Within Hercules, there is no restriction on the supported devices. Just as on the real machines, that restriction is left to the OS. And Hercules can readily run OEMI channel-only device emulation on FICON channel emulation, and vice-versa, without issue -- one of the benefits of an emulator.
I will note that I have programmed support for unsupported devices on multiple operating systems for production use. It works and can be done. It is also how we have commercially added new devices to the existing mainstream operating systems.
Restricting the devices that can be defined is an artificial control mechanism for which it’s only true use would come into play if running a licensed OS by those who can neither read nor understand documentation that is simpler to read than the documentation for the licensed OS that they are trying to run on a non-licensable platform.
I also do not recommend putting out warning messages when “unsupported” devices are defined; that again puts the design of Hercules into a precarious position of conforming to the OS rather than the overarching platform.
I agree 100% with my fellow developer.
I'm sorry Joe, but your enhancement request is going to have to be rejected.
Sorry! :(
joemonk64
commented
2 years ago "(Fish): And I think this is they key point: Hercules does not (and IMHO should not) attempt to emulate any particular machine. It attempts to emulate a given architecture, not any specific machine or set of machines."
And this is where the train left the tracks.
z/Arch is a continuum. Things are not valid today in z/Arch that were valid 20 years ago. As Jim Mulder has said many times, the POO is not model specific, but the ARCHITECTURE is. The POO is merely a description of the continuum.
As an example, ESA/390 DAT is no longer valid in z/Architecture. It used to be, so it is included in the POO. But when CZAM is present, there is no ESA/390 DAT. And we all know that today, you cant order a z/series without CZAM, just like all real z/series boxes run in LPAR mode.
And that's my point. Parallel channels are no longer supported, just as ESA/390 DAT is no longer supported, all of which is part of the ARCHITECTURE.
So if you are going to support an architecture, then do it. But just because you could do something 20 years ago in the architecture doesnt mean that you can do it today. You are explicitly acknowledging that by turning off ESA/390 DAT for CZAM.
s390guy
commented
2 years ago I am a bit late to this party. Fish is absolutely correct. I am happy to see this is now marked as WON'T FIX.
joemonk64
commented
2 years ago OK ... so using the latest hercules from Fish:
The ARCHLVL is z/Arch and the console is set to 3215. As you can see, I get to the point in the IPL where I must specify the XCF coupling, in this case **. My reply (from the 3215) is completely ignored...
The system just sits in wait mode, with the console DISABLED (SCLP inactive)...
joemonk64
commented
2 years ago OTOH if i change the console to SYSG, it works ... the SCLP interface goes active... which it never does with the 3215.
Fish-Git
commented
2 years ago Why are you posting screen shots?! Don't you have a Hercules log file?!
Fish-Git
commented
2 years ago It is becoming all too clear now that your problem is that you are unfamiliar/inexperienced with trying to run z/OS on Hercules.
The problems you are tripping over have absolutely nothing whatsoever to do with modern z/Architecture machines supporting or not supporting 3215 or 1052 devices.
You should be posting your questions and asking for help on the H390-MVS forum, and NOT HERE.
Your problem is NOT a Hercules issue. It does not belong here in the GitHub Issues web page. It belongs in H390-MVS. You are making very basic mistakes. The people over at H390-MVS can help you, but I am not going to waste my time trying to teach you how to run z/OS on Hercules. That is not my job. That is not any of the Hercules developers job.
If one of the Hercules developers wants to take the time to try and teach you how to run z/OS on Hercules, they are free to contact you privately and try to help you. But asking the people in the H390-MVS group for help is IMHO the actual proper place where to get help with what you are trying to do, not here.
I am closing this issue.
joemonk64
commented
2 years ago "It is becoming all too clear now that your problem is that you are unfamiliar/inexperienced with trying to run z/OS on Hercules."
No, apparently my problem is that I expect the emulator to behave like the real machine it is trying to emulate.
Fish-Git
commented
2 years ago No, apparently my problem is that I expect the emulator to behave like the real machine it is trying to emulate.
Correct! As already mentioned, Hercules does not try to emulate any real machine. It emulates ITS OWN z/Architecture capable machine.
It does not emulate any of IBM's "z" machines. It emulates the Hercules "z machine".
Furthermore, z/OS (which, based on the information you've provided, is clearly what you are trying to IPL and run), during its initial IPL phase, is only able to communicates with either an integrated graphics (e.g. 3270) device (known as a SYSG device), or with the HMC (Hardware Management Console, i.e. the Hercules panel). Once the IPL has completed, then it will enable all of its other devices (such as your 009 3215 device) and begin communicating with them (if it has support for such devices of course).
3215 and 1052 devices are not 3270 graphics devices however. They are not even close. The initial IPL of z/OS will never communicate with a 3215 or 1052 device during an initial IPL. The initial IPL messages that z/OS issues during an IPL (and where it expects to get its replies from) must be either a 3270 device (at an expected device address, which for most ADCD versions of z/OS is usually 700) or else to the HMC (Hercules hardware panel).
If z/OS does not detect a SYSG device that it can communicate with during the initial IPL phase (which must be defined at address 0000, not 0009), it issues its messages to, and reads its replies from, the Hercules hardware console (the so called HMC) instead.
To reply to such messages, you must enter your reply from the Hercules command line, prefixing your reply with a "." (period). Thus, in your first example, you should have entered the command ".r 0,couple=**".
But you tried entering your reply to the 3215 device at address 0009 instead (as evidenced by your "/" reply prefix). It is hardly any surprise that nothing happened since z/OS has not finished its IPL yet and thus has not enabled any of its devices. That is to say, device 0009 has not been enabled by z/OS yet. So you entered a "reply" to a device that z/OS does not even know exists yet and is still disabled!
If you define a 3270 SYSG device at address 0000, then when you IPL z/OS, its IPL messages will appear on that 3270 device, and you would enter your reponses on that 3270 device.
If you do not have a SYSG device (an integrated system console device) defined in your configuration, then z/OS will write its messages to the Hercules panel (the Hardware Management Console (HMC)) and you must respond to such messages using the Hercules command line by prefixing your commands with a dot/period.
As I said, you are clearly inexperienced with running z/OS on Hercules, which is why I suggested asking the H390-MVS group for help. The people there know how to run not only MVS but also z/OS too.
Your complaint about 3215/1052 device support in z/Architecture is a false one and clearly stems from your inexperience with the operating system you are trying to run, NOT with any shortcoming or flaw in Hercules's z/Architetcure support.
Respectfully submitted.
joemonk64
commented
2 years ago "Furthermore, z/OS -- which, based on the information you've provided, is clearly what you are trying to IPL and run -- is only able to communicates with either an integrated graphics (e.g. 3270) device (known as a SYSG device), or with the HMC (Hardware Management Console, i.e. the Hercules panel)."
This is not true. 3215 style support can be added (via RPQ) to the OSA-ICC server (now what OSA-Express7?) in the z/series platform. But it is very expensive to do so! When such a device is provided to z/os, then z/os can use it as the console, the same as a SYSG console. The only thing you need HMC/SE for is the automation to load the device load profile for the LPAR, or the device reset profile for the LPAR.
A SYSG type terminal runs on the HMC as yes, a 3270 device. But with the RPQ, you can also add a 3215 style device. This is done by adding CHPARM=40 to the IOCDS device definition via HCD, once the RPQ is installed.
With version 2.15.00 of the SE software, the HMC has become a virtual appliance, so the 3270 builtin consoles now run a little differently than in the past when they were run on standalone boxes.
Joe
Fish-Git
commented
2 years ago ... 3215 style support can be added (via RPQ) to the OSA-ICC server (now what OSA-Express7?) in the z/series platform.
When such a device is provided to z/os, then z/os can use it as the console, the same as a SYSG console.
But with the RPQ, you can also add a 3215 style device. This is done by adding CHPARM=40 to the IOCDS device definition via HCD, once the RPQ is installed.
Then WHY, pray tell, did you open this GitHub Issue requesting that we disallow 3215/1052 support when z/Arch is specified???!!!!! (Sheesh!) 8-<
joemonk64
commented
2 years ago I did it because a CHANNELATTACHED 3215 is not supported ... which is where I was trying to go with the whole thing.
What I was gonna try to get you to do was to ADD support for plain telnet sessions via a device like an OSA card...
I promise the motives weren't sinister :)
Joe
On Mon, Dec 20, 2021 at 4:12 PM Fish-Git @.***> wrote:
... 3215 style support can be added (via RPQ) to the OSA-ICC server (now what OSA-Express7?) in the z/series platform.
When such a device is provided to z/os, then z/os can use it as the console, the same as a SYSG console.
But with the RPQ, you can also add a 3215 style device. This is done by adding CHPARM=40 to the IOCDS device definition via HCD, once the RPQ is installed.
Then WHY, pray tell, did you open this GitHub Issue requesting that we disallow 3215/1052 support when z/Arch is specified???!!!!! (Sheesh!) 8-<
— Reply to this email directly, view it on GitHub https://github.com/SDL-Hercules-390/hyperion/issues/452#issuecomment-998308664, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF6U7NOFCFLLNRSCS4MLQNLUR6S4DANCNFSM5KHMK2RQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
joemonk64
commented
2 years ago But enough. Lets just drop it and still be friends.
Fish-Git
commented
2 years ago What I was gonna try to get you to do was to ADD support for plain telnet sessions via a device like an OSA card...
I don't understand. Telnet works perfectly fine with z/OS via OSA.
I promise the motives weren't sinister :)
I never believed they were. :)
I was just taken aback (quite surprised/confused) by your confirmation that 3215 devices are indeed supported when your original request was for us to not support/allow them for z/Arch. The utter illogicalness of it all completely threw me.
But enough. Lets just drop it and still be friends.
Done! :)
The 1052 or 3215 are not valid devices on z/Arch. So, when the ARCHLVL is z/Arch, those devices should not be allowed to be configured in a Hercules configuration file.