Hi,

Upgraded to bash 5.2 and now some of our users encounter a S0C4 abend in their TSO session when invoking OMVS command to enter their (bash) shell environment in z/OS USS. See the following in the SVC dump of the S0C4;

ASID(X'01BD') 21051A86. AREA(Subpool251Key08)+1BFA86 IN EXTENDED PRIVATE

ASID(X'01BD') 21051A86. SPECIALNAME+1BFA86 IN EXTENDED PRIVATE

+0000 61A58199 61999683 9285A361 82899561 | /var/rocket/bin/ |

+0010 8281A288 | bash |

Any ideas of possible root cause would be appreciated.

thanks

Hello Alfred,

Are there any similarities in the setup for the user accounts of the users that are impacted, and is this a consistent issue that happens every time those users try to use Bash, or an intermittent issue? Does it occur when logging in through SSH or only through a TSO session, and is Bash set to be your login shell? Has your sysadmin enabled any additional additional protections that might be impacting the application and preventing it from loading for those users? Bash is designed to print a dump to the terminal whenever it receives an abend, did your users see that dump? If they did not it would indicate that the program is failing to load at all, which would indicate an issue with the system.

If your users have only seen the issue when starting Bash through TSO, please try logging in through SSH if you can and let us know if those users are still seeing the same issue.

------------------------------
Giancarlo Frix
Software Engineer, Open-Source Porting
Rocket Software Inc.
------------------------------

Hi Giancarlo,

Thanks for responding. Through a process of elimination, we have determined the issue is only in TSO i.e. invoking OMVS via the OMVS command in either native TSO or TSO/ISPF, for those users with bin/bash defined for their shell as opposed to the default bin/sh. No issues when logging through either SSH or the IBM IDz eclipse client shell option. The resulting dump is printed to the terminal session. I was able to capture the dump to a file using a slip trap. 

thanks

Alfred

Alfred,

Thanks for narrowing down the issue to TSO. We've been trying to reproduce the issue on our own systems but so far have not had any luck. Does the issue occur every time a user with Bash set as a login shell tries to log in?

We may be able to use the dump to gain a bit more insight if you are unable to find anything wrong with the system, but I think in this situation that will not be enough on its own.

Are the users able to run bash manually after starting a shell session using /bin/sh? If so, you can try the following as a workaround:

1. Reset the login shell for each user back to /bin/sh
2. Add a line in your .profile to either `exec` bash or run it in interactive mode `bash -i`, perhaps with a guard to check that it is not already running under bash (something like `[ -z "$BASH_VERSION" ] && bash -i`).

------------------------------
Giancarlo Frix
Software Engineer, Open-Source Porting
Rocket Software Inc.
------------------------------

Alfred,

Thanks for narrowing down the issue to TSO. We've been trying to reproduce the issue on our own systems but so far have not had any luck. Does the issue occur every time a user with Bash set as a login shell tries to log in?

We may be able to use the dump to gain a bit more insight if you are unable to find anything wrong with the system, but I think in this situation that will not be enough on its own.

Are the users able to run bash manually after starting a shell session using /bin/sh? If so, you can try the following as a workaround:

1. Reset the login shell for each user back to /bin/sh
2. Add a line in your .profile to either `exec` bash or run it in interactive mode `bash -i`, perhaps with a guard to check that it is not already running under bash (something like `[ -z "$BASH_VERSION" ] && bash -i`).

------------------------------
Giancarlo Frix
Software Engineer, Open-Source Porting
Rocket Software Inc.
------------------------------

Hi Giancarlo,

I was able to execute the workaround successfully by adding an exec bash statement in my .profile with my initial login shell as /bin/sh.

thanks

Alfred

Hi Giancarlo,

Do you know of any virtual storage memory size limitations in loading bash 5.2 as the default shell i.e. /bin/bash as defined in the user's OMVS segment?

thanks