Verse Of The Day

Thursday, May 01, 2008

Some Old-School JAM and JPL Tips

The JAMster Speaks...

I was cleaning out the barn and found a CD of some old code and documents I had written at an old job, kind of a "portfolio" CD if you will. We used JAM to build Motif screens.

JAM let you visually build your screens, and had it's own procedural programming language, JPL (JAM Programming Language). JAM came with the necessary C code to handle launching of the screens and handling events. You could write your own custom C code to be called from the screens, or write your code in the JPL file for the screen, or a combination of both. One nice thing is you could write SQL code right inline with the rest of your JPL (just prepend the keyword "sql") and everything was taken care of, even down to binding the result set to variables.

It's not exactly cutting edge technology now, but I know it is still in use by at least a few companies. This is not a tutorial for non-JAMsters, but rather a collection of troubleshooting tips I had taken note of. Maybe this could be of use to someone just inheriting legacy apps, or who knows when I might run into JAM again. Yuck!

For reference, these tips are mostly for JAM 5 and 7, but they may be applicable for other versions as well.

SELECT 1 FROM table...This is often
done to see if a record meeting your criteria (where clause) exists in
the table.
Doing this from a JAM screen (at least in Jam 5) will produce a
@dmrowcount of
0 (zero), even if there are records in the table meeting the criteria.
are two alternatives within JAM to get the same information:

temp_var FROM table...

column temp_var FROM table...
This one can be tricky.
If there is no JAM variable with the same name as the the selected
then JAM will create those variables and put the results of the query
in those
variables. If the variables do exist already, JAM will overwrite the
with the results of the query, even when the query returns nothing (it
will essentially
clear the variables).
Mixed Case VariablesMixed case variables
can be a real problem with JAM, and the error messages are not
intuitive enough
to let you know what the real problem is. Keep tihs in mind when you
figure out some quirky behaviour, and all the other logic and syntax is
Changes in screen file don’t seem to take effectCheck the local
directory you are running from. JAM will use screen, JPL, and
dictionary files fro mthe current directory before
checking in the SMPATH, regardless of what the SMPATH is set to.

Check the data
dictionary. The screen fields and variables can be stored in here, as
well as
in the screen definition file. Data dictionary tends to overwrite
local (screen) vars.
Some Useful environment VarsMost of the relevant environment variables
start with SM, e.g. SMVARS, SMPATH

  • Also worth noting is that while it might make sense that they would just make use of the underlying Motif widgets, in some cases that was not the case. Simple text boxes for instance would not work with bi-directional Hebrew whereas pure Motif screens did. We had to have JYACC / Prolifics issue a patch for us before we could release to an Israeli customer.
  • There were also issues with some characters in the Turkish (ISO-8859-9) character set. Their database layer simply could handle it for some reason. Wouldn't bring back results, wouldn't update, and yet We ended up having to write our own generic database access layer using Pro-C, and replacing all the JPL "sql" statements with "call" statements into our library.

No comments: