AUTOMATIC SX37 ABEND RECOVERY IN AN ISPF EDIT SESSION 
by CRAIG HENSBY

A common occurrence in the ISPF manipulation of PDS (partitioned
datasets) is the Sx37 abend.  Collected under this category,
SD37, SE37 and SB37 are generally assumed to be space related
system abends.  Any active PDS will eventually run out of space
as new members are created and old ones are saved via the ISPF
editor.  The more DASD-constrained a data center is, the more
frequent this type of abend, and the more annoying it is to ISPF
users.  And whom do the users get mad at?  As usual, the local
DASD sheriff gets the blame.  Especially since he or she has
probably aggravated the situation by regularly implementing
schemes to release dead space from user PDSes and by establishing
restrictive rules on the use of secondary space allocations.  In
the sheriff's defense, no one keeps files as cleaned out as they
should be, and at some point, the growth of user files needs to
be brought under control. 

Once an Sx37 abend occurs in an ISPF edit session, the only way
to save a PDS member is to compress the file, either by a TSO
command or by getting into a split session and compressing from
option 3.4, and then entering the SAVE command again.  This same
strategy applies to the CREATE, END and REPLACE commands. 
However, this is not the only way to save the member.  You could
also choose to save your new or changed member in a different
dataset that contains enough free space to hold it. 

A while ago, I found myself as the bad guy DASD manager setting
up a job to compress all user PDSes and release the dead space
from them.  To compound matters, established shop policy
disallowed secondary space allocations on such datasets.  I did,
of course, provide for some free space to be left after the space
release was performed, but it was obvious that users would be
getting considerably more Sx37 abends than ever before.  I
decided to use the ISPF MACRO facility to intercept the abends
and retry the command without interrupting the user's normal
routine.  It took some time to develop the macros, but they have
been working for years with no complaints. 

The first macro you need is an IMACRO (initial macro) to assign
the new macros to be used instead of the BUILTIN or native ISPF
commands.  I call this one MACSTART.  It must be assigned by the
user as the initial macro, which is called as you enter an ISPF
EDIT session for the PDS, by EDITing a member of the PDS, typing
IMACRO MACSTART on the command line and saving the member.  The
macros must be accessible in your CMDPROC concatenation (an
installation CLIST library, for example.) See Figure 1.

Don't forget to document the method described in Figure 1 so
users can get MACRO MACSTART into the IMACRO variable in the
profile for each PDS dataset.  Now, every time a user begins to
edit this dataset via ISPF, all commands that relate to expansion
of the PDS are assigned a macro to execute on their behalf.  If
the macro doesn't do what the user wants it to, the user can
enter the primary command BUILTIN SAVE to bypass the macro call. 
Before the other macros can be used, a COMPRESS command must be
installed for use from TSO foreground.  I use the CLIST in Figure
2 which is based on an IBM example. 

Some minor explanations are in order.  The general approach is
to: 

o Attempt the BUILTIN COMMAND 
o If Condition Code = 0 
      Return 
    Else 
      Compress the file 
      Re-attempt the BUILTIN COMMAND 
o If Condition Code = 0 
      Return 
    Else 
      Notify the user that the file needs to be enlarged. 

Some other side effects of these macros are: 

o The CREATE command with no MEMBERNAME specified will cause a
short error message.  Using the HELP command, usually PF1, to get
the long text message will instruct the user to use BUILTIN
CREATE to get into extended CREATE mode.  This also applies to
the REPLACE command. 

o Both the CREATE and REPLACE commands will by default copy the
entire member when no FROM and TO line numbers or COPY BLOCK are
provided.  This is probably what the user wants to do anyway. 

o I included member recoverability in my MACSTART MACRO to help
our users.  You may not want to do this, and it is not necessary
for the other functions to work properly. 

o If you frequently use the PDS utility to recover old members
from your libraries, this inadvertent compression could get in
the way.  Remember that after file compression, old members are
permanently lost. 

o The messages issued by these macros assume that space was the
problem.  It could also be that no directory blocks are available
for a new member.  You might want to re-word the messages if this
is a concern, but I have not found it to be a problem.

These macros have proven serviceable.  I trust you will find them
useful.

/*
852