About Me

Since the 1990s I have been very involved with fighting the military "don't ask don't tell" policy for gays in the military, and with First Amendment issues. Best contact is 571-334-6107 (legitimate calls; messages can be left; if not picked up retry; I don't answer when driving) Three other url's: doaskdotell.com, billboushka.com johnwboushka.com Links to my URLs are provided for legitimate content and user navigation purposes only.
My legal name is "John William Boushka" or "John W. Boushka"; my parents gave me the nickname of "Bill" based on my middle name, and this is how I am generally greeted. This is also the name for my book authorship. On the Web, you can find me as both "Bill Boushka" and "John W. Boushka"; this has been the case since the late 1990s. Sometimes I can be located as "John Boushka" without the "W." That's the identity my parents dealt me in 1943!

Sunday, September 28, 2008

A career segment on the NBC Today show Sunday morning (Sept 28) indicate that mainframe computer programming jobs may come back strong despite the weaker economy. Many mainframe programmers (like me) have retired. One problem is that some older programmers might not have kept up with all the modern tools (associated with DB2 and other databases, direct connect, Case tools, scripting) needed even in the mainframe world now. Mainframe processors often host Linux-style operating systems simultaneously.

There was a lot of talk as early as 2002 that the mainframe market would eventually recover as older programmers retired.

Network engineers and administrators would also be needed.

But many of the other “recession-proof” jobs are “people intensive”, particularly in health care and personal care, such as for the elderly, disabled, and in teaching and child care.

Friday, September 26, 2008

Recently, career counselors have been writing or broadcasting columns about job interviewing techniques. This morning, the Career Management column in the Tech Republics blogs has an entry by Toni Bower, “Questions your interviewer doesn’t want to hear,” link here. And this morning (Sept. 26), on ABC’s “Good Morning America”, Tory Johnson gave similar tips (not available online yet).

The most important tip is to save questions that relate personal concerns until later in the interviewing process. Don’t ask about overtime or shift hours, or accommodations, or benefits, until you’re sure that you’ve sold yourself for the job.

Concerns about child care and family don’t get much of an ear, because “everybody has those” and has to deal with them. That tip even goes for concerns over eldercare, which is disturbing inasmuch as it is not always a “chosen” situation like having children is thought to be.

But the question about family responsibility could come up anyway if a person has been out of the workplace for some time because of it. The most common way this happens is, of course, the birth of a baby but eldercare is likely to surface as an issue that can cause long lapses in work history.

Better employers should be willing to discuss benefits, telecommuting, and family-friendly accommodations without the candidates having to bring them up. If the employer says nothing at all about them in an environment where they would seem to be expected, that could be a sign that it is not a good place to work.

The interviewing advice is complicated by the fact that many jobs in information technology are short-term contracts involving temporary relocation away from home where family issues could occur. This tendency has become much more pronounced in 2000, where the job market has become so variable with economic contractions and where employers demand such specific “job ready” skills. Obviously, given the current economic climate with the financial crisis, that may become even more true.

Another tip is to ask, “what’s a reasonable amount of time for me to expect to hear from you. Should I call you?”

AOL has an interesting pre-interview multiple choice quiz in an article by R. Roy about business etiquette, and the article says that businesses are giving quizzes like this. Know the purpose of BCC copies, and know when to shake hands. Business may require more sociability than many people, especially programmers, think. Here is the link. The questions came from the TemPositions Group.

Tuesday, September 23, 2008

Paul Baldwin, in the IT Consultant Column hosted by Chip Camden and Tech Republic, talks about the “business ethics” of a consultant (working for a personnel or consulting company) caught in the middle. The problem is that the consulting company cannot comply with the terms of its client’s contract, and the contractor knows. Should the contractor tell the truth?

The blog article link is here. The title of the article is “Ethics: When telling the truth to the client hurts everyone”.

The interpretation in the article is interesting and realistic. I’ve seen milder versions of this problem myself. I’ve seen contractors, when I was working for the host company, be mum when I thought they could be more forthcoming. I’ve mentioned this in earlier postings.

In 2003, I made up a “Business Ethics” certification test for Brainbench. I don’t know if they are using it now, but I did ponder this problem then.

Monday, September 22, 2008

Remember how it was in a lot of mainframe financial shops in the 80s and 90s. Salaried programmers put in unlimited overtime to make due dates, implementations, and provide on-call support.

Actually, in my case, in the 80s, everyone supported his own applications all the time so at the credit reporting company (Chilton) we didn’t have an on-call list as such. But in the 90s, at the insurance company, we did, and there were so many interlocking systems that the on-call programmer could have to respond to, most of the time with simple things, like JCL errors, empty files, bad policy master records, unverified VSAM files, etc.

Although not always the case, some people with kids or heavy family obligations had difficulty with this environment. This could gradually lead to various problems. Sometimes singles or people who, for whatever circumstances, had fewer obligations were expected to do more of the on-call for them, sometimes without compensation in a salaried environment. There was a flip-side to this. In a downturn, a company might be more inclined to keep the people who put in the overtime and who had made themselves essential to keep a place running, especially as it was been deconverted for a merger.
This could encourage “lowballing” and could lead to more layoffs of people with families. This kind of environment fed on a laissez-faire culture that assumed that kids (and other dependents like the elderly) should be the responsibility of parents.

This cultural value system may be changing. For one thing, the nature of jobs has changed: more of the jobs are held by contractors, who are paid hourly. More of the work today is end-consumer oriented and involves 24x7 operations, including implementation and testing. But another reality is that demographics are forcing people who did not have their own children to share more family responsibility, especially eldercare. I wrote about this yesterday in a review of a new book about marriage and “dependency” by a law professor (see my Books blog). It may no longer be acceptable for employers to play one kind of employee off against another.

The Family and Medical Leave Act of 1993 is relevant, but it is limited by the fact that it allows only unpaid leave. Some employers give longstanding employees paid leave for family emergencies. But we wonder how European employers can handle this but we can’t. Is it because of our health insurance mess?

Friday, September 19, 2008

A lot of Internet advice on job interviews gets pretty trite (dress conservatively, to be sure), but I thought the Tech Republic blog entry by Toni Bowers, “Three Interview Behaviors Managers Don’t Like” should be noted. The link is here.

The main no-no seems to be a weak or fishy handshake, and lack of eye contact. In fact, the absence of body language is a bad sign. Of course, once someone is working in an organization, sometimes eccentricity or marked introversion is actually treasured, if the person has the reputation as the individual come to with problems no one else can solve. How often have we seen that with I.T.? And who can solve the worst problems? Often it’s the preoccupied person. Not always, but often enough.

I once had an interview with a company that had been a vendor to a company from which I had retired. That company had generated complaints where I had worked and did not have the best reputation. I did mention this in the interview, trying to sound objective. I did not get the job. Okay, maybe there were other problems, like hidden “non compete” or some such idea.

Wednesday, September 17, 2008

I recall another juicy interview on the Friday afternoon before Labor Day in 1981, in Dallas, in the old mainframe days, when personal computers had barely been mentioned in the news.

I had been asked by a recruiter how I felt about a “very small shop” of two people. An entrepreneur in a strip mall in North Dallas was developing fire-casualty application to sell. It was going to run on Data General machines. He was going to hire a “technical director.” This was going to be the kind of job that you had to land on your feet the first day, or “I will just have to tell you.” He talked like the godfather-like character Stefano on “Days of our Lives.” This was an interview right out of a soap opera.

The job was going to pay $27000, which was fair by the salary standards then.

I thought I needed a job then because I was working for the Combined A&B Medicare Consortium as an analyst, and the project was tanking. I had a problem because I was doing a lot of analysis but little hands-on coding. The way the market was then, this was a big problem.

On my birthday, in July, I had interviewed a furniture company called Brinkman in Irving that had a DOS CICS shop. Remember DOS on the mainframe? I had also interviewed the Federal Reserve Bank of Dallas, which seems like an interesting memory today.

It would turn out that the Federal Reserve Bank did lead trading with Chilton Corporation, a credit reporting company that has now morphed into Experian. I would actually receive a letter from Chilton inviting me to an interview later that same month (September 1981).

I spend six years with Chilton, nestled conveniently then in Dallas’s Oak Lawn neighborhood. (The lowrise building would eventually become a data center for Hibernia Bank, and then get torn down for space for condos, probably cannon fodder now for subprime mortgages). They were stable, but I didn’t get back to actually implementing anything until Labor Day 1985, when we put in my changes into a DOS (DUO) assembler batch system that ran the monthly bills for their bureaus. (We called them the 162’s and 165’s). The change was to put in “consolidated billing across bureaus.”

Chilton had Datacomm DB/DC (rather than something like IMS DB/DC or CICS) on Amdhal machines that ran MVS emulation (having converted from DOS). The product mix came from a company named ADR, up on LBJ Freeway in Dallas. That would set the stage for what would happen next, when I returned to the East Coast, because Datacomm died out as a marketable skill, as IBM came to completely dominate the mainframe world and job market.

Friday, September 12, 2008

Given all the recent attention in the media to employer’s checking applicant’s social networking profiles, it’s curious that today Toni Bowers at Tech Republic posted a blog entry “Hiring Manager: Step Away from the Facebook”, link here. Here, an (unnamed) recruiter made an apparently inappropriate invitation to an applicant to become a friend on Facebook. At least, it sounds like inappropriate behavior in the personnel business to me.

As I've noted recently on my main blog, Facebook has recently booted some members for inappropriate use.

I still think that for professional purposes, recruiters and applicants should communicate on more profession-specific networking sites. LinkedIn (a good example of one recruiter’s (David Muir) professional page is here seems to be pretty good with professionalism, as is Ziggs.

The earlier problem had been text messages from job applicants to managers or recruiters.

On June 20 on this blog, I posted a discussion of a report that recruiters should tread carefully in getting involved with applicants’ personal social networking and blogging.

Thursday, September 11, 2008

On September 11, 2002 (a Wednesday) I had the first in-person job interview for a COBOL job since my layoff at the end of December 2001.

I had been contacted by a recruiter in Minnetonka, and gone out to chat with him. He claimed to have arranged an interview for me and one other mainframe programmer with a pharmaceuticals company along the 494 strip in Bloomington. He claimed this could be a slam dunk deal in advance, after nine months of very little. (Okay, there had been a nibble for a data warehousing job at Wells Fargo, but I really had no data warehousing.)

The woman from the company came down into the lobby and interviewed us, together and then separately right there in a plush lobby filled with “puffy chairs”. I even took some DB2 and COBOL Murach books along to prove that I was technically prepared. The tone of the interview was very general, with few specific and no technical questions.

Afterward we found out that she didn’t even have the authorization yet to fill the contractor positions. She was going to complete the work with existing staff. But I also got some interesting feedback from the recruiter. “She said, you tried too hard.” The recruiter said that he didn’t agree with her, given the difficult of the collapsed job market then. “But that doesn’t seem to send the right message.” OK, interesting.

I still wonder, why do the interview on September 11. I had preferred to watch the commemorations. On my main blog (in the archive a year ago) I describe the company cruise on September 11, 2001, as we spent the day, though in sunshine, in the dark as to what had happened.

Wednesday, September 10, 2008

Tom Olzak and Debra Littlejohn Shinder have authored a PDF paper “IT Leaders: Prepare for E-Discovery Requests: How to Avoid Disastrous Legal Sanctions and Fines,” a “Tech Republic Special Report.” The PDF is “entertaining”: it is well illustrated with lots of pictures and charts, but Adobe reader processes it very slowly.

There were amendments made in December 2006 to the Federal Rules of Civil Procedure (FRCP) that are important.

A significant concept in the paper is the idea of a detailed document retention policy, integrated fully with the organization’s systems. Discovery requests will include a copy of the company policy. There has been controversy (and variable advice) in a number of organizations (especially since Y2K) as to how long employees should be encouraged to keep their own correspondence, but it seems likely that companies will have to enforce uniform policies much more strictly. In the past, companies have sometimes told employees that should not retain correspondence longer than necessary Content Monitoring and Filtering (CMF) can be a significant issue.

Another potential issue, especially in view of recent incidents of consumer data loss from large organizations, could be employee retention of their test results, especially if based on copies of production databases.

The link for the download (published Tuesday Sept. 9) is here. You need to be a registered Tech Republic user to download it.

Tuesday, September 09, 2008

My goodness, we have come so far in basic I.T. production environment security since the mid 1980s. Particularly in areas where security vulnerability lies inside source code. Even on the mainframe, IBM assembler, for example, has always had the ability to change updating options and even dataset names from deep within the code with various macros and esoteric techniques (some involving the reflexive “execute” instruction). For example, as recently as 1995 I did a project to increment dynamically the dataset names of tapes to be sent to customers from within a salary deduction billing program, with a special step in assembler to do this.

Back in 1985 I worked on a project to consolidate billing across credit bureaus in an assembler system (MVS IBM assembler, running on Amdahl) of batch programs written originally for DOS and running in MVS under DUO. The DUO option was an execution parameter in the EXEC statement in the JCL.

We had bureau and member masters, and the monthly billing programs would update the member masters (especially the past dues buckets for billing). In those days, when we tested batch, there was no RACF or Top Secret yet. The assignment of the correct file (the test copy of a production file) was embedded in a catalogued proc. Test from production datasets were usually distinguished by a leading qualifier. I suppose as long as it was never touched or overridden, the real production master could not be updated. But then, no security protected the production sets from programmers, either in batch or possibly from TOS commands (or their equivalent) issued from "Tube City." But if a major master file were corrupted, no one would find out until “end of month” ran.

But what’s “worse” is that, in a DUO environment, we also had an “UPSI” parameter. The macros in the DOS program interrogated the UPSI parameter and skilled statements (by branching around them in some parameterized fashion) and if the parm was set to “NOUPSI” it would not update. Some programmers had run with the real master file but with NOUPSI. But, they were counting on good faith that no coding change could have left the file vulnerable to update.

I have some other “fine” memories of ALC programming. One time, all the quarterly (and less frequent) fixed charges failed to post because a programmer had inserted a byte in storage that upset instructions that depended on half-word or fullword alignment to work. I remember trapping that at 7 AM with some kind of snap, and fixing easily with a “DS 0F” command. But on a Saturday morning in January 1986 we had to rerun the statements for about 20 bureaus. It’s a good thing that I hadn’t prepaid any plans that weekend. It was January, after all, after the holidays!

We would soon convert the DUO system to OS, and that itself was a project.

In its day, assembler language on the IBM (or compatible) mainframe was a valued skill. It was an intricate world of its own.

I understand that the IRS still hires assembler programmers through contracting companies, for operations in Merrifield, VA and perhaps elsewhere. But they seem to want experience in very specific engineering applications.

Monday, September 08, 2008

Jeffrey Hiner continued his discussion on the pros and cons of information technology as a career this morning on his blog, with five more reads that IT, well, -- I won’t repeat his expletive. The link is here. He says that these additional "five things" were supplied to him by readers.

The most important observation is that users tend to think of information technology as “magic,” literally like the driving force between Clive Barker’s 1991 novel “Imajica.” Indeed, one could think of the world of broadband, wireless, and search engines (along with all the Web 2.0 and 3.0 gizmos) as “magic” that corresponds to Barker’s “in ovo”. I wonder if Barker would have written his fantasy novel differently had the Internet and especially the Web been “public” (other than just available in pieces like bulletin boards and user groups) when he wrote his novel while still in Britain.

Hiner is right that you can work yourself out of a job. Even as far back as 1980, when I was at a Combined Medicare Project that would eventually fail, one of the people whom we hired and moved down to Dallas from Iowa said, he had been laid off after finishing a mainframe state government project there because “we got done.”

Another idea is that often, “you are on your own” in solving problems, often when taking over someone else’s work. I worked in support the last two years before “retiring” in 2001 and found it challenging to fix “somebody else’s” bugs in a technology (Java, Powerbuilder, C, etc) where I have never developed a system from the start, as I had with mainframe disciplines like COBOL, ALC, and JCL. In earlier mainframe days (when "structured programming" was supposed to be all the rage), you didn't want to tell an interviewer that you were turned off by looking at other programmers' "spaghetti code".

Thursday, September 04, 2008

Back in the spring of 2003, while still in Minnesota, and 15 months out in “retirement”, I had an interview with a debt collecting company, that had started with a job fair. The first interview in HR went fine, and then I came back to talk to a manager, and it seemed to go well, but he picked up on the fact that I was very “analytical.” I did get a tour of the floor, with all the warm gear, and got to observe a collector for about a half hour. Somehow we got into a metaphorical conversation about red and green kryptonite and Smallville and Clark Kent. So I was invited back for a third interview with a youngish man who was the head of HR.

He challenged me with quite a blunt question. “Tell me the last time you told someone what to do, and they did it.” I made up some story about how we implemented the daily or monthly billing system at the credit reporting company back in the 1980s. I remember how, as a kid, I used to resent the idea of parents, teachers or superiors doing something “just for authority”.

I asked him, what were the consequences when a debtor didn’t pay. He said something nebulous like, “it gets on their credit report.”

Of course, you see my point. If there are clear, legal and enforceable consequences for failing to pay, then the consequences will speak for themselves, and my ability to project “authority” becomes a red herring. On the other hand, if the company is depending on me to put on an act, it’s business model is suspect. It shouldn’t need that. The fact that since then millions of people got subprime loans with poor credit says that the "consequences" didn't speak for themselves. People wouldn't do the right thing until they were "told" to by someone who projected authority.

At the close of the interview he said something else that still sticks in my mind. "I am convinced that you fully understand the job. I have reservations as to whether you can actually do the job." Because of not enough social bearing perhaps. Objection to manipulation and schmoozing.

I didn’t get that job, nor did I get a job as a first party collector for Target. But I did get on as an immediate hire at RMA a few weeks later. No existential questions in that interview.

I worked for two months before deciding I would come back to Virginia. The IT environment was stripped down and simple, with menu-driven, character based screens only, but the platform was actually Unix. The applications may have been written in some kind of COBOL. The sign-on procedure required us to enter an IP address, but there was no actual Internet connection. This was the first work logon that I had since my work account was suddenly canceled in front of my eyes in December 2001 prior to my layoff.

This was a good company; it gave a week of training, and was strict about complying with the FDPCA (Fair Debt Collection Practices Act). Even so, I was counseled to ask “is (Jane Doe) there?” and fake pretending to be a (now “Facebook”) “friend”, rather than sound like someone calling for official purposes. Once we reached the person, the mini-miranda starts.

Al Gore said, at the Democratic Convention, that we’re becoming a nation of sales people who don’t make things. If you have a real product or service, you really don’t have to manipulate people, do you?

Monday, September 01, 2008

Today, Jason Hiner has a companion “Sanity Check” piece to his article in the Aug. 25 Tech Republic blogs, today called “Five Things that make it great to work in I.T.”, link here.

One of these is that you’re the “hero” if you solve a problem. I’ve experienced that. In January 1989, I looked at some code from a government COBOL Medicare reimbursement program and found that the code did not match the specs in the Federal Register. I rewrote an outlier calculation routine to match the actual code and we got the results expected by the client, saving a business.

The “you get to be a revolutionary” idea is more related to the Internet or P2P, like launching Napster, or Facebook (from a dorm room).

He also says you get to make people more efficient. Jobs that I have done to consolidate billing states were justifications for elimination of administrative positions.

Hiner doesn’t say this: You also don’t have to schmooze with people much. You do have to work cooperatively and “sell” your own work, but you don’t have to “impress” them with phony social manipulations, as people in sales have to do. You shouldn’t “always be closing.”

This whole series does remind me of the movie “Thirteen Conversations about One Thing.”

(used for analytics)

Privacy Policy

Privacy Policy for billsitjobs.blogspot.com

If you require any more information or have any questions about my privacy policy, please feel free to contact me by email at JBoushka@aol.com.

At billsitjobs.blogspot.com , the privacy of my visitors is of extreme importance to me. This privacy policy document outlines the types of personal information is received and collected by billsitjobs.blogspot.com and how it is used.

Log Files Like many other Web sites, billsitjobs.blogspot.com makes use of log files. The information inside the log files includes internet protocol ( IP ) addresses, type of browser, Internet Service Provider ( ISP ), date/time stamp, referring/exit pages, and number of clicks to analyze trends, administer the site, track user’s movement around the site, and gather demographic information. IP addresses, and other such information are not linked to any information that is personally identifiable.

Cookies and Web Beacons billsitjobs.blogspot.com does not use cookies.

DoubleClick DART Cookie

.:: Google, as a third party vendor, uses cookies to serve ads on billsitjobs.blogspot.com .
.:: Google's use of the DART cookie enables it to serve ads to your users based on their visit to billsitjobs.blogspot.com and other sites on the Internet.
.:: Users may opt out of the use of the DART cookie by visiting the Google ad and content network privacy policy at the following link.

Some of my advertising partners may use cookies and web beacons on my site. My advertising partners include ....... Google Adsense

These third-party ad servers or ad networks use technology to the advertisements and links that appear on billsitjobs.blogspot.com send directly to your browsers. They automatically receive your IP address when this occurs. Other technologies ( such as cookies, JavaScript, or Web Beacons ) may also be used by the third-party ad networks to measure the effectiveness of their advertisements and / or to personalize the advertising content that you see.

billsitjobs.blogspot.com has no access to or control over these cookies that are used by third-party advertisers.

You should consult the respective privacy policies of these third-party ad servers for more detailed information on their practices as well as for instructions about how to opt-out of certain practices. billsitjobs.blogspot.com 's privacy policy does not apply to, and we cannot control the activities of, such other advertisers or web sites.

If you wish to disable cookies, you may do so through your individual browser options. More detailed information about cookie management with specific web browsers can be found at the browsers' respective websites.