Notes client 32 bit to 64 bit migration process recommendations

HCL Domino Domino Forum
,
1

Given the issues regarding LotusScript code compiled in 32 bit versions can cause errors for 64 bit clients and vice versa what would people recommend as a migration process?

As we have multiple clients across multiple sites we can't do a "big bang" and migrate all at once.

If you migrate at a slow pace then we will hit the issue as some 64 bit clients will be executing 32 bit code.

If we compile all code to 64 bit first then there will be issues of 32 bit clients executing 64 bit code.

Update 29 Jan 8:32 GMT

I am interested to know if there are any upgrade processes, recommended by HCL, or other users, to best avoid issues in a mixed 32/64 bit environment.

e.g.

1) Upgrade designer clients to latest 12.0.2 FP5 32 bit

2) Recompile all code in all DBs.

3) End user Notes 64 bit roll out

4) Upgrade designer clients.

some reported issues in mixed 32/64 bit environments

LotusScript code compiled on 32bit client fails on 64bit client, and vice versa. Not fixed until 14.5

https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0105456

LotusScript NotesView.GetAllEntriesByKey issues
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0102291

LotusScript Arrays - "out of stack space" error due to more memory allocation in 64 bit but still 32K overall limit.
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0040725

LotusScript - array of long values bug in 64 bit
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0101520

LotusScript Replace() - Passing an Array to replace function returns an empty string to older Notes version when a LotusScript is compiled using Domino Designer 12.0.2 FP2 64-bit

2

Hi Glen,

Normally codes compiled on 32 bit clients will work fine in 64 bit clients.

They do not need any changes as such, unless they use any 32 bit specific things like file paths "C:\Program Files (x86)" which will be different in 64 bit clients. Apart from that, normally codes run fine without any changes. So are you facing any such error ? If yes what is that error ?

Thank you.

Sandeep

3

Hi, I'm not facing an errors at the moment because we have avoided upgrading due to the reported issues.

4

Hi Glen,

If your code is using an ODBC manager DSN to connect to something, in cases like this you will need to recreate the DSN in the 64 bit ODBC manager.

If your LS code is making C API call outs you will want to review this KB article - Making C API Calls from a LS agent on 64 bit OS

Hope this helps,

Paul

5

Hi Glen,


As per your query, we understand that the you are migrated /upgraded HCL Notes 64-bit and you are observing the issue regarding LotusScript code compiled in 32 bit versions can cause errors for 64 bit clients and vice versa what would people recommend as a migration process?

We would request you to refer the below knowledge articles for more details about 64-bit Notes Client.
Title: Applications should be updated to run on HCL Notes 12.0.2 64-bit
URL--> https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0101520

You can refer the following Thirdparty URL as well for additional information.
https://www.panagenda.com/download/webinar/20240130_EN_HCL_Webinar_Slides_Developer-Special-How-to-Prepare-Applications-for-Notes-64-bit-Clients.pdf

Hope this will help to solve your query.

Thank you,

Regards,

Sridhar

6

Thanks, I was aware of that and it's a good resource ad highlights some of the problems I am looking to avoid.

7

Thanks, I understand there are some cases where there it will be necessary to rewrite code. But I was more interested to know if there were any upgrade processes, recommended by HCL, or other users, to best avoid issues in a mixed 32/64 bit environment.

8

I'm also very interested in this topic, but from a slightly different perspective.

We develop Notes client applications for ourselves and our customers. Some of our customers will soon be upgrading their Notes clients to version 14 (64 bit), while others will remain at version 12 (32 bit) or below for the foreseeable future.

Which Notes Client/Domino Designer version should we use to build the templates so that no client has to recompile before upgrading the applications that use this template?

And again: It's not about the C API (done), database connectors like ODBC, file paths (shouldn't be hardcoded anyway) etc., but about the "normal" LotusScript code.

9

Something along the lines of an "upgrade cook book" or "red book", that we used to get from IBM, would be useful.

10

My thought is that as long as you are writing for a mixed environment it is safer to compile on 32-bit (and therefore on 12.0.2 - once we move to 14 we will no longer have a choice).

There are a couple of gotchas when 64-bit code runs on a 32-bit client, but not the other way about (external interfaces, libraries, paths etc. of course excepted.

11

Regarding your list:

1) Upgrade designer clients to latest 12.0.2 FP5 32 bit

=> Why? The debugger was horrible in 12.0.2, so I remained on the last usable one, 12.0.1FP1. So I can debug code if I need to.

2) Recompile all code in all DBs.

=> Why? To quote Brent Ozar: "What's the problem you're trying to solve?"

3) End user Notes 64 bit roll out

=> Yes. But do pilot's of your applications first, especially ones calling any API's/DLL's etc.

4) Upgrade designer clients.

=> Only AFTER ALL clients are off 32 bits.

Regardfing your list of KB articles:

LotusScript code compiled on 32bit client fails on 64bit client, and vice versa. Not fixed until 14.5
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0105456

=> Because the code where this occurs is NOT shown in the KB, impossible to reproduce / test / decide how it impacts other code. So this article needs to document the failing code to be useful. Poor quality article in the current state.

LotusScript NotesView.GetAllEntriesByKey issues
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0102291

=> This should have been fixed BEFORE roillng out 64bit Designer, and is one of the reasons our company is stil on 12.0.1.

LotusScript Arrays - "out of stack space" error due to more memory allocation in 64 bit but still 32K overall limit.
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0040725

=> KB article is no longer available. When searching for "out of stackspace", a japanese article linking to KB0040725 is found: https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0036598, with the translated text:

Limitations of static string arrays in Domino 64 bit version

Applies to: Domino, Domino Designer

Question.
I created a string array in the agent, and it works fine in the 32 bit version of Domino, but in the 64 bit version of Domino I get an ‘out of stack space’ error.

Cause.
Static string arrays have a 32K limit: a 64 bit environment allocates twice as much memory as allocating string array entries in a 32 bit environment. Therefore, the limit is reached with a smaller number of arrays.

Answer.
Domino 64 bit reaches the 32k limit with a static string array of 4030 entries; in a 32 bit environment there can be 8126 elements declared in a static array before the 32k memory limit is reached.

To avoid this problem, use dynamic arrays instead of static arrays. If dynamic arrays are used, this restriction is not encountered. However, the overall memory usage of the agent code will be larger.

The following code declares a dynamic array of 8000 elements, which works fine in a 64 bit environment.

Dim myArray() as String
ReDim myArray(1 to 8000) as String
=> A static array has a more easily reached limit because the data size has increased. One more reason to pilot and TEST your apps before committing to client 64biot rollout.

LotusScript - array of long values bug in 64 bit
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0101520

=> This article made me unhappy and disappointed. It should have been the reason to not publish 64bit Designer/client until fixed. The title should have been"We need to fix the compiler in Designer 64bit, because we will force clients to do rewrites of their apps and break the famous Notes backward compatibility if we do not fix this".

LotusScript Replace() - Passing an Array to replace function returns an empty string to older Notes version when a LotusScript is compiled using Domino Designer 12.0.2 FP2 64-bit

=> No link or article number, but again one of the reason we're still on 12.0.1FP1, and should not have mede it into production.

In short: You need to ensure the entire client base is on 64bit clients until you can let Designer enjoy the latrgeer memory space. Which is a shame, since the 64bit Designer is faster than 32bit Designer, when the JVM underpinning Eclipse is properly tuned. Which it is not in the released 64bit products.

12

Re the list

1) Because the later FPs, supposedly, fix some of the 32/64 bit mixed environment issues.

2) Because, I'm assuming, the fixes won't be applied unless the code is recompiled. That's why I'm hoping we will get some official guidance, on the recommended upgrade process, from HCL.

3) and 4) Agreed.

Re "This article made me unhappy and disappointed. It should have been the reason to not publish 64bit Designer/client until fixed. " I share your disappointment.

The "LotusScript code compiled on 32bit client fails on 64bit client, and vice versa" is my biggest concern as it's so vague. As you say a "Poor quality article".