Profile on: ISPF Edit Profiles


What are TSO ISPF edit profiles anyway, What do they do for you, and How do you get them to do that?

This is another simple discussion of basic ISPF information, for people who don’t know much about ISPF.   All you experts, just move along.  These aren't the blog posts you're looking for.

You get a separate ISPF edit profile for each data set type you edit.

Data set type?

The data set type (in this context) is the file extension part of the data set name.

In z/OS, it isn’t actually called a file extension.  They call it the "low level qualifier", but it's the same idea as the file extension on PC file names. It's the last part of the data set name, after the last dot. Let's just call it type, since that's short, Englishlike, and easy to remember. Coincidentally it's also the name used for it on the ISPF "Edit Entry Panel", the screen that you see after you select ISPF Option 2, Edit.

So let's do that, select ISPF Option 2, Edit.

Next, type PANELID on the command line. Presto, the word ISREDM01 should appear near the upper lefthand corner of the screen. That's just the name of the first Edit screen, the Edit Entry Panel. I like to refer to panels by names — It's unambiguous — When you say "the Edit Entry Panel", somebody might not get exactly which screen you mean, unless they happen to be looking at it and notice that it has a title saying "Edit Entry Panel".  But when you say ISREDM01, that can only mean ISREDM01.

You've probably picked up that "Panel" is another word for screen.

So, on that ISREDM01 screen, put in the name of one of your data sets, assuming you have data sets.

If not, any data set you can access under TSO will do, as long as it's available, and you don't do "save".

(People will warn you that you shouldn't do that, because you might "save" accidentally. Okay, you've been warned. Let's continue.)   (To exit edit without saving the data, the command is CANCEL, in the unlikely event you don't already know that.)  (If you're REALLY nervous about accidentally saving, go up to the command line and enter AUTOSAVE OFF – – That will prevent it from saving automatically if you unthinkingly press F3.  It will only save if it sees the explicit SAVE command.)

For the example, let's use a data set that has "C" as the type (That is, any data set with a name that ends in .C — It would be even better for illustrative purposes now if you find one that also contains C program source. If no C source is available, find some other kind of source in a data set that ends in .COBOL or .PLI . . . or .ASM or .PASCAL … but if you don’t have any of that, just pick any data set you do have available.)

When you're into your edit session and you see your source displayed (on panel ISREDDE2), type the word PROFILE on the command line and press enter.

That will cause the ISPF editor to display some information lines just above the top line of the source/data, somewhat like this:


A lot of the things shown on those five =PROF> lines have values like ON and OFF. Unsurprisingly, those can be toggled between ON and OFF. Some also have extra options you can specify. So we'll talk about a simple one, then about one with options you don't care about, and then we'll see one with options you do care about.

CAPS is a straight ON/OFF toggle.

With CAPS ON in effect, any data you enter into your data set will be automatically changed to uppercase. That’s good for editing JCL. Accidentally putting lowercase letters into JCL statements is a common cause of JCL errors. On the other hand, for editing ordinary text, or a C program, you want CAPS OFF, which allows you to enter data in whatever uppercase and lowercase way you want, and it stays that way.

CAPS is one of the settings that ISPF will automatically change for you dynamically, depending on whether or not it finds any lowercase text in the source. So you only need to set it yourself — or reset it — if you don’t like the editor’s choice on the matter. For example, you might have some source that currently contains all uppercase data, but you want to add some lowercase. Every time you try, the editor converts it to uppercase as soon as you press enter. It’s downright annoying. That’s when you want to say CAPS OFF, and press enter, before putting in your lowercase text.

Some of the settings — HEX springs to mind — have options, but almost nobody would want the options.

On the command line, enter HEX ON, or just HEX, and the editor will display a two-line hexadecimal interpretation beneath each source/data line.


Command ==> HEX ON
****** ****************************** Top of Data ***
000001 #pragma title ("TESTPGM: C Sample program")
000002 // This is a Comment

The computer screen’s response (approximately):

Command ==>
****** **************************************** Top of Data ***
000001 #pragma title ("TESTPGM: C Sample program")
– – –  79988984A8A98447ECEEDCD74C4E899984999898975444444444444444
– – –  B7917410393350DF3523774A03021473507967914FD000000000000000
000002 // This is a Comment
– – –  664E88A48A484C899989A4444444444444444444444444444444444444
– – –  1103892092010364455300000000000000000000000000000000000000

This is the Vertical Hexadecimal display mode. The capital letter C has the hex value C3, so directly beneath each capital C in your data, the hex digit C will be displayed, and beneath that, the hex digit 3.  The 2-character hex value C3 is thus displayed directly below the single text character C and it all lines up in a way that is easy to read. Well, as hex displays go, it’s easy to read.

That’s vertical mode, and that accounts for the "VERT" where it says HEX ON VERT in the related =PROF> display (which I omitted from the illustration above for simplicity). The other option — DATA instead of VERT –does not line up beyond the first character in each line.   If your capital C happened to be in column 1, the hex digit C would go right beneath the capital C in the text, but then the asociated 3 would come right after it on the same line, meaning that the hex equivalent for the letter after your capital C would start in column 3 on the hex line.  So, okay, if you edit data records that are only one or two bytes long, maybe you would want that, and the hex would only take up one extra line per record, rather than two. Most of us actually don’t have any data like that, though. Anyway . . .

When you enter HEX OFF the hexadecimal display lines disappear.

This setting is remembered in the edit profile for the type you’re editing. So suppose you enter HEX ON to see the real hex values of some gibberish-looking data, and then you're interrupted.   When you come back, it's time to go home, and you've forgotten about the hex and you don't look at the screen very closely.  You press F3 a few times, logoff and go home. You come back another time and select option 2 to edit that data set again, or any other data set with the same ending on its name. The data will automatically be displayed with the Vertical Hexadecimal display mode.  Yes, and this is only part of what TSO/ISPF Edit profiles will do for you.  And no, it isn't a funny prank to do that to somebody when they walk away from their desk without locking their display.  Find some other way to express your affection.  Or disaffection, as the case may be.

Unlike the HEX setting, HILITE has meaningful additional operands you can (and should) choose.

HILITE means COLORS — Setting HILITE ON causes program source to take on meaningful colors, like what you get with pretty much any good PC-based program source editor.

You can enter HILITE ON to activate the basic feature.  However, if instead  you enter the word HILITE by itself, a useful popup screen will appear (named ISREP1).

You are shown (on ISREP1) a list of the choices you have for the type of highlighting you want, such as COBOL, REXX, JCL, XML, C HTML, PASCAL …You can page down (F8) to see more choices.

When you just type HILITE ON, with no specifics beyond that, the software generally tries to figure out what type of data/source you're editing, based largely on its quick evaluation of the first few lines. The evaluation is usually good, but you can do better. Since this is a C data set type we're editing — remember we entered a data set name with .C on the end — we're going to assume the data set we're editing contains C source code. (Yes, really I mean C or COBOL or whatever you found that you could use for this.)

Yes, that's why we chose .C in the first place, just to illustrate what you can do with highlighting. You caught me at it again  :)

So we're sitting here with the ISREP1 popup screen displayed in front of us. The title of the panel says "Edit Color Settings".

You Tab forward to "Language:" and you put in the number 4 to indicate C (unless you see some other choice you like better for your own situation).

You hit the Tab key again to go to "Coloring:", where you put 3, for "Both IF and DO". I've failed to imagine a scenario where anybody would want only one or the other of those, but such a thing must be possible, or the choices wouldn’t be offered. Maybe you can think of some hypothetical situation I've overlooked.

You tab forward again, and you make sure to put a slash (/) to the left of "Parentheses matching" to select that feature. Seriously, isn't that one of the main reasons you want highlighting? So you can get matching sets of parentheses in different colors, so they, uh, match ? Again, my imagination must be deficient, not seeing when anybody would say no to this. Anyway, you can keep tabbing forward and use slashes to select both of the next two options as well, which seem to embellish the results of the FIND command. (If you want to unembellish them after you’ve seen them, without resetting anything else, the magic phrase for you to use there is RESET FIND.)

You press Enter, though you don’t need to, and you stare at the screen for a second to make sure it suits you. You press F3. You're back on panel ISREDDE2 and, if you are in fact editing program source, it should be a lot easier to read now (unless of course you already had the highlighting turned on before we did this . . .)

One other very important thing for you to have in your ISPF edit profiles is RECOVERY.  In all but very rare and unfortunate circumstances, you want to set RECOVERY ON. This has the happy effect of enabling the UNDO command to work.

You want the UNDO command to work.

If you ever see the message “UNDO not available”, your first response should be to set “RECOVERY ON”. However, there is another way to get the UNDO command to work: Enter “SETUNDO STORAGE

Recovery is a feature designed to protect you against losing your editing changes if some disaster strikes while you’re in ISPF edit — A power failure, a system crash, or your TSO session freezing up and eventually getting cancelled. When RECOVERY mode is ON, a temporary work file is created, and ISPF keeps track of your changes using the work file.   When you come back later after the disaster, you get a chance to save what you had been editing.  One warning, the EDIT session you have while in recovery processing is not exactly the regular edit mode.  If you want to continue editing the same source, it's a good precaution to go ahead and save what  you get from recovery processing, exit from edit, and then go back into a new edit session.  Just sayin.

RECOVERY ON does slow you down just a little, but on a decent system the difference isn’t even noticeable in most cases. Occasionally, though, if you are editing a very large data set and making a lot of scattered changes, and your response time seems to be excruciatingly slow, you might pick up a little bit of speed if you choose to turn recovery off and take your chances with disaster; but issue the “SETUNDO STORAGE” command anyway, which, as far as I've ever seen, doesn’t slow you down in any way detectable by ordinary mortal people.  It's a good idea to issue SAVE fairly often in that case (if you're making changes you want to save).

SETUNDO STORAGE” causes the software to keep track of your changes in a table in memory, and then the UNDO command can use that table to back out your changes when you say UNDO.

If you are using RECOVERY ON, and you ever see the message “Recovery suspended”, that means UNDO is not going to be able to undo your changes by using the work file. That can happen if the work file fills up and can’t be extended. Besides UNDO being gone then, the disaster recovery feature is gone too. Sometimes you can just save your changes and exit from edit, then go back in, and the Recovery feature will become available again, or can at least be turned back on by saying “RECOVERY ON”; but sometimes not. In the latter case, you might try talking to someone responsible for z/OS system maintenance at your site, and let them try to fix it. Meanwhile of course you’ll be careful enough to save your edited data set at judiciously chosen intervals, and to use “SETUNDO STORAGE”.  Note that SETUNDO is all one word. No spaces. Important point to remember if you expect to be needing to use it.

On balance, all else being equal, you want RECOVERY ON

If that doesn’t work for you, then you want to say SETUNDO STORAGE

There are some other things you eventually want to know about in your edit profile settings, but let’s leave that and skip ahead a bit now, to some overview stuff.

To make the =PROF> information lines go away again, you do not say PROFILE OFF. That has the humorous effect of changing the name of the profile in use from “C” to “OFF”.

What happens there is this. You can use a different PROFILE for editing your file, it doesn’t have to be the name from the file extension — that’s just the default.   On the mainframe, the concept of using the file extension as a data set type has been around since before z/OS, since before its predecessor MVS, for as long as TSO has been a product, before the most ancient PC was ever built, when the very idea of a personal computer was, like cell phones, still Science Fiction. You’d think people would have caught on by now, yes?  but no, not really. People don’t stick to the plan. Most people don’t even seem to be aware of the plan. And it isn’t enforced. IBM likes to give people choices (which is both a blessing and a curse). So people name their data sets with any whimsical extension that seems like a good idea at the time. There are boatloads of data sets containing C programs but having file extensions like .C2, .C3, .CSOURCE, .Cx, .PROGRAMS, and so on. By default that would mean the creation of a separate profile for every such “type”, leading to an awfully lot of edit profiles being created for you.

The z/OS system, left to itself, as distributed, allows a maximum of 25 edit profiles, to correspond to a possibility of 25 data set types. While that might be enough if people named data sets according to a plan that treated the ending as the file type, in the real world the default should be something more like 255, which happens instead to be the maximum that your z/OS system maintenance people at your site can specify if they want to change it (the setting is called MAXIMUM_EDIT_PROFILES).

My recommendation is that you try to ask them (as nicely as you can) to do that:

Increase MAXIMUM_EDIT_PROFILES to 255, as documented by IBM in the “ISPF Planning and Customizing” IBM manual.

What happens if they leave it at the default of 25, and you have just gone into ISPF edit on your 26th ever data set type? Your least-recently-used edit profile is deleted, unless you’ve “locked” it to prevent that. That’s why you want the maximum to be increased. Not because you want a lot of edit profiles with names like CX2, DATAX and BKUP, but because you don’t want your real edit profiles to roll off the stack.

What you can do (without involving anybody changing the way ISPF is set up)  is to set up a few edit profiles the way you want them for a few data set types, and then LOCK those profiles. After that, when you edit a different data set that is really the same kind of data set but it isn’t named with the same extension at the end, you can enter something like PROFILE C to put into effect your saved edit profile named C, or PROFILE JCL to get the one called JCL, and so on. To lock a profile, you enter PROFILE LOCK on the command line.

Right, you’d think that would just bring in a profile named LOCK, wouldn't you?  But no, this is how they implemented the feature. You enter the command PROFILE LOCK. Later if you want to change something in the profile, you say PROFILE UNLOCK before you change it. If you forget to do that, then any changes you make to the profile will be temporary, meaning the changes will disappear when your edit session ends, and the profile will go back to the way it was. When you edit a data set with a name like SOURCE.C.BKUP and you want to use your C program profile settings, you enter PROFILE C on the command line, and you’ll get the highlighting and such that you put into your edit profile named C.

So you don’t say PROFILE OFF, which would bring about the use of an edit profile named OFF.   No, what you do to get rid of the PROFILE display is you say "RESET", or "RESET SPECIAL". Yes, those =PROF> lines are SPECIAL lines, as differentiated from, say, LABEL, ERROR, CHANGE, COMMAND, or EXCLUDED lines, any of which can also be RESET separately.

COMMAND? you ask.   Really? When would somebody want to say "RESET COMMAND", in reality, in the real world? It's a digression, but since you ask . . .

Suppose you're editing a big program source file, or a data file, something big, and you've excluded some lines and done other things to get the display to show you exactly the part you want to look at, but somewhere along the way you inadvertently typed, oh, say the letter "M", in a line number field, while you were paging up and down through the data. Now the upper righthand corner of the screen — the "SMSG" (short message) area — says "MOVE/COPY is pending", and the editor won't let you do the stuff you want to do until you deal with that.

You don't just want to say "RESET" and lose your carefully crafted display of the lines of interest. You certainly don't want to page up and down endlessly through the data looking for the errant keystroke.

Voila, you have found the situation where you want to say "RESET COMMAND".

Similarly, to get rid of the PROFILE display lines without affecting anything else, you can say "RESET SPECIAL".   The other thing you can do is just delete them with the “D” or “DD” line commands, just as if they were source lines. Yeah. It also works for other non-data lines you might get from time to time.

So, that’s enough meta-level information.

We can go back and look a little at more of the edit profile settings if you still want to know more, but you’ve got all the basics you need now — at least as far as ISPF Edit Profiles.  Although, having a bit of knowledge about the workings of line numbering, Nulls, and ISPF stats can occasionally be quite useful  . . .

The other settings . . . Well . . .

STATS controls the “ISPF Statistics” that show up in the member list of a library (a PDS, Partitioned data Set, PDSE — it has several names, but we’ll call it “library” for now). The name “ISPF Statistics” refers to data like the date, time, and userid associated with the last change to the data.   So if you edit a member, and save it, the statistics will have your userid together with the date and time it happened, if you have STATS ON (which is the default). If you don’t want the statistics to appear, you edit the member again, and type STATS OFF on the command line. Press enter, then type SAVE. Press F3 to go back to the member list, and the statistics are gone. When would you do this? If you have a library that is usually updated by some batch job, and it does not update the ISPF Statistics, then any existing ISPF Statistics, such as the record of your edit, will remain as a long-standing monument to your edit session. That would be misleading if the batch job ever updates the data subsequent to your edit update — it would look as though the batch job's changes had been done in your edit session.  So you'd want to get rid of the ISPF Stats in that case, to avoid confusing anyone.  There may also be other types of cases where you would do this; I don’t really know about that, though.

The main things for you to know about the ISPF statistics are: (1) That they are controlled by you, setting STATS OFF or STATS ON, but if you don’t do anything, the default is ON, and that means your userid plus the date and time of the update will appear in the member list after you SAVE the member. (2) You can also change the ISPF Statistics outside of edit, using ISPF option 3.5, (3) The data inside a library member can be changed by a program, usually running in a batch job, without causing the ISPF Statistics to be updated nor destroyed (although some batch jobs do update the stats). (4)   If you copy a member from one library to another, for example using ISPF option 3.3 copy, or using IEBCOPY in a batch job, the ISPF Statistics are copied along with the member (even though the stats are not contained within the member itself. They reside in the “directory” of the library.) So if someone copies a member from one of your libraries to some other library, and some third person just looks at the member list, they might easily think that you’ve been editing that other library. In some cases that can lead to social incidents. It’s just something for you to know, so if somebody ever asks you, perhaps in a hostile manner, why your stats are on some forbidden library, and you honestly have no idea, remember the words “3.3 copy”. Somebody (not you) must have used an ISPF 3.3 copy. That explains everything. You’re innocent. Innocent, I say. Really.

The Line Numbering settings (NUMBER and AUTONUM) are interesting to the extent that they sometimes cause trouble by virtue of their relative invisibility.

Here is a quick introduction to Ispf line numbers: ISPF line numbering differs depending on whether the data you are editing contains fixed length records or varying length records.

For fixed length records, based on an ancient tradition originating in the time of punched cards, the line numbers are put into the last eight columns of each line, on the far right. ISPF has put a tweak on that, though. If you are editing a member of a library, and if you have STATS on (which is the default for STATS), then ISPF borrows the last two digits of the line number and uses those for the “modification level number”.  They start out as 00. If you change any line in an edit session, the 00 at the end of that line becomes 01 (no matter how many times you change it within the same edit session). Go out of edit and come back, change the line again, and it goes from 01 to 02. And so on.

For varying length records, the punched card scheme doesn’t work, since there are no specific column numbers that can lay claim to the title of being the last eight columns for all the records.  So the line numbers go into the first 8 columns.

There is a “third way”, called COBOL line numbering. If you say NUMBER ON COBOL, then the line numbers go into the first six columns of each record, which is a COBOL standard.

The "fourth way" of course is NUMBER OFF, my personal favorite.  When you use NUMBER OFF, you still see line numbers displayed by the editor on the lefthand side of your data.  Those line numbers that are displayed are not actually in your data records, though.

What kind of trouble can the line numbers cause, and in what way are they invisible, you might ask. Take a quick example.

Your data is composed of fixed-length 80-byte records, and the last 8 columns are blank. (You have NUMBER OFF in effect.)   Your screen happens to be set to size 24 x 80 (24 lines by 80 columns, the usual default, and you haven't changed it).

The editor displays line numbers on the left of the screen regardless of whether or not there are actual line numbers within your data.  Since that line number display takes up the lefthand portion of the screen, you don't see all 80 columns of your data, and so you do not see the last 8 columns (unless you scroll over to the right using F11, which usually you don’t).

With those circumstances in effect, you decide to excerpt a few lines from some other data set and insert them into the source you're editing — maybe a few lines of a C program that do something you want. Quite unknown to you, the data you're borrowing was previously edited with NUMBER ON in effect. So now you have eight invisible digits at the far right of a few of the lines in your own file. You can see them if you scroll right (by pressing F11), but you don’t think about it.   Soon, if it’s a C program, you compile it, or if it’s an EXEC, you execute it, or if it’s data, you feed it into the program that reads it as data.  One way or another, you try to use it and you start getting bizarre error messages that make no sense to you. That is, they make no sense until you idly happen to press F11  and the display scrolls right, making columns 73 through 80 visible, and you observe the stranded line numbers hanging there.

You can mystify yourself for half an hour finding that; even longer, if you’re tired or something.

What else can go wrong? Another example.

You have data without line numbers (You have NUMBER OFF in effect), and you decide you want to have line numbers. You enter NUMBER ON, or just NUMBER with no operands, and the editor generates line numbers for you immediately, inserting them into columns 73 through 80 of your records, as if by magic. Unfortunately in this case, you happened to have data in some of those columns already, but only in a few records that you hadn't noticed. That data is overwritten by the line numbers. So a record that, a few short moments ago, ended with “/*This line is fine*/”, now ends with “/*This line is01230000”.  You don't notice immediately.  Next time you compile the program, a few lines of your C or PL/I program are ignored by the compiler because they have become part of a comment that starts with "/*This" and will end when the next “*/” is found, perhaps a few lines down.  In  languages that allow multi-line quoted strings, this same trick can also work with a multi-line quoted string  :)

If you're lucky, the compiler will generate an error message — though it's likely to be a bizarre and baffling message, telling you that you have a missing "end" statement, or an "else" without a preceding "IF", or mismatched parentheses.  That might not happen, though.  Some compilers will give you a  warning message when they notice a semi-colon embedded inside a comment, and this is one of the reasons such warnings exist; but not all compilers do that.   It is possible that no error message will be generated at all, if the particular lines of program code you've accidentally commented out do not prevent the compiler from making sense of what remains — for example if you only commented out a line that increments a loop counter or resets a pointer, leaving you with an infinite loop, or if you inactivated some lines that subtract a fee, or add a bonus, in some accounting calculation, leaving you with trouble.  Oh well. That’s line numbers for you.

There is a command UNNUM that you can use to remove line numbers, replacing them with blanks.

When you have Line Numbering active, and you insert new lines between existing lines, the editor generates in-between line numbers for the new lines.  If you insert two lines between line 200 and line 300, they'll get line numbers such as 210 and 220 assigned.  If you insert two more lines between 210 and 220, those will become 211 and 212.  When you insert a new line between 211 and 212, the editor changes 212 to be 213, and gives the new line the number 212.  So if you go on like that for a while, inserting more lines between other inserted lines, eventually you're generating a lot of renumbering work for the editor whenever you insert a line, and having the editor do all that extra work slows it down.  That brings us to the RENUM command.  When you issue RENUM the editor renumbers all the lines, using increments of 100.

That, in turn, brings us to the AUTONUM profile setting.  If you are using NUMBER ON and you have AUTONUM ON as well, the editor will automatically do a RENUM of the data as part of SAVE processing.  Interestingly (which in this case means "confusingly"), the line numbers being displayed are not changed as part of AUTONUM processing.  It makes sense when you think about it for a second — the renumbering is part of the saving — but it still feels like an oddity.

NULLS is another setting that can be of interest in that it can both create trouble and do the opposite. Most of the time you don’t care, but occasionally you do. Setting NULLS on or off makes other commands behave differently.

Say you want to cut-and-paste some comments into columns 60-70 of your data, all lined up nicely on the far right. You find that when you press enter, the comments are pulled back to the left, so there is only one blank between whatever was on the line before, and the comment you added. That means you have NULLS ON.   Say UNDO so you can try again. Say NULLS OFF. Again paste your comments into columns 60-70 of your data, all lined up nicely on the far right. You press enter, and your added comments stay where you put them.  That’s one practical example.

The underlying idea here is that blanks, in particular trailing blanks, are viewed differently depending on the NULLS setting. With NULLS OFF, the tendency is for each trailing blank to be treated as a character occupying space, whereas with NULLS ON, each additional trailing blank after the first tends to be viewed as more like empty vacuum space.

I don't have a good example to illustrate that right now, so let’s look at something totally irrelevant to edit profiles, but relevant to blanks and nulls.   I’m guessing you don’t yet know about the data shifting line commands. They’re good, and they’re interesting, very useful.

A single right parenthesis ) shifts data right, and a single left parenthesis ( shifts it left. If you put )5 on a line number and press enter, that shifts the data right 5 places, and (5 shifts the data 5 positions to the left. This is a straightforward shift. All of the data on the line is shifted, and data at either end of a line can be lopped off (truncated, as they say) if you shift too far. On balance, when you do )10 and follow it with (10, you end up where you started, except for any data you may have lost due to truncation.

Of course you can say )) on one line, and then go down a few lines and put another )) to shift the data on a block of lines all at once.  Either )) can also be followed by a number, as shown for single parentheses.

The “greater than” > symbol and the “less than” < symbol also shift data right and left. They treat embedded blanks differently, though.  Essentially they squish out embedded blanks.

Typing >7 and pressing enter, followed by typing <7 and pressing enter, does not get you back where you started.

> and < eliminate blanks, compressing a string of consecutive blanks into one blank.  It isn’t totally obvious what the elimination pattern is, though.   You need to actually do this yourself to get a feel for what it does, if you have any interest in ever using these. If you do, then put some blank lines into your data to start the demonstration. Be sure you have NULLS OFF. because you're going to use copy and paste for the setup.

Let’s assume you have ctrl-C and ctrl-V set up to mean copy and paste, or at least that you have some method of doing copy and paste. Highlight the line numbers on the far left, and press ctrl-C or your equivalent thereof. With that column of numbers safely tucked into your carryall, you move the cursor out across your blank lines and paste the numbers down a few times, so in the end you have dropped down three or four columns of data, leaving several blank spaces between each column.

While we're on the subject of copy and paste, let's sneak in an introduction to other cut/copy and pasting you can do in ISPF edit.  If you already know all about it, skip this rather long paragraph, and we pick up the discussion of <<>> data shifting again just after.  So —  You also have at your disposal a  line-oriented, non-cursor-based, ordinary TSO/ISPF edit command called CUT.  You also have PASTE.   To try it, do this.  Put CC on a line number field, and then go down a few lines and put CC on another line number field, then go up to the command line and say CUT  AAA and press enter.  (Or you can say CUT  BBB, or CUT  ITOUT, or use any other short valid name.)  The lines you marked have not disappeared from your file, but they have been copied into a holding area.  (So, yes, it's a misuse of the word "CUT".)  Now go to another place in the same member, or, more fun yet, go into split screen mode, and go edit some other file on the other screen.  Put the letter A on one of the line numbers there, and, on the command line, say PASTE AAA (or paste bbb, or whatever you called it).  The text you captured will be inserted into the place you've designated.  Why did they call this CUT instead of COPY?  Of course it's because they already used COPY for something else.  Put the letter A on one of your line numbers, and then move your cursor up to the command line and say COPY.  Press Enter.  It will pop up another screen for you, where you can enter the name of some other file.  When you press enter, that other file will be copied into the place you designated with the letter A (which in this context meant "After").  If you had said COPY CAT on the command line, rather than just COPY, the editor would have looked for a member named CAT in the library you're editing, and copied that into the place you designated.  But again I've digressed.  Back to the data shifting commands.

Go over to the line number field and put in >3 and press enter, and then do it again. Then do <3 on the same line and press enter, followed by another <3 and enter. It should have shifted the lefthand columns of data, while leaving the righthand columns unmoved.  If it isn't clear what's happening, Try  a few more iterations of >3 and <3 shifting until it seems to make sense.  (or you can do <2 or <5 or whatever is comfortable.)

You do know that the way to get out of EDIT without SAVING your changes is to enter CANCEL, right?  Very important editing command, CANCEL.

This >> << type of shifting can be useful when you don’t have columns, but you don’t have much room on the right or the left either, and you don’t mind losing embedded blanks.

As long as we’re on this tangent, you should know about TS (text split). Put TS on a line number, then move the cursor over to where you want to split the line, and press enter then. It splits the original line into two lines.  The first of the two ends at the point where you had the cursor when you pressed enter.

TF (text flow) is the opposite of TS. It runs lines together. Quite often it runs together more lines than you intended, so you need to be a little careful. It will stop accumulating its long string when it comes to a blank line, or when it comes to a line with different indentation.

SCROLLING – You want to know how to change your settings so that if you put the cursor anyplace on the page and press F7 or F8, then the page will go up or down based on where you placed the cursor.   Oh, same thing with F10 and F11, you also want to do left-right scrolling based on cursor position.  Okay.  First press the home key to go up to the command line (assuming you have the command line at the top).  Then press the Tab key to move to the field on the right labeled Scroll.  (If you do not have your command line at the top of your screen, then just press Tab a bunch of times until you end up in the field labeled Scroll.)  In the Scroll field you type the word CSR (an abbreviation for CURSOR) and press enter.  That's all there is to it.    Perhaps you're asking,  Why isn't this the default?  One can only wonder.  It's one of those questions pondered by philosophers I guess.  Certainly it's hard to imagine any rational reason.  Anyway, you Tab over to the Scroll field and enter the value CSR, and that does it.  The change should be saved when you exit.   ISPF Scrolling is not specifically an Edit thing — The same method works on other ISPF screens that have scrolling, such as the ISPF 3.4 Dataset List display.

So, hopefully we’ve covered the main things you want to know about edit profiles.   Congratulations, you now know more about it than a lot of people who have been using the ISPF editor for years.  Oh well, maybe you can help them out sometime. :)

The IMACRO edit profile setting allows you to specify an initial edit macro — to designate an EXEC containing a bunch of edit commands — to run automatically first thing whenever you go into an edit session using that edit profile. Anytime I ever used that feature, it was very slow, and not worth doing. They may have improved the feature since then, but I don’t bother with it. Edit macros can form an entirely separate topic in themselves, anyway. If you stick with z/OS you’ll want to learn to use edit macros eventually, but that's a topic for another day.


Updated 26 April 2016 to add the paragraph on SCROLLING — what an oversight to have omitted that originally!  Sheesh.