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. There are two alternatives within JAM to get the same information: 1. SELECT COUNT(*) temp_var FROM table... 2. SELECT column temp_var FROM table... |
| SELECT column FROM table | This one can be tricky. If there is no JAM variable with the same name as the the selected columns, 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 values with the results of the query, even when the query returns nothing (it will essentially clear the variables). |
| Mixed Case Variables | Mixed 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 can’t figure out some quirky behaviour, and all the other logic and syntax is proper. |
| Changes in screen file don’t seem to take effect | Check 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 Vars | Most 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:
Post a Comment