Hi Niels:
It’s possible that I’m misdiagnosing matters, but after having scraped Icebreak off my system and reloaded from scratch, without doing anything else other than changing the CCSID from 277 to 37, I find that once again, the navigation menu has disappeared from the admin interface, like so:
Is there some really obvious thing I’m missing or additional step I should have taken? For what it’s worth, even after having changed the CCSID and restarted the admin server, the server information page still showed 277 as CCSID, and continued to do so until I’d ended the ICEBREAK subsystem and restarted it. Which, of course, is when the menu disappeared.
My concern here, as I’m sure you’ll intuit, is twofold – I’ve spent most of my time ensuring that I had some sort of understanding of the copious material in your Programmer’s Guide. But before I start creating “new style” code for existing functions I want to web-enable, I really wanted to ensure that I wasn’t painting myself into a corner with codepages. Toward that end, I played around a bit with the code generators, first pretending (by renaming them) that my file names didn’t contain any codepage collision characters. Before moving forward, however, I really do need to ensure that there’s no fundamental barrier to using a proper CCSID, and thus not needing to rename my files solely to comfort the development environment.
In the potentially dubious case that it matters, there are files within the /Icebreak folder hierarchy that have odd CCSIDs, those other than the expected 37 or 1252. They include:
/icebreak/SyncBox CCSID = 1142 (all)
/icebreak/System/Includes CCSID = 865 (some, not all - all others are 1252)
/icebreak/System/Styles CCSID = 865 (one file, Help.css – all others are 1252)
/icebreak/System/_lock CCSID = 277 (file “verify” only; Lock file is CCSID 37)
/icebreak/Cache CCSID = 277 (Most files, perhaps 10 or so were CCSID 37)
On the off-off chance that the cached files were interfering, I stopped the server, cleared that directory, and restarted. To my complete lack of surprise, this had no effect on the navigation menu’s display. This effect occurs, of course, in both Chrome and Internet Explorer, but I’m sure you already knew that.
At your complete leisure, any clues you might be able to pass along will be greatly appreciated.
Re: Disappeared navigation menu
Hi;
As I have written before – "CCSID is the devils invention” and your post is just another nail in that coffin.
Hopefully you are still fighting the battle... And you don’t need to change your file names or field names – you can use # and $ as you like.
Now: IceBreak has evolved over the years. In the beginning we had only support for database/program CCSID(277) and IFS in windows-1252 (a.k.a. Cp-1252).
Well, welcome to a global village – we realized that the Chinese will never learn danish and CCSID 277 never became a smash-hit in the far east as expected.
Over the time introduction of unicode (as in always-two-bytes-pr-char) was the name of the game, and eventually UTF-8 ( as in: unicode-two-or-more-bytes-as-needed) is the man.
So you will find components in IceBreak that reflects which period in time it was written. Referring to all the above.
The CCSID on the server is the job CCSID of their server job. This handles the conversion from the database. And for the IceBreak database itself (the admin server) it is set to 277 – for historical reasons. Now switching from one CCSID to another after compile time can have interesting side effects since the JSON object escapes – namely {} and array ditto [] will be æø and ÆÅ. - I have not seen a JSON parser that fully supports that yet – and I think that is the reason that you don’t se any menu items after changing the admin server CCSID.
So it is not recommended to switching horses while parsing the river, nor CCSID on an IceBreak server.
When you create a server – then put it into CCSID 37 – and the source files can contain # and $ in fields and file names. If you change the server into something as obscure like 277 (which is native danish / norwegian) your source code needs to contain Æ and Ø and Å for the same file and field names .. This is the way IBM has designed it and there are not much we can do about it but obey.
The CCSID of the server will be the same as for the temporary source file that IceBreak JIT-compiler produces – which is QASPSRC and place it in the server application library.
My recommendation is to save your program sources on the IFS in UTF-8 with BOM-codes. Now what is that?
The BOM-code is three initial byes telling the JIT-compiler that the file contains UTF-8 and only UTF-8 – no matter what the CCSID in the IFS says. If you use “save with BOM-code” technique, you will see that the IFS files actually is changed to CCSID 1208.
Have said all that: My guess is that you have changed the CCSID of the admin-server to let the code generator accept you file names and field names. And maybe we have an issue there, I don’t know. But I will find out. And if there is an issue we will fix it.
Best regards,
Niels Liisberg