01045: Information about pinning programs in BBj

Here’s some additional information about PINNING programs in BBj that may help clarify why you would or would not want to use it. Pinning programs affects whether saved changes from the current interpreter session will be available to other interpreter sessions.

When pinning is turned off, all saved changes are immediately available to any interpreter session. New interpreter sessions always load the most current copy of the program from disk, but running interpreter sessions need to LOAD the program again to get the changes.

When pinning is turned on, new interpreter sessions initially load the most current copy from disk, but keep that version cached and do not detect any subsequent changes to the program, even if they LOAD the program again.

When BBj opens a file, it must search the prefix path to find the correct file. If you do not have program pinning enabled, this prefix search is repeated every time a file is opened. If another user adds a file with the same name into a directory that appears earlier in the prefix path, BBj will locate that new file when resolving the name.

Once BBj determines the complete path for a file (i.e. the complete path for the file that should be opened), it checks whether the file exists in the program cache. If it finds a cached version, it must still compare the last modified time of the on-disk version with the in-memory version. 

These prefix and timestamp checks are both expensive in terms of processing time, especially the prefix resolution.

If pinning is enabled, BBj maintains a session-specific map of resolvedProgramNames (a list BBj keeps to avoid re-searching for the same programs during your session). When a program is loaded, BBj first checks whether the same name has already been used during that session. If so, it skips the prefix path resolution. If a matching program is found in the cache, it also skips the timestamp comparison. If the name is new, BBj resolves it to a full path, and if the resolved path matches a program in cache, it skips the modification date check.

When the CHDIR command is executed, the list of resolvedProgramNames (which is specific to a BBj session)  is cleared for that session. As a result, the next time a program is loaded, BBj performs a full prefix path resolution, even if program pinning is enabled.

Programs can be unpinned dynamically using BBjAPI methods during runtime: BBjAPI().getConfig().unpinSessionEntity(prog_or_resource$) 

This unpins a specific program or resource within the session: BBjAPI().getConfig().unpinSession()

NOTE:   Starting with BBj 20.20 and the Class Loader re-design, regardless of pinning settings, the BBj Custom Objects (including the methods) will not be regenerated until you are in a new BBj session.

The pinning controls are found in:
EM > BBjServices > Settings > Thin Client Performance

• Pin Programs and Resources: Enables server-wide caching of programs and resources to improve performance by reducing disk access and resolution overhead.
• Pin by BBj Session: Applies pinning only for the duration of the current BBj session. This ensures that each session maintains its own pinned cache and does not inherit updates from others unless explicitly reloaded.

See Also

• Program and Resource Caching Overview (PDF)
• Session Pinning Help Page