From: CZIWKGA@VMSFE.ULCC.AC.UK ("Kevin Ashley, Systems Development, ULCC")
Newsgroups: comp.os.vms
Subject: Re: problem editing a file - wrong char set ?
Date: 27 Jan 93 16:35:00 GMT
Organization: The Internet

About a week ago (we've had some mail backlogs around here)
Ulli Horlacher wrote:

> We (VAX 9410, VMS 5.5, PSI 4.3) have users which use a databank on a VM
> System via x.25 remote login. They do a SET HOST/X29/LOG to the VM.
> 
> The logfile which is produced looks very wired (or at least I don't
> know what it means. :-) ):
> 
> If I TYPE it on a vt100, it looks like plain ASCII, but if I TYPE it on a
> VT220 or edit it (EDT or LSE) it contains only control-characters.
> 
> Now my questions: - why can I type (and read) it on a vt100 but not on a
>                     vt220?

  Because the IBM insists on sending out characters with parity bits
on (can't remember if it likes even or odd, but it likes one of them),
and the /LOG function of PSIPAD records data exactly as sent to the
terminal. The VT100 doesn't support eight-bit data, and so either
ignores the parity bit or, at worst, checks it. The VT200 does support
eight-bit data and tries to interpret the parity bit as part of the
character code, unless you've set it to 7-bit mark or space parity (which
causes it to ignore the parity bit) or some other 7-bit setting which
matches the IBM.

[Note that 7-bit space parity is the only safe one ;
VMS will still think that your terminal is using 8-bit no parity, and
won't recognise carriage return (amongst others) if it arrives
with a parity bit set.]

 When you use EVE or EDT, they always indicate the presence of characters
with the top bit set, even on terminals such as the VT100 that don't
support displaying them directly.

>		  - is there a way to prevent this wrong character set,
>		    like SET HOST /qualifiers?

Well, this question is a bit broad - it MAY be possible to prevent
the IBM system sending out characters with parity bits on by configuring
things within the IBM system. You don't say if it supports X.29 directly
(with NPSI and VTAM) or if the link is somewhat more indirect. In any event,
your message suggests you don't have much control over that end of things.

Given that that is the case, you can't stop the logfile containing these
characters, since PSIPAD always logs what it gets. Doing a SET TERMINAL/NOEIGHT
doesn't alter this (nor does it stop PSIPAD sending all eight bits to
the terminal).

What you can do is massage the logfile to make it readable, which
brings us to your next question...
> 
> 
> 		  - how can one translate old logfiles of this kind to a
>                     printable format (the databank inquiry was very
>                     expensive, please don't say: "do it again with other
>                     terminal/SET HOST setups")?
> 

I have a program which will take logfiles produced by PSIPAD (SET HOST/X29)
and turn them into variable-length record files with implied carriage
control, optionally stripping parity. You may or may not be aware (you
will be after removing the parity bits) that the logfiles are
confusing in more ways than one ; they are variable length, with no
end-of-record carriage control, but with carriage returns and linefeeds
possibly embedded within the records. This is another feature of
how PSIPAD produces the logfiles - each received X.29 packet produces
one record in the logfile. Such logfiles print OK, TYPE OK, but are
difficult to edit with most editors (TECO being an exception) and
difficult to post-process if that is what you want to do.

If you're interested in the program, and haven't already received better
answers, email me privately and I'll send it.
------------------------------------------------------------------------------
Kevin Ashley                              K.Ashley@Ulcc.ac.uk
Systems Development Group Manager         ...ukc!ncdlab!K.Ashley
University of London Computer Centre. 
Newsgroups: comp.os.vms