"Fish" (David B. Trout)

> I may be mistaken, but it appears from the above snippet that you are only telling gdb where the core file is, but not where the executable is that...

> Then you break something. System configuration statements should, and always have been, independent of the architecture level. Then how do you propose to eliminate the described "Surprise!" factor, as...

Hmmm... So you're proposing a `FORCE` option on the _`CPUIDFMT`_ statement, not the `LPARNUM` statement. Interesting. I think I like that better!

For 370: > CPUIDFMT 1 is specified: > Issue warning at IMPL/POR, do as if CPUIDFMT was set to 0. I would add that not only should we issuing a...

@ivan-w > Ok, let's run down the various cases. [...] Where in Hercules code should the above checks be made? In each of the `ARCHLVL`, `CPUIDFMT` and `LPARNUM` statement processing...

Thank you for reporting this, Alex. I have added this item to my "TODO" list and will eventually get around to doing it. Please let me know if this issue...

Thank you, Alex. Having a stand-alone test program would be very helpful. I will contact you once I begin work on this issue.

> The forward-porting of channel-based I/O was an alternative to both solutions. > Today, the "strange" I/O design you see here has been demonstrated as one that is not feasible...

> It is very obtuse coding, but essentially a lot of Hercules is compiled three times. Correct. > I thought that was true for all instruction tables. That has _never_...

> Normally, the function generates variations on the same instruction for the different architectures. However, there is nothing stopping the function for s/370 and z from having entirely different functionality....