home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 22226 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  4.0 KB
  1. Path: sparky!uunet!ulowell!m2c!bu.edu!att!ucbvax!VMSFE.ULCC.AC.UK!CZIWKGA
  2. From: CZIWKGA@VMSFE.ULCC.AC.UK ("Kevin Ashley, Systems Development, ULCC")
  3. Newsgroups: comp.os.vms
  4. Subject: Re: problem editing a file - wrong char set ?
  5. Message-ID: <9301280105.AA02133@ucbvax.Berkeley.EDU>
  6. Date: 27 Jan 93 16:35:00 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Organization: The Internet
  9. Lines: 76
  10.  
  11. About a week ago (we've had some mail backlogs around here)
  12. Ulli Horlacher wrote:
  13.  
  14. > We (VAX 9410, VMS 5.5, PSI 4.3) have users which use a databank on a VM
  15. > System via x.25 remote login. They do a SET HOST/X29/LOG to the VM.
  16. > 
  17. > The logfile which is produced looks very wired (or at least I don't
  18. > know what it means. :-) ):
  19. > 
  20. > If I TYPE it on a vt100, it looks like plain ASCII, but if I TYPE it on a
  21. > VT220 or edit it (EDT or LSE) it contains only control-characters.
  22. > 
  23. > Now my questions: - why can I type (and read) it on a vt100 but not on a
  24. >                     vt220?
  25.  
  26.   Because the IBM insists on sending out characters with parity bits
  27. on (can't remember if it likes even or odd, but it likes one of them),
  28. and the /LOG function of PSIPAD records data exactly as sent to the
  29. terminal. The VT100 doesn't support eight-bit data, and so either
  30. ignores the parity bit or, at worst, checks it. The VT200 does support
  31. eight-bit data and tries to interpret the parity bit as part of the
  32. character code, unless you've set it to 7-bit mark or space parity (which
  33. causes it to ignore the parity bit) or some other 7-bit setting which
  34. matches the IBM.
  35.  
  36. [Note that 7-bit space parity is the only safe one ;
  37. VMS will still think that your terminal is using 8-bit no parity, and
  38. won't recognise carriage return (amongst others) if it arrives
  39. with a parity bit set.]
  40.  
  41.  When you use EVE or EDT, they always indicate the presence of characters
  42. with the top bit set, even on terminals such as the VT100 that don't
  43. support displaying them directly.
  44.  
  45. >          - is there a way to prevent this wrong character set,
  46. >            like SET HOST /qualifiers?
  47.  
  48. Well, this question is a bit broad - it MAY be possible to prevent
  49. the IBM system sending out characters with parity bits on by configuring
  50. things within the IBM system. You don't say if it supports X.29 directly
  51. (with NPSI and VTAM) or if the link is somewhat more indirect. In any event,
  52. your message suggests you don't have much control over that end of things.
  53.  
  54. Given that that is the case, you can't stop the logfile containing these
  55. characters, since PSIPAD always logs what it gets. Doing a SET TERMINAL/NOEIGHT
  56. doesn't alter this (nor does it stop PSIPAD sending all eight bits to
  57. the terminal).
  58.  
  59. What you can do is massage the logfile to make it readable, which
  60. brings us to your next question...
  61. > 
  62. > 
  63. >           - how can one translate old logfiles of this kind to a
  64. >                     printable format (the databank inquiry was very
  65. >                     expensive, please don't say: "do it again with other
  66. >                     terminal/SET HOST setups")?
  67. > 
  68.  
  69. I have a program which will take logfiles produced by PSIPAD (SET HOST/X29)
  70. and turn them into variable-length record files with implied carriage
  71. control, optionally stripping parity. You may or may not be aware (you
  72. will be after removing the parity bits) that the logfiles are
  73. confusing in more ways than one ; they are variable length, with no
  74. end-of-record carriage control, but with carriage returns and linefeeds
  75. possibly embedded within the records. This is another feature of
  76. how PSIPAD produces the logfiles - each received X.29 packet produces
  77. one record in the logfile. Such logfiles print OK, TYPE OK, but are
  78. difficult to edit with most editors (TECO being an exception) and
  79. difficult to post-process if that is what you want to do.
  80.  
  81. If you're interested in the program, and haven't already received better
  82. answers, email me privately and I'll send it.
  83. ------------------------------------------------------------------------------
  84. Kevin Ashley                              K.Ashley@Ulcc.ac.uk
  85. Systems Development Group Manager         ...ukc!ncdlab!K.Ashley
  86. University of London Computer Centre. 
  87.