Welcome to jBASE's new documentation site! Many answers to your questions can be found by searching the Knowledgebase or viewing the jBASE Documentation. We also have a Google Group for peer discussion about jBASE. If you are unable to find the information you are looking for, jBASE Support will be glad to assist in resolving your technical problems. Enjoy and please provide comments and feedback .

How can we help you?


Understanding BASIC/CATALOG on jBASE

jBASE differs to other MultiValue platforms in many ways and one of the primary areas is BASIC run-time. In jBASE all programs must be cataloged to run. The use of: 



Will attempt to execute the catalog of MYPROG. 

Note: if your BP file is a directory and does not have an OBJECT data level and the program name does not end in “.b” then the RUN operation will attempt to catalog on the fly if the catalog is not already available. 

jBASE does not use the MD/VOC or have a global catalog area used by users in one or more accounts. Instead the native environment variables are used provide the executable path. 

For example (Linux) 


 export JBCOBJECTLIST=/myaccount/lib:$ JBCOBJECTLIST


A CATALOG jBASE produces binary executables (in the case of PROGRAMs) and shared objects (in the case of SUBROUTINEs). 

Note: that PROGRAMs are cataloged into both executables and shared objects which will be explained later in this section. 

Command not found  or Unable to perform CALL to subroutine (or wrong version being executed/called)

The first trouble-shooting step if a program/subroutine can’t be found (or is not the expected version) is to perform a jshow -c 


 jshow -c MYSUB

If this command returns nothing then you need to check your PATH and JBCOBJECTLIST. 

You may also need to check the permissions of the bin and lib directories where the program might be cataloged. 

There are various ways to control how PATH and JBCOBJECTLIST can be set (system wide, profile scripts, etc). One of them is to store the desired paths in attributes 25, 26 in the SYSTEM entry of each account (if your application is account based). 

Why does my main program also have a shared object?

When you catalog a non-subroutine it will generate an executable and a shared object in the target bin directory. The reason for this is that in jBASE when a program performs an EXECUTE/PERFORM of another cataloged program it will load the shared library version for performance and thread related reasons. The exception to this is if you execute with a new shell: 



Where did my CATALOG result go?

The destination bin and lib when cataloging programs/subroutines is determined by: 


 export JBCDEV_BIN=/myaccount/bin

If these environment variables are not set then they default to $HOME/bin and $HOME/lib. 

Unable to DECATALOG or CATALOG: “…already defined…”

An important issue when programming in jBASE BASIC (jBC) is that the item-id to the program is not necessarily the name used to catalog. 

For example 


 002 …
 002 …

Both of the above examples will attempt to product a shared object referencing a subroutine “MYSUB”. 

This is a common issue when making a copy of a program and neglecting to change the SUBROUTINE statement. 

The PORTBAS can be used to either rectify or report the status of any such occurrences. 

Without making any changes, if you attempt to CATALOG both of these the second one will fail reporting that MYSUB has already been cataloged and refer you to the object code that was used for that catalog at which point you need to determine which one is correct and which one should be modified and recompiled/cataloged. 

jSHOW shows multiple results

The jSHOW (when used with the -c option) command looks at your current PATH and JBCOBJECTLIST to discover a program/subroutine. As mentioned previously non-subroutine programs when cataloged results in an executable and a shared object so this will show as a duplicate. 

However, there may be situations where due to a change to JBCDEV_LIB (possibly when logging to different accounts) a program/subroutine with the same name is cataloged to a different bin/lib which is also in your PATH/JBCOBJECTLIST. 

jBASE will use the first one it finds (which may not be the one you want). If this is the case, you will need to either reorganize your PATH/JBOBJECTLIST or possibly perform a DECATALOG on the version(s) you don’t want (be sure to set your JBCDEV_BIN and JBCDEV_LIB accordingly when performing these tasks). 

Was this article helpful?