Re: Non displayable characters in a PF

David FOXWELL wrote:

I'd like to be able to understand why when the characters are
pasted to the screen by the user, they are not visible.
However, when validated, the unwanted data is available to
the RPG program and get written to the file. <<SNIP>>

The EBCDIC bytes of data that are 5250DS control characters take a position in the data stream, but each is not manifest as\with a visible glyph; for lack of a glyph, its position might appear to be a space character, regardless that it is in fact neither a 0x40 nor 0x41 in EBCDIC [both /space/ characters; x'41' is for most CCSIDs]. Some ASCII control characters will translate into mapped /equivalence/ characters or simply paste as the untranslated code point; i.e. the ASCII tab may become an EBCDIC tab, but an ASCII byte which has no specific mapping to EBCDIC may paste as the same hex byte value.

An earlier question about why DSPPFM /shows/ them is a simple case of that program [QNFBROWS] using the translate instruction to convert all non-displayable [i.e. mostly the control characters] into a /blob/ character [I do not recall its hex value]. Thus instead of showing no glyph, the equivalent of a space, the DSPPFM purposely represents each non-display-capable character [position] with a glyph which is basically all points of the block being lit; i.e. the /blob/ versus any typical keyboard character which might more easily be confused with real data.

An emulator may provide a translation table to enable changing the characters that are pasted. There may also be a /paste as text/ feature for an emulator which would automate such a translation with its own pre-defined translation table.

Regards, Chuck