eeePC 701 and OpenBSD

EeePC is somehow a quite old netbook nowadays, but there are a lot of folks around that still have it and keeping put it to good use.

I myself have a tiny 701 model. Back some years ago I used it basically for e-mail and Internet browsing, but it's limited disk space (4GB SSD) and single core processor make it useless for the current requirements for that (specially the websites that still uses the bitch called Adobe Flash). And, let's agree, any smartphone can beat it nowadays in terms of processor and memory.

Anyway, I was looking for an excuse to learn OpenBSD a bit. I always was curious about it but never gave me a change to learn it.

The "excuse" I was looking for was setting up a CPAN Reporter Smoke machine with OpenBSD, and my second thought (first was a VM in Virtualbox) was installing it on my EeePC.

I tried OpenBSD 5.7 (a few weeks before the release of 5.8) and setup run smoothly. The OpenBSD installer offered me a quite pleasant setup processes, with almost no questions and easy partitioning (very different of my first experience with it at 2000, when it offered disk space in sectors and let me do the math myself!). Keyboard configuration (something that is usually a pain to configure since I use ABNT2) was pretty simple too.

OpenBSD also does a good job about dealing with the limited disk space available on my EeePC, since it's basic install being really basic. I just removed the X-Window options from the file sets since the CPAN Reporter Smoker doesn't need one (and the screen size is really small) and fired away the installer.

Unfortunately, those were the good points about this "marriage": there are two big issues about installing OpenBSD on EeePC 701:

1. File system (FFS).
2. No fan control.

The default OpenBSD file system (FFS) is really slow compared to options available to Linux. Even after setting up the partitions to use noatime and soft updates my EeePC took a long time (most of it with I/O) to prepare the CPAN indexes. That's something that I could have fixed with mfs as a workaround, but the 512MB of memory of EeePC does not allow it. And, to be fair, I'm still working on providing statistics for each tested module by CPAN::Reporter::Smoker, some more things might doing the tests execution slower and I'm not aware of it.

Also, FFS does not implement TRIM (at least that's what my research found), so basically the support for SSD disks on OpenBSD is pretty weak.

The EeePC fan is another problem too. The thing is that the hardware configuration of it leaves the netbook get to high temperatures (and I'm not overclocking the processor) without turning the fans properly (yes, it really sucks). Since OpenBSD 5.7 kernel is not capable to detect the fans control, there is nothing left to do about it. I searched for some patches/user land software but none seems to be "production ready".

Conclusion

So, my conclusion about the experiment is: although OpenBSD has a good install for the limited hardware of EeePC 701, the limitations I explained above (specially number 2) tells me that is not even that safe to let the EeePC running for long periods with it, something that a CPAN Reporter Smoker requires. And, just to leave a comparison, I was able to easily install Debian Jessie on the EeePC with fan-control and lm-sensors packages, run a quickly setup and voila: the fans worked like a charm.

Checking all modules configured in OHS

That's something I've being looking for since I started working with OHS (a cousin of Apache web server in the case you don't know it).

Apache happily will tell you the modules it has running with by usage of apachectl (or httpd -M depending on the distribution you're using).

Well, that's not that easy for OHS, at least not while you're in the shell. Based on a tip that I found about /proc (see details here) I wrote this little Bash script for OHS 11g:

#!/bin/bash

PID=$1
full_path=$2

if [ -z $PID -o -z $full_path ]
then
    echo <<BLOCK
Usage:
iasenv.sh <PID> <path to httpd>
BLOCK
fi

temp_file=$(mktemp)
xargs --null --max-args=1 echo export < /proc/${PID}/environ > "${temp_file}"
source "$temp_file"
"${full_path}" -M
rm -v "$temp_file"

Then I call the shell script passing the PID of a running process of OHS and the complete pathname to the httpd.worker process (probably I should try to fetch this information from /proc too). Here is a sample of the output:

bash-3.2$ ./list_mods.sh 28377 /foobar/ias/product/OHS/ohs/bin/httpd.worker
Loaded Modules:
core_module (static)
mpm_worker_module (static)
http_module (static)
so_module (static)
oralog_module (static)
ohs_module (static)
ora_audit_module (static)
file_cache_module (shared)
vhost_alias_module (shared)
env_module (shared)
log_config_module (shared)
mime_magic_module (shared)
mime_module (shared)
negotiation_module (shared)
status_module (shared)
info_module (shared)
include_module (shared)
autoindex_module (shared)
dir_module (shared)
cgi_module (shared)
asis_module (shared)
imagemap_module (shared)
actions_module (shared)
speling_module (shared)
userdir_module (shared)
alias_module (shared)
authz_host_module (shared)
auth_basic_module (shared)
authz_user_module (shared)
authn_file_module (shared)
authn_anon_module (shared)
authn_dbm_module (shared)
proxy_module (shared)
proxy_http_module (shared)
proxy_ftp_module (shared)
proxy_connect_module (shared)
proxy_balancer_module (shared)
cern_meta_module (shared)
expires_module (shared)
headers_module (shared)
usertrack_module (shared)
unique_id_module (shared)
setenvif_module (shared)
context_module (shared)
rewrite_module (shared)
onsint_module (shared)
weblogic_module (shared)
plsql_module (shared)
swe_module (shared)
Syntax OK
«/tmp/tmp.hKZiBm6589» deleted
bash-3.2$

Your eScript loop sucks!

Scripting in Siebel has a bad reputation.

I'm not that old with Siebel, but I believe this bad reputation may had started because Siebel started scripting with VBScript language. It is that easy to make terrible code with it.

If you don't agree, please leave some comments explaining why Microsoft moved from it favoring other programming languages.

Anyway, I'm always listening that scripting is bad and you should avoid it at all costs.

Yeah, right.

"Because learning how to program is not for everybody" should be the rest of the recommendation that nobody will give you.

That's not because programming with eScript requires an "Einstein". Because programming requires attention and dedication. If you want to do it right, you must practice it, study it. There is no way around, this is not the same thing than drawing squares and dragging arrows around.

And, to finish my rant, let's go for a example. You should have seen that a lot in your life developing with Siebel:

var OfferBO = TheApplication().GetBusObject("Offer");
var OfferBC = OfferBO.GetBusComp("Offer");

OfferBC.ActivateField("Priority");
OfferBC.SetSearchSpec("Id", TreatmentID);
OfferBC.SetViewMode(AllView);
OfferBC.ExecuteQuery();
var rec = OfferBC.FirstRecord();
while (rec) {
    //do something with the data
    rec = OfferBC.NextRecord();
}

OfferBC = null;
OfferBO = null;

It's the same old story to get data from the data layer. Let's ignore that this lame code is not using try-catch for now,  just please take a look at the while block.

You did? Right... now, if you're doing loops like that PLEASE STOP for God's sake!

eScript has the proper statement to do that kind of thing and I wonder why people keep writing the same damn thing:

if ( OfferBC.FirstRecord() ) {

    do {
   
        //do something with the data
   
    } while ( OfferBC.NextRecord() )

} else {

    TheApplication().RaiseErrorText("What the hell?!? Where is my data???");

}

Now you have it. Cleaner code. No extra variable to control execution flow. Properly validating that you have the data you're looking for or doing something about otherwise.

Let's tweak a little further:

    var OfferBO: BusObject = TheApplication().GetBusObject("Offer");
    var OfferBC: BusComp = OfferBO.GetBusComp("Offer");

    try {

        //Get the priority
        OfferBC.ActivateField("Priority");
        OfferBC.SetSearchSpec("Id", TreatmentID);
        OfferBC.SetViewMode(AllView);
        OfferBC.ExecuteQuery(ForwardOnly);

        var Priority:String = null;

        if (OfferBC.FirstRecord()) {

            do {

                //a silly example, but anyway...
                Priority = OfferBC.GetFieldValue("Priority");

            } while (OfferBC.NextRecord())

        } else {

            TheApplication().RaiseErrorText("No offer found for treatment id " + TreatmentID);

        }

    } catch (e) {

        throw (e);

    } finally {

        OfferBC = null;
        OfferBO = null;

    }

Let's review the changes:

1. Using strongly typed variables: you should be using it nowadays to improve eScript performance.
2. Hey, try-catch-finally is there for something! Use it!
3. Always declare your cursor type when calling ExecuteQuery, and use a constant for that, not a number. "ForwardOnly" is the one you want in most cases.
4. Always check if you're getting what you're expecting. If you're not, do something except hiding the dirt under the carpet. If you don't know what to do in such situation, add an exception and later you figure it out during your QA tests with some functional expert.
5. Clean up your objects, you don't want a memory leak crashing the Siebel component.

That's it. And come on, it wasn't that difficult, it was?

Additionally, let me tell that despite Siebel Tools not helping you with that, your code does not have to look like indented by your cat sleeping on your keyboard. There are plenty tools to make your code look nice, I personally use http://jsbeautifier.org/ for that.

Cheers!

Resolving HTTP 404 errors for Siebel on Linux

I couple of weeks ago I was checking OHS logs files that serves a Siebel web application instance for some errors regarding the application and what I found were a lot of errors regarding "File Not Found" (HTTP 404) errors.
Double checking those messages, all them seem to be happening because of two different "categories":

• transparent GIF images used in the Siebel vanilla application
• favicon.ico

In the first case, I had to look for those GIFs in the Siebel default folder for web content. The files were there. Looking further, I found a bug regarding Cascading Style Sheet: those CSS files, while used under Microsoft Windows OS didn't bother to use the correct case for file names or file extensions. For those GIFs, that meant the file extension was written as ".GIF" meanwhile it should be lowercase (at least the image files had that in lowercase).

File extensions don't make much sense for Linux, but the OS is case sensitive regarding file names. That's why OHS wasn't able to find them.

A fix to this issue is simple: change the CSS or the GIF file names. I preferred the former since using Sed for that is pretty straightforward. Assuming that the Siebel Server is installed in the directory defined for the $HOME environment variable, that's what I did:

tmp_file=$(mktemp);sed -e 's/\.GIF/.gif/g' $HOME/81/siebsrvr/webmaster/files/esn/main.css > "${tmp_file}";cat "${tmp_file}" > $HOME/81/siebsrvr/webmaster/files/esn/main.css; rm -v "${tmp_file}"

tmp_file=$(mktemp);sed -e 's/\.GIF/.gif/g' $HOME/81/sweapp/public/esn/files/main.css > "${tmp_file}";cat "${tmp_file}" > $HOME/81/sweapp/public/esn/files/main.css; rm -v "${tmp_file}"

That took care of fixing in place those CSS in webmaster and sweapp directories (yes, you should make that on both since they are synchronized by the Siebel application). This bug seems to be present only in Siebel versions 8.1.1.7 or lower.

The second issue is easy to fix as well. You only need to find the proper favicon.ico file to use (most probably the one used by the company in their institutional web site). Just copy the file to the root folder of OHS and the next time a modern browser hit the page, it will find the icon just fine.

Conclusion

I really don't know if the end user will ever notice that those images are now available... if they did, we should know about errors long before looking at OHS log files.

The main reason is to avoid thousands of HTTP 404 errors being logged. It doesn't hurt anyway to check OHS logs anyway from time to time to see how things are going.

Faster imports of Siebel Repositories

So, it is just another day in your SADMIN life. The development team just finished cooking their configurations and now they want to test their doing in another Siebel Enterprise, which implicates that you need to import a new Siebel Repository.

Well, all you need is to launch Database Server Configuration Utility, go over all those dialog boxes filling the fields as necessary and choosing the correct options to import a Siebel Repository.

Lame try... as you probably did that on MS Windows, didn't you ever pay attention to the command line application that is invoked when you finish entering the details? That guy over there execute "repimexp", which is a command line program that you can actually use on your own.

Well, by using this program you can select different options that the Database Server Configuration Utility will not expose to you. And two of those options will allow you to dramatically improve the speed of importing a new Siebel repository.

Don't bother looking around a documentation that gives you all those details... they are only at command line help message. Let's review it:

bash-3.2$ repimexp

Siebel Enterprise Applications Repository Import/Export Utility, Version 8.1.1.7 [21238] LANG_INDEPENDENT

Copyright (c) 1990-2008, Oracle. All rights reserved.

The Programs (which include both the software and documentation) contain

proprietary information; they are provided under a license agreement containing

restrictions on use and disclosure and are also protected by copyright, patent,

and other intellectual and industrial property laws. Reverse engineering,

disassembly, or decompilation of the Programs, except to the extent required to

obtain interoperability with other independently created software or as specified

by law, is prohibited.

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of

Oracle Corporation and/or its affiliates. Other names may be trademarks

of their respective owners.

If you have received this software in error, please notify Oracle Corporation

immediately at 1.800.ORACLE1.

repimexp

Error: Value missing for argument 'Rows Per Commit'.

Usage:

-------------- required parameters -----------------

/C <ODBC data source>   ODBC data source.

                          Default: SIEBEL_DATA_SOURCE environment variable.

/U <userName>           User name

/P <password>           Password

/D <table owner>        Siebel database table owner.

                          Default: SIEBEL_TABLE_OWNER environment variable.

/R <repository>         Repository name, default: Siebel Repository

/F <dataFile>           Import/Export/Dump repository data file's name

------------- choose which action you want to take by /A -------------

------------- and select the sub-parameters accordingly --------------

/A <D|I|X|E>            Dump/Import/Import_INTL/Export actions

/A D                    Action: Dump basic data info from the datafile

/A I                    Action: Import base tables and (optional) INTL tables

  /G <languages>       (Optional) Specify what languages to import, e.g. ENU,FRA,ITA

                                  ALL for all languages. Default: no language import

  /X <Codepage#>       (Optional) Verify (not really import) the data file against

                                  a codepage character set, e.g. CP1252,CP874 ...

  /H <number>          (Optional) Number of rows per commit

  /8 <moduleFile>      (Optional) Module list filename

  /K <Y|N>             (Optional) Preserve DB system column values (Default: N)

  /J <string>          (Optional) DB system column source (DB_LAST_UPD_SRC) (Default: repimexp)

  /Z <number>          (Optional) Array Insert Size (Default: 5)

  /A X                    Action: Import INTL tables only

  /G <languages>       Specify what languages to import, e.g. ENU,FRA,ITA

                          ALL for all languages

  /O <Y|N>             (Optional) Abort INTL import if unable to resolve parent row

                                  in server repository, i.e. orphans

                                  Default: N

  /I <Y|N>             (Optional) Abort INTL table import if insert fails

                                  Default: Y

  /A E                    Action: Export

  /1 <exp rep userName>       (Optional) Default: to same as User name

  /2 <exp rep password>       (Optional) Default: to same as Password

  /3 <exp rep ODBC dt src>    (Optional) Default: to same as ODBC data source

  /4 <exp rep table owner>    (Optional) Default: to same as Siebel database table owner

  /5 <exp rep repository>     (Optional) Default: to same as Repository name

  /E <Y|N>                    (Optional) Export prototype data. Default:N

  /S <Signature>              (Optional) Repository signature

  /N <0|1|2>                  (Optional)

                                  0: no change.

                                  1: change CREATED_BY, UPDATED_BY, OWNER_BRANCH

                                  2: change CREATED_BY, UPDATED_BY, dates columns, OWNER_BRANCH

                                  Default: 1

------------ other optional parameters ---------------

/L <logFile>            (Optional) Log output messages to this file as well.

/W <lang code>          (Optional) The language env where this program is running.

                                  Default: SIEBEL_LANGUAGE, if not set ENU

/B <appServer root>     (Optional) Siebel server installation directory to

                                  override SIEBEL_HOME environment variable.

/T <Y|N>                (Optional) Test/Debug use only, do not import into database

/V <Y|N>                (Optional) Verify data.  For import, default: Y

                                  For export, default: N

/M <Y|N>                (Optional) Commit changes even if verification failed.

                                  Default: N

I highlighted the options that will help you get better performance.

The /H is the one that you will use in most cases, and probably the one that gives you the best improvement of speed. It's is basically allowing you to set the number of rows imported before doing a single commit. If you don't set this option, the program will commit every line inserted, which is a very secure operation... but also a lot slower.

It is all about trading off data consistence with I/O speed. The point is, the worst thing that might happen with a repository import that went bad is that you will need to erase it and repeat the operation. Not a big deal in most of cases.

That said, talk to your DBA about how much lines he considers reasonable inserting before a single commit to avoid using all your UNDO (or whatever other term is used by the DBMS Siebel is installed over) space and set the /H option with it.

The /G options allows you to select which languages you want to import. If you have a multilingual repository but do not need all those languages, just select the one you need it. That will reduce the number of rows to be imported. This parameter is not as good as /H but it will help anyway.

Another tip to improve Siebel Repository maintenance speed is to keep only the most recent ones imported (see Doc Id 761894.1). By my experience, keeping the current and the previous one should be enough. You don't need to try doing "big data" with Siebel Repositories. If you are worried about backups, just use the .dat files for that and erase all of those older repositories. Your DBA will thank you later for that.

Installing openSSL inside your Perlbrew

A while ago I had to install some monitoring scripts in reasonable old Linux servers. The script would require a substantial number of Perl modules from CPAN and I was not interested in running the issue to convince the administration responsible team (I didn't have root access) to install those modules for me.

The easiest way to solve that was installing Perlbrew. Perlbrew allows anyone to download perl source code, compile and install anywhere, including your own home directory (Perlbrew is available only for UNIX-like operational systems at the moment I'm writing this post).

Since I didn't have direct access to the internet on those servers, what I did was create a VM with the same Linux distribution and version and install Perlbrew from there, connecting to CPAN and installing all dependencies that I need too.

After that I just had to generate a tarball from everything and move to those Linux servers. Another wonder from Perl community made my day.

After some days of having those test scripts working, I had receive a new testing request: validate if some webpages were working fine. Perl has a lot of tools to help with that, so no issue here. The problem is that those webpages where available only through TLS and the version available of openSSL was so old that newer versions of IO::Socket::SSL would simple not compile with it.

Old libs and no play makes Jack a dull boy

IO::Socket::SSL depends on Net::SSLeay, that will then look for shared libraries of openSSL to compile C/XS code.If there are changes in the expected interface, this code will not compile at all.

Some how I would need to avoid using the present openSSL binaries and download and install a newer one inside my Perlbrew setup. I spent an unpleasant time trying to do that (I'm not a C programmer) because first I thought that I should use static libraries, than I tried to force shared libraries... and during all this time I was being stomped by SELinux (yes, it was installed in all those servers).

It turned out at the end that a much more simple was available: just compile openSSL with standard options. And some changes regarding system variables. Let's review my recipe on that:

1. install Perlbrew: you probably already know how to do that. If not, just visit it's website for instructions.
2. Install openSSL: no magic here, the simplest
3. Installing Perl modules that depends on openSSL

Step 2 is pretty easy. I suggest to set up the option --prefix as a sub directory under the Perlbrew install. For instance, that might be something like:

./config shared --prefix=$PERLBREW_ROOT/openssl
make
make test
make install

For Step3, some previous setup is necessary.

Create a test file named "openssl_env" in your $HOME with the following content:

export OPENSSL=$PERLBREW_ROOT/openssl
export C_INCLUDE_PATH=$OPENSSL/include
export LIBRARY_PATH=$OPENSSL/lib
export LD_LIBRARY_PATH=$LIBRARY_PATH:$LD_LIBRARY_PATH
export OPENSSL_PREFIX=$PERLBREW_ROOT/openssl

Now go back to the shell and type:

perl -MCPAN -e shell
get Net::SSLeay
look Net::SSLeay

perl Makefile.PL
make
make test
make install
exit

Make sure all tests from "make test" worked fine. If not, check if the declared variables paths are correct.

Now edit again the openssl_env file and comment the C_INCLUDE_PATH variable. Should be unnecessary to have it setup unless you need to compile more stuff.

Now add the following to the end of your .bashrc (or whatever other shell configuration file you're using):

source $HOME/openssl_env


Now, go back to the CPAN shell to install IO::Socket::SSL:

perl -MCPAN -e shell install IO::Socket::SSL

If you did everything right, now you should have a plenty functional customized Perl with openSSL working!

Better checking your Java version

A couple of days ago I received a task to check installed applications in a bunch or servers. One of the things to check was the Java VM installed into those and see which versions was there.

It looks a simple task, but it is not: some applications requires different versions of Java, so there is none "one JVM to rule them all".

It should a be simple thing to do it automatically, but actually Java doesn't help as much I as would like. This is the output from Java in my MS Windows box:

C:\>java -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) Client VM (build 24.71-b01, mixed mode, sharing)

C:\>

The version is there, right? Well, it is, but can you tell me if this JVM is 64 or 32 bits version?

The truth is, if the JVM is 64 bits it should let me know... but for 32 I'm just guessing. That's OK when I'm doing it manually, but guessing from script is not so.

After some searching over the Internet I got this ridiculous simple code, actually I could say this could be the "Hello World" example of Java, and here it goes:

public class JavaArch {
 
    public static void main(String[] args) {
                          System.out.println(System.getProperty("sun.arch.data.model"));

    }

}

Compile that code with javac and ship it with your script and you're good to go. No guessing required, just the bare information.

C:\>javac JavaArch.java

C:\>java JavaArch
32

C:\>

Can't be easier than that.

See more information about here.

If you need even more properties available for the environment from the JVM point of view, go checking http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#getProperties%28%29.

Here is an example from my environment:

C:\>java JavaArch
java.runtime.name = Java(TM) SE Runtime Environment
sun.boot.library.path = C:\Program Files (x86)\Java\jre7\bin
java.vm.version = 24.71-b01
user.country.format = BR
java.vm.vendor = Oracle Corporation
java.vendor.url = http://java.oracle.com/
path.separator = ;
java.vm.name = Java HotSpot(TM) Client VM
file.encoding.pkg = sun.io
user.script =
user.country = US
sun.java.launcher = SUN_STANDARD
sun.os.patch.level = Service Pack 1
java.vm.specification.name = Java Virtual Machine Specification
user.dir = C:\Users\foobar\Documents\temp
java.runtime.version = 1.7.0_71-b14
java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment
java.endorsed.dirs = C:\Program Files (x86)\Java\jre7\lib\endorsed
os.arch = x86
java.io.tmpdir = C:\Users\foobar\AppData\Local\Temp\
line.separator =

java.vm.specification.vendor = Oracle Corporation
user.variant =
os.name = Windows 7
sun.jnu.encoding = Cp1252
java.library.path = C:\Program Files (x86)\Java\jre7\bin;C:\windows\Sun\Java\bin;C:\windows\system32;C:\windows;C:\oracle\product\11.2.0\client_1\bin;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Lenov
o\Fingerprint Manager Pro\;C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;C:\oracle\product\11.2.0\client_1\bin;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Lenovo\Fingerprint
Manager Pro\;C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files (x86)\Java\jre7\bin;C:\Program Files (x86)\PuTTY;C:\Users\foobar\Downloads\sqldeveloper\jdk\bin;.
java.specification.name = Java Platform API Specification
java.class.version = 51.0
sun.management.compiler = HotSpot Client Compiler
os.version = 6.1
user.home = C:\Users\foobar
user.timezone =
java.awt.printerjob = sun.awt.windows.WPrinterJob
file.encoding = Cp1252
java.specification.version = 1.7
user.name = foobar
java.class.path = .
java.vm.specification.version = 1.7
sun.arch.data.model = 32
java.home = C:\Program Files (x86)\Java\jre7
sun.java.command = JavaArch
java.specification.vendor = Oracle Corporation
user.language = en
user.language.format = pt
awt.toolkit = sun.awt.windows.WToolkit
java.vm.info = mixed mode, sharing
java.version = 1.7.0_71
java.ext.dirs = C:\Program Files (x86)\Java\jre7\lib\ext;C:\windows\Sun\Java\lib\ext
sun.boot.class.path = C:\Program Files (x86)\Java\jre7\lib\resources.jar;C:\Program Files (x86)\Java\jre7\lib\rt.jar;C:\Program Files (x86)\Java\jre7\lib\sunrsasign.jar;C:\Program Files (x86)\Java\jre7\lib\jsse.jar;C:\Program Files (x86)\Java\jre7\lib\jce.jar;C:\Program Files (x86)\Java\jre7\lib\charsets.jar;C:\Program Files (x86)\Java\jre7\lib\jfr.jar;C:\Program Files (x86)\Java\jre7\classes
java.vendor = Oracle Corporation
file.separator = \
java.vendor.url.bug = http://bugreport.sun.com/bugreport/
sun.cpu.endian = little
sun.io.unicode.encoding = UnicodeLittle
sun.desktop = windows
sun.cpu.isalist = pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86

And the updated code to retrieve that:

import java.util.*;

public class JavaArch {

    public static void main(String[] args) {
   
        Properties props = System.getProperties();
        Enumeration names = props.propertyNames();
       
        while (names.hasMoreElements()) {
       
            String current = names.nextElement().toString();
       
            System.out.println(current + " = " + System.getProperty(current));
       
        }
   
    }

}