toll roads vs. surface roads; car vs. scooter; work vs. not

Just got ticketed for speeding. Sunday, 11:59am, beautiful day at the beginning of springtime. On my way to the office, of course. Been taking surface roads recently to save $1.25 in pike tolls, using some extra gas but not $1.25 worth. This little event, however, obliterates a lower-bound of 160 decisions not to take the pike. That’s without counting the extra gas to take surface roads, or how this will affect my insurance.

I almost always take the pike home, so that’s 160 days. At 5 days a week, that’s 32 weeks. At 6 days a week, it’s still just over half a year assuming zero vacation.

On a scooter:
I wouldn’t be speeding,
I’d be using about a quarter as much gas, and
I’d be paying zero insurance.

Pretty compelling until winter rolls around in a few months, for a few months.

Workaholism vs. not:
Work certainly contributed to my being on the way to the freakin’ office this morning. I’m pretty sure that related stress also contributed to my tendency to drive faster. It might even have a bit to do with buying a torquey car, but I didn’t need much help there. But even including the rising cost of gas (both in ++$/gal and –mpg), the rising cost of (my) insurance, and the cost of this ticket, I’m definitely coming out ahead.

Conclusion: I should keep working like a sonofabitch, but I should get an EZPass transponder and take the pike to work.

RIM is about to get pwn3d. Whether they merely get partially pwn3d or wholly pwn3d is somewhat up to them. Apple’s smartphone market share is 28% and rising, but their share of mobile browser hits is more like 75%. Predictions:

• in the next 18 months, Apple’s device share numbers will climb to 45%, and no other platform will seriously compete with either iPhone or Blackberry
• that trend will accelerate noticeably when the 3G iPhone is released
• if RIM (or someone) develops a BB browser that seriously competes with mobile safari within that time frame, they have a shot to strong-stalemate and retain like 40% of the market…
• …else they’re like totally bwned. If their ego can stomach it, they’ll become a niche company specializing in camera-less devices with strong crypto support for the government market or something.

If I were a major RIM shareholder, I might actually be holed up in my bathroom puking my guts out right now.

I was away over the past couple days, failing to get a pre-release (alpha-ish) version of a custom app installed in a customer’s mainframe test environment. The following note represents the most valuable results of around 16 hours of direct professional effort, during which I developed a sore jaw from chewing gum, and our business partner spent about ten grand:

\redacted\-

The following is an overview of the SSL problem, which should provide IBM with enough insight to ‘hit the ground running’ to bring it to resolution.

- - - - - -

We’re trying to initiate a mutually-authenticated SSL session from a z/OS client program to a remote Linux server.

The z/OS system has the client-side certificate / private key ADD’d to the RACF certificate store, as well as the CERTAUTH certificate that was implicitly ADD’ed with auto-generated label ‘LABEL\redecated\’.

In our gsk trace, IRRSDL00 throws an SAF 8, RC 8, REASON 84 error. According to the RACF callable services reference, that indicates:

“The key ring profile for RACF_user_ID/Ring_name or z/OS PKCS #11 token is not found, or the virtual key ring user ID does not exist.”

We’re not trying to use a virtual key ring. We’re trying to explicitly target the keyring and label with the userid/ring-name string and label names in our gsk_* calls to setup and subsequently apply the gsk_environment to the socket we open.

There are two key rings, one for each user we’ve tested with, each of which is CONNECT’ed to BOTH:
1. the client certificate (PERSONAL use)
2. the CERTAUTH root relevant to the client cert

So in each of our tests, the job owner has owned the target key ring. In half of our tests, the job owner does not own the client certificate itself, but in those cases the job owner has UPDATE authority to the LISTRING resource in the FACILITY class.

When we RACLIST all of the profiles that match DIGTRING, we clearly see profiles that appear to map onto the key rings for each user.

For most of the tests, we did NOT have a generic IRR.DIGTCERT.* resource profile, but did have specific ADD, ADDRING, and LISTRING resources defined. When we debugged to the point of discovering IRRSDL00, we found doc indicating that we should define a generic resource, and we did so. We then permitted one of our test users READ authority on the DIGTRING.* generic resource profile, and did a setropts refresh.

There was no change in our program output or the gskssl trace.

Ta daaaaaaa! *takes bow*