I think you have identified the problem twice.
First your system works normally with one modem and fails
with another. Another is a problem!

Second you are not getting "OK" response some times.
In the clip from your post shown below twice the response was not "ok".
First the response was a blank (I assume) line. (to ATQ0H0)
The second was a blank line followed by "ok". That is not "ok".

Walter Wagner wrote:
> Hello
> ATQ0H0
>
> ATQ0H0
> OK
> Modem hangup OK
> Initializing: 20:50:41...
> Dialing: 20:50:42...
> ATD56913
>
> OK
> DIAL Failure: 20:50:42: "OK"

Regards...Dan.

Thanks for the Hint!
This gave me motivation to do some further tests, and i found out that the
problem was in my old initialization file which worked for Kermit 6 but not
for Kermit 8.

I used the output command to do modem initialization and to set the ISDN MSN
numbers(for callback). The following "kermrcS4" init file worked well with
kermit 6.
(i used this command to start kermit: kermit -y kermrcS4)
....
out AT&F\{13}
input 1 OK
out ATZ\{13}
input 1 OK
out AT&o0\{13}
input 1 OK
out AT&L1\{13}
input 1 OK
out AT&ZI0=29\{13}
input 1 OK
out AT&ZI1=29\{13}
input 1 OK
out AT&ZI2=29\{13}
input 1 OK
....

Now I use the "set modem command init-string" instead the "output" command
and this works on Kermit 8.
SET MODEM COMMAND INIT-STRING
AT&FZ&o0&L1&ZI0=29&ZI1=29&ZI2=29&ZI3=29&ZI4=29&ZI6=29\13

Sure now the initialization is now done shortly before the dialout happens
and erlier it was done when i started kermit, but this is OK so far.

If there is better solution which can do the MSN settings... during kermit
start, then i would prefer it!
Otherwise i let it as it is now.

In my opinion the problem is that the zyxel modem is somtimes not
answering(or answering too slow) and then it happens that the OK from a
previous command comes back while dialing. And the result is:
> > ATD56913
> >
> > OK
> > DIAL Failure: 20:50:42: "OK"
I tried also some other "input" commands, for example: input -1 OK\13\10
and the failure happend rarely but it was not completly solved!
And maybe the reason why my USR Modem is working perfect(also with output
commands), could be because it is an analog modem and there is no need to
set so much MSN numbers.

Thanks/Regards
Walter



schrieb im Newsbeitrag
news:1102429542.133619.87860@c13g2000cwb.googlegro ups.com...
> I think you have identified the problem twice.
> First your system works normally with one modem and fails
> with another. Another is a problem!
>
> Second you are not getting "OK" response some times.
> In the clip from your post shown below twice the response was not "ok".
> First the response was a blank (I assume) line. (to ATQ0H0)
> The second was a blank line followed by "ok". That is not "ok".
>
> Walter Wagner wrote:
> > Hello
> > ATQ0H0
> >
> > ATQ0H0
> > OK
> > Modem hangup OK
> > Initializing: 20:50:41...
> > Dialing: 20:50:42...
> > ATD56913
> >
> > OK
> > DIAL Failure: 20:50:42: "OK"
>
> Regards...Dan.
>

On 2004-12-10, Walter Wagner wrote:
:...
: In my opinion the problem is that the zyxel modem is somtimes not
: answering(or answering too slow) and then it happens that the OK from a
: previous command comes back while dialing. And the result is:
:> > ATD56913
:> >
:> > OK
:> > DIAL Failure: 20:50:42: "OK"
:
The DIAL command takes common kinds of problems and modem misbehavior into
account, so it tends to work better than simple OUTPUT/INPUT scripts,
especially ones that don't check for failure and take corrective action.
If you SET DIAL DISPLAY ON you can watch what happens when you give a DIAL
command. If something goes wrong, it retries the operation and/or adapts
automatically in various ways.

: I tried also some other "input" commands, for example: input -1 OK\13\10
: and the failure happend rarely but it was not completly solved!
: And maybe the reason why my USR Modem is working perfect(also with output
: commands), could be because it is an analog modem and there is no need to
: set so much MSN numbers.
:
INPUT has a timeout, and no matter what you value you give (except -1), it
might not be long enough. If you make it too long, then it takes too long
to detect an error. If you make it too short, it reports an error when
it might have succeeded. In any given situation, use trial and error to
arrive at the best value, and code your script to do what you would do
if an error occurred, e.g. reissue the command and wait again (perhaps for
a longer time) for the response. You can find a lot of examples in the
script library:

http://www.columbia.edu/kermit/ckscripts.html

e.g. OUTPUT followed by a looping INPUT, in which actions are governed by
the loop counter.

- Frank