gabriel rosenkoetter on Fri, 16 May 2003 22:48:48 -0400


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] City Lawyer: We Don't Store Data on Hard Disk


You should probably know, Ed, that Barry designs truly large
(hundreds of millions of rows) Oracle databases for a living. He
also interfaces a formerly MVS OS/390, now Z/OS (in fact basically
the same thing with flashy new buzz words; cf, Digital [Open]Unix,
Tru64 Unix, or whatever else they've called that OS), mainframe with
Unix (as in, Solaris) and Linux systems for a living. So,
incidentally, do I, though I haven't been doing it nearly as long
(Barry's been doing it long enough to have been around when SCO
actually *sold* an operating system, and it was a good idea to use
it.)

His arguments, you'll note, are the same as the ones I gave you. And
not too different from the ones that William Magill (who *also* has
more than a bit of experience in this department) was giving you
initially. We are no better informed about the city's computer
systems than the folks with only a Linux/(free, as in beer) BSD
background who've been responding, but we've got a frame of
reference that allows us to make an actually educated guess on just
what's going on in the city's IT department.

On Thu, May 15, 2003 at 11:51:48PM -0400, Edmund Goppelt wrote:
> The City lawyer told a series of falsehoods that are obvious to anyone
> who knows anything about computers.  Do I feel stomped?  No. Do I feel
> angry that the City didn't even bother to concoct a halfway plausible
> lie?
> 
> Absolutely.

Their "lie" is very plausible to both Barry and me. We don't think
that they're telling the whole truth. We do think that there exists
work that they don't want to do, that it is, in fact, not totally
trivial, and that if they don't want to do it, you can be stuck
asking them to for *years* with no result. It won't get you
anywhere.

> Ok, so what do you think we should be concentrating on in Court?

You should forget about court, go web scrape the data, and go on
with getting something useful done. Litigation is not a functional
process here.

> Why assume? Information about the BRT's computer systems is a matter
> of public record.  The BRT is in the midst of a transition from a
> Mainframe/VSAM environment to Oracle.  According to public records,
> the BRT currently maintains its property file on both the mainframe as
> well as an Oracle 9i database with a web front end:
> 
> http://www.hallwatch.org/rtkasuits/suits/brt/brtweb

Who says their design actually meets that spec? Who says that all of
the data truly exists in the same place? More importantly WHO CARES?

They said, "No!". You accused them of not knowing how their system's
designed. They chose to be obstinate. They can be obstinate for an
indefinite period of time. If what you want is a petty lawsuit
against the city of Philadelphia, go to town, but whining about it
at PLUG and getting affidavit's isn't going to help much. If what
you want is for your web site to provide useful information, you've
GOT a way to get that information. Go get it, go on with your life.

> Were you aware that the City uses Linux?  Check out this photo taken at
> the BRT's offices at 34 S. 11th St.:
> 
> http://www.hallwatch.org/rtkasuits/suits/brt/cama/brt_closet_cama.jpg

So, they've got a text book hand-labeled Linux buried in a closet.
Are we to assume from that picture that they also still use Lotus
1-2-3?

What's more, how does Linux-use prove competence at *anything*? I
drive a VW Jetta. Does that make me qualified to work on its air
conditioning system, let alone rebuild its engine?

> 2. The BRT will currently provide any member of the public who can
> pony up $100 with a CD with their property file on it.  The file
> consists of 73 fields.  How much more work could including the two
> additional fields possibly be?

It means a change in their application. They're a beauracracy. That
means it takes even more time than it would for a corporation.

> If I lose the suit, I will "spider" the information.  But there is a
> larger issue here.  Is it reasonable to expect the City to be honest
> about what it can and cannot do with its computer systems? I think it
> is.

If that's what you want to get done, then you need to have someone
familiar with how their systems actually work (that is NOT someone
who's speculating; ALL of us on PLUG are speculating) on your side.
Nothing else is going to convince any court.

> delinquents.  He was able to ftp me the requested records from the
> mainframe the same day.  FWIW, the Revenue Dept. runs their real
> estate database on DB2 and Cobol.

So? The database design of the system you want information out of
could very easily be drastically different.

It sounds like the two "fields" you want are actually produced by
some applying some function to other data. I don't know how simple
that function may be, but neither do you. Either the data for them
is already there in the CD-R you can have burned, or it's not in the
DB in a static form. That's all, again, speculation.

> > Do you REALLY know the data is SQL accessible, or are you guessing?  
> See the contract.  It specifies Oracle 9i.

I believe you have misunderstood Barry's question. Neither he nor I
really care about the answer, though, so...

> Barry, thank you for your comments.  You may well be right about the
> disk being a side issue.  The important thing for me is that the City
> come clean about just how easy or hard it is for them to provide the
> public with copies of public records stored on their computers.

That's all well and good. But you've asked a political question of a
technical list, which is why you're getting responses like Barry's
and mine. To people like us, there's an obvious method to get what
we would want if we were in your position, which is the data. You
want to prove a point. I can't even conceive of caring enough about
proving petty city politicians wrong to go to the effort; it seems
vaguely reminiscent of pissing up a pole to me.

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgp87S0SvaKna.pgp
Description: PGP signature