COBRA Nonsense
I had to field 2 calls from a medical complex which apparently was checking my health insurance today and found it in expired status. Since I have an upcoming outpatient procedure scheduled in the near future, this left me in a squeeze between two bureaucracies, one that I had anticipated and tried to preempt but couldn't.A few weeks ago I, while still on my employee health insurance, had gone to a specialist clinic to deal with an unexpected issue that I first noticed during a normal health checkup. I got a preliminary diagnosis but had to wait a few weeks to see a prospective surgeon who would confirm the diagnosis. And of course, there would be weeks before he could schedule the repair. So basically in the interim I left my job for reasons beyond the scope of this post. This condition had developed during my last 2 years in my recent job, and in my view, should be covered by my/employer insurance. The employee insurance expired at the end of March (last week). This is definitely a preexisting condition under my employee coverage. But from a health insurance perspective, they are going to pretend that this condition occurred in the current month in which the surgery is being done, and I didn't have much control when the surgeon would meet me or schedule the procedure.
I had been in contact multiple times with my former employer's HR over the last 2 weeks pushing on getting CORBA setups done. (For unfamiliar readers, COBRA provides ongoing health insurance coverage after job separation for a limited period of time (up to 18 months); basically you have to pay the full rate (including any employer cost/contributions), which can amount up to $1K/month or more. CORBA is basically an invention of government policy which normally I would oppose except for other dysfunctional government policies, which basically regulated what kind of "insurance" you could purchase and linked it to employment. For most of my adult work career, I've enjoyed good health and rarely, if ever, saw a doctor. Was any money set aside by the insurance company to shore up reserves for my senior years when presumably my medical expenses would be more significant and my income declining with eventual retirement? Nope. What about involuntary layoffs when one might experience a gap of income and have to deal to unexpected medical expenses? The whole issue for me was to deal with catastrophic expenses, say like the relatively low risk of cancer. I wasn't worried so much with the occasional $100 doctor visit. Oddly enough, the cost of generic drugs from my mandatory home delivery costs triple what Walmart would charge.
When I spoke to HR, they assured me no issues with use of my insurance card during the CORBA period. But the paperwork is generated after employee insurance expired. But among other things, my CORBA administrator is back in the Stone Age, despite being owned by a name brand health insurance company., my actual insurer. I remember a decade ago being able to set up an online account and set up automatic payments. So they hadn't received my enrollment and first month's payment yet (none of this is discussed in the paperwork) (four days into the CORBA period!) God knows what happens with snail mail and maybe getting stuck in some clerk's inbox. And they tell the surgical staff that I don't have insurance, with the implicit threat of my upcoming procedure. So I'm being told they won't go a damn thing until they cash my first check. Do they have a procedure where I can wire the amount from my bank account? Of course not! No wonder our healthcare system is fucked up. Amazon sellers provide more modern service.
What this insane scenario means is if and when they get my first month's period, I'll still have been denied coverage until the time they cashed my check. All I've been told by the surgeon's staff is they'll check the status of my insurance daily in the interim. The impression I get is the procedure will be cancelled if they don't get verification soon enough.
So I'm talking to the COBRA people, telling them I need an accommodation. The best they can come up with that I do an overnight delivery of my election form with my check. Do you know what the USPS charges for overnight? $25. (The last time I checked it was more like $14-18.) That was ridiculous. I checked and they had a priority service that came with a tracking number for about a third the cost (but they don't guarantee 1 day service; up to 3 days: of course, first class mail is much cheaper with a similar time frame).
It's almost like dealing with the typical government Procrustes. They think the world should act by accommodating their own rules and regulations, convenience. In the real world you need to operate by the needs and preferences of the consumer. This situation puts me between the devil and the deep blue sea.
Dealing with Tech Support
I may cross-post this discussion in my Oracle blog.
I'm going to attempt to be as readable as possible in describing a couple of Oracle Tech Support scenarios. I'm sure almost every reader has their own past issues with tech support. Let me describe the typical Oracle Support scenario during the late 90's when most issues were still handled through calling an 800 number. (Oracle Support is not "free"; don't quote this percentage, but it's close enough: maybe around 22% of your license costs annually.) Oracle has a support portal, originally called Metalink, more recently My Oracle Support; this includes a knowledge base/search engine of notes, etc., on error conditions, best practices, and other material. . Oracle Support has access to a superset of KB called webiv, including information not available to Oracle customers.
Oracle trains a lot of inexperienced analysts just out of college. So they may take your issue symptoms, feed it to webiv, maybe pull up 40 or so hits, almost all totally irrelevant to your context. And they want to go through each link in order (and demand you provide evidence that the irrelevant citation doesn't hold); if you push back on any of that, they'll accuse you of having a bad attitude and threaten to close the TAR (technical assistance request)/SR (service request). So in the real world as a production DBA, I don't have the time or patience to deal with inexperienced analysts; what helped was escalating the issue to a senior analyst, I can think of at least a couple of dozen occasions where a senior analyst would resolve my issue literally within 5-10 minutes.
Oracle Support duty managers hate me with a passion because in their view, I was escalating issues too frequently (not true, but that's a judgment call). For the most part, I consider duty managers as not so bright self-important incarnations of the Peter Principle. Keep in mind none of these people ever directly interacted with me. But a couple of telling incidents; while my boss was out of the office, the switchboard forwarded a screaming duty manager to me, and this guy, clueless that he was talking to me, started lying about me in his rant. In a second example, while I was a senior principal (highest non-managerial rank) at Oracle Consulting, a hostile duty manager called my practice manager and promised to help recruit my replacement if he would fire me.
I think I've previously discussed my initial bad experience with Oracle Support I think around the summer of 1996 working as a subcontractor for a large credit card issuer in the St. Louis suburbs. The company probably had the worst setup for new people I've ever seen. I was assigned to a cubicle over the next several weeks where I didn't have access to voice mail or a network account, so basically I had to work at an open workstation out of sight from my cubicle. So, among other things, I wouldn't be able to hear or answer my cubicle phone--and even if there was a call that dropped to voice mail, I couldn't retrieve it.
So my boss, basically another contractor (different company) told me to call Oracle Support and not to settle for anything less than a response to a technical issue. (He headed the production DBA efforts (with OPS, a precursor to RAC, which involves multiple servers with access to the same database, effectively supporting nearly 100% uptime) while I maintained the (non-OPS) test database. The client had nearly 2 dozen "DBA's", being transitioned from mainframe roles, but basically contractors were doing the real work.
I called up Support and got connected to a Support analyst doing a form of computer triage; he determined that the issue I was trying to address didn't deserve same day service. The client had an expensive "Gold Service" maintenance agreement. I tried to argue the point, given my boss' instructions, but I got nowhere with this Oracle cog. In fact, he started ranting that I was violating Gold Support standards, and Oracle could decide to drop Gold Support for the client.
It didn't stop there. It turns out one of the mainframe DBA retreads served as the local Metalink administrator. So the analyst or his duty manager ends up calling up the client "DBA" and starts ranting over this rogue contractor and repeated the (empty) threat to revoke Gold Support coverage. Now client management (who really didn't know me) are pissed off at me; if my boss said anything to defend me, I didn't know about it.
The Oracle troublemaking bastards weren't done with me. As the reader may have guessed (given my explanation of voicemail access), if and when Oracle Support did call me back on the SR, it went to voicemail. Now the SOBs are going back the the client Metalink administrator and complaining that this rogue contractor is refusing to return their calls and they want to close the TAR. Do you think the client management takes responsibility for the fact after weeks, I still don't have voicemail access and fixes the problem? Of course not. It's easier to them to accept Oracle's complaints at face value. (As I recall, they let me go not that long after that. Luckily I had written into my contract that my employers would have to pay my moving expenses back to the Chicago area. The clients wouldn't agree for me to travel from Chicago.)
It would take me several book chapters to chronicle my issues over the years with Oracle Support. But I'll settle for a couple of recent examples that I think speak for themselves and illustrate the level of incompetence that I've had to deal with.
A few years back Oracle purchased Sun Microsystems; probably a good plurality of my first 15 years or so of professional DBA work dealt with Sun hardware and their signature Solaris (Unix) operating system, although I think their main motivation was to acquire rights to the very popular Java language.
One thing that Oracle did with their hardware acquisitions is develop the concept of a database appliance. Basically the Oracle database appliance (Oracle engineered systems) provided Oracle customers with a one-stop shop concept; instead of customers having to deal with vendors pointing at each other over technical issues, Oracle assumed that risk and provided comprehensive support and patching for everything from firmware to RAC database patching through ODA patching; unlike Oracle's quarterly security "Critical Patch Updates", ODA patches (including CPU), in my experience, were released at irregular intervals from 6 weeks to up to 5 months.
So my first example was an issue that affected my development ODA. One of the 2 clustered servers would not update. As I seem to recall, it was eventually resolved by replacing a configured parameter that affected ODA's that had undergone a prior bare metal reinstall (done by a predecessor in my role), But when I initially filed the SR, the Oracle Engineered Systems Support analyst denied the ODA bundle patch in question (it may have been 12.2.1.3.0) had been released, demanded to know where I got this unofficial (beta) software, and reminded me Oracle Support didn't support beta software. I got the usual presumptuous lecture (I think it's a script they all memorize) that I need to read ODA master note 888888.1; I knew 888888.1 better than any Support analyst I ever dealt with.
I have no idea how bad internal communications are at Oracle Engineered Systems, but I have no clue how Support engineers were unaware of a released patch. But 888888.1 noted around the transition from 12.1 to 12.2 ODA patching, that client DBA's should identify new versions from release note links on the OES help/home page. [Think that Oracle Engineering would send a new bundle patch alert to their customer distros like for CPU patching? No, that would make too much sense.] (Eventually 888888.1 would be updated to link to the latest patch.)
So I patiently tried to walk him through the publicly available release note link to the release notes and the hot link in the release notes to the platform patch download. But there was no reasoning with him; he was in a state of denial. I think I ended up having the SR reassigned. This was embarrassing for Oracle because you can't explain away that kind of incompetence.
The second example requires knowledge of an overview of ODA patching from the original OAKCLI (command line interface). There is an unpacking operation of the ODA patch from typically 3 zipfiles to local root-accessible directories. Then one basically does version updates of up to 3 components: system, storage, and database.
So there was no 12.2.1.5.0; we had to go from 12.2.1.4.0 to 18.3. This was a major change in ODA patching for my version ODA: we would be transitioning from OAKCLI to the DCS model with an ODACLI language during the system component upgrade. The documentation then outlines (supposedly) the process of using ODACLI to patch the storage and database components.
It turns out that there's a separate zipfile/"updating the repository" [unpacking] step for the database component. And the DOCUMENTATION STOPS THERE. (The last time I checked a few weeks back they still hadn't modified this.) Conceptually unpacking the software/updating the repository doesn't involve applying the patch. You know, is the emperor wearing clothes? On my own, I discovered the missing piece (a verb to update the database home) using a published OAKCLI/ODACLI cross-reference. I'm trying to explain to the Support analyst: "Dude, my RAC software hasn't been updated from the April to July CPU." I had already filled in the missing pieces. I thought they had a duty to fix the documentation so DBA's following me wouldn't have to resolve the issue on their own. As a documentation guru, I had no idea how they could leave their documentation incomplete during a one-time migration process. This is not rocket science; they simply were too incompetent to fix their own mistakes, even when a customer pointed out the problem and what to do to fix it.
