Lansa Editor still rewrites my code

A follow-up to the other post from last year, I have now experienced this in a new and disturbing way.

I realize that this code is not pretty but it was just a quick job that I would fix later. In this case, I added some javascript that would append an HTML element with an attribute. The javascript used double-pings (“) and the attribute would then use pings (‘):


Unfortunately, when checking in the changes the Lansa Editor changed the pings to double-pings, rendering my code buggy.


Switching technology services

I have now had the help from Lansa support for a very specific problem. We have a number of solutions, some of which use the XHTML technology service, some the PPC_XHTML technology service.

None of these solutions use more than one technology service.

PPC_XHTML is no longer supported by Lansa so when we upgraded to v.14 this presented a problem. Support found a way to make it work and we continued, making only minor adjustments to the code.

Now we have been upgraded to v.14.1 and something broke in the process.

It can still be made to work but we can only have either XHTML or PPC_XHTML working at the same time. Due to a deadline we will live with that for a short time and then we will start the migration of the PPC_XHTML solutions.

The work-around is this:

Getting XHTML to work: Use Tools -> Import to import the v.14.1. weblets. Done.

Getting PPC_XHTML to work: Use Tools -> Import to import the old v.12 weblets. Check out the specific design weblets made for our solution. Check out the WAM that we need to work with. Done.

So, not bad but not optimal either. That is of course the problem using a technology that is no longer supported.

An example of the JSM HashService

The documentation for some of the functionality in Lansa is sparse, at best. The HashService in Lansa Integrator is one such area (documentation currently here), so here is an example I have that works:

It is important to read up on cryptography first and a short and good guide can be found here.

Define Field(#JSMXHDLE1) Type(*CHAR) Length(4)
Define Field(#JSMXSTS) Type(*CHAR) Length(20)
Define Field(#JSMXMSG) Type(*CHAR) Length(512)
Define Field(#JSMXCMD) Type(*CHAR) Length(512)
* WVALUE is the value to be hashed
Define Field(#WVALUE) Type(*CHAR) Length(255)
* WHASH is the hash returned
Define Field(#WHASH) Type(*CHAR) Length(64)
* WSALT is the salt for the hashing
Define Field(#WSALT) Type(*CHAR) Length(64)
* WINPUT is the value sent to the hashing function = WVALUE + WSALT
Define Field(#WINPUT) Type(*CHAR) Length(319)
* Open service
Execute Subroutine(CHECK) With_Parms(#JSMXSTS #JSMXMSG)
* Load service
Execute Subroutine(CHECK) With_Parms(#JSMXSTS #JSMXMSG)
* Set
* See
* WSALT should be unique for each WVALUE
* WSALT should be at least as long as the result value
* - for SHA-256 that is 256 bits
Execute Subroutine(CHECK) With_Parms(#JSMXSTS #JSMXMSG)
* Unload service
Execute Subroutine(CHECK) With_Parms(#JSMXSTS #JSMXMSG)
* Close service
Execute Subroutine(CHECK) With_Parms(#JSMXSTS #JSMXMSG)
* Check routine
If Cond('#JSMXSTS *NE OK')
Menu Msgtxt('Java service error has occured')

In this example I have chosen SHA256 which I believe is OK. Avoid MD2 and MD5 if possible, as collisions has already been found, and as SHA1 has a theoretically attack described I would avoid that one as well, even if it is default for the HashService. SHA384 appears to also be supported and could be used.

The HMAC algorithms would be even better but there I ran into a problem. I am running on Lansa v. 14, I think that the documentation is for v. 14 SP1, and there is no HMAC parameter in the HashService on my machine. Also in the documentation, there are the CONVERT and CREATE commands, the last of which should give me a good random unique salt, but the are not present on my machine.

Anyway, the code above works.

Old application and new(-ish) browser

Back in a web application built using Visual Lansa v. 12.5 and using the technology service PPC_XHTML, I got the task of getting it to work on a new unit. It was – unsurprisingly – a PDA application and the new “PDA” would be a modern, fast and capable android unit.

The application was built for an Internet Explorer for the handheld units and on an Android it is logical to look at Chrome.

To my surprise very little had to be done to get it to look nice. CSS media queries and a tiny bit at that and I was practically done.

However, one of the WAMs had an auto-submit when the user made a change to the selection in a radio and in Chrome 54 for Android, that resulted in a request with the old value being sent. The radio button was updated but as the request contained the old value, the response was “wrong”. The problem was that the request body was being constructed, on the click event, before the radio button change had taken effect.

The fix was rather simple – I inserted a bit of javascript using jQuery:

$("input#RADIOBUTTON1").mousedown(function() {
$("input#RADIOBUTTON2").mousedown(function() {

This way, as the mousedown event fires before the click event (remember, a click event is combination of a mousedown and a mouseup on the same element), the radio button was updated before the request body was constructed.

Unfortunately the final unit turns out to run a browser built on Chromium 52. And there is a bit difference for the web application.

I have not solved it yet – we might be able to get the units with a newer browser – but I needed to test it on my own machine. And getting an old Chrome/Chromium does take some steps.

First of all, you can’t really get an old Chrome. But Chromium should be good enough.

I found the guide on the Chromium website but I will repeat it here, just it case:

And then I could confirm that the issue exists in Chromium 52. Now I could just find the cause in the change logs.

Update: I think I managed to “fix” my problem. The browser was built using the system component WebView on Android. WebView, which uses Chromium and will be using Chrome on Android 7, can be updated using the Google Play Store and after doing that, it now runs on Chromium 55 and our web application works as intended.

Setting timeout for SOAP client

This one required help from our support. I don’t know what the default timeout value for the JSM SOAP client is, but by experiment I would guess about 3 minutes. Which is a long time to wait for a user.

So I wanted to change this and it turns out to be quite easy, though not supported by the Lansa Integrator UI.

In the solution folder, like


you add a file called


in this file you write

stub.setTimeout ( 20000 );

if you want the timeout to be 20 secconds (20,000 milliseconds, obviously).

Then you generate, compile, publish and reboot the JSM service and your new timeout is set. And, again obviously, this applies to the entire solution. I wonder if it is an Apache Axis client Stub we are using here, and this page holds the documentation?

JSM bindings and field length

Normally, in RDML, setting a char field to a string value that is too long truncates the string, silently.

Imagine my surprise when, using Lansa Integrator’s JSM, this was different. I am pretty sure that is because JSM, being Java, does not truncate a string value silently. In fact, looking at the trace files, in SERVICE.TXT I find

stack trace: java.lang.IllegalArgumentException: DataTypeText: byte data exceeds size of data type definition (34,30) (field: WERROR)
at com.lansa.jsm.d.setValue(Unknown Source)
at com.lansa.jsm.service.SOAPAgentService.a(Unknown Source)
at Source)
at com.lansa.jsm.service.SOAPAgentService.a(Unknown Source)
at com.lansa.jsm.service.SOAPAgentService.for(Unknown Source)
at com.lansa.jsm.service.SOAPAgentService.command(Unknown Source)
at com.lansa.jsm.f.for(Unknown Source)
at Source)
at Source)

Command : ERROR : "DataTypeText: byte data exceeds size of data type definition (34,30) (field: WERROR)"

Unfortunately, using RDML and JSM, this is difficult to prevent in all cases. In this specific case, I can be fairly sure what the maximum length of the string value will be so I changed #WERROR to be a char(255).

A Farewell To Internet Explorer

For the first time since Internet Explorer 4, I no longer have to support the IE browser. The nail in the coffin is update 11.0.34 to Internet Explorer, as this messes up the Visual Lansa Framework frameview. I verified that it worked in 11.0.32 and 11.0.33, but from 11.0.34 the filter and instance list is hidden.

Given that Internet Explorer is all but discontinued, I no longer have to support it.

Implicit Visible(True)

Another small lesson: When setting the display position of a column, the column is implicitly set to visible. Understandable, but if one does not know it…


Set Com(#GDCL_161) Displayposition(#I2)

is the same as

Set Com(#GDCL_161) Displayposition(#I2) Visible(True)

If this is not what you want you have to set visible to false, explicitly:

Set Com(#GDCL_161) Displayposition(#I2) Visible(False)

Added later: Also, setting visible separately to false resets the display position to zero.

So, precision is not just for the result

Today’s small lesson

Change Field(#PCTFLT) To(#ANTSAL * 100 / #KTOTKOB) Precision(4 1) Round_Up(*YES)

only really works if #ANTAL is sufficiently small, that is, one digit. As I would probably have numbers up to a maximum of three digits, I changed the precision to 7 2 and (5 digits with 2 digits after the decimal point, as * 100 adds another 2 digits). Also, I know that #KTOTKOB can only be an integer and will always be larger than #ANTSAL.