What Is Bshell?

Bshell Explained

When a user starts a session, the environment starts a bshell process to run it. That process reads the compiled objects for the session and its libraries, executes the pseudo-code, manages the form and data flow, and issues database calls that the porting set drivers convert into native SQL. The application code itself never sees the database directly, which is what makes the same compiled objects run unchanged on completely different platforms.

Because bshells are processes, they are also the unit of capacity planning. Interactive users consume one, batch jobs and the job daemon consume more, and application servers are sized on the expected concurrent bshell count multiplied by the memory footprint each one carries. Environments that feel slow under load are frequently constrained by memory pressure and process count on the application tier rather than by the database.

The bshell is also the natural place to look when diagnosing behavior. Runtime tracing and debugging options attach at this level, letting you see which objects are executed, which SQL is generated and where time is spent. Long-running sessions that generate unexpectedly large numbers of database round trips almost always show up here first, and the fix is usually application logic rather than database tuning.

Configuration is driven by the Baan software environment variables and configuration files, which tell the bshell where to find compiled objects, temporary space, the data dictionary and the database drivers. Misconfiguration produces characteristic failures: sessions that cannot start at all, temporary file growth that fills a filesystem, or environments that silently pick up objects from an unexpected VRC because the software layering was resolved differently than intended.