I would just like to ask you all about the toughest assignment in your career and how you got through it.

Although I dont contribute a lot here, but I do refer the posts regularly to update my knowledge.I am sure there may be many more around the world like me. This may seem like a waste of time to some people; but people like me can learn a lot from your experiences.

If some of you seniors could share your experiences that would be great.

In my experience, the toughest assignments are the ones where "someone" has insisted on a bad course of action. And this is happening more and more often due to the improper foundation of some the people who are making decisions and/or providing direction.

Using technology is rarely the challange - sometimes people are the challange. . .

Two of my most interesting "assignments" were:

1. Being co-author the internals for an entire computing environment (dbms, programming language/compiler including an interactive debugging facility, a spool (like jes but stripped down), a terminal interface (like cics but stripped down), a sort, and various utilities.

2. Being project lead to migrate the entire application inventory from an environment of 4 MVS mainframes to UNIX (HP-UX).

The technical aspects of assignments, while challenging at times, don't really stand out -- writing a COBOL program to generate a report table where every column heading, row heading, page heading, and data point were input parameters from a file; or writing 350 pages of system documentation that wound up being used by the developers of the system. The real challenges have been management and non-technical -- such as being responsible for development to QA to production moves and being told to "read the programmers minds" to move what they wanted moved, not what they told me to move.

The rule of thumb my compiler teacher offered was that tools are three times harder to write than application programs, and compilers are three times harder to write than tools. I'd probably say tools are 3 to 5 times harder to write than applications, and compilers are 3 to 5 times harder to write than tools. Anyone without 5 to 6 years experience writing progressively harder applications will probably fail in writing tools.

The hardest thing I ever did was being the lead on a 'annual purge' project. Come in on a Saturday morning, run a batch process of about 150 jobs to delete old data from 200 vsams files, 100 flat files, and 800+ DB2 tables, and have the system up with data available on Monday morning. That was one of the worst days of my life (weekend actually).

And since it went so well, I got to do it every year until I left the company.

The hardest thing I ever did was being the lead on a 'annual purge' project. Come in on a Saturday morning, run a batch process of about 150 jobs to delete old data from 200 vsams files, 100 flat files, and 800+ DB2 tables, and have the system up with data available on Monday morning. That was one of the worst days of my life (weekend actually).

And since it went so well, I got to do it every year until I left the company.

The toughest assignments I can think of are those that had to be done when no one thought they could be done, or when complacency had stagnated the business process. There have been times when we needed to do something just to kick them in the ass and make them think about what was being done and how much it could be improved through automation.

The scariest part was during the implementation of the HIPAA process guidelines. The legal department had provided us with copies of the federal documents that laid out the specific and severe penalties for failure to comply. Those included long-reaching prosecution for ANYONE found complacent, and included fines and mandatory prison time. We had to go head-to-head with corporate attorneys on more than one occasion when we felt their companies were in violation of those guidelines.

For 16 years I generated the medical resident schedules for the entire upcoming year at a major medical college residency program.

This included fixed and floating night schedules, emergency room days and nights, clinics, and also some locations at the local VA hospital.

Various constraints were honored, such as "cannot work two nights before or after a night," but all with various exceptions.

The biggest challenge, as with most complicated "programming" tasks, is not how to code, but how to structure the data. Also, the data (resident, location, and date data) were to be entered by users, so the I/O interface had to be intuitive and robust.

With annual enhancements, this grew to a very clean 6000 line PL/I program, with about 50 subroutines.

Data structures included dynamically allocated arrays, bitmaps and two way linked lists.

Probably the most challenging assignment of my career was not mainframe-related; it was developing an OS for a PDP-11 clone.

The most challenging mainframe assignment was installing and ADMing successive versions of the strategic general ledger system for (as we say in the IT contracting business ) a major producer of computer hardware and software. I started with V1.0.3 for Canada; I ended with two V2.0 systems for North and South America...

My toughest assignment was my 5 years as a Manager. For me, dealing with technology is infinitely easier than dealing with people.

I got through it with the help of a good mentor, and by continuing to do technical work as well. I finally decided I enjoyed the technical work too much to stay in management.

I've been in a similar situation. I tried to keep writing code but found I couldn't do it properly because my management duties sucked up all of my time and energy. Leaving the company to become a consultant saved what was left of my sanity.

I managed to do development while I was a manager by severely cutting back the number of development items I was responsible for during that time, which was frustrating. Once I got out of management, I was able to go full bore again.

I've had a number interesting challenges, some from my own cockups, but here's a couple of projects that were pretty tough.

1. Getting standards in place in preparation for SMS implementation in 1988-89. The technical standards were relatively easy, but getting a new set of dataset naming standards agreed was unbelievably difficult and became very political. Same with getting people used to sharing Storgrps and not 'owning' their little bit of DASD.

2. I decided to set up an entire new DR backup system to replace a very creaky old one. This was prompted after having to spend hours going through lineflow reports just to identify a full volume backup to stand alone restore a failing mastercatalog volume from! It was definitely a job waiting for a sucker to do it.

3 I've done three site migrations and each has been horrendously stressful in different ways. Latter one using XRC to synch to DASD in a transporter and take it to plug in at new site was alot easier, but had to re-establish XRC DR immediately at new site before old site switchover to maintain DR. All done in 8 hours on the live day but felt like 80 hours.

4. Our Storage team used to do all the cabling between mainframe and peripherals in the days or grey and blue bus/tag cables. Swapping out a processor was a nightmare, not only the planning but the very physical work of laying and retrieving cables, running wrap-tests to identify broken cables, fixing bent pins etc, all in the small hours in a freezing cold machine room and having to complete with enough time for backout (kill me it's easier!) before next online day. You'd literally come out bleeding and bruised. The pub immediately beckoned, even at 7am!

I joined in at one on-site office in US and they asked me to have a look at a program which was malfunctioining. There was some mismatch in financial-calculations and I was supposed to create some reports showing the possible adjustments. The data was supposed to be fetched from the DB2-tables using Image-Copy Jobs.

Reports should show the data for last 7-years. Yuck, I was instructed to generate the reports in "readable format" (this is where I first heard about the word "readable" and undestood what different meanings this word can have for differnt people) - The readable format for zOS-boy was not that readable to the lawyers at DOJ, US. Not much technical work, as such, was involved in this but the pressure to get the correct-reports and readable in the given time was driving me crazy!