Support newbie figured out how to avoid all-nighters, and his colleagues hated him for it ON CALL Welcome to another installment of On Call, The Register's Friday column in which we share readers' tales of tech support jobs that go south, pear-shaped, or just badly. This week, meet a reader we'll Regomize as "Lionel" who told us that in the 1990s he worked for an outfit that operated what he described as "big IBM …
I did an 18 month contract for Goldman Sachs back in 1999 and was given a pager in case they needed to reach me after hours. I was a software engineer on an hourly rate, not support staff, so I promptly removed the batteries and put it in the back of a drawer. How did I sleep? Very well, thank you.
The few times that happened, because there was nothing in it about being on call. I didn't mind getting contacted off hours for an emergency, but I wanted to have everything specified. I would insist on 2x rate for overnight/weekend calls with a two hour minimum.
I never asked for (but on one occasion received without asking) compensation simply for being "on call". I asked them what that meant and they said since I was refusing to carry a pager (because I already had a phone) to make sure I'm someone where my phone works and don't get too drunk, which they defined as being able to legally drive. For being paid 1/4 of my normal rate for the ~120 hours I wasn't already working during the several weeks when their team lead was away I was fine skipping the binge drinking lol
I was working on a contract, living about 90 minutes away from the office (and commuting daily!) with no remote access, so I didn't really want to be on the call-out rota. One week there was nobody else available, so I reluctantly agreed to do it for just that week.
On the way back home, I had the radio on, knowing that I would recognise the beep of the pager. I heard nothing.
Next day, my name was mud. 20 minutes after I left, someone paged me to get me back before I had gone too far. Looking at the pager, it had gone off, but I hadn't heard it. Thinking the pager might be faulty, we had it paged. Imagine my surprise when instead of the recognisable, and difficult to ignore beeping, we got a tune played by the pager! Turns out that the previous person with the pager had changed the alert from the default to the tune, which had disappeared into the music playing on the radio. I was still blamed, but some of the fault was deflected to the person changing the alert.
Management added an instruction to the standby procedures for the person taking the pager to do a test page to check the audible alert, and also that the pager was working. Fortunately, I was never put on the rota again at this contract, and I had a mobile phone for all the roles afterwards, not that I did much standby.
Had a mate who was on call who mislaid his pager. He kept sending paging requests while his wife searched the house listening for the beeps.
He then received a call from the garage that had been servicing his car... "We've ripped out half the dash looking for the source of an intermittent beeping"
I once worked for a company that received overnight orders from multiple large customers directly to each of the distribution hubs.
Each hub employed people to go through the orders to check for corruptions of varying types, and throw out junk data (not having a shelf full of Sellotape if that order line was corrupt was not going to cause the end of the world and the customer would just reorder the next day.)
I wrote a little Paradox program that did this for them, we inserted it into the parallel test system and monitored the output against the human filtering for a month. Not only was it much faster (a couple of minutes opposed to about 4 hours for the humans), but also more accurate. (For instance, the humans tended to delete blocks of corrupt data, whereas the program would extract all good lines within a block.)
When the program was moved to the live system, most people whose jobs had gone were moved to other tasks, but I do know that some of the older staff took redundancy now their cushy job was gone.
Ah yes, Paradox. I did one of these efficiency jobs as well, but in this case I save management time so no people had to leave.
I basically replaced two weeks of stock data entry with a 15 minutes batch job; the longest part taken up by a Kermit client that had to suck data through a 1200 bd straw. Not only quicker, also substantially more accurate..
You hit the nail on the head there - I HAVE used 2G for email (required a special data cable from Nokia for it), and I have used anything from 300 baud upwards to send email (although briefly, I imported a 1200 baud modem the moment they came out) and it worked. Mainly because we used text, and kept signatures simple instead of the crud you see today where especially lawyers demand disclaimers the length of War and Peace attached, with.Marketing then adding non-optimised graphics because, well, it's Marketing. Enough said.
Some people associate email with the Internet but it's been around a heck of a lot longer - some old docs of software I wrote in those days list my FidoNet BBS address :)
Last century I worked for a large company where all of the developers had to spend time on the Helldesk (usually on the night shift when the company was busiest), which I thought was a good idea, as the standard of coding measurably increased when this was introduced!
I, unfortunately, was in the full-time support team and would regularly get a pager call to perform more in-depth support.
Then the company decided to move over to using mobile phones rather than the pagers.
I told the managers that there was no mobile signal where I lived (on paper and I kept a copy for CYA). They still went ahead with the introduction of the mobiles and removal of the pagers. And I continued to accept an "on call" supplement and had a good nights sleep.
The opposite for me, when on call one of the developers was also on standby to deal with anything deeper that normal errors. He BEGGED us to call him because he wanted that money.
When we didn't need him he tried inserting little deliberate errors into batches, which we easily spotted and corrected ourselves. He did actually get quite angry about it.
&\or put in some Start-Sleep -Seconds* to match the time it should take to do it if individual task processing time is being monitored (Not paper hours claimed) & don't claim bragging rights over efficiencies**.
*Or nearest equivalent command.
**Learned the hard way that it leads to downsizing.
I worked for a company on a team of 6 and joined the weekly on call rota except we had one pager we to hand on each Monday morning, But for some reason, the on call period started Saturday night for 7 nights….so e.g. a weekend away was impossible for two people as this weekend was disrupted, plus the person with the lager would get paged on Sunday when they were no longer on call.
My first week, I asked ‘why are doing this? Why isn’t on-call running from Monday morning?’
The murmuring did not include any valid reasons why. We changed the following week.
This post has been deleted by its author
It's a bit like the woman who used to cut the ends off sausages before cooking them.
She was preparing them for a meal one day whilst talking to a friend who asked her why she cut the ends off.
She replied "Isn't that what you're supposed to do? My mum always cut them off".
She got back to her friend some days later to say she had asked her mum about it - "Oh, they didn't fit in the pan otherwise".
My other half spent her first year at college in Sheffield sharing a place with a girl who had had a somewhat sheltered upbringing.
She was observed, whilst cooking bacon under the eye-level grille, pulling the grille out every few minutes & snipping at the bacon before sliding it back under the heat.
"On the instructions it clearly says "snip at intervals"
“Then you, like me, have never read them.”
Instant coffee has instructions too,
They may surprise you.
They state hot not boiling water.
Hands up if you’ve been burning your instant coffee?
Now hang your head in shame, not for burning it, for drinking it.
When you get your bacon from a pork butchers there are no instructions.
I cannot comment on bacon purchased from supermarkets etc as I go the good quality option of a decent butcher (or sometimes buy bacon & sausage direct from the local pig farmer down the road!)
I genuinely don't understand what this bacon instruction "snip at intervals" is actually supposed to mean. Could someone help me out?
(Surely, for cooking bacon, it's basically: take out of pack, place on grill, turn over occasionally. When ready, eat. ?)
I think it means to cut it before you cook it so it won't curl as much in the pan. I tend to cut my sausages and hotdog like foods with little slashes down the sides, across the length, so that they don't explode and also don't curl as much from cooking on one side or the other.
Icon for obvious cooking!
I believe it might be 'rind on' bacon that needs to be snipped. The bacon will shrink whilst cooking but the rind tends not to. So the bacon will curl up due to this. Cutting the rind at intervals prevents this.
The bacon I buy is rindless, so doesn't really have this problem.
The gammon rashers that I buy do have the rind on, and do need to be snipped to avoid some serious curling.
If the bacon isn't mindless the rind shrinks faster than the bacon pulling it into contorted shapes. Either trim off the rind or cut through it every inch or so, so the bacon stays more or less flat.
And don't flip it over either, even thick bacon will grill quite happily straight through from one side. Flipping it pours away all the juices that collect on the top surface, so you can cook it for either moist bacon or crispy fat. You can have both cooking from one side.
I once had a job running a kitchen with a lovely girl who wasn't the sharpest spoon. She insisted on keeping a small piece of uncooked beef on a cling-film covered saucer in the bottom of the fridge at all times, because her food-hygiene training materials had included a line about 'raw meat must always be kept on the lowest shelf in the fridge'.
This post has been deleted by its author
This post has been deleted by its author
It would be fine if the companies used the savings to reward the fixers. But far more often than not they just pocket the savings as dividends or management bonuses. So no real incentive for the plebs to fix stuff, especially if it ends up losing then money through lost on-call or overtime.
One of the things I did on more than one contract was to fix an IT organization's ticketing issues - I'd look at the top 10 ticket types and do deep dives to fix the root of the problem or fix monitoring to stop generating spurious tickets. (I"d do other stuff like smoothing the workflow for stuff like system build/retirement workflows but that's not important here) At the first client I did this I got about an 85% reduction in ticket count in six months.
I heard anecdotally from the service desk manager (who was very very happy with that outcome and said it would have a yearly payback of 10x what they paid me - this was a BIG company with a huge service desk) that some of her level 1 staffers were very unhappy about this, because they had basically gamed the system by grabbing some of the tickets I'd made go away. The "problem" could be fixed in a minute or two, so they'd easily hit their quotas. Now there were too few tickets and they'd take longer to work so they couldn't max out their bonus every month. Some of them even quit over what they saw as a "pay cut", but I doubt she was sad to lose them since she needed to cut staff thanks to the reduced ticket count anyway.
I've probably related this before but we had various period end procedures which the IT department carried out remotely on a Sunday morning (we worked 4-4-5 week periods). They'd been doing this well before I arrived when we had a full time operator who generally did the work. It wasn't terribly onerous, probably 30 minutes actual work over around a 4 hour period, but it did mean you had to be connected so couldn't just go out for the day*. Whoever did the work, which later was myself or my boss, would get an afternoon off in lieu, everyone was happy.
Then the big boss decided that we couldn't have the afternoon off in lieu, effectively meaning we'd be working in our own time. At that point I automated the few actual IT parts of the process and we handed the rest over to finance telling them it was now their problem! They weren't happy as they'd now got a few more hours work to do over the weekend but they couldn't do much about it.
*I did once run the month end sat outside my tent at a waterways rally, laptop connected to the phone via IrDA, with a beer in hand as we were both away that weekend. I still took the time off in lieu.
Some data entering our "data Warehouse" * comes in via delimited text files or spreadsheets dropped off by users into folders to be picked up by an SSIS processes , these are the most likely to have bad data , not just in the content of the data but even the layout of said files .
So I created an internal web app , now they post these files in there and it audits the file against a template , checks as much as is possible and tells them when they have missed a column off , or a date is not acceptable, or whatever. Covers all the user submitted submissions and saves us a lot of digging to find why an SSIS process has failed again .
as a bonus it kicks of the relevant SSIS process right then , rather than waiting for next scheduled check of the drop folder .
.
.
* outdated term I know , theres Data Lakes now , and Beach-houses , and motor launches and whatever else some buzzword merchant wants to stretch the metaphor to.
Good call, I guess I could do a search and replace to clean up that kind of bad data, now how do you feel about a comma at the end of a series before the "and" ?
A) "Tom, Dick, jane and Harry went to the park"
or
B) "Tom, Dick, jane, and Harry went to the park"
I've always believed A was correct and did that but now I'm starting to go with B because it just feels more .. readable .
And I believe in some places it *is* acceptable - probly 'Murica where grammar goes to die.
It's (B) called the Oxford comma, and is a subject of much international & transoceanic debate. This former Yank is all for it, but obviously, given the name (and the assumption it's so-called after the Oxford (rather than some little village in America named after it), which is indeed the case, more directly named for the Oxford University Press, whose editorial style insists on it), you can't blame this one on the Americans.
there was even a lawsuit over it. I don't recall the exact details but it boiled down to "<condition 1>, <condition2>, <condition 3 or condition 4>" . the gist being there were only really 3 conditions, not 4.
in the Tom, Dick, Jane and Harry example given above it could be argued that there were 3 people not 4. Tom, Dick, and 1 named "Jane and Harry".
hmmmm, google says.......... https://www.ohiobar.org/member-tools-benefits/practice-resources/practice-library-search/practice-library/2018-ohio-lawyer/the-case-of-the-missing-comma/
see what a missing comma will get you?
"and" negates the comma, shouldn't be used more than once in a listing and should be before the last subject listed lest it changes the meaning (separates them in two groups)
A) "Tom, Dick, jane and Harry went to the park" - Correct
B) "Tom, Dick, jane, and Harry went to the park" - Incorrect
C) "Tom and Dick and jane and Harry went to the park" - Incorrect
D) "Tom and Dick, jane, and Harry went to the park" - Correct, but changes the meaning.
I've already told this, but it's eerily similar (to a point) to this tale. During the Y2K project I was in, my team was correcting a COBOL application consisting of almost 100 programs chained together and we were made aware that that particular batch chain would break every single night, meaning an hefty on-call bill. And that it had been going like that for years.
So, I analysed the failure point and it was seemingly simple to correct. IIRC there were numeric conversions that would fail under certain conditions, conditions that would almost certainly be met once or twice per run.
That correction was deemed out-of-scope by our client rep, who, curiously, was also that application's IT boss.
Years ago I worked for a company that had 30+ IBM mainframe sites, each with its own local support teams, of which mine was one. After various restructurings we all ended up u der the same national manglement who decided to report on call-up and on-site call-outs.
Of course they focused on the wrong things, and bigger numbers are better. Then they started rewarding those with the highest calls, and giving them monetary pats on the back for getting called out for the simplest of changes.
With predictable results. One guy became a national hero because he got called every single weekend. This didn't go down well with me or my team as we had almost a 100% faultless record.
It took quite a bit of moaning that they were measuring and rewarding the wrong thing, errors not succes, but ultimately the hero himself provided the evidence when he quite obviously and deliberately messed up an incredibly simple change. A change nobody else messed up.
He didn't last long after that.
At one time in the not-so-distant past I was involved in the maintenance of some applications used to generate user-facing information from the raw data produced by an Earth Observation satellite. During one meeting, the customer's representative mentioned that one of the applications had failed about 50 times over the last three years (it is typically run daily) with the same error code; the previous company that had maintained the software had declared that they could not find the problem. After the meeting I went into the source code, and about 5 minutes later isolated it to one function - the only one that generated that error code. Unfortunately, the error code was generated for two entirely different reasons which we could not distinguish without further diagnostic log information, although I had a side=bet as to what the fault would actually turn out to be (basically, out of memory).
At college, I had a job as a babysitter for a computer lab. When the manager was doing the rotation, he told us that there would be a rotation for weekends and nights. If you scheduled yourself for a night or a weekend, you would be off of those rotations. When it got to be my turn for the first round of scheduling, I asked for "Sunday night." The manager paused for a moment, said "well played," and went on.
When the rotation schedule was set up, one of the other team members asked why I wasn't on any of the rotation. The manager explained that I had taken both a night and a weekend. One of the other team members muttered, "You bastard." I couldn't help but grin.
Back in the 19980-1990s - more specifically at some point between 1986 and 1998 - Computer Weekly ran a very similar story to this on the back page of one edition of their magazine.
The story as printed concerned a bit of hardware - pretty sure it was a laser printer - that had a habit of failing "every now and then", as a result of which a sheet or two of paper would get jammed up in the works and the operator would call a technician from a central IT Team over to fix it.
This particular operator, however, was single, female and stunning, so the attendant engineer clearly didn't mind having to make repeat visits...
Except that in the case of this particular tekkie, things unraveled when they took a vacation. The central IT Team were a bit stretched, so they hired in an engineer from one of their main suppliers to act as a "backup"... and it was this individual who attended the failing laser printer. They spotted the fault - an internal part had been "over-adjusted" and would fail on a particular type of heavier paper, used one day a week for specific correspondence - and made an adjustment that resulted in a permanent fix.
They also reported what they'd found to management...
As the anecdote was told via the back page of CW, the engineer who had done nothing but remove the jammed paper without fixing the actual problem was reassigned, and the guest engineer ended up dating the very attractive user of the printer.
As it happened, we had 4-5 different hardware engineers from a couple of companies that looked after our kit at that time, one of whom was very much a "ladies man" ... so we photocopy/enlarged the article and pinned on the notice board by his desk. He took it down - of course - but that's what photocopiers were made for... and because as we told him, he was "one of the team", we made sure that a fresh copy of the article was waiting for him every time he came on site.
This made me laugh. I worked for a government civil aviation department and I fixed an issue with a X25 network link interface to international data trunk lines for an ATC system, French I told them they should have bought British or US . I was a systems administrator on it, ran Unix and tripple redundancy for core processing and storage systems however I raised the concern that comms links weren't at the network interface and a failure meant loss off comms and an alternate secondary link on a totally different network address application level comms interrupted, handled once the system had seen a failure and systems such as flight planning loosing inputs for a time. Totally unacceptable for ATC. So an engineer would be called out, one of my former techs at 12,1,2,4am, usually when busy and noticed out of hours. I knew the fix simply entailed hitting reset on link card in our ops equipment room. They'd get a call-out charge, good money. I was concerned with the regulatory requirements and meetings international ICAO standards and why I was there. I looked at software that controlled the comms boards, network link drivers, one for each of links were local and a few international. It's not a good look seeing our comms down too and they could flag it with ICAO. It's safety more than anything. Lives, women, kids, babies, oldies, men, women, students, us basically. I wrote a program to monitor all the network drivers and reset the the failed ones automatically. It ran 24/7 every any failure was addressed immediately, a Unix system demon process which has above admin and seen as part of the operating system. I got told off for it and told to take it down by head technician and union rep. What are you trying to do, taking money, food off the table of working families! I said we'll still need callouts but not on that. And we did. I said I'd take it down but didn't as I didn't answer to him. He must have known after all our links remained connected with no callouts. We had other failures that required a higher level of expertise which I'd trained them up for so everyone's happy.
