Yes, James' suggestion (below) may very well work
as a circumvention.

I am not an AIX wizard, but one possibility is an
AIX 4.3 APAR, IX83028. The problem description from
this APAR is as follows:

 PROBLEM SUMMARY:
 When stty is done in the background, it gets the
 current settings after the shell has set them to
 the mode that it wants which is usually raw mode
 in a shell that has vi history set. The setting
 of the modes then blocks because stty is in the
 background. When stty is finally put back into
 the forgound, the set completes but sets the
 modes in a way that the user does not really like.

 PROBLEM CONCLUSION:
 The solution is to put a signal handler for
 SIGTTOU. If this is caught, then stty can re-get
 the settings when it is finally brought back into
 the foregound.

You may want to check with AIX support on the
availability of a PTF. I can not find anything
indicating that a PTF is available yet, although
the APAR closed back in October.

Best regards,

Andy

Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com
"The only dumb question is the one that goes unasked."

James Purdon wrote:

Maybe this would work for you:

$ nohup dsmc sched >/dev/null 2>&1 </dev/null &


> ----------
> From: Grendelman M.
> (Martijn)[SMTP:Martijn.Grendelman AT NL.FORTIS DOT COM]
> Reply To: ADSM: Dist Stor Manager
> Sent: Wednesday, December 16, 1998 9:06 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Problems starting client scheduler on AIX
>
> Hi,
>
> When I try to start the client scheduler by issuing
>
>      $ nohup dsmc sched 2>/dev/null &
>
> on an AIX machine, I sometimes get the following
> behaviour: after a couple of seconds, the process
> stops:
>
> [1] + Stopped (SIGTTOU) nohup dsmc sched 2>/dev/null &
>
> and it won't let me exit my shell without killing
> the process. Issuing
>
>      bg ; exit
>
> works, but the scheduler doesn=B4t seem to accept
> any commands from the central scheduler.
>
> I have had this problem on AIX 4.1.5 (with the
> proper client) and on AIX 4.3.1 (with the 4.2
> client code). Has anyone experienced the same
> problems?
>
> Thanx,
> Martijn.
>
> P.S. SIGTTOU means a "background write attempted
> from control terminal", but that's as far as my
> knowledge goes. Maybe some AIX wizard can tell me
> what that means in plain English? ;-)