> And under VM, of course, the translation should follow the 3215 HW
> capabilities, requiring at least as many kernel tables as there could
> be legitimate "consoles" for it to talk to, I would think. That or VM
> needs to provide an HMC virtual device (I know, that one's a lot less
> likely to get done).
Uhh... That's not what I meant to suggest.
Having lots of kernel A/E tables might be alright as an option.
My beef was just that the default translation when talking to a
(virtual) 3215 should match the ISO 8859-1 to CP 37 v2 mapping.
I am *not* anxious to see a plethora of codepages loaded up
into the kernel to support the myriad of IBM devices out there.
It would make a lot more sense to get the default translation right
and then require emulators ('x3270' is what I use) to handle
"CP 37 v2" or at least handle CP 1047.
Having a vast array to choose from
and loading one at a time ... THAT might be palatable.
In fact, it would be truly spiffy if some user-space program could
take IBM-defined binary translation files and do the right thing
to the kernel's console driver from that spec, one map at a time.
> >it is fair that console kernel codepages be asymmetrical:
...
> But commands from the real HMC to a linux LPAR (and by extension, from
> a hercules HMC) might well need to include any characters needed to do
> shell-level scripting in an emergency. The translation needs to be
> accurate for those cases, I would think.
Right. But accurate scripting in an emergency
does not also require that the translate table be symmetric.
You get input translated correctly from a number of possible
reference code pages. If the output does not match,
the operator can figure out what is happening from the context.
Again, this is for the emergency, not for "production".
(But avoid HMC for production work anyway, as IBM recommends.)
> >Here too, a switch after the fact would be reasonable.
>
> ??? After which fact? You lost me here.
I mean that you could load a symmetrical table later on,
after the emergency has passed.
-- RMT
