FAQ is a collection of answers to some of the common Mainframe MVS questions,
which tend to pop-up from time to time. The answers (however trivial
they might be) get easily forgotten in the day-to-day routine, and sometimes
they are hard to find in the seemingly endless and often confusing labyrinths
of the MVS documentation. However, when you need the answer, it might
be a burning issue, and a desperate search under pressure can be quite stressful
brother Victor and I have been collecting those answers for several decades
and it seems it's about time to select the most important information from
all of our scattered notes into one FAQ which will be hyperlinked for the
ease of use, and will be accessible from anywhere and by anybody who might
have interest in it. However, this selection is not compiled for the
Web only – rather it's our working reference, which we try to maintain
as accurate and current as possible. As such it inevitably
will always lack an overall integrity and completeness, yet it is still a
rather useful tool that often saves time.
of the questions originated from a real-life experience of a professional
mainframe programmer. Most of the answers were found (or verified)
in the MVS documentation (lately in the
IBM Book Manager) or on-line
Help. Every answer was checked to the best of our competence, and
as a rule was tested by many years of repeated usage. This is not
to suggest that it is in any way guaranteed to be error-free –
you will be using any advice you pick from this FAQ
entirely at your own risk, and will be completely responsible
yourself for any problems that might arise from this usage.
So when trying an advice, please exercise the common sense precautions, and
test it most thoroughly yourself before applying it to anything
legal mantra been chanted, I want to mention that all error reports and any
comments about this FAQ are most welcome, and I'll try to do my best to fix
any known problem as quick as I'll be able to do this.
Apart from the natural curiosity, the knowledge of
the MVS version that one is using might be required in order to
to look for system messages either in IBM
Book Manager or QuickRef.
Open SDSF session and enter
primary command WHO. In reply to this command
SDSF will display several lines of information
describing session environment and containing among other useful
things versions of MVS, JES, ISPF and
Compile date might be needed for various reason,
the most typical of them is the necessity to compare load modules
of the same program in different libraries.
Open program partition for browse in the load
module library. Scroll one screen right ([F11])
and you'll see the program name immediately followed by the date
in the format of YYYYMMDD. This is
the program compile date.
The ChangeMan package, in which program was compiled,
might be needed in order to get a list of associated objects, as
well as program compilation printout saved in the ChangeMan archive.
The latter is useful for program code analysis and is indispensable
Open program partition for browse in the load
module library. Right on the first screen you'll see program
name followed by a "/", hex number (ChangeMan
ID code of load module), and another "/",
which is immediately followed by ChangeMan package number.
Define file as having variable
length records in a way similar to the following (MODE
and BLOCK lines are useful for output files only
— to avoid specifying RECFM and BLKSIZE in JCL):
RECORDING MODE IS V
BLOCK CONTAINS 0 RECORDS
RECORD IS VARYING FROM 1 TO 1000
DEPENDING ON Record-Length.
01 Var-Length-Record PIC X(1000).
Maximum record length is assumed here to be
1000 bytes (minimum is always 1).
Record-Length variable should be defined as an elementary
unsigned integer capable of holding the maximum length
value —  PIC 9(5) BINARY  for the above
example. Record-Length treatment depends on the I/O
The actual length of the record prepared
for the output must be placed by the program into
Record-Length variable before any output
operation (WRITE, REWRITE
The actual length of the record just read
gets placed by the operating system into
Record-Length variable after the successful input
Execution of an output operation as
well as execution of an unsuccessful input
operation doesn't change the value of the Record-Length
Omission of  FROM ... TO ...
range specification is tolerated by the COBOL compiler, but output operation
causes S0C4 AbEnd (protection exception)
in this case.
The most common reason of a B37
AbEnd is a situation when operating system can't allocate secondary
extent for DASD output data set because there is not enough space
on the DASD unit[s], defined for the data set allocation.
Sequential data set can be allocated in up to 16
extents (normally one primary and up to 15 secondary). When
Operating System can't find space for primary allocation, job gets
cancelled with JCL error before attempting to execute it.
If primary allocation request is satisfied, job starts running,
allocating secondary extents when (and if) necessary. If
an attempt to allocate secondary extent fails, job AbEnds
There is a popular belief that increasing primary
space solves B37 AbEnd problem. Indeed,
it might work for some situations, but it might fail to work for
other (those with significant deviations in the size of the data
set). B37 AbEnd is caused by the
failure of secondary space allocation and this is what
should be addressed when fixing a B37
The right solution is to specify more than one
(default) UNIT for the output data set, E.g.: UNIT=(SYSALLDA,3).
Thus, when system can't find secondary extent on the first volume
(i.e. volume where primary extent is allocated), it switches to
the second volume, etc. Normally specifying 2 or 3 UNITs
will work, but it might make sense to specify more, depending on
the number of generally available DASD units and predicted deviations
in the data set size.
Provided that there are enough DASD units for secondary
space allocation, it is important also to maintain some sort of
a reasonable balance between primary and secondary space requests.
While there are no universal rules for determining what balance
is "right", there is "rule of a thumb" that works reasonably well
in most cases.
Evaluate the "peak" volume of the output
data set (CYLs or TRKs). One good way is to look at input
file processing of which caused B37 AbEnd
and make approximate adjustments based on the ratio of output/input
record lengths. Let it be 100 CYLs, for example.
Use 50% of the "peak" volume as primary
space and 10% of the peak volume as secondary space.
This will give the following space allocation for 100 CYL "peak"
volume example:  SPACE=(CYL,(50,10),RLSE).
Requesting to ReLeaSE
unused space when the output data set gets closed is a good
practice improving the overall system performance.
As can be easily seen, this allocation balance,
while requesting only 50% of "peak" volume
upfront in primary space request, permits to increase
data set size up to 200% of the "peak" volume
(50%+15*10%=50%+150%=200%). Provided, of course, that
the sufficient number of DASD units was defined. For
most practical situations (a typical one is space request
for sort work files) this will be a reasonable balance between
primary and secondary space.
/ Program Development
How to position
screen at the specified text line in the Edit/View/Browse session?
Screen positioning is the most basic and obvious
operation in dealing with texts and lists of data sets or library
members. It is repeated dozens of times every day and even
minimal shortcuts can save hundreds of keystrokes. Some of
the descriptions below are based on the presumption of the standard
functional key assignment of UP/DOWN
primary COMMANDs to [F7]/[F8]
In order to make current cursor string
first/last on the screen make sure that you have
Scroll ===> CSR
and simply hit [F8]/[F7] key.
If you have
Scroll ===> PAGE
(this is a default in most applications), overtype PAGE
by CSR (CurSoR)
and exit and re-enter the application so that scroll amount
setting will be saved in the profile.
If you want to position screen to text top,
use 3 successive keystrokes [Home]–[M]–[F7];
use [F8] as a last keystroke to position
screen to text bottom. TOP/BOTTOM
commands (or equivalent UP MAX /
DOWN MAX) can be used also, but this
is a longer way (unless you'll assign those commands to functional
keys — however, this might not always work with the applications
which would redefine functional keys their own way).
In order to move screen for a certain amount of
lines up/down type this amount in the primary
COMMAND field and hit [F7]/[F8]
If you know the relative line number (left
column in the Edit/View session), use Locate
primary COMMAND (can be abbreviated to L)
to make desired line first in the text area of the screen.
E.g.: primary COMMAND L 123
will position screen to the line number 123
(from the beginning of the text). It is possible to use
the same method in the Browse session, but it's less obvious where
you are, since there are no displayable relative line numbers in
Browse (relative number of the first line in the text area
of the screen is displayed in the top-right corner, E.g.:
If you have to skip many times to the same
line of the text, you can label this line by overtyping line number
field with a line label, e.g.: .A or .XYZ
(should start with "."). To make labelled line first
in the text area of the screen enter L .label
primary COMMAND. E.g.: L .A
will position screen to the line labelled .A.
Line labels are applicable to Edit and View sessions only.
You can have as many labelled line as you wish, but it's hardly
practical to use more than just several of them. Line labels
are lost once you leave Edit/View session. Use RESet LAB
primary COMMAND to delete all line labels.
Find command in the SDSF
has a default limit of 25,000 lines. This makes the
data search in the long output a rather annoying procedure,
especially considering the fact that SDSF
limits DOWN to 9,999 lines only.
"RFIND is not active" in the SDSF,
and the ability of SDSF Find
command to "remember" the parameters of it's previous entry
is a poor substitute for the actual RFIND
(you have to enter Find without parameters
in the Command field
landing each time on already found entry unless you'll hit
[F8] in between).
A simple way to overcome this limitation is to enter
a FINDLIM 9999999
command that will reset the default limit of 25,000 to a more
reasonable limit of 9,999,999 making a search limited practically
only by the end of the file (which definitely should be a default
as it is in the ISPF/PDF).
Alternatively it is possible to enter a FINDLIM ? command to display
the current search limit and to overtype it by 9999999.
In any case it is necessary to exit and re-enter the
SDSF so that search limit setting will be
saved in the profile.