Make_recovery and stty

[Rushank]

Hello,

I've posted similar question around month back but I did not get any satidfied answer.
Here is the Problem.

I run make_recovery script on every saturday with a automated script. The script runs perfectly fine but after running script it surprisingly changes the stty 'stop' parameter to 'undef' because of this the visifax software on the same box doesn't work properly (Visifax need stty stop as ^S )
Attached file is the sample of the script And this runs on L box with hp-ux 11.
Any clue..??
Thanks.

[Patrick Wallek]

Neither make_recovery nor this script should do anything to your stty parameter. I don't see anything that should even come close to making a change like that.

Are you sure that there isn't something else running around the same time as your make_recovery that could make that change?

[Uday_S_Ankolekar]

There is nothing else is running at this time and infact I'm sending a mail every 5 minutes which sends me the out put of stty /etc/ttyconf, stty /dev/ and stty -a before and while running this script. Surprisingly It happens.!!

[Jerry Zhang]

If the make_recovery script is called by a cron job, that should not affect other jobs.

Put stty in beginning and end of the script and re-direct them into a file. Compare and see if they are different.

[Rushank]

Hello,


I tried modifying this script with same result. Infact last week I didnot tun Make receovery and stty was unchanged. Now at the end of script I'm asking stty stop to change it's parameter to ^S.!!

I don't find any reason why it is happening

[Jerry Zhang]

Rushank, I do not know why it happens either? Let me ask you this, do you run make_recovery from a cron job ? Or run it from command line?

[Uday_S_Ankolekar]

I run it through Meastro Schedular...

[Jerry Zhang]

Check with "Meastro Schedular". Stty should be defined in each shell by profile or other default environment setting. Your script starts with "#!/bin/sh", that means it runs at an own shell. It should not affect other shell (or scripts, etc.) unless it changed profile or other default settings.
I do not know anything about "Meastro Schedular". It looks to me that the schedular environment itself get changed.

[Justin Willoughby]

I have the SAME problem! I did not know what it was until I read this message. I have been working with HP for weeks to try and figure out what is going on. I also run ignite from cron and after it would run I had problems printing to a serial printer! I just checked stty for the device and guess what, stop is not set! There is something else that is not set also that is on a box that is working! Did you find a solution for this yet? I am going to let HP know what I found out and see. My problem started earlier this month, I never had a problem before then!

- Justin

[Rushank]

Hello Justin,

My problem remains same.. I've changed my make_recovery script to resolve this issue.!
I'm executing stty stop ^S at the end of my make_recovery.

If you get any feedback from HP please let me know
Thanks
Rush..

[Justin Willoughby]

OK, I will let you know! My Case number for this problem is 3200253528.

Do you hold your tty open with a sleep process so you can set stop?

If you don't hold it open then setting something with stty will not hold will it?
- Justin

[Rushank]

Hi,

I run make_recovery on weekend and I turn on stty stop paprameter at the end of script and it holds it till next make_recovery runs

I run stty stop "^S" /dev/ttyconf and same command for other used devices

-Rush

[Justin Willoughby]

OK, I just figured out about /dev/sttyconf after I asked.

I forwared the output from stty -a of the serial devices of a system that was set right and from the system that was not (because of Ignite) The guy working on my case id got a hold of guy from their Expert Center and this guys responce was:

"These both ports are closed at this time that is why all the flags set to default as they should.

The difference in the user defined flags is on one system he has set this flags with the /dev/ttyconf file and on the other they have not been."

The thing is I did not make any change to /dev/ttyconf, Ignite did and should not have.

The guy from the Expert Center also said: "This change could be from the system where he created the tape the flags were unset and that is why you are seeing this."

The guy working on my case is out until next Tuesday so I have re-set the sttyconf to what it should be using the following at the command line:

stty 0:0:0:0:0:3:1c:7f:15:4:0:0:0:0:0:0:0:3:1c:7f:15:4:0:0:0:ff:ff:ff:1:1:ff:11:13:0:0:ff:ff:0:0:0:0 < /dev/ttyconf

(all one line)

I got this from a system that had /dev/ttyconf set correctly. e.g. stty -g < /dev/ttyconf

I put this stty at the end of my Ignite backup script also.

Once I figure out the real fix for this I will let you know.

BTW, what version of Ignite are you running?

- Justin

[Justin Willoughby]

Rush,

What version of Ignite are you using?

I believe version 3.4 is out but I have not tried it. I thought if that is the version you are using then there is not since seeing if it's fixed in this version.

HP told me he had to put in a request to get this problem fixed and he had no time line as to when it would be fixed. He asked if he could close the case because I had a work-around. I told him I wanted the case left open until a real fix for this problem was found.

- Justin

[Rushank]

Hello Justin,
The version I'm using is B.3.3.116
Also Thanks for the updates.!
Regards,

Rush.