Side effects of "OS.EXECUTE"?

[Gary]

I hit a little snag... I need to transmit a file from my server to my
client machine WHILE running OpenQM. On SystemZ, I simply executed a
shell command (such as 'sz filename') from within Z. I am running a
kermit session, so this always worked. This seems to NOT work within
OpenQM. It looks like the local kermit does not see the i/o from the
sz command. Perhaps OpenQM is grabbing the output of the command even
though I am not specifying "CAPTURING". Has anyone any experience and/
or suggestions with this?

GaryW

[Tom Potts]

Which system are you running OpenQM on?  This might make a difference.  In any case, I would suggest trying out a simple command first to see what is happening -- e.g. dir or touch.  As I understand it, OS.EXECUTE creates a new shell session, so if I understand what kermit is this will bypass it entirely.  Am I right in saying that Kermit is a protocol which sits on top of telnet?  If so, OS.EXECUTE will never see Kermit at all.

Tom

2009/7/31 Gary <gwal...@gmail.com>

[Ashley Chapman]

I don't use terminal I/O at all, hence me not replying to your earlier posting.  However, you could try the various statements and see if one works differently (OS.EXECUTE, EXECUTE, PERFORM).  alternativly, how about capturing the output, then immediately PRINTing it to the terminal/kermit session?  You might need to put Qm into a binary-clean mode, which has been discussed in the past.  Search for "binary clean" in the archives.

HTH

Ashley
 

[Gary]

Ashley,

Thanks for replying. I have tried all the aforementioned
statements (OS.EXECUTE, SH, etc.) to no avail. Also, "CAPTURING" will
not work because the data is STILL on the remote system. It might
make more sense if I told you waht I'm doing. When I finish printing
to a file, I convert the file to a PDF. That is working fine. Then I
send that PDF from the OpenQM machine to the user's machine and open
it in Acrobat. Everything works EXCEPT the "sending" part. On Z I
simply used the Z CMND subroutine to invoke sz (zmodem) to transmit
the file to the user. This fails when I'm in OpenQM (works OK from
the command line or from within Z). There must be a "work around".

GaryW

[Ashley Chapman]

2009/7/31 Gary <gwal...@gmail.com>

Ashley,

  Thanks for replying.  I have tried all the aforementioned
statements (OS.EXECUTE, SH, etc.) to no avail.  Also, "CAPTURING" will
not work because the data is STILL on the remote system.  It might
make more sense if I told you waht I'm doing.  When I finish printing
to a file, I convert the file to a PDF.  That is working fine.  Then I
send that PDF from the OpenQM machine to the user's machine and open
it in Acrobat.  Everything works EXCEPT the "sending" part.  On Z I
simply used the Z CMND subroutine to invoke sz (zmodem) to transmit
the file to the user.  This fails when I'm in OpenQM (works OK from
the command line or from within Z).  There must be a "work around".

Okay, I've tried running  ":SH cat test.txt"  from TCL, and it does NOT capture it.  Works as expected.  Tried it on 2.6-6 of QM and an old 2.4-14 version.

Looks like the Kermit sz command might be causing the problem.  My guess would be that it produces output to stdout in the form of zmodem packets, but is also expecting to get acknowledgements back in stdin.  Perhaps you can SH to a script that runs the Zmodem transfer?

It might be worth you considering the commercial product Accuterm.  I don't know it myself, but apparently it works only on Windows Clients, and has built-in QM -friendly file-transfer capabilities.

Ashley

[Gary]

On Aug 1, 2:48 am, Ashley Chapman <ash.chap...@gmail.com> wrote:

> Okay, I've tried running  ":SH cat test.txt"  from TCL, and it does NOT
> capture it.  Works as expected.  Tried it on 2.6-6 of QM and an old 2.4-14
> version.
>
> Looks like the Kermit sz command might be causing the problem.  My guess
> would be that it produces output to stdout in the form of zmodem packets,
> but is also expecting to get acknowledgements back in stdin.  Perhaps you
> can SH to a script that runs the Zmodem transfer?
>

Yes, that is EXACTLY what happens... sz sends a "start" packet that my
local kermit receives and then the local kermit sends a packet back to
initiate the transfer. My end sees the "start" packet output by sz,
but sz doesn't see anything coming back. It seems that OpenQM is
grabbing the input before it gets to sz. How would doing this in a
script help? Will that change the I/O at all?

> It might be worth you considering the commercial product Accuterm.  I don't
> know it myself, but apparently it works only on Windows Clients, and has
> built-in QM -friendly file-transfer capabilities.

Well, I'm on LInux, so Accuterm is not an option. If/when I finish
the port and need to support clients on WIndows, I will certainly keep
that in mind.

>
> Ashley

BTW, I have found a workaround (but it's ugly). I can start kermit on
my end in server mode listening on a specified port. Then, when I log
in to the OpenQM system, I forward the port that kermit is listening
on. I can then use kermit on the OpenQM system to initiate transfers
to the remote kermit via the forwarded port. It involves one extra
step (starting kermit in server mode) and a change to the ssh command,
but it seems to work OK because it bypasses OpenQM completely. I
would still like to get sz going. It was much simpler to set up (for
new clients) than the present scheme.

GaryW

[Ashley Chapman]

2009/8/1 Gary <gwal...@gmail.com>

Yes, that is EXACTLY what happens... sz sends a "start" packet that my
local kermit receives and then the local kermit sends a packet back to
initiate the transfer. My end sees the "start" packet output by sz,
but sz doesn't see anything coming back.  It seems that OpenQM is
grabbing the input before it gets to sz.  How would doing this in a
script help?  Will that change the I/O at all?

That was the intention.  I was hoping that the script might block QM from grabbing stdin.  It sort of works for Anji, although I start QM in an entirely different way from a normal terminal user (as a pipe).  Sometimes  I just throw random ideas at a problem, in a desperate attempt to gain enlightenment!

BTW, I have found a workaround (but it's ugly).  I can start kermit on
my end in server mode listening on a specified port.  Then, when I log
in to the OpenQM system, I forward the port that kermit is listening
on.  I can then use kermit on the OpenQM system to initiate transfers
to the remote kermit via the forwarded port.  It involves one extra
step (starting kermit in server mode) and a change to the ssh command,
but it seems to work OK because it bypasses OpenQM completely.  I
would still like to get sz going.  It was much simpler to set up (for
new clients) than the present scheme.

Haha, I too had to do some ugly terminal I/O stuff when I first ported Anji to QM.  Eventually, I managed to clean it up at a later date with some apparently unrelated tips from this forum.

Ashley

[Diccon tesson]

*Wakes up and returns to QM after muppeting around elsewhere*

The theory is that when executed the shell program basically takes
over stdin and stdout but since QM is launching the shell there can
easily be complications. Some brief look at the underlying code shows
that there may (i said MAY, not does :D ) be a distinction between
OS.EXECUTE from a basic routine and running ! or SH from qm command
line. Can you give a Kermit execute a go from the qm shell and confirm
you still have issues there.

Tom: Yes, Kermit was designed for Telnet, but is essentially a
protocol and accompanying programs for transmitting any files via
ASCII, sitting on top of something designed for user character input
and display. Presumably named Kermit after the green screens :)

I know it can optionally have compression too, are you using the
compression Gary? Could cause issues.

Ok, so I took a further look into the c source (src/op_sh.c). When the
qm session is run from a OS shell it lets the sh command take over
stdin and stdout, but when it runs over a network socket or needs to
capture it switches to using pipes. There could be a bug in the code
there in terms of relaying the stream correctly. It essentially forks
of the shell command and attaches pipes in and out, relaying the
characters to the socket. It doesn't, on the face of it, seem to mega
with the stream/pipe itself. I'm not aufe enough with Kermit to know
what kind of control characters it uses.

I can look further if you want, but I've not got a huge amount of free
time atm, so it might take a while. (money, coffee or free shiny
things can always change this lol)

I suggest in the meantime you check all of kermits options, see if one
of them might change the way it works. Also look at transmitting files
other than PDF, see if its some specific data that's causing you
issues.

-Diccon

On 1 Aug, 16:17, Ashley Chapman <ash.chap...@gmail.com> wrote:
> 2009/8/1 Gary <gwalb...@gmail.com>