Re: Issue with new IBM Access Client Solutions Emulator (still!)

On 13-Apr-2017 08:37 -0500, Jeff Young wrote:

On Tue, Apr 11, 2017 at 4:53 PM, CRPence wrote:

On 31-Mar-2017 10:14 -0600, Jeff Young wrote:

Just upgraded to latest version.
On prior version, I had a issue when attempting to display data
where the field in question had an X'03' (ETX) as the last
position.
I was first informed that this had been fixed in a prior PTF, but
I had the version after that fix.
The new version still has this problem:
[ed.] msgCPF5411 rc00002301 fc00002301 t/QWSGET x/3478
msgCPF5257 t/QQURB X/050E

When I used the old Client Access Emulator, it works just fine.

I am not authorized to report problems to IBM.

Given there is no possibility to present the non-alphanumeric code
point 0x03 as a visible glyph on the report display [file
QDQUWSRUN], why not just correct the apparent problem with the
underlying data, by ensuring that the character data field
contains only /characters/ instead of control codes. Or if the data
is legitimate, in a BINARY [or DDS Hex] data-type field, then
present the data for that field using an effective HEX() scalar, or
replace/translate each of the non-displayable characters as another
that is printable/displayable, e.g. presented as a blank. That
effect can be encapsulated in a logical file/view without changing
the physical data; so instead of changing emulators, just refer to
the logical file [every time any displayed/printed reporting is
directed against the file].

While that is a possible solution, I am capturing a string of data
received via a TCP Socket from a 3rd party and prefer to keep the
raw data (translated to EBCDIC) as received.
The old IBM Client Access Emulator has no problem showing this as a
non displayable character with the [ed] msg QRY1041 "Cannot show this
data at the display station." appearing on the bottom of the screen.
I would *think* that the new emulator should at the very least have
the same ability and not blow up.

I agree with the desire for consistency; that the emulated WS Controller feature and emulated WS Device should quite well mimic the actual hardware. I had even argued for that, multiple times.

But that effect should be understood to be effectively, more generally, as somewhat unpredictable results, for the presentation of non-character data; lest the non-character data were known to be valid control sequences being sent to the controller. That is to suggest, that there is an inherent problem in such scenarios, generally, with allowing the Query/400 report writer to function as designed; i.e. to push the data to the screen irrespective the unprintable characters, and that report writer expecting the the WSC to diagnose that any non-printable characters were sent. And that is a problem because, the binary/non-character data allows for some of that data sent to the screen to be interpreted as valid 5250 data-stream controls, such that what is eventually presented on the display may not actually be consistent with glyphs that might be expected to have been visible and aligned on the displayed report, just as the report writer would do correct with *only* _character_ data -- similar potential issues can occur with spooled data, depending on how the control codes are interpreted, as well as on the RPLUNPRT() setting.

So I am suggesting that, if the data is known to contain non-printable data, then the safest approach is to explicitly suppress or otherwise re-represent those control codes, rather than depending on the hardware or the emulation to suppress them -- which neither might, and the results [of attempting to present various un-planned control characters as character data] should be considered suspect. That even if the terminating error goes away [e.g. per a PTF], sending the control codes to the display should still be avoided; that some translation of the codes to displayable characters is still the more prudent path.

Try for example [in that and other emulator(s)], the following query, for which the 0x03 appears just once per line; presumably, everyone would expect to see three rows of data. But I doubt few if any who would run this report, and who see the Display Data screen presented, will actually see those three rows presented as the effect of reporting:

values ( 'aaaaa' concat x'03' )
, ( 'BBBBB' concat x'03' )
, ( 'CCCCC' concat x'03' )

On my emulator for example, the report for the above query requested in STRSQL does not give the error\failure, but the displayed report appears as *only* the first row of data [i.e. the 'aaaaa'], but conspicuously devoid of either of the 'BBBBB' and 'CCCCC', and the End-Of-Data line [perhaps less conspicuously] is also missing; surely that effect not an accurate portrayal of the character data.?:

....+.
VALUES
aaaaa