MF Server rts32 does not run in AIX 5.3L batch queue

Help.  We are trying to migrate our
Object Cobol under AIX 4.3 to
Server Express under AIX 5.3L in
a Test box.  We have plenty of
Cobol jobs which are submitted
to a job queue (qprt -Pbqueue ......).
Everything is working in 4.3 but
not in AIX 5.3L.  The job just sits
in the queue and the PID is on rts32 of
the COBOL program.  If we run the
same job under a shell script from
within a Cobol online program,
the job runs.

What are we missing?

Thanks in advance.

If you are currently "under support", I would strongly suggest contacting Mi
cro
Focus directly for this.  If you aren't, you still should be able to use the
"support line" (forum) and probably get a quicker/better answer there.

--
Bill Klein
wmklein <at> ix.netcom.com
"C C" <someone@atsbcglobal.net> wrote in message
news:SbUZe.104$Vk.71@newssvr24.news.prodigy.net...
> Help.  We are trying to migrate our
> Object Cobol under AIX 4.3 to
> Server Express under AIX 5.3L in
> a Test box.  We have plenty of
> Cobol jobs which are submitted
> to a job queue (qprt -Pbqueue ......).
> Everything is working in 4.3 but
> not in AIX 5.3L.  The job just sits
> in the queue and the PID is on rts32 of
> the COBOL program.  If we run the
> same job under a shell script from
> within a Cobol online program,
> the job runs.
>
> What are we missing?
>
> Thanks in advance.
>

Thanks.  We have a open incidence with MF regarding this.

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:e7_Ze.148283$hQ4.56068@fe02.news.easynews.com...
> If you are currently "under support", I would strongly suggest contacting
> Micro Focus directly for this.  If you aren't, you still should be able to
> use the "support line" (forum) and probably get a quicker/better answer
> there.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "C C" <someone@atsbcglobal.net> wrote in message
> news:SbUZe.104$Vk.71@newssvr24.news.prodigy.net... 
>
>

In article <SbUZe.104$Vk.71@newssvr24.news.prodigy.net>, "C C" <someone@atsbcglobal.net> wr
ites:
> Help.  We are trying to migrate our
> Object Cobol under AIX 4.3 to
> Server Express under AIX 5.3L in
> a Test box.  We have plenty of
> Cobol jobs which are submitted
> to a job queue (qprt -Pbqueue ......).
> Everything is working in 4.3 but
> not in AIX 5.3L.  The job just sits
> in the queue and the PID is on rts32 of
> the COBOL program.  If we run the
> same job under a shell script from
> within a Cobol online program,
> the job runs.

This is just a guess, but it wouldn't surprise me if the rts32 process
is in stopped state due to a SIGTTIN - attempt by a background process
to read from the tty.

Try starting the job with the standard I/O file descriptors closed or
redirected, eg by wrapping the program in a ksh script like:

#! /bin/ksh
exec cobrun my-program <&- >&- 2>&-

That will close descriptors 0, 1, and 2, which will prevent the COBOL
RTS from trying to read from (or write to) the former controlling tty.

--
Michael Wojcik                  michael.wojcik@microfocus.com

When most of what you do is a bit of a fraud, the word "profession"
starts to look like the Berlin Wall.  -- Tawada Yoko (t. M. Mitsutani)

Thanks.  But why would rts32 wait for input from tty
when the cobol program doesn't even have any accept
statement from tty?

The same program submitted to the queue (for scripts)
runs to end-of-job when run with rts32 of microfocus
object cobol in AIX 4.3.



"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dhbnq3029pj@news1.newsguy.com...
>
> In article <SbUZe.104$Vk.71@newssvr24.news.prodigy.net>, "C C"
> <someone@atsbcglobal.net> writes: 
>
> This is just a guess, but it wouldn't surprise me if the rts32 process
> is in stopped state due to a SIGTTIN - attempt by a background process
> to read from the tty.
>
> Try starting the job with the standard I/O file descriptors closed or
> redirected, eg by wrapping the program in a ksh script like:
>
>   #! /bin/ksh
>   exec cobrun my-program <&- >&- 2>&-
>
> That will close descriptors 0, 1, and 2, which will prevent the COBOL
> RTS from trying to read from (or write to) the former controlling tty.
>
> --
> Michael Wojcik                  michael.wojcik@microfocus.com
>
> When most of what you do is a bit of a fraud, the word "profession"
> starts to look like the Berlin Wall.  -- Tawada Yoko (t. M. Mitsutani)

In article <iPI_e.843$DY.563@newssvr33.news.prodigy.com>, "C C" <someone@atsbcglobal.net> w
rites:
> Thanks.  But why would rts32 wait for input from tty
> when the cobol program doesn't even have any accept
> statement from tty?

In some versions of MF COBOL for Unix, rts32 queries the tty for
certain control functions at program startup, regardless of whether
the program does any tty I/O.  If the program has a tty attached to
descriptor 0 and is not part of the foreground process group for
that tty, it gets a SIGTSTP.

> The same program submitted to the queue (for scripts)
> runs to end-of-job when run with rts32 of microfocus
> object cobol in AIX 4.3.

It's only a problem with some COBOL versions.  I know of it because
it caused an issue with running the MF Client/Server Binding
feature's server program in the background.  The problem popped up
with one build, was fixed, regressed, was fixed again...  It's hard
to predict whether a given COBOL build will have it.

It's easy to test for, though.  Try running your program in the
background and see if it ends up in Stopped state.

--
Michael Wojcik                  michael.wojcik@microfocus.com

I gave my love some irises.
(She was sick with viruses.)		-- Charlie Gibbs

Thanks.  I think that's what's happening.  Is there a variable
or Declaration we can include in our script so that when
submitting a job to the job queue, any rts32 process within
there will be forced NOT to query the tty on batch jobs?

BTW, we submitted the same job to the background and
it is a stopped state.  I had to kill it.

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dhguel0ftt@news3.newsguy.com...
>
> In article <iPI_e.843$DY.563@newssvr33.news.prodigy.com>, "C C"
> <someone@atsbcglobal.net> writes: 
>
> In some versions of MF COBOL for Unix, rts32 queries the tty for
> certain control functions at program startup, regardless of whether
> the program does any tty I/O.  If the program has a tty attached to
> descriptor 0 and is not part of the foreground process group for
> that tty, it gets a SIGTSTP.
> 
>
> It's only a problem with some COBOL versions.  I know of it because
> it caused an issue with running the MF Client/Server Binding
> feature's server program in the background.  The problem popped up
> with one build, was fixed, regressed, was fixed again...  It's hard
> to predict whether a given COBOL build will have it.
>
> It's easy to test for, though.  Try running your program in the
> background and see if it ends up in Stopped state.
>
> --
> Michael Wojcik                  michael.wojcik@microfocus.com
>
> I gave my love some irises.
> (She was sick with viruses.) -- Charlie Gibbs

In article <XbV_e.1418$cF6.323@newssvr30.news.prodigy.com>, "C C" <someone@atsbcglobal.net>
 writes:
> Thanks.  I think that's what's happening.  Is there a variable
> or Declaration we can include in our script so that when
> submitting a job to the job queue, any rts32 process within
> there will be forced NOT to query the tty on batch jobs?

I don't believe so - this was a bug, not a feature - but why not just
close the standard I/O descriptors when you start the program, as I
suggested in my first reply?

If your script has a command like

cobrun foo

just change it to

cobrun foo <&- >&- 2>&-

This assumes your script is a ksh script; the syntax for other
shells may be different.  (It might also suffice to redirect
standard I/O to/from /dev/null.)

In ksh, you can close or redirect standard I/O for the script
itself and any programs it starts all at once by making the
first command

exec <&- >&- 2>&-    # close standard I/O

or

exec < /dev/null > /dev/null 2> /dev/null    # redirect standard I/O

The latter is probably safer, as some programs assume that the
first three descriptors will be open.  You might also want to
redirect stdout / stderr to a file to preserve any information
the script or its children might try to display.

> BTW, we submitted the same job to the background and
> it is a stopped state.  I had to kill it.

Sounds like you have a version with this bug, then.

--
Michael Wojcik                  michael.wojcik@microfocus.com

Pocket #16: A Ventriloquist's "Helper" -- Recordings for Divers Occasions,
especially cries to put in the mouths of enemies -- "God Bless Captain
Vere!"  "Les jeux sont faits!"  &c.  -- Joe Green

I can't redirect output to /dev/null as the program running under the
control of the queue daemon displays messages, and these messages
are captured to the backend output file specified in the device
configuration of the queue device for the job queue.

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dhk4ba030ir@news1.newsguy.com...
>
> In article <XbV_e.1418$cF6.323@newssvr30.news.prodigy.com>, "C C"
> <someone@atsbcglobal.net> writes: 
>
> I don't believe so - this was a bug, not a feature - but why not just
> close the standard I/O descriptors when you start the program, as I
> suggested in my first reply?
>
> If your script has a command like
>
>   cobrun foo
>
> just change it to
>
>   cobrun foo <&- >&- 2>&-
>
> This assumes your script is a ksh script; the syntax for other
> shells may be different.  (It might also suffice to redirect
> standard I/O to/from /dev/null.)
>
> In ksh, you can close or redirect standard I/O for the script
> itself and any programs it starts all at once by making the
> first command
>
>   exec <&- >&- 2>&-    # close standard I/O
>
> or
>
>   exec < /dev/null > /dev/null 2> /dev/null    # redirect standard I/O
>
> The latter is probably safer, as some programs assume that the
> first three descriptors will be open.  You might also want to
> redirect stdout / stderr to a file to preserve any information
> the script or its children might try to display.
> 
>
> Sounds like you have a version with this bug, then.
>
> --
> Michael Wojcik                  michael.wojcik@microfocus.com
>
> Pocket #16: A Ventriloquist's "Helper" -- Recordings for Divers Occasions,
> especially cries to put in the mouths of enemies -- "God Bless Captain
> Vere!"  "Les jeux sont faits!"  &c.  -- Joe Green

[Edited for legibility.]

In article <jJ%%e.61$AY4.4@newssvr24.news.prodigy.net>, "C C" <someone@atsbcglobal.net> wri
tes:
> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> news:dhk4ba030ir@news1.newsguy.com... 
> I can't redirect output to /dev/null as the program running under the
> control of the queue daemon displays messages, and these messages
> are captured to the backend output file specified in the device
> configuration of the queue device for the job queue.

In that case stdout (and probably stderr) is already redirected (by
the queue backend processor), so you only have to close or redirect
stdin.

--
Michael Wojcik                  michael.wojcik@microfocus.com