| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1444.1 | | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Fri Dec 13 1996 14:52 | 27 |
| Hmmmm...... a quick code check shows the following offending line:
sprintf(temp,"%s\r\n", ptr1);
the variable "ptr1" which contains the string that is specified after
the SEND command is copied to "temp" and appended with a CR-LF pair.
"temp" is then handed off to the routine that actually transmits the
string to the managed system.
SET TONE=SCOLDING_YOUR_DOG
Bad code... bad bad code... bad code....
The workaround...
Use your favorite editor to implant a CR in the send string so that the
resulting stream sent to the console is (spaces added for clarity)
your-string CR CR LF
This way you can fake it out by sending a "null" record and the lf will
follow the "null" record and not the actual "init" command.
Regs,
Dan
|
| 1444.2 | good idea, but will not work because.... | CSC32::J_WIELAND | | Thu Dec 19 1996 06:30 | 14 |
| dan,
great suggestion, unfortunately, it will not work. it seems that the
'concurrent' systems when they recieve 'ANY' character at the serial
port, (including a <lf>), will think that they are in recieving data
mode, and will not leave this mode until they get a <cr>. while in
'recieving data' mode, the init command that the customer is trying to
initiate will not function properly..
any other thought on how to resolve this problem?
thanks in advance,
john wieland
customer support center
|
| 1444.3 | | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Thu Dec 19 1996 13:05 | 9 |
| >any other thought on how to resolve this problem.
Not without changing the code. What I would recommend is that you
submit an IPMT. The right way to fix the code is to enhance it to look
for a new environment variable that would allow the user to specify
the terminating character(s) for any record sent via DIALOG.
Regs,
Dan
|
| 1444.4 | | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Thu Dec 19 1996 13:14 | 22 |
| One final question about your response in -2.
You said that
>It seems that the 'concurrent' systems when they recieve 'ANY' character
>at the serial port, (including a <lf>), will think that they are in
>recieving data mode, and will not leave this mode until they get a <cr>.
If this is true then why doesn't the first CR satisy this condition and
allow the "init" command to execute? If a time delay between characters
would help then place the following command at the top of your
DIALOG file:
SPEED 1000
This will cause a 1 second delay between transmission of each
character. The delay value is in units of milli-seconds.
Regs,
Dan
|