* Posts by Baroda

6 posts • joined 3 Jun 2019

Lies, damn lies, and KPIs: Let's not fix the formula until we have someone else to blame

Baroda

Re: KPIs

(IMHO) here follows a wonderful quote: I hope I have it down accurately. It repays careful reading.

'When the right thing can only be measured poorly, it tends to cause the wrong thing to be measured only because it can be measured well. And it is so often much worse to have good measurement of the wrong thing - especially when, as so often is the case, the wrong thing will IN FACT be used as an indicator of the right thing - than to have poor measurements of the right thing.'

Tukey, J.W. (1979) methodology and the statistician's responsibility for both accuracy and relevance, Journal of American Statistical Association, 1974, No. 368, pp 786-793

Calling all the Visual Basic snitches: Keep quiet about it and so will he...

Baroda

When a manager wants something, he doesn't care about the rules, he just wants the result.

Or when IT wants something...

Many years ago, I was in a project to consolidate a number of systems onto a much smaller number of servers and deploy them to production.

I was working alongside two fellow greybeards who really knew their stuff, (and to whom I am very grateful for their advice and help on an OS of which I had far less knowledge).

FWIW, the multiple builds in production included some for which we simply had no test/dev systems so we had to build them and get them working in place.

Of course, *much* data had to be transferred between the firewalled test/dev and production networks - and we were given a DAT based system to do it by the client.

So it was tedious and introduced a lot of delay. We were very clear the project deadline (tight as per usual) was unachievable but shrugged our shoulders and just got on with it.

Until greybeard1 found by accident that he could ssh from a single test/dev server to the live system(!)

... and in the twinkling of an eye had installed a software distribution server.

... and had organised the addition of a LOT of disk to the server for the distributions and database backups etc etc

... and then told us.

Needless to say, our portion of the project's deadlines were met...

I wonder if that hole in the network is still there?

COBOL: Five little letters that if put on a CV would ensure stable income for many a greybeard coder

Baroda

Re: First language

'just for giggles'

Early in my career I was given a COBOL program to change.

The previous coder must have been very bored: Try understanding a program with PERFORM PING THROUGH PUNG varying PANG by PENG etc etc. All the program's variables were similar gibberish so I had to do an awful lot of work to even get to the start line.

For other greybeards ... it was running on an ICL 1900A. just before the upgrade from GEORGE 2 to 3. All coding was on A4 landscape 80 column paper, sent for punching and being returned on reels of paper tape.

Job submission was in two steps.

First create the GEORGE code to submit and run the program on an electronic paper-tape punching machine. There was an electronic keyboard at which you typed and out came the punched tape like a ticker-tape.

Supplemental step 1(a) was then (all too often in my case) hand-editing spliced portions of the tape to correct mis-types. This was done by laying the tape with the blank spliced-in portion on a channel (very similar I suspect to hand-editing film). Then you folded down a short piece of perspex (plexiglass) with an array of holes over the tape. If my dubious memory serves me correctly, the holes were 8 across the tape - 7 for the character and one parity hole, even or odd - I forget which. You checked the chart on the wall above the machine and using a small rod in a handle called a 'dibber' you poked it through the perspex row by row making the characters one by one. Negating a character simply involved making a row across the tape of all holes.

Finally the finished tape was wound around a cardboard ring, fixed with a rubber band and then attached to a 'run sheet' for ops to load the correct tapes and program and run the program.

Some time later we used a teletype to submit our own jobs and even make alterations in place to memory before after loading a program but before running them (e.g. initialising an unitiailised variable).

Oh joy, oh bliss!!

I don't know but it's been said, Amphenol plugs are made with lead

Baroda

Re: "The router went dark"

' to make the result of a lab experiment match the required result.'

<sigh> I remember rubbing out the actual values I had measured and fudging them in my pencil-on-graph paper curve to make the experimental results fit the chemistry book 'S' curve. As had legions of children before and since no doubt.

The experiment was dropping zinc granules into HCl and graphing the release of hydrogen - starting slowly, rapidly reaching a steady high rate then dropping off to zero as the Zinc was exhausted.

The slow-down I had measured and eliminated midway or higher on the steepest part of the graph was no more.

Many years later I heard of a truly scientific chemistry teacher observing this (probably having ignored it before) and carefully re-doing the experiment. The rate *did* slow then speed up.

It turns out that the hydrogen bubbles forming on the surface of the zinc and clinging by surface tension before floating off prevent the maximal access of the HCl to the surface as the reaction progresses. (My best understanding - if anyone can improve or correct this please do.)

Hat's off to that anonymous teacher.

Firm fat-fingered G Suite and deleted its data, so it escalated its support ticket to a lawsuit

Baroda

Re: If only...

'if only there was a company that could store it off site and return it to your business as needed'.

Around 15 years ago I went as part of a group to support a third-party customer who had hired a dedicated DR company.

The DR company's dedicated DR site was in another country in a site that was entirely surrounded by a grass-covered embankment - bomb proof(?). The 3rd party who used the DR company wanted to test the end-to-end process. They picked a nice simple NT server with a couple of DBs on it as the first step.

They allocated a whole weekend to this - did they know something we didn't?

On Saturday morning, the DR folk who *knew* we were coming did not have the required tapes ready.

They then took around two hours to find them.

They then realised after more hours of faffing about that they could not provide the contractually required server until late the same day. Despite having dozens and dozens of servers 'ready' on site.

Long before they found and allocated us one we had left in disgust.

On Sunday morning we returned and restored the NT server, recovered the DB's and completed local testing to our customer's satisfaction.

After a short booze-cruise by the driver, the boot fully stocked and the car's front wheels making occasional contact with the ground, we headed back to the UK.

The driver generously handed over some of his liquid stock to us passengers, so not an entirely wasted trip.

Planes, fails and automobiles: Overseas callout saved by gentle thrust of server CD tray

Baroda

Re: I've been doing it that way for decades!

While relocating software to newer homes and decommissioning dozens of aging HP servers, I came across two in the same rack where one had been unused for more than a year.

The other had still been used until the previous week. Both had uptimes of several years.

The unused one was still powered up as was it's external backup tape drive - with tape.

The other also had an external backup tape drive, with tape.

Both servers and tape drives were labelled.

Server 'A' was attached to the tape drive labelled 'B' and vice-versa.

As far as i know they had been that way since they had been installed.

I leave the implications of this as an exercise for the reader...

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER

Biting the hand that feeds IT © 1998–2019