[BUG] STRTCPSVR doesn't show `sc` output in 5250

[ThePrez]

See #115/#116 for some context, but the reason the STRTCPSVR handler sometimes runs in non-batch mode is because during bringup, I was able to see sc progress messages, warnings, etc.

Even outside the scope of STRTCPSVR, I can't get this desired behavior. For instance, if I run:

CALL PGM(QP2SHELL ) PARM('/QOpenSys/pkgs/bin/bash' '-l' '-c'            
        'echo hi && exec /QOpenSys/pkgs/bin/sc start zookeeper 2>&1 |cat
;echo done  ;sleep 5'                  )                                
``
... the "hi" and "done" show on the screen but the `sc` output does not!! 😠 
cc @chrjorgensen for awareness/input

[chrjorgensen]

Why the 'cat' command?

[chrjorgensen]

If you remove the "|cat" part it works...!

[chrjorgensen]

CALL PGM(QP2SHELL)                                          
     PARM('/QOpenSys/pkgs/bin/bash' '-l' '-c' 'echo hi && echo hi again 2>&1; echo done; sleep 5')           

gives the following output:

hi                                  
hi again                            
done                                
Press ENTER to end terminal session.

[ThePrez]

@chrjorgensen , the |cat made this mysteriously work during bringup (should have documented that!).

Your sample QP2SHELL invocation works for me also, but if I put the /QOpenSys/pkgs/bin/sc command in there, the sc output still goes to SPLF (at least on my current system).

I'm very confused. Is it something different with how bash is handling subshells? Something to do with blended stderr/stdout? Something particular on my system?

[ThePrez]

This is the only real change I ever made to the sc script.. https://github.com/ThePrez/ServiceCommander-IBMi/commit/08e5ccc0dfc1c41cc11b8519589dc4ab744eea8e

[chrjorgensen]

According to this link about QP2SHELL it does not reliably setup stdin, stdout and stderr - and it is suggested to use QSH instead.

What do you think about this? My test using QSH instead of QP2SHELL (after changing some quotes) worked and the output from the sc command was returned to my 5250 job...

[ThePrez]

I seem to recall that QP2SHELL won't set up the descriptors, but bash would. Maybe it's a matter of reliably setting up descriptors Did you need to set QIBM_MULTI_THREADED for it to work? Or can you do that right on the QSH invocation? If memory serves me right, I shied away from QSH on the first impl because:

• Assumed QIBM_MULTI_THREADED would cause issues (but I didn't try it)
• I'm not sure if QSH would honor the #! line and do the right thing in the sc script (but I didn't try it)
• I've always used QP2SHELL2 as my first stop

I think all of those are horrible reasons, so it's worth a revisit

[chrjorgensen]

I see two options:

• Switch to QSH and add QIBM_MULTI_THREADED - this is what I have always used, but I'm no PASE expert and also do much CL programming.
• Continue using QP2SHELL but add programming for

stdin, stdout, and stderr must be forkable file descriptors

(mentioned in the link).

I have always been confused about QP2SHELL - probably for the same reasons that is causing these problems with stdout back to the job.

[kadler]

You can open file descriptors in Bourne shells if you want: https://bash.cyberciti.biz/guide/Opening_the_file_descriptors_for_reading_and_writing

That works for standard files, but won't get you the "fake" stdin/stdout/stderr provided by QSH/QP2TERM.

[kadler]

I don't believe that bash will set up file descriptors. Those are supposed to be set up by the caller.