On Tuesday, 11/01/2016 at 04:22 GMT, [email protected] wrote:
> > Browse, on the other hand, is full screen. Be careful what kind of
data <
> > 0x40 you send to pipelines full screen stages.
>
> In other words, it is my fault that some codepoints turn out
> different by cons/term and browse. In that case the simplest
> solution would be to reuse the 3270 I used before. :)
It may be, yes. If browse was designed to protect the integrity of the
3270 data stream and it doesn't, then it's broken. If it was designed to
send data as-is and depends on the programmer to normalize the user data
to 0x40-0xFE, then yes, it's on you. I would think that browse would do
that on its own since you can't directly edit or view data < 0x40 as a
typeable character.
> > Note that it provide TERMCODEPAGE and DATACODEPAGE so that it can
> > translate correctly.
>
> I played with this two options, seems I have to play a bit more.
Your application can parse the output of DIAGNOSE 0x8C (REXX diag('8C')
BIF) to discover the code page of the terminal and use that value on
TERMCODEPAGE.
> One more question about your note, that cons/term is 3215 line
> mode. And if I set CMS fullscreen on, is it still line mode?
No. It works like XEDIT. That is, CMS is building the 3270 data stream
and handling all the translation. As with CP, most data < 0x40 will be
converted to the "non-displayable" character you select via SET NONDISP.
Behavior of a 3270 is device-dependent with respect to its behavior when
it encounters a non-control character (0x40-0xFE) that it cannot display.
3277s used to give a PROG error. 3278s changed it to use a 'substitution'
character and keep going..
Alan Altmark
Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
[email protected]
IBM Endicott
