I got into this racket in 1971 when IBM decided I should be a programmer rather than an accountant, and who was I to argue? They introduced me to the IBM 029 keypunch machine and the PL/I(F) language along with JCL and utilities. I began to program, such as it was. Write a description of the program, convert it to a flowchart, code the program by hand onto keypunch sheets, give the sheets to the keypunch operator and wait for her (always 'her') to produce a deck of cards with neat rectangular holes, proof-read the cards, deliver them to the RJE (Remote Job Entry) station downstairs (we had a Mod 25, I think, that was used as a glorified card reader), pick up the output when ready along with the cards, check the SYSOUT, correct the program, repeat until success.
A few years later, the department got a shipment of 2741 terminals, Selectric-y things with the ability to communicate with computers far away. There was a sign-up sheet where one would bid for time on the few terminals, and we would wait in our offices (yes, real offices) for the phone to ring with the news that it was 'time' to go work on the terminal. Log on to TSO, edit the datasets, compile the program, build the JCL, run it, check the output, fix the program, fix the JCL, repeat until success. Later, the 2741s were replaced by 3274s, 'green screen' paperless terminals, but the process, while faster, remained essentially the same.
Then, along came SPF, the Structured Programming Facility, with a suite of utility functions and an editor... a WYSIWYG editor! What You See Is What You Get. Each improvement made the process easier and faster and less error-prone. It was a long time before anyone realized those three things were operationally connected.
SPF mutated into ISPF, the Interactive System Productivity Facility, and with it came a whole raft of new features... and new problems. One of the new features was something called "edit profiles". ISPF would handle different types of data differently, and the user could control this by strategically naming datasets. The profiles were named based on the low-level qualifier (LLQ) of the particular dataset plus its record format (F or V) plus its record length, so you wouldn't get a PLI-F-80 profile mixed up with a CNTL-F-80 profile, even though the data had the same general 'shape'. Alas, ISPF only made provision for 25 profiles, and when a user created a 26th profile, the least-recently-used profile would be summarily discarded to make room for the new one. Because users were never given much education in 'profiles and their care and feeding', and since the system administrators were often system programmers whose use of ISPF was rarely more than rudimentary, the stage was set for all kinds of mischief:
The Jones Company uses COBOL and PLI, along with CLIST and REXX, in a zOS/TSO setting. Everyone uses ISPF. There are no standards regarding dataset names that deal with other than the first two nodes; the LLQ is never even considered as something that ought to be standardized.
Arthur is a programmer. He has datasets named (we ignore here the high-level qualifiers and concentrate on the LLQs) PAYROLL.PLI, TOOLS.PLI, REPORTS.PLI, and MISC.PLI. They all contain PL/I source and all use the same profile, PLI-F-80. He also has PAYROLL.CNTL, TOOLS.CNTL, REPORTS.CNTL, and MISC.CNTL. These all contain JCL and similar data and all use the same profile, CNTL-F-80. Betty has datasets named PLICODE.STUFF, COBOL.STUFF, and JCL.STUFF. They all use the same profile, STUFF-F-80, even though their contents are radically different. Betty is constantly changing profiles in ISPF Edit to get the behavior she wants from the editor. Cheryl has datasets named ACCTG.SOURCE (a mixture of PL/I and COBOL), and PROTOTYP.SRC (a similar mixture of languages) along with ACCTG.JCL and PROTOTYP.JCLLIB. Cheryl has four profiles: SOURCE-F-80, SRC-F-80, JCL-F-80, and JCLLIB-F-80. Betty asks Cheryl to look at a module in COBOL.STUFF that won't compile in hopes that Cheryl might see something wrong. Cheryl views Betty's COBOL.STUFF and suddenly gets a new profile, STUFF-F-80, that she never had before, and it's different than Betty's STUFF-F-80. Cheryl is stumped by the problem and asks for Arthur's help. Presently, Arthur has a STUFF-F-80 profile and his, too, is different than either Betty's or Cheryl's. Neither Arthur nor Cheryl edited Betty's data; they both used VIEW which, unfortunately, is affected by the problem since it uses edit profiles.
We're dealing here with just three people and already the problem is showing its potential. Imagine a setting with 200 programmers, technicians, testers, and so on, all operating guidance-free. One day you go into edit on one of your datasets and the highlighting is wrong, the data is shifted into all-CAPS whenever you type something new, and your tab settings seem to have gone away. "What the hell happened to my profile?" you ask. The answer is that it got purged when Larry had you look at a stack of ISPF skeletons he found in an archive. You created profile #26 and lost one that you had counted on keeping. P.s.: when you went back into edit on that all-wrong data you re-created a profile for that dataset and purged another, different profile. Which one? I have no idea and neither does anyone else.
Is there an answer to the problem of "where did my profile go?"? There is, and the answer is 'standards'. Someone in authority — and the higher, the better — must say: "All xxx data must reside in a dataset whose LLQ is aaa" and repeat as necessary for all known common types of corporate data. Exceptions, where a case can be made for an exception, are granted by managers. There also needs to be a catch-all category for material that doesn't fit neatly anywhere else.
In recent years, ISPF changed the protocol a little. Profiles can be locked or unlocked. When EDIT goes looking for a profile to purge, it selects the least-recently-used unlocked profile. If there aren't any of those, the least-recently-used locked profile gets tossed. Also, there's something the sysprogs can do post-installation that allows each user to have 37 profiles, somewhat easing the problem if not eliminating it. Regardless, be careful about how you name your datasets and urge everyone else to be just as careful. If corporate doesn't set standards, try to get your department or division to do it.
