Posts by Don Casey 53 publicly visible posts • joined 1 Jan 2008
A couple years back I took a farm tour of the Rogue Creamery plant. The cows, when they feel the need, queue up and walk into a booth where machinery milks them... no humans involved. Lasers detect where the apparatus needs to attach, and a camera records the QR code on the ear tag so they know which cows got milked, and what their production was.
If this can be done with cows, SURELY they can devise a machine to auto-charge an EV taxi with a direct attachment?
One could argue that, in the mainframe world, IBM's CICS is a predecessor to this approach. It allowed/required application code to make all 'system' calls to the container (CICS), not the underlying operating system. Mainframe architecture forced this approach, so that CICS could maintain control of the processor and internally dispatch the multitude of threads it was managing. This meant replicating Opsys functions such as memory management, timers, file access, and task dispatching. It was only when there was no internal work ready to run that CICS (and IDMS) would issue a 'wait' and free up the TCB/thread/processor.
CICS is not a database, it is a teleprocessing monitor of course, but Cullinet's/CA's/Broadcom's IDMS-DC is both a TP monitor AND a DBMS. IDMS-DC is architecturally similar to CICS, with the addition of the DB component to the mix. The system definitions for both the DB side and the DC portions are stored in a database (called the 'Dictionary', but no different in form than a user database). CICS has been around over 50 years (longer than Ingres), IDMS-DC more than 40 (but commercialized in bulk to the existing IDMS-DB user base while Ingres was still a pup).
Both CICS and IDMS-DC provide 'system calls' for memory management, file access, etc. Those calls are generally processed internal to the container, using a pool of resources obtained from the operating system.
One could contemplate an approach where the 'few' operating system functions and batch processes these systems need being folded into the DB itself.
May be nothing, but I went into Google maps and looked around that area (being a SF Bay Area denizen and SF Native-born I got curious)... two things about that location:
1) Waymo has a major depot (Waymo Toland Depot) at 201 Toland.
2) A little way down Toland, where it intersects Toland Place (at 700 Toland) is a building that houses, at least in part, "Ace Dog Sports", a facility that appears to provide agility training.
So sure, some random mutt from a homeless encampment, not some expensive nob's little Jack Russell who bolted after their session in the gym.
(Getting more and more cynical the older I get and the more time I spend on social media).
As a retired big shop guy, with a focus on things like D/R and database, I worry that unless your role in IT is data-focused you are insufficiently paranoid when it comes to making changes that impact data.
Losing data can be an extinction event for a company.
That's why ransomware is so effective.
That is why I once had to let an insufficiently paranoid DBA go.
How is this in any way different from how IBM has been marketing their mainframes for the past several decades?
The "chip" (size of a DVD case) can scale from a handful to dozens (if not hundreds) of processors.
It is cheaper for IBM to make identical chips, and allow people can pay for whatever power they need. This allows small organizations to buy only what they need, instead of IBM having to price to the median.
If you need more power, a mainframe box can scale quickly and massively through 'just' a simple software key download (all it takes is $$$$$$).
No; never worked FOR IBM, but spent the last 10 years of my career managing the mainframe capacity and upgrade cycles of a company with four large-ish mainframes.
Patches to assembler-generated code were typically done in machine language.
On rare occasions I would 'patch' on the fly a COBOL program with a bug after it had run for a couple hours then failed. After figuring out a patch, I would restart from the last checkpoint, set 'stop on address' switches on the 360/40, then set data and address switches to push the patch into memory, hit the "STORE" button, and pray. Actually worked more than once.
This would normally take place at 2am, after I was woken by Ops when my weekly Hospital Billing program failed. It had to complete in order for the next daily to run.
Good times.
My first IT job was with a county government that had 360-series gear; initially a 360-40 and 360-30, then the 40 got upgraded to a 360-50 (by the time I 'graduated' from programmer to PFY systems programmer).
Our single most time-critical application was the election tally system... if things ran slow we had the media (bad) and the politicians (fatal) all over us. The weak spot in the chain was the 1052 console, coupled with the fact that the application was 'console chatty' (for no good reason).
We lived in constant fear the app traffic to the 1052 would overrun the console buffer and crash DOS (sic!).
This was mid-1970s. By the time I left in the late 1970s (as BOFH) we'd migrated to a 370-155 running OS/MVT with a partition or two running the DOS emulator. All this in 384K of memory, as this was pre-virtual (needed a 370-158 or better).
Good times.
DownDetector shows a double spike for Comcast, 10pm and 6am.
It also shows similar spikes for T-Mobile, Verizon, AT&T, and other single-spikes for other carriers that match one or the other of the two Comcast spikes (e.g. Frontier shows the 10pm spike).
Feels like either Comcast infected large numbers of providers, and/or a major backbone/routing issue.
Early in my career as a field support type with an unnamed (mainframe) database vendor (not IBM), I was called to an organization that couldn't get their backups to restore. Seems they were taking month-end financial backups, and then at end-of-year restoring in order to run year-end reports.
After some poking around and detective work I discovered there was a disconnect between our backup software and the (DOS) tape management software (EPAT) they were using. The result of that disconnect is instead of writing database blocks to tape, it was writing unused buffers to tape.
I sadly told them there was no way to get that data back. I left quickly (and silently).
Had they ever tried a restore, they would have seen this in time to fix things.
BTW; 'fault' was in EPAT making assumptions on where data is being written from is the same location as where the DTF was pointing at OPEN, our software was using (legal) facilities to change that, post-OPEN.
I don't know for sure what happened, but people below Newsom KNEW for days, maybe weeks, there were problems with the data, and they let him make public statements about how good the numbers were.
They deserved to be fired. You don't set your boss up like that. Never.
... as a struggling Computer Science major at The University of California (Berkeley): in one class we were tasked with writing a simple compiler (using SNOBOL) to spit out COMPASS (assembler code for the CDC 6x00-series) code for a set of statements.
I graduated, and passed the course (somehow), but never got the damn thing to work. After graduation moved into the commercial world and never saw Fortran, Algol, SNOBOL, or COMPASS ever again.
A year after I got my degree in Computer Science (1970), one Steve Wozniak enrolled. He later dropped out, and had a significantly larger impact on computing that I ever did... so much for the value of a degree. So yeah, BSD, and Cal arguably played a roll in the formative years of an Apple co-founder. Also INGRES, arguably the first complete implementation of a relational DBMS came from work by Cal professors M. Stonebraker and E. Wong. RISK and RAID have roots in Cal research. 7 ACM/Turing awards.
Yeah, although some of that would have to be downhill. The engine wasn't happy the last quarter mile. I think I did this maybe 2-3 times... but that was in the 70s and my memory ain't what it used to be. Truth be told, it was probably sucking a little gas sloshing around the tank during the first minute or so of 'fibrillation'.
... that SU fuel pump reference did. In my youth (we're talking 50 years past) I had a beloved AH 100-6, the BN6 two-seat variety. The fuel pump (electric) was located directly behind the driver's seat below the trunk. Once could actually feel it go into Atrial Fibrillation when the tank ran dry, giving you about 1/2 mile notice to find a gas (I'm on the wrong side of the pond) station or safe parking spot before the SU carbs ran completely dry.
Good times!
This is not a case where the number of corporate entities in an economic sector decreases, impacting competition (which is pretty much all the FTC cares about).
If two different grocery chains were to merge the FTC would rightly need to look deeply into it. Not sure that holds here, regardless of how you view Amazon. If anything, this could increase competition.
I used to think I knew something about Physics; I was even a Physics major into my Junior year. Having trouble piecing this together.
Universe is said to be around 13B years old.
This galaxy is 13B light-years away.
Universe is expanding.
So this galaxy and us have been separating at the speed of light since the Big Bang (see icon)? Yes/no?
The light we're seeing is 13B years old, where is this galaxy now? Another 13B years away (thus moving TWICE the speed of light)?
My head hurts.
Cloud vendors are interested in your business (the money you pay them), not your Business (what you do to have people pay you money).
They don't know your wants/needs/tolerance for outages, etc. etc. If commodity is all you need from IT, then fine.
If IT is mission critical to you (and that is an ever-expanding universe) then you have to think twice about giving up even indirect control over what happens to the infrastructure running your Business.
Outsourcing is one thing; you have a direct line of communication to people who should understand your Business and can react accordingly when making changes and when things go sideways.
Going to The Cloud completely removes you from the decision makers and actors, you have no control over the how and when and all you can do is hope your business is enough to keep them competent enough so they don't screw up your Business.
At the time, Cullinet (makers of IDMS, later absorbed into CA) was developing an integrated desktop application called Goldengate, which included Word/Excel/PPT equivalents (my memory is hazy on the latter).
On bit of this was the ability to upload/download mainframe database data from an IDMS facility known as the Information DataBase (some packaged IDMS facilities that provided a quasi-relational database).
Apple and Cullinet were in joint development, until Apple (as I hear it) pulled out of their side. Cullinet went on to develop the product for the PC side of things, where it pretty much underwhelmed, in spite of being arguably revolutionary.
I still have my square "Lisa/Cullinet: the Intelligent Link" button.
There is no "California University". There are two systems, the California State University system, including semi-independent campuses such as "California State University - Chico" (AKA "Chico State) and the University of California system, including campuses such as UC Berkeley (AKA "Cal"), UCLA, etc.
This appears to be the product of the UC, as opposed to the CSU system. There is NO CU system.
IDMS structure diagrams used to be referred to as "Bachman Diagrams". Problem was, Charlie didn't create the gory details of the structure diagram... each Record box on the diagram was subdivided into about a number of sub-boxes (Record name, location mode, Area name, etc). These were extensions to the classic E-R diagram; CulCorp even used to give away rubber stamps with the Record block so people could draw their diagrams (I still have mine).
On tech conference Charlie was invited as a guest, and my region had created t-shirts that featured a portion of a database diagram on the front.
Your zen moment: watching the head of West Coast Field Education explain to Charlie Bachman the "Bachman Diagram" on his tshirt.
Microsoft's problem is if they distribute an app with a GPL3 type license, then effectively they are cutting off their ability to sue anybody over any code found later to exist in that app.
They will, in effect, be granting to the world a license to use any code so distributed, whether they knew it or not.
Like if somebody included the Linux kernel in such an app.
oopsie
Aside from the photo, her image ITSELF is in many jurisdictions copyrighted; a photographer cannot use an image of a person for a commercial work unless there is a release, or the image falls into the "educational or editorial" category. Neither applies here.
Defendant most definately screwed (and should be).
Having spent a day on jury duty recently, I can confirm the rules are:
1) No talking about a trial while it is going on
2) After the verdict is delivered, fair game
Fortunately as a consulant who doesn't get paid if I'm not working, I didn't get picked for an actual trial so I'll just take my coat and head back to work.
I love photography, but shooting people is just too icky. First off, if you shoot a person or small group you really ought to ask, but I'm on the shy side. Secondly, if you intend to use the photo in some commercial setting, you need to ask for/negotiate/get a "model release". Too much hassle.
That said, the inclusion of people in photographs makes them that much more engaging to those who view photographs: people. Landscapes are pretty, but people draw you in.
I just don't want the aggravation that comes with 'candid' shots of people, so I live with shooting rocks, trees and buildings, and hope the local gendarmerie are looking for terrorists somewhere else.
Of course, you can get hassled for shooting somebodies building too, so really rocks are about all you have left that are at all safe.
sigh
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
