Duane Percox ([log in to unmask]) wrote:
: I was afraid someone would ask that question! I have a
: customer who has HP and Fujistu pads in an ISDN x.25 setup. Now
: I am not claiming to be much of an expert on these matters, but
: this is what has been determined (I think <g>) by HP and the
: customer: The hp pad behaves differently than other pads (the
: Fujitsu in this case) when a running vplus application calls
: vcloseterm to do some character mode operations. Some flow
: control issues are left "undone". The app is printing a report
: on the slave printer using <esc>&pW<data> syntax (sic). The 'S'
: response for each line printed and the large report creating
: much confusion and subsequent missed lines of print. The
: Fujitsu pad works just fine. HP found some reference in the
: knowledge base to this and the escape sequence to reset things
: to a good state. This has solved the printing problem.
: Mike Hawkins of HP was the person I worked with.
: -- Duane Percox (Quintessential School Systems)
: [log in to unmask]
Since I have not been involved in troubleshooting this specific
scenario, my text here cannot be read to be 100% correct but I'm
hoping to hit some of the right areas anyway.
First, I think the Fujitsu PADs work by accident. Not that I'm saying
there's something wrong with them, I'm just would not expect any other
than HP PADs to understand anything about HP's VPLUS block mode (BTW,
the only blockmode supported over X.25 PADs to my understanding).
What I think could be happening is that HP3000 application opening the
terminal in block-mode sends down some X.29 command sequences to
the PAD to set it's LOCAL parms (vendor defined, most PAD's have some).
Since Fujitsu PAD probably knows nothing about what local parms an HP PAD
might have, it probably ignores those and remains in the same state it
was. On an HP PAD, I would expect it to switch from DC1/DC3 (Xon/Xoff)
handshake to DC1/DC2/DC1 (blockmode handshake). Maybe the the Fujitsu
PAD actually knows nothing about block-mode and just acts as an open
pipe between the HP3000 and the terminal - and happens to appear working
as expected (externally). An HP PAD, on the other hand, knows to switch
to block-mode and probably changes it's echoing and data forwarding
characteristics so that it'll only send on DC2 (well, not quite but close
enough). This ought to result in better utilization of the line, less
packets etc, moving into 'normal' character-mode data forwarding and
echoing when instructed so by the host.
Second, if the application was ported (or just copied) from a V/E system,
it most likely does not handle switching between VPLUS and character mode
correctly. On MPE/iX, there was a pair of new VPLUS intrinsics introduced
that _HAD_TO_ be called if you were to switch from block mode to character
mode and print to a slaved printer. The calling sequence should be
something like:
..in block mode
call VTURNOFF
call FCONTROL (13 - echo off)
repeat
print line to the slave printer
read status from printer
if status <> 'S' then
{ some problem - handle error }
until nothing_more_to_print;
call FCONTROL (12 - echo on)
call VTURNON
..back in block-mode.
I recall seeing/hearing from several customers that had to make this
modification to their applications. Checking one of our problem report
databases shows 251 hits using keywords "VTURNON VTURNOFF" for search.
One of those recommends the following steps for returning to block-mode
after printing to the slave:
After a data Xfer to the printer, the terminal responds with a status
byte, either S, F or U (Successful, Fail or User intervention).
Recommended steps for using VTURNOFF and VTURNON
After calling VTURNOFF, these are the recommended steps to return the
VPLUS application to block mode:
1. CALL VTURNON
2. DISPLAY escape lowercase b (example: %33 b) to unlock keyboard
3. MOVE $REFRESH TO NEXTFORMNAME
4. CALL VGETNEXTFORM
5. CALL VSHOWFORM
Hope some of this helps,
:-) Eero Laurila - HP CSY Networking lab, NS services.
|
