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, October 22, 2006

I recall that in the 1980s, at a Texas credit reporting company (then, Chilton), we had gotten used to coding a label parameter to save tape datasets as LABEL=EXPDT-99000 to assume catalog control. That is, the tape could not be written over unless uncatalogued. We had used a third party vendor tape management system.

In 1988 I took a new job in a small shop in Washington DC that had a 4341 and 4381, which at the time were the small mainframe computers that could run MVS (or VM, which actually emulated a PC on the mainframe). I had created and saved a lot of data tapes and coded them the same way. Lo and behold, one summer evening in 1989 (after a small data center move) I find out that all of the tapes are unprotected. Fortunately, none of them had yet been written over. But if they had been, a whole business could have been lost. My career could have ended right then and there.

The new shop used IBM's own standard only, which at the time were EXPDT=yyddd, where 99365 or 99366 kept the tape indefinitely.

It appears that all of this changed with Y2K. The correct way to code is yyyy/ddd (1999/365 or 1999/366 still gives permanent retention).

The lesson is, if you are a consultant and work in a shop where you have some responsibility for manually managing data resources, be very sure that you know the exact rules for your shop. And know the official IBM standards, which may appear on certification quizzes.

Wednesday, October 18, 2006

The example here supposes that we are building a database of political theory. We are trying to classify the arguments that people try to make to support their political or social positions. This could be build up into a social studies learning tool.

We may have to tinker with the basic setup from time to time to make some of the examples applicable. For example, outer joins wouldn’t make sense if you had already enforced referential integrity with foreign keys.

1amend,Internet,00000001,2006-01-01,11,12, “Children should be protected on the Internet”1amend,Internet,00000002,2006-01-01,12,11, “filters will protect children”1amend,Internet,00000003,2006-01-01,13,11, “content labeling will protect children”service,draft,00000011,2006-02-28,21,22, “military service is am obligation of citizenship”service,draft,00000012,2006-02-28,22,21, “the draft is involuntary servitude”

This join would return all authors as potential matches but only the arguments authored by matched authors. If you coded “right” you would get the same result if the tables were switched in the select statement. Full outer joins allow only an equality operation, but left and right joins can use any comparison operator.

Tuesday, October 10, 2006

Some quizzes on DB2 programming may test knowledge of date formats. Sometimes there is confusion about character and numeric representations.

A DATE data type in DB2 is represented in character format in Y2K chronological: “yyyy-mm-dd”. That is 10 characters in COBOL. The order will always be in logical chronological sequence.

In a similar fashion, a TIME data type is simply hh-mm-ss, 8 characters in COBOL.

However, these types have the implicit ability to generate durations (when two different items are “subtracted”) and to be modified by adding and subtracting durations. DB2 regards as date duration as DEC(8,0) which would be hosted by COBOL in a variable as PIC S9(8) COMP-3. Time duration would be regarded as DEC (6,0) and have a COBOL picture of PIC S9(6) COMP-3. (The pictures could obviously be S9(9) COMP-3 and S9(7) COMP-3., to fit within EBCDIC)

CICS transactions reference data either through a commercial database package (DB2, IMS, Adadbas, IDMS, Datacom DB) or through VSAM itself. Some commercial packages, like Vantage for life insurance and annuities (or the older and much less successful VLN) access VSAM through their own proprietary I/O modules, with which application programmers in a shop using these packages must become very proficient.

A good reference book for VSAM programming is a red paperback, Practical VSAM for Roday’s Programmers, by James G. Janossy and Richard E. Guzik, published by Wiley in 1988, ISBN 0-471-85107-8. The book gives a lot of historical background and “philosophy” behind VSAM in connection with both the old DOS and MVS as it developed throughout the 1970s and 1980s.

Technical interviewers are likely to expect a body of technical knowledge on how to access various VSAM formats from CICS transactions. In many shops, however, programmers often use only a portion of the technical knowledge that recruiters and certification tests may expect the applicant to demonstrate. This is particularly true of maintenance programmers.

For example, consider VSAM formats. By far the most common is the Key Sequenced dataset, the KSDS. But older formats include the Entry Sequenced Data Set, essentially a sequential file, and the Relative Record Data Set, RRDS, related to the old BDAM. With an ESDS, the Delete command cannot be used, and neither can the START, since an ESDS can only be accessed sequentially from the beginning of the file. These are available for the RRDS.

An important concept will be the RIDFLD, the “record ID field.” Applicants may need to be familiar with the RRN (relative record number) or RBS (relative byte address) options, that may occur on some CICS commands, in connection with the RIDFLD.

When RRN is specified, the RIDFLD specifies a relative record number, and the file must be a RRDS.

When RBA is specified, the file is an ESDS, and the RIDFLD is a relative-byte address.

With the KSDS, however (again, by far the most common), the RIDFLD must give the name of the field that contains the key value for the record (it could be an alternate index).

When you want to read a KSDS sequentially, you must use a STARTBR command (like the COBOL START, which is optional in batch COBOL if you want to start at the “beginning” of the file.)

Monday, October 09, 2006

I am starting to summarize a few mainframe review questions that could come up in phone interviews or in technical quizzes given by recruiters. This is all part of a review process that may lead to my own recertification in a job search.

Topic: Change Control

The skill most often requested is Endeavor. I am familiar with ChangeMan and CA-Librarian.

I became familiar with ChangeMan in the mid 1990s at ReliaStar. The package automatically stages components of an elevation (source, link decks, parmlibs, procs, JCL, etc) into various stages of Test, QA, and production. The package will not let you compile and link without linking the source. This automatically guarantees that when a package is moved to production, the source matches the load modules (a security issue). That to me sounds like a good concept for an interview question.

I first had CA-Librarian in 1990. At the time, one had to "process" a module to freeze, and it was possible to produce load modules that could be elevated without freezing the source. On the other hand, a source module itself could not be elevated without being frozen individually. This does sound like it could expose an installation to security problems, and I don't know whether this has been changed since then. I suspect that it has.

Monday, October 02, 2006

Bob Weinstein’s Tech Watch column (one place is The Washington Times, Recruitment Times, Oct. 2, 2006) discusses “companies need techies who can sell.” Indeed they do. It is easier to budget a position that is at least partially compensated by commissions, particularly as the economy just starts to uptick..

As a partially retired “baby boomer” from the largely mainframe IT market, I have been asked why I am not willing to “sell” what I worked on. Become a life insurance agent. Or a software salesman. That sounds like a very natural thing as you age out of the fast paced geeky coder market.

A short answer is that sales for sales sake is against my temperament. I am a Myers-Briggs blue, the artist. I like to create the content and get it published. I like to find the truth, disseminate it, and get people to deal with what the truth means.

Of course, in sales, you are paid to represent in public just one point of view about something. It is a Faustian deal, where you give up all pretense of objectivity that you learned in school. I see many want ads for salespeople, for people who have proved that they can sell anything. No technical experience in the hiring company’s products or services needed. Sales culture is its own mindset, as so well demonstrated in the little art film “100 Mile Rule.” (My review is here.) It does seem to be predicated on socializing for its own sake, and on manipulating people and their perceptions and on hiding the truth. From my perspective it sounds cheesy, but that’s relativistic. Always be closing!

A couple of points, here, though. Artists still need sales and people skills to sell their own work – just read all the success stories about Hollywood in the popular fashion magazines. And it is perfectly all right to help someone else’s work if that person’s work has a connection to your own, and you can work in synergy. That’s a good and necessary strategy.

Furthermore, technology sales people have to keep as current as the coders. They have to help non-technical business executives solve technology problems. There is a legitimate place for this, even if it doesn’t fit my own temperament. I think, though, that for a lot of ex-techies, selling someone else’s content and not your own represents a major psychological challenge.

(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.