A couple of years ago, elsewhere on the Internet, I covered the installation into OS/2 Warp Server for e-Business (WSeB ) of IBM's then recently launched WebSphere Application Server Community Edition (WASCE) version 1. I used the OS/2 native Java implementation by Golden Code Development (GCD) and an Java Cryptography Extension (JCE) by Bouncy Castle; without the latter, WASCE would install into OS/2 but would only partially run during start up. Noticing that the last native implementation of Java for OS/2 ended with GCD's version 1.4.1_07, I examine in this post the installation into OS/2 of WASCE version 1.1.0.1 November 03, 2006, release. Although WASCE version 1.1.0.2 may still run under OS/2, it failed to install using the methodology about to be described. In effect, during the procedure described subsequently I will only use tools available under the OS/2 environment ...nothing else.
One should realize that although the WASCE equivalent Apache Geronimo Application Server is available for download in compressed Zip and Tar/Gzip operating system agnostic formats, IBM makes WASCE available as GNU/Linux and MS Windows specific installation bundles, i.e., those ending with bin and exe extensions, respectively. Accordingly, we could simply download an version of Apache Geronimo that might still be supported with OS/2 Java 1.4.1_07 and this post would end here; and we could conclude with the statement: Apache Geronimo can be uncompressed into an OS/2 files system and can be subsequently instantiated.
Notwithstanding, based on my limited tests in the past I can state that Apache Geronimo and GCD's native OS/2 Java implementation do not work well together, if at all. According to at least one report in response to my initial WASCE 1.0 on OS/2 treatment, the Odin implementation hack by Innotek Java 1.4.2x does, in effect, instantiate Apache Geronimo on OS/2. Nevertheless, Innotek Java is not an native OS/2 implementation for it uses an rather limited OS/2 port of Wine, referred as Odin in the OS/2 world, to enable an existing Windows Java implementation of an relevant version to execute under OS/2. Evidently, this quick and dirty hack was designed and maintained until IBM formally ended support for the OS/2, at the end of 2006.
For those OS/2 users who merely used Java for relatively frivolous applications, the free Innotek Java created the illusion that it offered a better value than the fee-based license of Golden Code Development OS/2 Java alternative. Those of us who knew about the legendary stability of OS/2 and demanded native development as a precondition to maintain the integrity of operating system, were not fooled. For instance, we realized that if an user were to engage in the effort to install WASCE into OS/2 it was because the user would run business grade Java applications on the application server. In turn those Java applications demand a stable underlying foundation that is seriously degraded by the quirks exhibited by Odin based hacks executing on OS/2.
In effect, those Odin derived quirks undermine the performance and stability of an OS/2 machine when least expected; those may range from a sudden loss of usability features, like in the Odin based reimplementation of the OS/2 font engine, to large applications like Virtual PC for OS/2 hanging the operating system. Moreover, the Odin based Innotek Java hack will not execute on multiple processor (core) hardware aware OS/2, whereas Golden Code Development exhibits a much higher degree of compatibility on SMP.
I have gone through the above elaboration to justify my selection, a priori, of GCD Java native OS/2 implementation as the prerequisite foundation for the subsequent manipulation of IBM WASCE; we will install and instantiate WASCE on SMP aware OS/2. Needless to say, at Metztli Information Technology we know OS/2 and we may be able to provide assistance for your relevant legacy needs.
"The gods decide that the fifth, and possibly last, sun must offer up his life as a sacrifice in fire. [...]Nothing happens at first, but eventually two suns appear in the sky."
Wikipedia, the free encyclopedia: Nanahuatzin.
Downloading IBM WebSphere Application Server Community Edition (WASCE) 1.1.0.1
We visit IBM WebSphere Application Server Community Edition (WASCE) resource page:
And proceed to the WASCE download section; we scroll down to select Earlier versions of WebSphere Application Server Community Edition link.
The interested user needs to register and create an user name - password combination to have access to the archives --after selecting the aforementioned link. Once we are authorized to access the WASCE archive, we scroll down the subsequent web page until we find the WebSphere Application Server Community Edition version 1.1.0.1; we select the radio button on the left of the WASCE label and scroll down to select the relevant button to continue.
After the user agrees to the WASCE license agreement, the user is taken to the download section for the relevant WASCE version of her choice. Select the Server for Windows wasce_setup-1.1.0.1-win.exe. Additionally, please select the tab labeled Download using http if you experience problems using the IBM Download Director utility.
The user may also decide to scroll down to the section labeled Add-ons and download the Sample J2EE applications wasce_samples-1.1.0.1.zip as an additional resource to become familiar with the interaction of relevant applications on WASCE.
Having downloaded an MS Windows executable does not necessarily imply that we will repeat the pattern a great majority of OS/2 users automatically re-trace over and over; that is, they use that operating system to decompress the file and subsequently copy over the contents somehow to an OS/2 file system. No, that is not acceptable if an user genuinely desires alternatives.
As a matter of fact, I could have selected the WASCE GNU/Linux executable; however, under OS/2 we currently can not decompress an .bin executable (that I know). My selection of the Windows WASCE installation executable is due to the fact that I can use the Odin limited environment to decompress the OS/2 foreign executable. The inherent instability of Odin mentioned initially is negligible in this case since I only need to make use of it to decompress and seed the Windows specific installation routine.
Hence, we may use Odin for mundanely trivial or frivolous OS/2 tasks, as that of my illustrations of the IBM Lotus Connections Flash 8 screen saver environment supported by Odin. If you are unfamiliar with Odin and desire to install it under your OS/2 environment, you may head to Netlabs pertinent repository and download the last published Odin release, dated June 26, 2005. For this post, however, I was searching for an newer Odin build that I use; it may possibly be an nightly build (hence even more unstable) but it worked well for the present task. I do not seem to find it after browsing a few search pages but for the interested user, I will make it available here as Odin2006.zip.
For an OS/2 Warp 4 and above, the Odin set up is relatively painless. For instance, assuming that we are using the limited version of PkWare pkzip.exe for OS/2 available for download at Hobbes we can extract the Odin2006.zip into our root OS/2 install. First we create a directory, say at drive J: as below,
MKDIR J:\odin
and we proceed to the extraction procedure,
PKZIP /extr /dir Odin2006.zip J:\odin\.
Evidently, we assume that the compressed Odin file is at our current directory location.
We subsequently add the location of the extracted executables and dynamic linked libraries (DLLs) to our OS/2 PATH and LIBPATH environment variables in our CONFIG.SYS (make a back up of this important file before any modifications) and reboot OS/2 for the changes to be effective. Clearly, we might dynamically adjust the PATH and LIBPATH for the current OS/2 window session but we should keep in mind that these modification will be ephemeral; those will last only for our current OS/2 widowed session.
Hence, if the user desires to effectuate the relevant Odin modifications on-the-fly, s/he could set up an command file, named myOdin.cmd as an specific instance, and place content similar as below (where J:\odin represents the drive and directory where the Odin2006.zip content was extracted):
PATH J:\odin\system32;%PATH%
SET BEGINLIBPATH=J:\odin\system32
After saving the sample file myOdin.cmd content and placing the same under an directory already referenced by your OS/2 variables, for instance X:\OS2\myOdin.cmd (where X is your OS/2 root drive), you may invoke myOdin.cmd from any command shell window you open. After its invocation, you will be able to execute certain Windows programs by merely adding the prefix pe.exe and a space before the Windows program name. We are ready to execute the Windows specific WASCE installer under our OS/2 environment. Or are we?
Applying Java Cryptography Extension to Golden Code Development OS/2 native Java Implementation.
Well, it is one thing that we can install WASCE into our OS/2 and it is another to be able to instantiate the Java application server with our GCD native OS/2 Java. Specifically we need to retrofit our GCD Java with an appropriate Java Cryptography Extension (JCE). For whatever reason, WASCE does only partially instantiate with the Golden Code Development originally bundleded JCE support. Accordingly, we visit Bouncy Castle latest releases page and, under the section labeled SIGNED JAR FILES, download the current bcprov-jdk14-ver.jar, where the ver represent the current version available.
Assuming an GCD Java directory named java141 under our root OS/2 directory, we should place the JCE support file just downloaded at:
X:\java141\jre\lib\ext\
(where, again, X represents our OS/2 root drive directory).
We should also open our java.security file under an text editor and modify it to reference the newly added JCE support from Bouncy Castle. But first, we should make a back up copy of java.security. Hence, we change our file system location as below:
CD X:\java141\jre\lib\security\
COPY java.security java.securityBAK
And we use our OS/2 EPM editor to effectuate the modifications:
EPM java.security
At approximately line 52, the user should add the line:
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
Save your changes and close your GCD OS/2 Java java.security file. Please note that in the immediately above description I assume that the java.security file has not been previously tampered by you or other parties; if, however, that is not the case then adjust your current modification line to properly work with your prior java.security alterations.
Please be aware that later, when the time comes to instantiate your WebSphere Application Server Community Edition, you see output at the OS/2 command shell similar errors as below:
[*********> ] 40% 56s Starting geronimo/tomcat/1.1/car [*********> ] 40% 56s Starting geronimo/tomcat/1.1/car 20:39:42,758 ERROR [Http11BaseProtocol] Error initializing endpoint
java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:739)
at java.security.KeyStore.load(KeyStore.java:652)
And subsequently WebSphere Application Server Community Edition fails to start with additional errors similar to:
LifecycleException: service.getName(): "null"; Protocol handler start failed: java.io.IOException: Keystore was tampered with, or password was incorrect at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:403)
[...]
... 15 more
[*********> ] 40% 58s Startup failed
[*********> ] 40% 59s Startup failed
Stopping server...
Server stopped
The above errors are symptoms that you have not properly applied Bouncy Castle (or equivalent provider) Java Cryptography Extensions (JCE). If when the time comes to instantiate your WASCE, you experience similar to the above in the OS/2 command shell, please go back and review the application of JCE support to GCD native Java for OS/2.
Enough has been elaborated by now. We are now ready to install WASCE with Odin and instantiate the WebSphere Application Sever Community Edition with GCD's Java with our newly updated JCE from Bouncy Castle.
Installation of IBM WebSphere Application Server Community Edition (WASCE) Under OS/2 Warp Server for e-Business.
Well, assuming that we downloaded WASCE wasce_setup-1.1.0.1-win.exe to the root of our M: drive directory location, then we can start up the Windows specific WASCE installer by entering:
PE.exe M:\wasce_setup-1.1.0.1-win.exe
You will get an dialog by the WASCE Installation Wizard, executing within the Odin environment, with an message similar to:
Unable to locate an IBM/Sun SDK/JRE V1.4.2 or IBM SDK/JRE 1.5 in a
well known location on your system. If you have a recommended Java
environment, either indicate your Java command now, or re-invoke the
launcher and explicitly specify the Java installation directory with the
-is:javahome option.
After the user presses the OK button, the subsequent InstallShield Wizard mechanism activates another dialog asserting that the OS/2 GCD Java has not been detected:
A suitable JVM could not be found. Please select a JVM by selecting its Java.exe file.
Accordingly, we need to manually specify the location of either of our GCD Java executable in the file manager utility provided by the InstallShield Wizard. The GCD Java executables may be located at:
X:\Java141\jre\bin\java.exe
or
X:\Java141\bin\java.exe
I assume, of course, that your GCD Java root directory is X: and its directory containing all its GCD resources is X:\java141; please modify accordingly to your specific file system layout:
If the installation hangs or, in certain instances, the user may see an out of memory error similar to the snapshot that follows, please make sure to close any other programs that may me running, remove the temporary files left over from the failed installation, and kill the Odin process (pe.exe), if necessary. The OS/2 TMP or TEMP environment variables will point to your directory location for your temporary files; whereas, an utility like PSMP2 will allow you to kill processes like that of Odin pe.exe
Nevertheless, once these ephemeral probabilities are overcome the user simply is presented the much anticipated InstallShield Wizard dialog to proceed WASCE installatin in her OS/2:
Please note that I am using the public domain Korn Shell (ksh) supported by Eberhard Mattes' EMX libraries to emulate an Unix environment under OS/2. Accordingly, the illustrations throughout this blog post will reflect the Unix shortened commands, as well as slashes that differ from OS/2 and Windows.
We are required to accept the IBM WASCE Software License Agreement. If the user agrees to the license, please select the appropriate radio button and proceed by selecting the Next button at the bottom of the dialog:
The subsequent dialog prompts us whether to accept the default installation directory for WASCE. You may notice that there is no drive letter at the beginning of the default directory path suggested. In this specific instance I have to add manually the drive letter to the dialog field where I want WASCE installed. As can be seen, I have highlighted J: --my manual modification to the dialog field:
Most important note: You should additionally create manually, at your OS/2 command shell environment, the relevant local file system directories leading to the default path where WASCE is to be installed --using as guidance the path in the installation dialog. For instance, if the user observes my ksh shell at the bottom left of the OS/2 desktop, s/he can read that I created all such directories:
MKDIR J:\IBM
MKDIR J:\IBM\WebSphere
MKDIR J:\IBM\WebSphere\AppServerCommunityEdition
Reiterating Do not overlook creating the directories manually at your OS/2 shell. Due to unknown reasons, the Windows specific installer being run by Odin will not create those directories and your WASCE installation will fail.
After the user presses the Next button to proceed, we note another idiosyncrasy of our WASCE installation hack. The dialog states that WASCE will be installed on the default path on drive J:, which is correct; however, just below we can read the misleading assertion: for a total size: 0 KB.
If you manually created the directories composing the default WASCE installation path, simply disregard the misleading for a total size: 0 KB statement and select the Install button. We can see that the progress indicator in the installation dialog is increasing:
After a couple of minutes (less than those shown in my snapshots 
since I was taking those live and elaborating at length), we can see that WASCE installation continues smoothly, passing the 70% progres mark:
And finally, IBM WebSphere Application Server Community Edition version 1.1.0.1 completely installs into our OS/2 operating system. We select the Finish button to close the WASCE installation dialog.
Starting an Instance of WebSphere Application Server Community Edition 1.1.0.1 on OS/2
Well, it is time to test our newly installed Java based application server. We proceed to change our file system location to the WASCE bin executable directory:
CD J:\IBM\WebSphere\AppServerCommunityEdition\bin
And we start our application server with the Java command:
java -jar server.jar
In executing the above statement, I assume that the user may invoke GCD native Java executables from any location in the file system. I assume, additionally, that the OS/2 Java CLASSPATH environment variable is not set. If in doubt about potential issues introduced by your OS/2 CLASSPATH environment variable, you may set it to a null value, at least for the current OS/2 windowed session, as specified below by typing:
SET CLASSPATH=
Below is a snapshot of WASCE starting up within my specific OS/2 environment:
Evidently, our IBM WebSphere Application Server Community Edition 1.1.0.1 instance successfully starts up for my current OS/2 host. By default it can be accessed at port 8080 so as not to cause conflict by an instance of the Apache web server that may be running on port 80.
Subsequently, I proceed to my Firefox web browser pointing to my OS/2 localhost port 8080. Please adjust the browser path to your unique setup but, if you have been following the procedure at length, the default port will be 8080.
firefox http://localhost:8080
We can see in our web browser that there are plenty of resource available to increase our proficiency with WASCE and subsequently engage in developing and deploying Java applications within our OS/2 environment.
Selecting the Documentation link from the left pane, we are taken to an entry point for the various available IBM WASCE versions. For instance, we may proceed to select the relevant WASCE version that we are currently running; it is labeled 1.1.0 and has been hilited by me:
In effect, having selected our WASCE current version link, we are taken to the IBM WASCE documentation project web page. A quick glance of the information will convey the fact that WebSphere Application Server Community Edition is an enterprise grade Java application server. If that were not the case, why would IBM bother to provide fee-based support for WASCE?
Scrolling down the page, under the section labeled Verify the installation, we can find default authentication information to log into our WASCE administrative console:
- Initial Username: system
- Initial Password: manager
Selecting the link to analyze the IBM supported Java virtual machines (JVM) if an organization desired to obtain WASCE fee-based support from Big Blue, we can see that our Golden Code Development native OS/2 Java implementation would not be covered. Well, we knew that; we also knew that IBM ended, officially, OS/2 support at the end of 2006. And there the reason that there is an online petition to Big Blue to open source all or any fraction of the OS/2 source code for the 21st century.
As a matter of fact, only IBM 32bit and 64bit JREs and SDKs versions 5 and 6 are (R)ecommended for WebSphere Application Server Community Edition. Additionally, the Sun MicroSystems 32bit SE 5 is listed as (C)ompatible with WASCE.
We may subsequently explore WebSphere Application Server Community Edition Administrative Console, either by selecting it from the link on the left pane when we opened our browser to http://localhost:8080, or by directly accessing WASCE Admin Console by typing into our browser search field: http://localhost:8080/console. We know from above sections what our default Username and password should be typed into the Admin Console authentication fields.
Once authenticated into WASCE Admin Console, we are provided an Welcome resource page that will serve as the entry point for all our WASCE management tasks.
As an instance, selecting Information under the Server section on the left pane, we are presented with the WASCE build version, operating system architecture and available processors, JVM in use, as well as memory allocated to WASCE.
At the lowest extreme of the left pane in WASCE Admin Console, we may select DB Info under the Embedded DB section. We simply confirm that Apache Derby, formerly IBM CloudScape, is the default DB for WebSphere Application Server Community Edition, as well as for most enterprise grade IBM products.
Well, I believe to have provided an spark of curiosity for an OS/2 user interested in IBM WebSphere Application Server Community Edition to develop and host Java applications within her favorite environment. Perhaps I even provided an ray of insight, similar to an ray emanating from Nanahuatzin that found its way into some nebulous valley of an receptive intellect, to those who, being constantly blasted by negative OS/2 propaganda by third parties with self-serving interests, never even bothered to experience OS/2. Wrapping up this entry, I will proceed to select the WASCE Admin Console Shutdown option under the Server section, located on the left pane.
It is the 21st Century and OS/2 continues to be viable. Not bad for an operating system that certain information outlets, manipulated by mediocre but powerful software development entities, have asserted as dead without even bothering to confirm whether that assertion holds merit.
The biggest drawback for the OS/2 operating system continued viability in the 21st Century CE is its inherent closed source property. This in effect decreases the availability of potential developers needed to adapt the operating system to the requirements of modern Cloud Computing environments. We may enumerate one of those requirements as the need for OS/2 to be virtualized under open source technologies like Xen, OpenVZ, or ...KVM? An open source OS/2 kernel that adheres closely to the properties of its equivalent GNU/Linux or freeBSD might be the answer.
Nevertheless, the obvious question might be, how unique is OS/2?
NOTE
The educated opinions expressed do not necessarily reflect those of Metztli Information Technology as a whole.
Suggestion code for commands entered at the OS/2 shell(s) prompt are provided on an AS-IS basis. Although due diligence has been applied, the information may not be accurate under all circumstances.
Consequently, please do not hold Metztli IT responsible if unforeseen effects are experienced. You are not obliged to use the information provided.
Metztli IT reserves the right to modify the procedure --including deleting the blog entry.