search

SDL-Hercules-390 / hyperion

The SDL Hercules 4.x Hyperion version of the System/370, ESA/390, and z/Architecture Emulator
Other
240 stars 90 forks source link

Allow for a SYSGPORT configuration statement #505

Closed arfineman closed 1 year ago

arfineman commented 1 year ago

It would be nice to have a SYSGPORT statement to distinguish a SYSG port from a 3270 port. If not specified, it would default to the current CNSLPORT.

Fish-Git commented 1 year ago

Why? What's the problem? Why would you want/need to use a separate port?

arfineman commented 1 year ago

Currently, if you have a SYSG defined, the first 3270 connection automatically gets assigned to SYSG. Then any subsequent connections are assigned to 3270 devices. But this may not be desirable. On real hardware, SYSG is started on demand and one could have lots of 3270 devices without SYSG.

Fish-Git commented 1 year ago

Currently, if you have a SYSG defined, the first 3270 connection automatically gets assigned to SYSG. Then any subsequent connections are assigned to 3270 devices.

Only if your configuration file is coded to behave that way.

But this may not be desirable. On real hardware, SYSG is started on demand and one could have lots of 3270 devices without SYSG.

Understood. Which is why Hercules supports the groupname, ipaddr and mask options on its 3270 device statements, including SYSG devices:

Fish-Git commented 1 year ago

_P.S.   It is preferred that you not respond/reply to GitHub Issues via email *`()`**, and instead respond/reply directly via the GitHub Issues web page itself:_

_When you reply directly via their web page, I can make minor edits to your reply so it is more readable (prettier) by editing the fonts being used, formatting log messages, etc. When you reply via email however, I cannot edit your reply (GitHub does not allow it), so oftentimes it is much harder (more difficult) to read._

It is up to you whether or not you want to take the time to reply via their web page or continue to reply via email, but it is generally preferable that you reply directly via their web page instead.

Thanks

(*) GitHub does not support formatting of, nor attaching files to, email replies, making it impossible for me to fix the formatting of a person's reply for readability or receive the file that was requested from them. Thank you for understanding.

arfineman commented 1 year ago

Thank you, Fish.

The problem may be with my 3270 emulator. I can't specify a groupname or a device address on the hostname. I may be wrong, but it looks like the doc implies that not all emulators support that. Currently I just comment out the SYSG and only put it back in when needed.

Again, I thought this is a nice to have, but if you feel its not needed, you can close it out.

Fish-Git commented 1 year ago

The problem may be with my 3270 emulator. I can't specify a groupname or a device address on the hostname.

What emulator are you using?

Again, I thought this is a nice to have, but if you feel its not needed, you can close it out.

It certainly has merit, I'll give you that. And it should certainly be easy enough to implement too IMO, so I think we should probably keep this request open. Maybe someone out there will be able to implement it for you before I do. (*)

Any takers?

(*) I'd do it myself but I'm kind of busy with the "COD" thing right now, so if I do it it'll have to wait until later. Sorry. But maybe somebody else can do it before I can? Hello? Anyone?

arfineman commented 1 year ago

I did try a few different 3270 emulators to see if I can accomplish this using a group name. I found only the wc3270 command line allows for entering a groupname@hostname:port. But the session wizard does not allow for a '@' in the hostname.

Fish-Git commented 1 year ago

Aaron (@arfineman),

Closed by commit 6dee8ff37b3b92a10fc33d873c5f6eea2cce5f8c.

Please give it a try and tell me what you think.

Thanks.

arfineman commented 1 year ago

Hi Fish, Thank you so much for putting this in. I'm sure besides me a lot of other people will make good use of this feature. This allows users to create a separate x3270 session for the SYSG port. I'm a Windows user and never had success building Hercules from source. So I'll have to wait for the next release, which I hope will come out soon. Best regards,

Fish-Git commented 1 year ago

I'm a Windows user

As am I.

and never had success building Hercules from source.

What's the problem? Building Hercules from source is actually pretty easy IMO. Of course, I'm a developer too, and so do it all the time, which is why I find it to be easy. But even for the average non-developer Windows user it's not really that difficult.

In fact, Bill Lewis (i.e. @wrljet, a fellow Hercules developer) has created a very nice, easy to use Windows Power Shell helper script called "Hercules Helper" that totally automates the entire process, making doing so dirt simple. You just enter a simple command, press enter, and in a few minutes, Voilà! You've got a working version of Hercules on your system.  :)

Of course you have to clone his repository first, which requires having git already installed on your system, but that's not really a big problem. Installing git is just a simple download and a few mouse clicks, and cloning Bill's "Hercules Helper" repository is just a simple one-line command once git is installed. <shrug>

Try it!   I think you'll be glad you did.

(Bill? Does your script support building the "develop" branch?)

wrljet commented 1 year ago

"develop" branch is the default.

You can download the Hercules-Helper-Windows repo as a zip file from GitHub, without git.

I'm here, and all ears, to help anyone who wants it.

Bill

Fish-Git commented 1 year ago

"develop" branch is the default.

That's good to hear!

You can download the Hercules-Helper-Windows repo as a zip file from GitHub, without git.

(Doh!)  Of course.  How silly of me.  <%-þ

wrljet commented 1 year ago

I have also just created a macOS Homebrew installation formula. Makes installing the latest SDL-Hercules-390 develop absolutely trivial on macOS. (not "released" yet)

wrljet commented 1 year ago

Correction, "develop" is not the default. You need to add the command line option -GitBranch develop

arfineman commented 1 year ago

Thank you, Bill. I downloaded the zip file. But neither my W7 or W10 can open the 'README.md' to start the process. Am I doing something wrong, or do I need to download something to read that file. I do have Office 2016 installed. Best regards,

arfineman commented 1 year ago

Please ignore the previous message. Looks like if I associate .md file extension to Wordpad, it opens fine. My bad.

wrljet commented 1 year ago

Aaron,

README.md is a "Markdown" file. That is the default for such things on GitHub.

If you scroll down on the GitHub page past the file list, it displays the README.md with its formatting.

I don't know how to view those with their formatting on Windows.

Bill

Fish-Git commented 1 year ago

But neither my W7 or W10 can open the 'README.md' to start the process.

What do you mean by "cannot open"? Did you "unblock" the downloaded .zip file before you unzipped it, as Bill's web site explains in Step 2?

Sometimes when files are copied to Windows, it will decide they have come from an untrusted remote system, and a directory bit will be set to remember this fact. This will cause Windows to not allow them to be executed.

Right-click on the hercules-helper.zip file and select Properties. At the bottom of the Properties dialog, you may see a warning about the file coming from a remote system. Click the button to Unblock the file. Close this dialog.

This is standard Windows behavior:

I believe ".md" files are treated as browser files, just like ".htm" or ".html" files are, and thus either your browser or Windows itself may be purposely preventing you from opening them since it considers them "untrustworthy" since they came from a foreign system. You need to manually unblock the file before attempting to open it.

As far as displaying the README.md files in an easy-to-read format in your browser, you might consider installing a "markdown viewer" type extension, such as the following one that I myself use for Chrome:

If you so search the web there are even "online" web pages where you can upload or paste your markdown file/code into a text box and it will display the rendered markdown code for you.

(Markdown files are just simple, specially formatted text files, similar to HTML files that can also be opened in Notepad, but which when opened in a browser are parsed and displayed in a much more user friendly manner.)

Fish-Git commented 1 year ago

But all of that (what I've written in my previous comment above) is only if you want to view on your own system the information that already exists on Bill's web site:

Visit the above web page and scroll down maybe one page, and you will see exactly the same information that is in the README.md file. The GitHub web site automatically displays .md files already properly formatted for you. If you want to display the same thing (i.e. .md files) locally in your own browser window, then you need to install a browser extension like the one I suggested.

Fish-Git commented 1 year ago

I don't know how to view those with their formatting on Windows.

You need to use a browser extension, such as Markdown Viewer.

Fish-Git commented 1 year ago

Looks like if I associate .md file extension to Wordpad, it opens fine.

You shouldn't need to do that! You should (IMHO) leave the file associated with your browser, just like it was. Opening and properly displaying .md files is not that hard to do once you know how.

(And once you UNBLOCK them beforehand, of course!)

wrljet commented 1 year ago

I don't know how to view those with their formatting on Windows.

You need to use a browser extension, such as Markdown Viewer.

I don't do Chrome.

Fish-Git commented 1 year ago

I don't do Chrome.

What do you do?

wrljet commented 1 year ago

Firefox, and when that doesn't work (which is more and more common on websites these days), the new MSFT Edge.

Fish-Git commented 1 year ago

Firefox, and when that doesn't work (which is more and more common on websites these days), the new MSFT Edge.

wrljet commented 1 year ago

Thanks, Fish! I put in the one for MSFT Edge, and it just worked.

arfineman commented 1 year ago

Hi Bill,

Does hyperion-buildall.ps1 script download the Hercules source, or do I need to do that manually?

If so, is there a wget command to get the latest source?

wrljet commented 1 year ago

It will install Visual Studio (you can select which major version you prefer) with the required workloads, clone the SDL-Hercules-390 GitHub repo, and do the whole thing.

(That said, I don't often retest with a completely pure virgin Windows, so things can break over time.)

Be sure to add the -GitBranch develop option to the command line so you get the latest with the new feature.

arfineman commented 1 year ago

There has to be powershell for dummies manual somewhere.

PS C:\users\asus\desktop\hrc\hrc> .\hyperion-buildall
File C:\users\asus\desktop\hrc\hrc\hyperion-buildall.ps1 cannot be loaded. The file C:\users\asus\desktop\hrc\hrc\hyper
ion-buildall.ps1 is not digitally signed. The script will not execute on the system. Please see "get-help about_signing
" for more details..
At line:1 char:20
+ .\hyperion-buildall <<<<
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

PS C:\users\asus\desktop\hrc\hrc>
wrljet commented 1 year ago

I hate PowerShell as much as the next guy, but it's what Windows gives us.

You need to enable it to run foreign untrusted scripts.

Check out my Step 1 where it talks about Set-ExecutionPolicy RemoteSigned.

arfineman commented 1 year ago

But I already did that the first time. And again here:

PS C:\users\asus\desktop\hrc\hrc> set-executionpolicy remotesigned

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution
policy?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y
PS C:\users\asus\desktop\hrc\hrc> .\hyperion-buildall
File C:\users\asus\desktop\hrc\hrc\hyperion-buildall.ps1 cannot be loaded. The file C:\users\asus\desktop\hrc\hrc\hyper
ion-buildall.ps1 is not digitally signed. The script will not execute on the system. Please see "get-help about_signing
" for more details..
At line:1 char:20
+ .\hyperion-buildall <<<<
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

PS C:\users\asus\desktop\hrc\hrc>
wrljet commented 1 year ago

OK This is where I normally start cussing.

Let's start with, what Windows are you on, and what version of PowerShell is it?

With that info I'll fire up a fresh copy in a VM.

Bill

wrljet commented 1 year ago

One more question: did you close and reopen the PowerShell window after doing Set-ExecutionPolicy RemoteSigned? And, you need to run that command in an As-Admin PowerShell.

arfineman commented 1 year ago

OK. Making progress. I exited PS and came back in. Now it is complaining about a -BuildDir parameter. Where do I specify -Gitbranch develop? Can you post the exact command I need to enter?

PS C:\users\hp\desktop\hrc\hrc> .\hyperion-buildall.ps1
Transcript started, output file is .\hercules-helper-20221018_18-56-49.log

Options:
C:\users\hp\desktop\hrc\hrc\hyperion-buildall.ps1 : Error: -BuildDir parameter is missing
At line:1 char:1
+ .\hyperion-buildall.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,hyperion-buildall.ps1

Transcript stopped, output file is C:\users\hp\desktop\hrc\hrc\hercules-helper-20221018_18-56-49.log
PS C:\users\hp\desktop\hrc\hrc> .\hyperion-buildall.ps1 -gitbranch develop
Transcript started, output file is .\hercules-helper-20221018_18-58-58.log

Options:
C:\users\hp\desktop\hrc\hrc\hyperion-buildall.ps1 : Error: -BuildDir parameter is missing
At line:1 char:1
+ .\hyperion-buildall.ps1 -gitbranch develop
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,hyperion-buildall.ps1

Transcript stopped, output file is C:\users\hp\desktop\hrc\hrc\hercules-helper-20221018_18-58-58.log
PS C:\users\hp\desktop\hrc\hrc>
Fish-Git commented 1 year ago

Now it is complaining about a -BuildDir parameter. Where do I specify -Gitbranch develop? Can you post the exact command I need to enter?

It's all documented in Bill's README!

Refer to the instructions for Step 4:

Decide where (what directory) you want Hercules to be built, and decide if you prefer to use Visual Studio 2017, 2019, or 2022, and then specify those options (as well as the -GitBranch option too) in your command, e.g:

    .\hyperion-buildall.ps1 -VS2017 -BuildDir c:\hercules -GitBranch develop
arfineman commented 1 year ago

Thank you. I misunderstood. I thought that script does all those steps for you.

Success!

This script is unbelievable! Build is complete. Now I can pickup the latest and greatest without having to wait for a new official release. Now I can test the SYSGPORT command.

Thanks so much to Bill and Fish!

wrljet commented 1 year ago

Glad to hear it!

Aaron, if you don't mind, would you find the log file it created, the one with the newest timestamp, zip it and send to me. I'd like to review it. The filename will be along the lines of hercules-helper-20220920_18-26-13.log.

arfineman commented 1 year ago

Will do. This was done on my home PC as will take care of it this evening when I get home. Thanks again for putting this together for dummies like me. I had tried it several times before on my own without success. Best regards,

arfineman commented 1 year ago

Hi Fish,

I tested the SYSGPORT as a configuration statement and also as a command and it works perfectly.

I see that you set the default port number to 3278. That works great for me. I added a SYSGPORT 3278 to my config file regardless. I should point out however that this may be problematic for an existing user of SYSG that is used to the old port 3270, as this change may not be considered backward compatible. This is strictly your call if you want the default to be 3270 or 3278.

Fish-Git commented 1 year ago

I see that you set the default port number to 3278. [...] I should point out however that this may be problematic for an existing user of SYSG that is used to the old port 3270, as this change may not be considered backward compatible. This is strictly your call if you want the default to be 3270 or 3278.

Unfortunately the SYSGPORT port number must be different from the CNSLPORT port number. This is because you can't have two listening sockets both listening for connections on the same port. Otherwise when someone tries connecting to that port, it would be completely unpredictable which listening socket would end up accepting the connection (thereby making it impossible to determine whether the user wanted to connect a SYSG console or a regular 3270 terminal). The new code should be enforcing this restriction. Otherwise it just wouldn't work right. You can verify this for me if you want by trying to define both of them to the same port. Depending on which one you define first, the other one should be rejected with an error.

Your point is valid however: introducing new unexpected behavior is rarely a Good Thing.

I suppose I could tweak the new code a tiny bit to support specifying e.g. SYSGPORT NO (and make that the default) to prevent the new SYSG port listening socket from being created. Doing that (and making a few other minor adjustments) should I believe allow the old behavior to work the same as it did before.

Let me think about it...

arfineman commented 1 year ago

Log attached.

On Wed, Oct 19, 2022 at 10:55 AM Bill Lewis @.***> wrote:

Glad to hear it!

Aaron, if you don't mind, would you find the log file it created, the one with the newest timestamp, zip it and send to me. I'd like to review it. The filename will be along the lines of hercules-helper-20220920_18-26-13.log.

— Reply to this email directly, view it on GitHub https://github.com/SDL-Hercules-390/hyperion/issues/505#issuecomment-1284148330, or unsubscribe https://github.com/notifications/unsubscribe-auth/APLI2226PXQWBCJV7XN34NDWEADW3ANCNFSM6AAAAAAQYADSYU . You are receiving this because you were mentioned.Message ID: @.***>

Fish-Git commented 1 year ago

Log attached.

Um, no it isn't.  :(

This is yet another reason why I prefer that people respond directly to GitHub Issues and not via email.

arfineman commented 1 year ago

Sorry, I replied this time, expecting it directly to go to Bill. Here is the attachment.

Fish-Git commented 1 year ago

... expecting it directly to go to Bill.

That would only occur if you manually changed the email "To:" field to his email address. If you don't do that, the email goes "To:" GitHub, which, as explained, doesn't support attachments.

arfineman commented 1 year ago

Fish, My opinion on this is that your update fixed an existing problem. On a real hardware, SYSG is only used either during IPL or an emergency when TCP/IP is lost. It is known as the Integrated 3270 Console and is a standard feature on HMC and is only started on demand. The way this was implemented on Hercules, you were forced to open a SYSG session if you wanted to use any of the 3270 ports. This was inconsistent with the way it works on HMC, where OSA-ICC (Local 3270) devices connect independently. I know you initially marked it as an enhancement, but I considered it a bug. I was just happy that you agreed to consider it. Best regards,

Fish-Git commented 1 year ago

Your point is valid however: introducing new unexpected behavior is rarely a Good Thing.

I suppose I could tweak the new code a tiny bit to support specifying e.g. SYSGPORT NO (and make that the default) to prevent the new SYSG port listening socket from being created. Doing that (and making a few other minor adjustments) should I believe allow the old behavior to work the same as it did before.

Let me think about it...

Done!

Aaron? (@arfineman) Please rebuild and re-test. The original Hercules behavior (before any of my changes) should be restored now when a SYSGPORT statement is not specified (or is specified as "NO"). The new behavior is only triggered whenever a SYSGPORT statement is specified with a valid port number.

This should prevent "unexpected new behavior" for our existing users while still allowing them to take advantage of the new behavior should they wish to.

Thanks.

I am closing this issue as completed again. This time hopefully for good!  ;-)

wrljet commented 1 year ago

Aaron,

Hercules-Helper will not re-clone or update your local SDL-Hercules-390 git repo. This is for safety, until I add an override option for that.

So to update and rebuild:

pushd C:\hercules\hyperion
git pull
popd

The Visual Studio installation should have left you with a command line git, so the above will hopefully just work.

Then rerun your original hyperion-buildall command.

Bill

arfineman commented 1 year ago

Fish, I tested the changes and it's perfect. It just can't get any better than this. Without SYSGPORT it behaves exactly as before, as you intended. With SYSGPORT specified, it acts just like a z15. Thank again again for fixing this. And thank you Bill for providing the wonderful Hercules_Helper tool. Best regards, Aaron

wrljet commented 1 year ago

Fish,

The latest commit https://github.com/SDL-Hercules-390/hyperion/commit/66ff70ab4830660fef2a881ba4918fdb212972cf , related to this SYSGPORT, is busted (on Linux).

Hercules won't connect to the 3270 console with c3270 127.0.0.1:3270. It just hangs, waiting. This was reported to me on the Moshix Discord channel and I have reproduced it here on Debian 10 and 11, and narrowed it down to the latest commit.

Bill

Fish-Git commented 1 year ago

The latest commit 66ff70a , related to this SYSGPORT, is busted (on Linux).

Hercules won't connect to the 3270 console with c3270 127.0.0.1:3270. It just hangs, waiting. This was reported to me on the Moshix Discord channel and I have reproduced it here on Debian 10 and 11, and narrowed it down to the latest commit.

That's odd. The logic is platform independent and should work identically on Nix as it does on Windows. I promise you I did test it on Windows, and it worked just fine! Aaron, who also uses Windows, also reported that it worked just fine for him too, so why the frick it's failing on nix I have no freaking idea.

(sigh) Let me look into it an get back to you...  :(