Diigo Links

Saturday, August 07, 2004

A detailed description of what I for a crust.
My grampa describes what he did in WWII as put up and maintain radio stations, from India into China. He says the radio equipmentwas designed so that if it stopped working, all the tech had to do was unplug a part and plug in a new one. You kept doing that untilthe transmitter started working again. That's very similar to what I do, but I do that in !cyberspace!

Small talk. I'm not good at it What do I do? It's a common question. Everybody seems to get asked this question now and again. I think some people enjoyanswering it. At most any social event this is one of the questions I fear the most because I know that me answering it can be deadly(for conversation).

My short answer is "IT" or "computers". This is a little inside joke I have with all the other "Knowledge workers" geeks) out there. Tosay "IT" or "computers" leaves things wide open. I might as well say "I work in an office." IT is a very broad set, in which I sit in a littlecorner with a keyboard and two screens.
The most common response is to my answer is: "Oh".

At this point - you're still reading, still curious as to what it is that I actually do. For real!? You either have a sincere interest, or just a blinding need to compare your lot with that of others -

I actually do software support for what might be called "middleware"

http://www.whatis.com/ defines middleware as: "In the computer industry, middleware is a general term for any programming that serves to "glue together" or mediate between twoseparate and usually already existing programs. A common application of middleware is to allow programs written for access to aparticular database to access other databases" Follow this link for a totally dull and unreadable report on middleware.
and http://www.dictionary.com/ defines it as: "Software that mediates between an application program and a network. It manages the interaction between disparate applicationsacross the heterogeneous computing platforms."

So, why is it important to know that our product is middleware?
a. if you're not a system administrator or network administrator, you might not have known that it exists
b. it helps to define who I work with (network/system administrators)

Our middleware deals with Output. It's an Output Management Software Suite. It "provides the leading output management solutions forthe reliable delivery of business-critical information throughout the enterprise and beyond." That's "reliable delivery of jobs (documents)to their destinations (printers, fax machines, file destinations, the web, etc) across operating systems (AIX,HP-UX, Solaris, Windows,NT) and to many different destination types (printers, fax machines, file destinations, the web, etc)" That's marketing-speak on what it does.
So, in regular English?

In regular English, lets say you have a huge network with ten thousand printers on it (this software is almost always sold to hugecompanies with huge networks - Like Ford, Nortel, etc.). Let's say you work in a warehouse far from headquarters, but still on thenetwork. Every morning a hundred shipping lists print off the printer and it's your job to take those lists, match them with orders andgive the orders to a truck driver to ship off to stores all over the country.

In your company there's probably a server room full of computers. On one (or two) of those computers there's probably an "ERP"application (Enterprise Resource Planning) running. This application (program) helps you to keep up with supply and demand. You feedit sales forecasts and it churns out orders and packlists and picklists and more forecasts and purchase orders and budgets andeverything you need to run a huge company. The most popular ERP these days is an application suite called SAP R/3.(still with me?I'm almost to the part where I talk about what our product actually does for people). SAP R/3 and ERP applications like SAP tend toproduce a lot of print - more print than people alone could produce: reports, financials, picklists, packlists, bills of material, shippingmanifests, and on and on. The huge number of print jobs brings with it problems.

How do you keep track of all that print?
What if you want to have the system reprint a report you ran last week?
What if you need to have the system reprint pages 1-56 of a 5000pg reportrun an hour ago?
What if you 're a system administrator and you get three phone calls in 20 minutes concerning problems printing?How would you sort this stuff out?

SAP and ERP applications like SAP won't help much. They're more concerned with producingoutput than keeping track of it.

SAP R/3 is not alone in having issues with printing, so lets just say ERP programmers aren't very interested in printing or faxing. They figure the Operating System will take care of it. And why wouldn't they figure that? A long time ago SAP released its R/2 application formainframe (this goes way back) and the mainframe computers were very good at dealing with printing. So, nobody gave it muchthought.

But the mainframe, as a platform for running businesses, hit hard times in the mid 80's/early 90's. It became out of style. Mainframecomputers are huge and were very expensive. The personal computer was making it big and with the PC came "servers". A newparadigm of "client - server" was becoming popular, and with it an operating system called UNIX.

A brief history of UNIX

Most of you probably run WinXP/Win2k or maybe MacOS on your home computers. UNIX is just another operating system like those.You've probably heard of Linux - this is another offshoot of UNIX - it happens to be "free'. Well, most client server networks are run with UNIX servers and Windows PCs as clients. The servers run applications that the business is run on, and the users (like you, thewarehouse worker) have PCs with some sort of Windows operating system on the "client" side. So, UNIX is meant to replace the mainframe in a client server world. But UNIX (the name) is a play on words. It's a cut down version of an operating system called Multics - UNICS (UNiplexed Information and Computing Service)--an 'emasculated Multics' - which became UNIX. As the name implies,UNIX is missing some things. One of the things it's missing is a robust output management system. It doesn't have a really good printspooler like the mainframe did.

At first this wasn't a problem because UNIX was cooked up in the mid 1970s so Ken Thompson and Dennis Ritchie (pictured above)could continue to play their video game "Space War" (which they had been playing on their Multics machine, but that got taken away.And I'm not making this up.) So, they weren't thinking too much about how Fortune 100 companies would be using this operatingsystem in 2002 to make zillions of dollars. At some point in the mid 1980s UNIX started to catch on and by the mid 1990s the shortcomings were showing through.

Venture Capital Software Startup to the rescue

The guy who founded the company that wrote the software wasn't necessarily a keen programmer. He wasn't much of a geek at all.He'd just heard enough admins and captains of business complaining about some certain things that he started to hear a market for a middleware - something that would allow the applications to get their "output" to the people who needed it (warehouse workers, truckdrivers, etc.). Real life doesn't happen inside the computer. If you want a computer to do something, you have to get the stuff out of it. That's output. Your computer screen is output, printers, fax machines, email, all output. Think of using your computer without amonitor. Doesn't work. Pretty much the same idea with businesses and print.

You'd cry if you knew how much paper Big Business uses every day. They print everything, often times twice. I've had customers that have printers that take rolls of paper 6ft in diameter and go through more than one roll a day printing financial reports, checks, purchaseorders, emails, etc. It's total madness.
(the paper goes into the printer in a stream and is cut by the printer into various sized pages as it prints)

The Value Proposition

We solve several problems for the business. I'll go through a few of them (hopefully briefly).
UNIX is an operating system. But there are many different versions of UNIX from different companies, and they don't all work the sameway. Some companies have servers running several different types of UNIX. We run on HP Unix (HP-UX), IBM Unix (AIX), Sun Unix(Solaris) and we also run on Microsoft's stab at a server operating system (NT). So we solve the problem of what is called the "heterogeneous" network (a fancy name for a network that's got a little bit of everything).

There are also a number of different printers out there. They don't all work the same either. As long as they conform to a certainsuper-set of standards, the software works with them. It works with standard fax machines, email, web delivery and file transfer,pagers...

Another issue is the printer language (format) of the document. I'm not talking about languages that we talk. I'm talking about formattinglanguages like HTML. They tell the printer when to print in bold or italic or which font to use or whatever. The ones we work with arePostscript, HTML, PDF, PCL, AFP and straight ASCII text like I'm typing here.

Some printers only handle text, or only handle Postscript. The software is smart enough to read a little bit of the document, check to see if the printer can handle that language, and if it doesn't, the software translates the data to a language the printer can handle.

The application also keeps track of all the jobs. It keeps them for a while in a repository in case someone wants to reprint or redirect ajob somewhere. This doesn't happen too often, but it's a feature that sells big with the CEO types. They want to feel secure that they spent all this money to buy an ERP and they damned well better be able to get the shipping dockets to the trucks (because that'swhat it's all about).

And what was it that I do? I provide technical support for this product for all of the customers in the Asia Pacific (AP) region.

What does it mean to do "technical support"?

You'll remember I have you working in a warehouse, waiting for a hundred jobs to come off the printer so you can get your day's workdone at a decent hour. Let's say now that the jobs never come. Nothing comes out of the printer. Who do you call? Not me. No, youcall your local helpdesk. They ask you questions like;

Is the printer turned on?
Does it have paper in it? Is there an error on the screen?
Have you tried turning it off and then back on?

If you stump the helpdesk person, they usually call a system administrator. They sys admin usually asks the helpdesk personquestions like;
Is the printer turned on?
Does it have paper in it?
Is there an error on the screen?
Have you tried turning it off and then back on?

If the helpdesk person stumps the sys admin they'd be the person to call me (or send an email depending on how urgent the issue is).The first thing I do is try to determine where the problem resides. So I ask questions like:

Is the printer turned on?
Does it have paper in it?
Is there an error on the screen?
Have you tried turning it off and then back on?

and might continue on with questions like: Is this a supported destination? Can you send me a log file? What's format of the document causing the problem? How is the printer attached (serial parallel, tcp/ip)? If tcp/ip: Is it network or terminal server (serial or parallel)? Are they using a custom cover sheet? What is the exact syntax of command they are issuing? Where is the output coming from? What application? If networked: Can they telnet (telnet ip port) to the socket? can they ping it? What does nslookup return? (and on the IP?)

And I might get some logging information that looks like:
dsm2.log Back sing PS job jqm2:2947830.1 on device prt22 Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 101 [debug 00100049] prt22 is a Write-Only Device Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 101 [info 000B11B7] Opening up new connection ... Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84Thu Apr 18 15:15:39 prod dzl_dsmd[9976]: Thread 84: [debug 000B019F]Starting document processing for job jqm2:2947830.1 on device prt22
Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0075] Number of documents is 1 Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0078] Printing document 1 Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0046] Looking for next document Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84Thu Apr 18 15:15:39 prod dzl_dsmd[9976]: Thread 84: [info 000B1025] Jobidentifier -- jqm2:2947830
Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0026] Document sequence number -- 1 Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B004A] This was the last document Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0079] No document type specified for document - assuming it isprintable
Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0165] .... Processing Document .... Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0177] Determining input document format Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0178] Determining output document format Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0179] Validating input and output document formats Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0082] Number of copies for current document being processed(may be a job sheet) -- 1
Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84 [debug 000B0073] Done with all documents Thu Apr 18 15:15:39 proddb7 dzl_dsmd[9976]: Thread 84Thu Apr 18 15:15:39 prod dzl_dsmd[9976]: Thread 84: [debug 000B01A0]Finishing document processing for job jqm2:2947830.1 on device prt22

and this is where things start getting fun (for me). If I can get honest answers to these questions, I can usually start to determine if theproblem resides somewhere within our software, or if it's from something outside our control. It's kind of like being a detective (without the guns and criminals). I'm using clues to implicate someone, or something. The funny part is when you're gathering information from the sys admin who might have accidentally cuased the problem. This can get pretty touchy sometimes and it's important not to gloat too much if you do find the problem. Usually it's appropriate to saysomething like:

"I'm glad we could work together to solve this issue."
when what you want to say is:
"You caused this problem because you don't know what you're doing and I'm going to tell your boss on you."

In conclusion

I can't tell you how uninspiring the business world is when compared with the world of the student. At least when you're a student you can be jaded and cynical while you don't really know what you're talking about. And there's always that hope that you can make adifference. Once you cross over that threshold into the world of business it becomes blatantly apparent that we are all guilty of original sin and doomed to be fallen souls only redeemed in faith. People couldn't consciously evolve themselves out of a paper bag given true Free Will or the freedom of determination that's coming with the advent of genetically-engineered-nanomesh-spintronic-quantum-uFog.We are our own worst enemy (not to mention the worst enemy of every cute animal and attractive plant on the planet - think about it -cockroaches and slime molds will likely be our legacy if we don't get it right).

That said, I'd like to use a uniquely human ability now and recognize a portion of the divine labyrinth of coincidence that got me where I am today. A long time ago, the universe came into being. This occurrence was more improbable than winning the powerball lottery every month for the next 10 years, but it happened. A long time after that, I was born - a smaller, but even more improbable miracle. I moved all over, went to some schools, didn't study computer science. I got a temporary job calling people onthe phone and trying to get them to attend a telephone seminar. I did well enough at that to get hired for real, then transferred to another department (support). I still didn't know much about computers at all. Then some really great people got hold of me and started to teach me things and make me think and study a little bit. And finally at the end of all of that, I'm no Unix guru, but I can keep my head above water and manage to swim around a little bit in the broad and unbounded pond of "IT", "computers".

Sometimes the lights all shining on me
Other times I can barely see
Lately it occurs to me
What a long strange trip it's been
Truckin' -Robert Hunter

Warning :Serious Tech talk about how the software works and where the complexity is:
I've established that ERP produces a lot of output. That output needs to be directed and ushered out to any/many devices on thenetwork. To do this we use names and addresses. In SAP, there's a facility to create printers. For every printer on the network, there's a registered name and configuration of that printer in SAP. Each SAP printer name maps to a short name. The SAP short name is theactual address in the database. The long name is meant to be more human readable. One short name can be fed by several longnames. Short names are only four characters - from A-Z to one through nine - e.g. IN4w is valid, IN$8 is not. So you can see there's alimit to how many printers SAP will allow, albeit high.

The SAP configuration controls how the raw data from the database is pumped out to the spool (e.g. format, forms, fonts, etc.). The SAP printer is like your windows printer driver. SAP builds a document by inserting raw data into a file according to a style-page (notsure what it's actually called, but you get the idea - a long string of data is chopped up and made printer-readable in order that onceprinted it's human readable). In my case, SAP usually creates PostScript documents. The document is handed to the SAP spool. From there it would be handed to the operating system (LP) if we didn't have a dedicated bolt-on to SAP. OMS (Output Management System) is a SAP API that allows SAP to pass values to an outside application (like ours). Handy thing is that the same people who wrote our application had a hand in writing the OMS API. It forms a tight integration that allows us to pass data both ways (jobs outfrom SAP and status messages back in) - so the user only needs the SAP GUI to get status of their print jobs. We're invisible to the user.
The print job is passed through SAP OMS to our software along with attributes and values it picked up from OMS and from the SAPprinter configuration. The attributes and values tell our software what to do with the job (print 2 copies, duplex, staple, etc.) In oursoftware there's also a complete list of all of the printers configured on the network. But to make it worse, printer definitions in our software are chopped up into three components; logical printer, queue, physical printer. Each have to be configured per printer to talk to each other. The job flow looks like this:
SAP spawns print job to DEVICE, DEVICE correlates with SAP-short-name, SAP-short-name passes job to OMS, OMS passes job toour logical, the logical passes it to the queue, the queue drains to the physical (which actually communicates to with the device on thefactory floor). Feedback from the device is handed back similarly.
There can be multiple logicals to one queue, or multiple physicals (device farm) to one queue, or both. We have the luxury of keeping mostly to a one-to-one-to-one relationship which makes things so much easier. But still, in that delivery sequence there are no less than 7 named configurations that have to reference each other in a chain. One break in that chain, and no print. We have thousands and thousands of those chains strung across any number of servers and databases. One change to one printer is actually one change in about 20 points. Even if all of those points are in alignment, there's a handoff at each point. If any of the handoffs don't quite workright, no print. Tracking down this type of stuff constitutes the best part of what I do (lot's of log reading and under-the-covers intrigue:white-hat hacking). Most of the problems don't reside within the software. Problems usually stem from the interface between cyber and reality - network cables, printers, toner, paper. Once I can isolate and prove the problem is in the real world, I can throw it over the wall to whomever deals with the real world.
The software also retains accounting data. So we generate reports of our own - jobs per day, data per day per customer, whatever.
We also institute change, test new configs, patches, workarounds. I don't "write" scripts. I adapt/adopt them. No high powered nothinggoing on here, general knob turning and problem resolution.

No comments: