SCOUG-Programming Mailing List Archives

Date:	Tue, 28 Oct 2008 16:43:41 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	Scoug Programming <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: A brief hiatus

Content Type: text/plain

We had a power failure last week. Not unusual here in Simi Valley. We
get them on average three or four times a year on particularly hot or
windy days. Good old OS/2 Warp 4 would take it in stride. Despite the
long recovery period of the disk drives it recovered completely...except
for this last time. Inexplicably something got lost.

It reflected itself during the IPL when it failed to connect over the
network to the internet. Trying to determine why proved a challenge.
Oddly enough it came down to JAVA which is used by TCPIP. JAVA tried to
help as it gave an abstract trace of the process to the failure in
tcpcfg2.cmd. Obviously something was missing in JAVA someplace that
wasn't missing before.

I did a reinstall of JAVA 1.1.8 plus an update, did a shutdown, and
re-ipled. It came up fine. Yeh. So I set it up to do an archive, did
a shutdown, and re-ipled, mind you without having done anything else.
It failed as it had earlier.

As I have a working Windows NT Professional machine I switched over to
it with outlook express so that I could continue with my email
processing. I had decided that I was going to have to understand JAVA
better and set up to do so. I got out my books. I installed the latest
version of VisualAge for Java (3.02) that I had though the MindQ DVD
with the tutotial would only work with my Windows machine.

Being somewhat suspicious of why my config.sys had three separate SET
CLASSPATH= statements, I combined them into one. As tcpcfg2.cmd had its
own SET CLASSPATH= statement which overrode that of config.sys for that
session I couldn't see a connection.

So with these changes I did a shutdown and re-ipl. It came up normally.
I immediately did another shutdown and re-ipl. It came up normally
again. At this point I again set the archive switch on, shutdown and
re-ipled. I write this from a now working system though I haven't a
clue why.

Now I haven't given up on pursuing our project beginning with an
understanding of FORTH. Like FORTH JAVA is an interpretive language
with supposedly the advantage of an object-oriented methodology. So is
REXX. So what's the problem. The lack of easy access to source. With
the JAVA I had a method failure, possibly even a class definition
failure though obviously both had to appear somewhere among the
installed JAVA on my machine as a "correct" environment indicates.

So what good is a error trace which lists the transfer points within
JAVA source down to the point of failure, if you do not have access to
the source? How do you know which of the .jar files contained either
the class or the method? I located a JAVA decompiler, JAD, which I want
to try to determine JAVA library file contents. It's written in C++.

It's been 10 years since Warpstock98 in Chicago and the Warpicity
proposal. Throughout that time I've had a solid OS/2. Thus when it
turns out less so as it did here I get out of sorts. I look at what I
have to deal with against what I have proposed. Multiple libraries
versus one. Multiple languages versus one. Multiple tools versus one.
Source only. A single data directory/repository versus none.

I will stick to the lesson plan while I have to deal from time to time
with problems with JAVA and TCPIP, with trying to find someway to live
with the incompatibilities with Seamonkey, Thunderbird and Firefox. Ah,
yes.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 28 | October | 2008 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.