UP 8068_Rev4d_Systems_90 25_90 30_90 40_Operating_System_3_(OS3)_Basic_Data_Management_User_Guide_Jun83 8068 Rev4d Systems 90 25 30 40 Operating System 3 (OS3) Basic Data Management User Guide Jun83

UP-8068_Rev4d_Systems_90-25_90-30_90-40_Operating_System_3_%28OS3%29_Basic_Data_Management_User_Guide_Jun83 user guide pdf -FilePursuit

UP-8068_Rev4d_Systems_90-25_90-30_90-40_Operating_System_3_(OS3)_Basic_Data_Management_User_Guide_Jun83 UP-8068_Rev4d_Systems_90-25_90-30_90-40_Operating_System_3_(OS3)_Basic_Data_Management_User_Guide_Jun83

User Manual: UP-8068_Rev4d_Systems_90-25_90-30_90-40_Operating_System_3_(OS3)_Basic_Data_Management_User_Guide_Jun83

Open the PDF directly: View PDF .
Page Count: 682

Download
Open PDF In Browser	View PDF

Basic Data Management

Environment: 90/25, 30. 30B. 40 Systems

UI\JIVAC

UP 8068 Rev 4

PUBLICATIONS
LiPDATE
Operating System/3 (OS/3)
Consolidated Data
Management
User Guide

UP$068 Rev 4-D
This Library Memo announces the release and availability of Updating Package D to “SPERRY
Operating System/3 (OS/3) Basic Data Management User Guide”, UP-8068 Rev. 4.
This 8. 1 release update documents a correction applicable to a feature present in basic data management prior
to the 8. 1 release,
Copies of Updating Package D are now available for requisitioning. Either the updating package only or the
complete manual with the updating package may be requisitioned by your local Sperry representative. To
receive only the updating package, order UP-8068 Rev. 4—D. To receive the complete manual, order UP-8068
Rev. 4.

Mailing Lists
BZ, CZ and MZ

Mailing Lists AOO, AOl, 18, 18U, 19, 19U, 20, 20U;
21, 21U, 75, 75U, 76 and 76U
(Package D to UP-8068 Rev. 4,
7 pages plus Memo>

Library Memo for
UP-8068 Rev. 4—D

June, 1983
UD1-25 Rei. 3

•

PUBLICATIONS
UPDATE
Operating System/3 (OS/3)
Basic Data Management
User Guide

UP—8068 Rev. 4—C
This Library Memo announces the release and availability of Updating Package C to ‘SPERRY UNIVAC Operating
System/3 (OS/3) Basic Data Management User Guide”, UP—8068 Rev, 4.
This update documents the following new information on the basic data management file lock
feature for the 8.0 release:
How to avoid unnecessary locking out of files
Additional information on file shareability
All other changes are corrections or expanded descriptions applicable to features present in basic
data management prior to the 8.0 release.
Copies of Updating Package C are now available for requisitioning. Either the updating package only or the complete
manual with the updating package may be requisitioned by your local Sperry Univac representative, To receive only
the updating package, order UP—8068 Rev. 4—C. To receive the complete manual, order UP—8068 Rev. 4.

Mailing Lists
BZ, CZ and MZ

Mailing Lists A00,A01,18,18U,19,
19U,20,20U,21,21U,75,75U,76 and
76U
(Package C to UP—8068 Rev. 4,
32 pages plus Memo)

Library Memo for
UP—8068 Rev. 4—C

February, 1983
c•
,Di
p
2

,?3

PUBLICATIONS
UPDATE
Operating System/3 (OS/3)
Basic Data Management
User Guide

UP4068 Re 4-B
This Library Memo announces the release and availability of Updating Package B to “SPERRY UNIVAC Operating
System/3 (0S13) Basic Data Management User Guide”, UP-8068 Rev. 4.
This update for the 8.0 release indicates the availability of a new conversion routine for basic data management. This
routine is the OS/3 Sequential DTF Mode to CDI Mode Converter (DTFCDI3O1). This converter processes a basic
data management BAL source program module and produces a consolidated data management source module that,
with minimal modification, can be used in the consolidated data management environment.
All other changes are corrections or expanded descriptions applicable to features present in basic data management
prior ot the 8.0 release.
Copies of Updating Package B are now available for requisitioning. Either the updating package only or the complete
manual with the updating package may be requisitioned by your local Sperry Univac representative. To receive only the
updating package, order UP-8068 Rev. 4—B. To receive the complete manual, order UP-8068 Rev. 4.

Mailing ListsBZ,
CZand MZ

Mailing Lists A00, AOl, 18, 18U, 19, 19U, 20, 20U,
21, 21U, 75, 75U, 76, and 76U
(Package B to UP-8068 Rev. 4,
29 pages plus Memo)

Library Memo for
UP.8068 Rev. 4—B

September, 1982
uDi

251 1e J73

PuBLICATIONS
UPDATE
Operating System/3 (OS/3)
Basic Data Management
User Guide

UP-8068 Rev. 4-A
This Library Memo announces the release and availability of Updating Package A to “SPERRY UNIVAC Operating
System/3 (OS/3) Basic Data Management User Guide”, UP-8068 Rev. 4.
This update documents the following new basic data management features for the 7.0 release:
Consolidated Data Management migration considerations
New information on the file lock feature
All other changes are corrections or expanded descriptions applicable to features present in basic data management
prior to the 7.0 release.
Copies of the Updating Package A are now available for requisitioning. Either the updating package only or the
complete manual with the updating package may be requisitioned by your local Sperry Univac representative. To
receive only the updating package, order UP-8068 Rev. 4-A. To receive the complete manual, order UP-8068 Rev. 4.

Mailing Lists
BZ, CZ and MZ

Mailing Lists 18, 18U, 19, 19U, 20, 20U, 21,
21U, 75, 75U, 76 and 76U
(Package A to UP-8068 Rev. 4,
38 pages plus Memo)

Library Memo for
UP-8068 Rev. 4-A

December, 1981

PSS 1
Update D

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

PAGE STATUS SUMMARY
Update D UP-8068 Rev. 4
8.1 Forward

ISSUE:
RELEASE LEVEL:
Part/Section

Page
Number

Cover/Disclaimer
PSS
Preface

Contents

Page
Number

Update
Level

6 thru 14

Orig.

Title Page

Orig,

1 thru 75

Orig.

Title Page

Orig.

Appendix A

1 thru 11

Orig.

Appendix B

1 thru 15

Orig.

Appendix C

1 thru 1 1

Orig.

Appendix D

1 thru 32

Orig.

Appendix E

1 thru 26

Orig.

Appendix F

1
2,3

A
B

Index

1, 2
3
4thru6
7
8thrul0
11 thru 23
24
25 thru 27

Orig.
A
B
Orig.
C
Orig.
C
Orig.

Part/Section

Page
Number

Update
Level

Orig.

10 (cont)

16 thru 22

Orig.

16 (cont)

PART 5

l0thru 15
16
17 thru 51

Orig.
A
Orig.
A
C
Orig.
A
Orig.

1 thru 9
10
11 thru 13

Orig.
B
Orig.

1 thru 18
iSa
19 thru 29

Orig.
C
Orig.

1
2
3
4
4a
5 thru 13

Orig.
B
Orig.
B
B
Orig.

1
2
3 thru 5
6
7 thru 12
13
14
15 thru 17
18
i9thru2l

Orig.
B
Orig.
D
Orig.
C
D
Orig.
B
Orig.

1 thru 13

Orig.

1 thru 7
8,9
10
11,12
13
14
15,16
17
18 thru 20
21
22 thru 1 1 1

Orig.
C
Orig.
C
Orig.
C
Orig.
C
Orig.
C
Orig.

2
3
4
4a
5

B
Orig.
A
B
C
C

Update
Level

1
2
3, 4

Orig.
A
Orig.

1 thru 11
12
13, 14
15
16,16a
17,18
19

Orig.
C
Orig.
B
A
Orig.
C

2
3 thru 7
8

13
PART 1
Title Page

Orig.

1
2
2a
3
4 thru 18

Orig.
A
A
A
Orig.

13A

Title Page

Orig.

135

1 thru 4

Orig.

1 thru 31

Orig.

1 thru 5

Orig.

1 thru 12

Orig.

1 thru 12

Orig.

1 thru 31

Orig.

—

Part/Section

17
PART 6

PART 2

PART 3
Title Page

Orig.

1 thru 17

Orig.

1 thru 62

Orig.

Title Page

Orig.

1 thru 7
8
9,10
11,12
12a
13
14,15

Orig.
A
Orig.
A
A
Orig.
A

PART 4

All the technical changes are denoted by an arrow

(-0.-)

User Comment
Sheet

( I next to a line indicates that
( 41 is found. A horizontal arrow (-0-) pointing to

in the margin. A down ward pointing arrow

technical changes begin at this line and continue until an upward pointing arrow

‘

a line indicates a technical change in only that line. A horizontal arrow located between two consecutive lines indicates technical
changes in both lines or deletions.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

PSS 1
Update C

PAGE STATUS SUMMARY
ISSUE: Update C UP-8068 Rev. 4
RELEASE LEVEL:i 8.0 Forward
—

Part/Section

Page
Number

Cover/Disclaimer

Update
Level
Orig.

PSS

Preface

1
2
3,4

Orig.
A
Orig.

1 thru 11
12
13, 14
15
16,16a
17, 18
19

Orig.
C
Orig.
B
A
Orig.
C

Contents

Page
Number

Update
Level

10(cont)

14,15
16 thru 22

A
Orig.

16(cont)

1
2
3 thru 7
8
9
10 thru 15
16
17 thru 51

Orig.
A
Orig.
A
C
Orig.
A
Orig.

PART 5

1 thru 9
10
11 thru 13

Orig.
B
Orig.

1 thru 18
18a
19 thru 29

Orig.
C*
Orig.

1
2
3
4
4a
Sthru 13

Orig.
B
Orig.
B
B
Orig.

1
2
3 thru 5
6
7 thru 12
13,14
15 thru 17
18
19 thru 21

Orig.
B
Orig.
B
Orig.
C
Orig.
B
Orig.

1 thru 13

Orig.

1 thru 7
8,9
10
11,12
13
14
15,16
17
l8thru2O
21
22 thru 111

Orig.
C
Orig.
C
Orig.
C
Orig.
C
Orig.
C
Orig.

2
3
4
4a

B
Orig.
A
B
C

Part/Section

PART 1

Title Page

Orig.

1
2
2a
3
4thru 18

Orig.
A
A
A
Orig.

13A

PART 2
Title Page

Orig.

1 thru 4

Orig.

1 thru 31

Orig.

1 thru 5

Orig.

1 thru 12

Orig.

1 thru 12

Orig.

1 thru 31

Orig.

13B

PART 3
Title Page

Orig.

1 thru 17

Orig.

1 thru 62

Orig.

Title Page

Orig.

1 thru 7
8
9, 10
11,12
12a
13

Orig.
A
Orig.
A
A
Orig.

PART 4

Page
Number

Update
Level

5
6 thru 14

C
Orig.

Title Page

Orig.

1 thru 75

Orig.

Title Page

Orig.

Appendix A

1 thru 11

Orig.

Appendix B

1 thru 15

Orig.

Appendix C

1 thru 11

Orig.

Appendix D

1 thru 32

Orig.

Appendix E

1 thru 26

Orig.

Appendix F

1
2,3

A
B

Index

1, 2
3
4thru6
7
8thrul0
11 thru 23
24
25 thru 27

Orig.
A
B
Orig.
C
Orig.
C
Orig.

Part/Section

17
PART 6

User Comment
Sheet

*New pages

All the technical changes are denoted by an arrow (*—) in the margin. A downward pointing arrow ( ) next to a line indicates that
technical changes begin at this line and continue until an upward pointing arrow (
is found. A horizontal arrow (-0.-) pointing to

a line indicates a technical change in only that line. A horizontal arrow located between two consecutive lines indicates technical
changes in both lines or deletions.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

PSS 1
Update B

PAGE STATUS SUMMARY
ISSUE: Update B UP-8068 Rev. 4
RELEASE LEVEL: 8.0 Forward
—

Part/Section

Page
Number

Cover/Disclaimer

Update
Level
Orig.

PSS

Preface

1
2
3, 4

Orig.
A
Orig,

Contents

1 thru 11
12
13,14
15
16, 16a
l7thru 19

Orig.
A
Orig.
B
A
Orig.

Part/Section

Page
N umber

Update
Level

2
3 thru 7
8
9thru 15
16
17 thru 51

Orig.
A
Orig.
A
Orig.
A
Orig.

1 thru 9
10
11 thru 13

Orig.
B
Orig.

1 thru 29

Orig.

13A

1
2
3
4
4a
5 thru 13

Orig.
B
Orig.
B
B*
Orig.

2
3 thru 5
6
7thru 17
18
l9thru 21

Orig.
B
Orig.
B
Orig.
B
Orig.

PART 1
Title Page

Orig.

1
2
2a
3
4thru 18

Orig.
A
A
A
Orig.

Title Page

Orig,

1 thru 4

Orig.

1 thru 31

Orig.

1 thru 13

Orig.

1 thru 5

Orig.

1 thru 111

Orig.

1 thru 12

Orig.

16
2
3
4
5
6thru 14

B
Orig.
A
B
A
Orig.

Title Page

Orig.

1 thru 75

Orig.

Title Page

Orig.

Appendix A

1 thru 1 1

Orig.

Appendix B

1 thru 15

Orig.

Appendix C

1 thru 1 1

Orig.

Appendix D

1 thru 32

Orig.

Appendix E

1 thru 26

Orig.

13B

PART 2

1 thru 12

Orig.

1 thru 31

Orig.

Title Page

Orig.

1 thru 17

Orig.

1 thru 62

Orig.

Part/Section

Page
Number

Appendix F
2
3
Index

1,2
3
4thru6
7 thru 27

Update
Level
A
B

Orig.
A
B
Orig.

User Comment
Sheet

PART 3
PARTS

17
PART 6
PART 4

Title Page

Orig.

1 thru 7
8
9,10
11,12
12a
13
14,15
l6thru 22

Orig.
A
Orig.
A
A
Orig.
A
Orig.

*New pages
All the technical changes are denoted by an arrow

(-b-) in the margin. A downward pointing arrow I
next to a line indicates that
‘ )
technical changes begin at this line and continue until an up ward pointing arrow (
is found. A horizontal arrow (-) pointing to
a line indicates a technical change in only that line. A horizontal arrow located between two consecutive lines indicates technical
changes in both lines or deletions.

UP-8068 Rev, 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

PSS 1
Update A

PAGE STATUS SUMMARY
ISSUE:
RELEASE LEVEL:
Part/Section

Page
Number

Cover/Disclaimer

Update
Level
Orig.

Update A UP-8068 Rev, 4
7.0 Forward
—

Page
Number

Update
Level

1
2
3 thru 7
8
9thru 15
16
17 thru 51

Orig.
A
Orig.
A
Orig.
A
Orig.

1 thru 13

Orig.

1 thru 29

Orig.

13A

1 thru 13

Orig.

138

1 thru 21

Orig.

1 thru 13

Orig.

1 thru 111

Orig.

1,2
3 thru 5
6thru 14

Orig.
A
Orig.

Title Page

Orig.

1 thru 75

Orig.

Title Page

Orig.

Part/Section

PSS

Preface

1
2
3, 4

Orig,
A
Orig.

Contents

1 thru 1 1
12
13
15,16
16a
17 thru 19

Orig.
A
Orig,
A
A*
Orig.

Title Page

Orig.

1
2
2a
3
4 thru 18

Orig.
A
A*
A
Orig.

Title Page

Orig.

1 thru 4

Orig.

1 thru 31

Orig.

1 thru 5

Orig.

1 thru 12

Orig.

Appendix A

1 thru 11

Orig.

1 thru 12

Orig.

Appendix B

1 thru 15

Orig.

1 thru 31

Orig.

Appendix C

1 thru 11

Orig.

Appendix D

1 thru 32

Orig.

Title Page

Orig.
Appendix E

1 thru 26

Orig.

1 thru 17

Orig.
Appendix F

1,2

1 thru 62

Orig.
Index

1,2
3
4 thru 27

Orig.
A
Orig.

PART 1

Part/Section

Page
Number

Update
Level

PART2
PART 5

17
PART 6

PART 3

PART 4

Title Page

Orig.

1 thru 7
8
9,10
11,12
12a
13
14,15
16 thru 22

Orig.
A
Orig.
A
A*
Orig.
A
Orig.

User Comment
Sheet

*New pages
All the technical changes are denoted by an arrow (-*—) in the margin. A downward pointing arrow
technical changes begin at this line and continue until an upward pointing arrow

(

I next to a line indicates that

I is found. A horizontal arrow

(-0.’-) pointing to
a line indicates a technical change in only that fine. A horizontal arrow located between two consecutive lines indicates technical
changes in both lines or deletions,

PSS 1

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

PAGE STATUS SUMMARY
ISSUE:
RELEASE LEVEL:
Part/Section

Page
Number

Update
Level

UP-8068 Rev. 4
7.0 Forward

Part/Section
PART 5

Cover/Disclaime
PSS

Preface

1 thru 4

Contents

1 thru 19

17
PART 6

Page
Number

1 thru 15

Appendix C

1 thru 11

Title Page

Appendix D

1 thru 32

lthru4

Appendix E

1 thru 26

lthru3l

Index

1 thru 27

lthru5

User Comment
Sheet

lthrul2

lthru3l

PART 2

PART 3

lthrul8

Title Page

lthrul7

lthru62

PART4

Update
Level

Title Page

Appendix B
1

Page
Number

lthru75

1 thru 1 1

Title Page

Part/Section

Title Page

Appendix A

PART1

Update
Level

Title Page

1 thru 22

lthru5l

1 thru 13

lthru29

13A

lthrul3

13B

lthru2l

1 thru 13

1 thru 111

1 thru 14

All the technical changes are denoted by an arrow (.-) in the margin. A downward pointing arrow ( I next to a line indicates that
is found. A horizontal arrow (-*) pointing to
technical changes begin at this line and continue until an upward pointing arrow
a line indicates a technical change in only that line. A horizontal arrow located between two consecutive lines indicates technical

(4)

changes in both lines or deletions.

t
$

•

‘S

-..

----I.

I••

•.

.-Th

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Preface 1

Preface

This manual is one of a series designed to instruct and guide the programmer in the use
of the SPERRY UNIVAC Operating System/3 (OS/3). This manual specifically describes
OS/3 basic data management and its effective use. Its intended audience is the
applications programmer with a basic knowledge of data processing, but with limited
programming experience, as well as the seasoned applications programmer.
Two other manuals are available that cover OS/3 basic data management; one is an
introductory manual and the other is a programmer reference manual (PRM). The
introductory manual briefly describes OS/3 basic data management and its facilities. The
PRM provides the characteristics of OS/3 basic data management in skeletal form and is
intended as a quick-reference document for the programmer experienced in the use of
OS/3 basic data management.
For systems with interactive facilities, an additional series of manuals is provided to
instruct and guide the programmer in the use of OS/3 consolidated data management.
These are:
s

Introduction to consolidated data management, UP-8824

•

Consolidated data management concepts and facilities, UP-8825

•

Consolidated data management macro language user guide/programmer reference,
UP-8826

In general, any further references to the term data management in this user guide imply
basic data management.
This user guide is divided into the following parts:
•

PART 1.

OS/3 DATA MANAGEMENT

Introduces OS/3 data management in terms of what it is and how it is used;
introduces and briefly describes consolidated data management; describes the data
management/user interface and the relation of data management to other OS/3
software.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

•

PART 2.

Preface
Update A

CARD, DISKETTE, and PRINTER FILES

Describes file and format conventions and the function and operation of OS/3 data
management in relation to punched card, diskette, and printer files.
•

PART 3.

MAGNETIC TAPE FILES

Describes file and format conventions and the function and operation of OS/3 data
management in relation to magnetic tape files.
•

PART 4.

DISK FILES

Describes file and format conventions and function and operation of OS/3 data
management as related to disk files. Describes the indexed sequential access method
(ISAM) both with and without an index structure, the sequential access method
(SAM), the direct access method (DAM), the indexed random access method (IRAM),
the multiple indexed random access method (MIRAM), and the nonindexed access
method. Also includes information on disk space management.
•

PART 5.

PAPER TAPE FILES

Describes record, character, and file conventions and the functions of OS/3 data
management for perforated paper tape files.
•

PART 6.

APPENDIXES

Provide selected functional characteristics of peripheral devices relevant to data
management use; explain the OS/3 data management procedures for error and
exception handling; compare the EBCDIC/ASCII/Hollerith codes and other card codes
used in OS/3; describe the systems standard labels for magnetic tape and disk files;
and describe the consolidated data management migration considerations.
Statement Conventions
The conventions used to delineate the data management macroinstructions are:
•

Positional parameters must be written in the order specified in the operand field and
must be separated by commas. When a positional parameter is omitted, the comma
must be retained to indicate the omission, except for the case of omitted trailing
para meters.
Examples:
Assume that CNTRL is a data management macroinstruction with three optional
positional parameters: A, B, and C.
TAG1
TAG2
TAG3
TAG4

CNTRL
CNTRL
CNTRL
CNTRL

A
A,B
A,B,C
A,,C

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev 4

Preface 3

A keyword parameter consists of a word oracode immediately followed by an equal
sign, which is
1 in turn, followed by a :specification. Keyword parameters can be
written in* any order in the operand field. Commas are required only to separate
parameters; however, a comma must neither be coded in column 16 of a continuation
line nor follow the last keyword of a string.
Example:
Assume that the data management DTF macro for a card file (called CARDIN) has
three keyword parameters: IOAREA1, BLKSIZE, and WORKA.
CARDlN DTFCD IOAREA1=AREA1,BLKSIZE=80;WORKA=YES
•

Capital letters, commas, equal signs, and parentheses must be coded exactly as
shown. The exceptions are those acronyms that are part of geheric terms
representing information to be supplied by the user and the commas preceding
keyboard parameters of declarative macroinstructions. (These commas serve to
ust be separated by
remind the user that keyboard parameters coded in a string
commas.)
Examples:
Ft ELDS=([AD DR][,A2TD][,FR EQJ)
REOC=(MERGE,label,reel,to)
CMceNUMBCHAR=n
X aa (NOV)

Lowercase letters and words are generic terms representing information that must be
supplied bythe user. Such lowercase terms may contain hyphens and acronyms (for
readability).
Examples:
name
sta rt- addr
number-of-bytes
pa ram-i
CCB-name

•

Information contained within braces represents mandatory entries of which one must
be chosen.
Examples:
ffilename

UP8O68 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Preface A

Information contained within brackets represents optional entries that (depending
upon program requirements) are Included or omitted Braces within brackets signify
that one of the specified entries mustbe chosen if that parameter isto be included.
Examples:
[I NPUT=NO]
[OUTPUT=NO]
I Jworkname

L’o
•

An optional parameter which has a list of optional entries may have a default
specification which is supplied by the operating system when the parameter is not
specified by the user. Although the default may be specified by thern user with no
adverse effect, it is considered inefficient to do so. For each reference, when a default
specification occurs in the format delineation it is printed on a shaded background If
by parameter omission, the operating system performs some complex. processing
other than parameter insertion it is explained under an if-omitted heading in the
parameter description.
Examples:
F,M ERG

F
L
•

iNC
JASCII
iEBDUDH

An ellipsis (series of three periods) indicates the omission of a variable number of
entries.
Example:
param-1

•

param-n

Commas are required when positional parameters are omitted, except after the last
parameter specified.
Example:
positional parameter 1, positional parameter 2,, positional parameter 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Contents 1

Contents

PAGE STATUS SUMMARY
PREFACE
CONTENTS
PART 1. OS/3 DATA MANAGEMENT
1.

INTRODUCTION
1.1.

THE FUNCTION OF DATA MANAGEMENT

1-1

1.2.

BASIC AND CONSOLIDATED DATA MANAGEMENT

1-1

1.3.
1.3.1.
1.3.2.
1.3.3.
1.3.4.
1.3.5.
1.3.6.
1.3.7.

DATA STRUCTURE
Définitión of Terms
Punched Card Files
Diskette Files
Printer Files
Magnetic Tape Files
Disk Files
Paper Tape Files

1-4
1-6
1-7
1—7
1-7
1-7
1-8
1-9

1.4.

PROGRAMMING FOR DATA MANAGEMENT

1-9

1.5.
1.5.1.
1.5.2.
1.5.3.
1.5.4.
1.5.5.
1.5.6.
1.5.7.

OS/3 DATA MANAGEMENT ENHANCEMENTS
ISAM Files
SAM and DAM Files
IRAM Files
MIRAM Files
Error and Exception Returns
Disk Flexibility and Hardware Constraints
Shared Data ManagerneritModules

1-10
1-10
1-10
1-10
1-11
1-11
1-11
1-12

1.6.
1.6.1.
1.6.2.
1.6.3.

DATA MANAGEMENT/USER INTERFACE
Declarative Macroinstructions
Imperative Macroinstructions
Assembler Rules for Operand Field

1-12
1-12
1-14
1-14

1.7.
1.7.1.
1.7.2.
1.7.3.
1.7.4.
1.7.5.

Contents 2

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

1—15
1-15
1-16
1-17
1-17
1-18

RELATED OS/3 SOFTWARE
System Service Programs (SSP)
Job Control
Supervisor
Linkage Editor
Data Utilities

PART 2. CARD, DISKETTE, AND PRINTER FILES
2.

CARD FORMATS AND FILE CONVENTIONS
2.1.

GENERAL

2.2.
2.2.1.
2.2.2.
2.2.3.

FILE ORGANIZATION
Card Input Files
Card Output Files
Combined Files

2.3.
2.3.1.
2.3.2.
2.3.3.

RECORD FORMATS
Start-of-Data Job Control Statement
End-of-Data Job Control Statement
Card Punch Records

2-1
:21
2-2
2—3
2-3

(/$)
(/*)

2-3
2-3
2-3
2-4

FUNCTION AND OPERATION OF PUNCHED CARD SAM
3.1.

GENERAL

3.2.
3.2.1.
3.2.2.

FUNCTIONAL DESCRIPTION
Punched Card Input
Punched Card Output

3.3.

DEFINE A SAM CARD FILE

3.4.
3.4.1.
3.4.2.
3.4.3.
3.4.4.
3.4.4.1.
3.4.5.

IMPERATIVE MACRO INSTRUCTIONS
Open a Card SAM File
Retrieve Next Logical Record
Output a Record
Controlling Stacker Selection on the Card Punch
Using the CNTRL Imperative Macro
Close a Card SAM File

3.5.
3.5.1.
3.5.2.

ERROR AND EXCEPTION HANDLING
FilenameC
FilenameS

3.6.

SAMPLE PROGRAMS

3-i
3-1
3-1
3-2
(DTFCD)

3-3

(OPEN)
(GET)
(PUT)
(CNTRL)

3-13
3-14
3-15
3-17
3-19
3-20
3-24

(CLOSE)

3-25
3-25
3-25
3-25

DISKETTE FORMATS AND FILE CONVENTIONS
4.1.

GENERAL

4-1

Contents 3

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

4.2.
4.2.1.
4.2.2.
4.2.3.

FILE ORGANIZATION
Diskette Input Files
Diskette Output Files
Combined Files

4-1
4-3
4-4
4-4

4.3.
4.3.1.
4.3.2.

RECORD FORMATS
Fixed-Length Records
Variable-Length Records

4-4
4-4
4-4

FUNCTION AND OPERATION OF DISKEUE SAM

5—1

5.1.

GENERAL

5.2.
5.2.1.
5.2.2.
5.2.3.
5.2.4.
5.2.5.
5.2.6.

FUNCTIONAL DESCRIPTION
Input Record Processing
Output Record Processing
Combined File Record Processing
Multisector I/O
Specifying 8413 Diskette Use
Diskette Limitations

5.3.

DEFINE A SAM DISKETTE FILE

(DTFCD)

5.4.
5.4.1.
5.4.2.
5.4.3.
5.4.4.

IMPERATIVE MACROINSTRUCTIONS
Open a Diskette SAM File
Retrieve Next Logical Record
Writing a Diskette Record
Closing a Diskette File

(OPEN)
(GET)
(PUT)
(CLOSE)

5—1
5—1
5-2
5—2
5—3
5-3
5-4

5—6
5—7
5-8
5-10
5-12

PRINTER FORMATS AND FILE CONVENTIONS

6-1
6-2
6-2
6-2
6-2
6-2

6.1.
6.1 .1.
6.1.2.
6.1.3.
6.1.4.
6 1 5

GENERAL
0773 Printer
0770 Printer
0768 Printer
0776 Printer
0778 Printer

6.2.
6.2.1.
6.2.2.
6.2.3.

FILE ORGANIZATION
Text
Tabular Data
Printer Forms

6-2
6—3
6-4
6-4

6.3.

RECORD FORMATS

6—5

6.4.
6.4.1
6.4.2.
6.4.2.1.
6.4.2.2.
6.4.2.3.
6.4.3.
6.4.4.

VERTICAL FORMAT AND LOAD CODE BUFFERS
Load Code Buffer Interchangeability
LCB Statement Specification
LCB Specification fOr the 0773 and 077S Printers
LCB Specification for the 0770 and 0776 Printers
LCB Specification for the 0768 Printer
Vertical Format Buffer Interchangeability
VFB Statement Specification

6-7
6—7
6-7
6-8
6-8
6—8
6—9
6—9

Subsystem
Subsystem
Subsystem
Subsystem
Subsystem

UP-8068 Rev. 4

6.4.4.1.
6.4.4.2.
6.4.4.3.
6.4.4.4.
6.4.4.5.

Contents 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Specifying Home Paper Position
Specifying Forms Overflow Position
Specifying Special Forms
Paper Tape Loop, 0768 Printer
Vertical Format Buffer Statement Example

6—9
6-9
6-10
6-10
6-12

FUNCTION AND OPERATION OF SAM PRINTER FILES
7.1.

GENERAL

7—1

7.2.

FUNCTIONAL DESCRIPTION

7-1

7.3.

DEFINE A SAM PRINTER FILE

(DTFPR)

7-4

7.4.
7.4.1.
7.4.2.
7.4.3.
7.4.4.
7.4.5.

IMPERATIVE MACROINSTRUCTIONS
Open a Printer File
Output a Record
Control Printer Forms
Print Overflow Action
Close a Printer File

(OPEN)
(PUT)
(CNTRL)
(PRTOV)
(CLOSE)

7-15
7-16
7-18
7—21
7-24
7-27

7.5.
7.5.1.
7.5.2.

ERRORAND EXCEPTION HANDLING
FilenameC
Truncation of Print Line

7-28
7-28
7—28

7.6.

SAMPLE PROGRAM

7—28

PART 3. MAGNETIC TAPE FILES
8.

MAGNETIC TAPE FORMATS AND FILE CONVENTIONS
8.1.

GENERAL

8-1

8.2.
8.2.1.
8.2.2.
8.2.3.
8.2.4.
8.2.4.1
8.2.5.

TAPE VOLUME AND FILE ORGANIZATION
EBCDIC Standard Volume Organization
EBCDIC Nonstandard Volume Organization
EBCDIC Unlabeled Volume Organization
ASCII Standard Volume Organization
End-of-File and End-of-Volume Coincidence
Magnetic Tape File Record and Block Formats

8-1
8-2
8-2
8-8
8-9
8-9
8-14

FUNCTIONS AND OPERATIONS, MAGNETIC TAPE SAM
9.1.

GENERAL

9.2.
9.2.1.
9.2.2.
9.2.2.1.
9.2.2.2.
9.2.2.3.
9.2.2.4.
9.2.2.5.
9.2.2.6.

DEFINING A MAGNETIC TAPE FILE
Format of the DTFMT Declarative Macro
Required and Most Frequently Used DTFMT Keywords
Specifying the I/O Buffer
Specifying the Length of the I/O Buffer
Specifying Type of File Processing
Error Processing
End-of-Data Processing for an Input File
Specifying a Register Save Area

9—1
(DTFMT)

(IOAREA1)
(BLKSIZE)
(TYPEFLE)
(ERROR)
(EOFADDR)
(SAVAREA)

9—1
9—2
9-10
9-10
9-10
9—11
9—12
9—12
9-13

UP-8068 Rev.4

Contents5

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

9-13
9-13
9—13
9-14
9-14
9—15
9—15
9—17
9-17
9-18
9-19
9—21
9-22
9-22
9-23
9-23
9-23
9-23
9-24
9-24
9-26
9-27
9-27
9-28
9-28
9-28
9-29
9-29
9-30

9.2.3.
9.2.3.1.
9.3.3.2.
9.2.3.3.
9.2.3.4.
9.2.3.5.
9.2.3.5.1.
9.2.4.
9.2.4.1.
9.2.4.2.
9.2.4.3.
9.2.5.
9.2.5.1.
9.2.5.2.
9.2.5.3.
9.2.5.4.
9.2.6.
9.2.6.1.
9.2.6.2.
9.2.6.3.
9.2.7.
9.2.7.1.
9.2.7.2.
9.2.7.3.
9.2.8.
9.2.8.1.
9.2.8.2.
9.2.9.
9.2.10.

Commonly Used DTFMT Keywords
Specifying a Secondary I/O Buffer
Specifying an Index Register
Processing in a Work Area
Handling Parity Errors
Processing Block Numbers
Block Number Specification
Parameters Related to Tape Record Formats
Specifying a Record Format
Providing Record Size
Blocking Variable Records in an I/O Area
Parameters Related to Tape Movement
Specifying Input File Direction
Exercising General Rewind Options
Rewinding at Open
Rewinding at Close
Parameters Related to Tape Label Processing
Specifying Type of Tape Labels
Eliminating Tape Mark After Header Labels
Special Label Handling
ASCII Processing
Specifying ASCII Processing
Specifying ASCII Buffer Offset
Checking the Length of Variable ASCII Records
Other DTFMT Keyword Parameters
Specifying That a File is Optional
Bypassing Checkpoint Dumps
Nonstandard Forms of DTFMT Keywords
Processing Multivolume Files

9.3.

JOB CONTROL STATEMENTS USED WITH MAGNETIC TAPE
FILES
(DVC)
Assigning a Tape Device to Your Job
(LFD)
Defining Your Logical File
(VOL)
Specifying Tape Volume Information
Inhibiting Volume Serial Number Checking
Specifying Dynamic Tape Prepping and Recording Density
Specifying a Scratch Volume
(LBL)
Specifying Tape File Label Information
Specifying File Identifier
Checking Volume and File Serial Numbers
Specifying File Expiration Date
Specifying File Creation Date
Specifying File Sequence Number
Specifying File Generation and Version Numbers
Creating Multivolume Tape Files
Extending Tape Files
Error Messages Related to Tape Label Processing

9-31
9-31
9-32
9-33
9-34
9-34
9-36
9-36
9-36
9-36
9-38
9—39
9-39
9-39
9-40
9-41
9-43

IMPERATIVE MACROS FOR PROCESSING
MAGNETIC TAPE FILES
Initiating Tape File Processing
Terminating Tape File Processing
Delivering the Next Logical Output Record to Tape SAM
Reading the Next Logical Input Record From Tape

9-43
9-46
9-48
9-50
9-52

9.3.1.
9.3.2.
9.3.3.
9.3.3.1.
9.3.3.2.
9.3.3.3.
9.3.4.
9.3.4.1.
9.3.4.2.
9.3.4.3.
9.3.4.4.
9.3.4.5.
9.3.4.6.
9.3.5.
9.3.6.
9.3.7.
9.4.
9.4.1.
9.4.2.
9.4.3.
9.4.4.

(IOAREA2)
(IOREG)
(WORKA)
(ERROPT)
(BKNO)

(RECFORM)
(RECSIZE)
(VARBLD)
(READ)
(REWIND)
(OPRW)
(CLRW)
(FILABL)
(TPMARK)
(LABADDR)
(ASCII)
(BUFOFF)
(LENCHK)
(OPTION)
(CKPTREC)

(OPEN)
(CLOSE)
(PUT)
(GET)

UP-8068 Rev. 4

9.4.5.
•
.

9.4.6.
9.4.7.
9.4.8.
9.4.9.
9.4.10.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Changing File Processing Mode for an IN/OUT
Tape File
Writing Short Output Blocks to Magnetic Tape
Skipping to the Next Input Block
Forcing End-of-Volume Procedures
Processing User Tape Labels
Controlling Tape Unit Functions

Contents 6

(SETF)
(TRUNC)
(RELSE)
(FEOV)
(LBRET)
(CNTRL)

9-54
9-56
9-58
9-59
9-60
9-62

PART 4. DISK FILES
10. ISAM FORMATS AND FILE CONVENTIONS
10.1.

GENERAL

10-1

10.2.
10.2.1.
10.2.2.
10.2.2.1
10.2.3.
10.2.4.
10.2.5.

ISAM FILE ORGANIZATION
ISAM Record Formats
ISAM Data Block Format
Calculating Space Requirements for the File
ISAM Index Blocks
Calculating Space for the ISAM Index Area
Loading the Top Index into Main Storage

10-3
10-5
10-8
10-11
10-12
10-14
10-16

10.3.
10.3.1.

ALTERNATE SEQUENTIAL ACCESS METHOD
ASAM Data Formats

10.4.

MULTIVOLUME ISAM FILES

(ASAM)

10-18
10-22
10-22

11. FUNCTIONS AND OPERATION OF ISAM
11.1.

GENERAL

11—1

11.2.
11.2.1.
11.2.2.
11.2.3.

FUNCTIONAL DESCRIPTION, OS/3 ISAM
Processing an Indexed ISAM File
Processing an ISAM File Without an Index Structure
Deleting Records From an ISAM File

11-2
11-2
11-3
11-4

11.3.

DEFINING AN OS/3 ISAM FILE

11.4.
11.4.1.
11.4.2.
11.4.3.
11.4.4.
11.4.5.
11.4.6.
11.4.7.
11.4.8.
11.4.9.
11.4.10.
11.4.11.
11.4.12.
11.4.13.
11.4.14.
11.4.15.

DTFIS KEYWORD PARAMETERS
11-8
Specifying File Accessing Options
(ACCESS)
11—8
Specifying Size of Data Blocks
(BLKSIZE)
11—9
Specifying Your Error Exit
11-10
(ERROR)
Describing an Index Area in Main Storage
(INDAREA,INDSIZE) 11-11
Eliminating the Index Structure
(INDEXED)
11-12
Specifying I/O Buffers
(IOAREA1 IOAREA2) 11-12
Specifying Current Record Pointer
11-13
(IOREG)
Specifying the Type of File Processing
(IOROUT)
11-13
Specifying Location of Retrieval Search Argument
11-14
(KEYARG)
Specifying Length and Location of Record Keys
(KEYLEN,KEYLOC)
11-15
Suppressing a File Lock
(LOCK)
11—16
Providing Cylinder Overflow Area
(PCYLOFL)
11—17
Specifying Record Size and Format
(RECFORM,RECSlZE) 11-17
Specifying a Save Area for Contents of General Registers
(SAVAREA)
11-18
Specifying the Type of Retrieval
(TYPEFLE)
11—18

(DTFIS)

11-6

Contents 7

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

(UPDATE)
(VERIFY)
(WORK1 ,WORKS)

11—19
11—19
11-19
1 1—20
11—21

11.4.16.
11.4.17.
11 .4.18.
1 1 .4.19.
11.4.20.

Forestalling Use of Update Functions
Specifying Parity Check of Output Records
Specifying Location of Record Work Areas.
Nonstandard Forms of the Keyword Parameters
Recapitulation of DTFIS Keyword Parameters

11.5.
1 1 .5.1.
11.5.1.1.
11.5.1.2.
11 .5.2.
11.5.2.1.
11.5.2.2.
11.5.2.3.
11.5.3.
1 1 .5.3.1.

11.5.3.3.
11.5.4.
1 1 .5.4.1.

IMPERATIVE MACROS FOR ISAM FILES
Basic Macroinstructions
Initializing an ISAM File
Terminating an ISAM File
Loading and Extending an ISAM File
Initiating the Load Sequence
Writing Initial Records to the File
Terminating the Load Sequence
Inserting New Records in an ISAM File
Adding a New Record to Overflow in an
Existing File
Adding a New Record to Overflow in an Existing
File
Ensuring Completion of Record Transfer
Processing an ISAM File Randomly
Retrieving a Record

11.5.4.2.
11.5.4.3.
11.5.5.
11.5.5.1.
11.5.5.2.
11.5.5.3.
11.5.5.4.

Updating a Record
Updating Last Record Retrieved
Processing an ISAM File Sequentially
Initializing a Retrieval Sequence
Retrieving Next Logical Record
Updating a Record
Terminating a Retrieval Sequence

11.6.
11.6.1.
11.6.2.

ERROR AND EXCEPTION HANDLING
FilenameC
Other Addressable Fields of the DTFIS File Table

11-49
11-49
11-49

11.7
11 .7.1.

PROGRAMMING EXAMPLE
Sample ISAM File Load Program

11—50
11—50

1 1 .5.3.2.

(OPEN)
(CLOSE)
(SETFL)
(WRITE,NEWKEY)
(ENDFL)

11-23
1 1—23
11—24
11—25
11-26
11—27
11—28
11—30
11—31

(WRITE,NEWKEY)

11—32

(ADD)
(WAITF)

11—34
11—35
11-35

(READ,ID and
READ,KEY)
(WRITE,KEY)
(UPDT)
(SETL)
(GET)
(PUT)
(ESETL)

11-36
11-38
11—40
11-40
11—42
11—44
11—46
11—48

12. IRAM FORMATS AND FILE CONVENTIONS
12.1.
12.1.1.

GENERAL
IRAM Concepts

12-1
12-1

12.2.
12.2.1.
12.2.2.
12.2.3.
12.2.4.

IRAM FILE CONVENTIONS AND FORMATS
The Data Partition
Entries in the Index Partition
Structure of IRAM Index
Estimating Disk Space Required for an Indexed
IRAM File
Estimating Disk Space Required for a Nonindexed IRAM File

12-3
12-3
12—3
12-6

12.2.5.

12-9
12-12

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Contents 8

13. FUNCTIONS AND OPERATIONS OF IRAM
13.1.
13.1.1.
13.1.1.1.
13.1.1.2.
13.1.1.3.
13.1 .1 .4.
13.1.1.5.
13.1.1.6.
13.1.2.
13.1.2.1.
13.1;.2.2.
13.1.2.3.
13.1.2.4.
13.1.2.5.
13.1.2.6.

PROCESSING NONINDEXEDIRAM FILES
Processing Sequential IRAM Files
Creating a Sequential IRAMFIle.
Extending a Sequential IRAM File
Adding Records to a Sequential File
Retrieving and Updating Records in a Sequential IRAM. File
Deleting Records from a Sequential IRAM File
Reorganizing a Sequential IRAM File
Processing Direct IRAM Files
Creating a Direct IRAM File
Extending a Direct IRAM File
Adding Records to a Direct IRAM File
Retrieving and Updating Records in a Direct IRAM File
Deleting Records from a Direct IRAM File
Reorganizing a Direct IRAM File

13—1
13-2
13-2
13—3
13-3
13-3
13-5
13-5
13-5
13-5
13-6
13-7
13-7
13-8
13-8

13.2.
13.2.1.
13.2.2.
13.2.3.
13.2.4.
13.2.5.
13.2.6.
13.2.7.

PROCESSING INDEXED IRAM FILES
Creating an Indexed IRAM File
Extending an Indexed IRAM File
Retrieving and Updating in an IRAM File With Index Active
Adding Records During Retrieval Index Active
Retrieval and Update When Index is Inactive
Deleting Records from an Indexed IRAM File
Reorganizing an Indexed IRAM File

13-9
13—10
13-11
13-11
13—12
13-13
13-14
13-14

13.3.

DEFINING AN OS/3 IRAM FILE

13.4.
13.4.1.
13.4.2.

DTFIR KEYWORD PARAMETERS
Specifying File Accessing Options
Specifying the Addition of Records.toIRAM
:
Input File
Specifying the Buffer Size for IRAM File
Specifying the End-of-File Handling Routine
Specifying Error Routines
Naming Main Storage Location for Index Block Processing
Specifying the Index Area Length in Main Storage
Indicating Processing by Key
Identifying the I/O Area
Identifying an Additional I/O Area
Pointing to Current I/O Area
Naming a Place for Key Retrieval
Specifying Key Lengths for IRAM Files
Specifying Number of Bytes Preceding Keys
Suppressing a File Lock
Specifying Retrieval and Load Modes for Indexed and
Nonindexed IRAM Files
Specifying Optional Files
Specifying Record Length
Locating Relative Disk Address for Processing
IRAM File by Relative Record Numbers
Verifying Ascending Record Key Order During
File Creation
Specifying the File Type
Updating Records
Verifying Output Records

13.4.3.
13.4.4.
13.4.5.
13.4.6.
13.4.7.
13A.8.
13.4.9.
13.4.10.
13.4.11.
13.4.12.
13.4.13.
13.4.14.
13.4.15.
13.4.16.
13.4.17.
13.4.18.
13.4.19.
13.4.20.
13.4.21.
13.4.22.
13.4.23.

...

(DIFIR)

13—15

(ACCESS)

13—18
13—18

(AD D)
(BFSZ)
(EOFA)
(ERRO)
(INDA)
(INDS)
(INDX)
(IOA1)
(10A2)
(IORG)
(KARG)
(KLEN)
(KLOC)
(LOCK)

13-19
13—19
13-19
13—19
13—20
13—20
13-20
13-20
13—21
13—21
13—21
13—21
13—22
13-22

(MODE).
(OPTN)
(RCSZ)

13—22
13—22
13—23

(SKAD)

13—23

(SQCK)
(TYPE)
(UPDT)
(VRFY)

13—23
13-23
13-24
13-24

13.4.24.
13.4.25.
13.4.26.
13.5.
13.5.1.
13.5.2.
13.5.3.

Contents 9

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Specifying File Processing With One Volume
Online at a Time
Specifying Input or Output Record Processing in
a Work Area
Nonstandard Forms of the Keyword Parameters
IRAM KEYWORD PARAMETERS DDJOB CONTROL
STATEMENTSUPPORTONLY
Variable Sector Support for IRAM Files
File Recovery Support for IRAM FiIes
Automatic Computation of Initial Allocation
Percentages for IRAM Files

(VMNT)

13-24

(WORK)

13-24
13-25

(VSEC)
(RECV)

13—25
13-26
13-27

(AUTO)

13-28

13A. MIRAM FORMATS AND FILE CONVENTIONS
13A.1.
13A.1 .1.

GENERAL
MIRAM Concepts

13A—1
13A-2

13A.2.
13A.2.1.
13A.2.2.
13A.2.3.
1 3A.2.4.
13A.2.5.
1 3A.2.6.

MIRAM FILE ORGANIZATION
The Data Partition
Entries in the Index Partition
MIRAM Index Structure
Retrieving Records froman Indexed MIRAM FiIe
Estimating Disk Space Required for an Indexed MIRAM File
Estimating Disk Space Required for a Nonindexed MIRAM File

13A-3
13A-3
13A-6
13A-7
13A-8
13A-9
13A-12

13B. FUNCTIONS AND OPERATIONS OF MIRAM
13B.1.

GENERAL

13B-1

13B.2.
13B.2.1.
13B.2.2.
13B.2.3.
13B.2.4.
13B.2.5.
13B.2.6.
13B.2.7.
13B.2.8.
13B.2.9.
13B.2.1O.
13B.2.11.

PROCESSING NONINDEXED MIRAM FILES
Creating a Sequential MIRAM File
Extending a Sequential MIRAM File
Adding Records to a Sequential MIRAM File
Retrieving and Updating Records in a Sequential MIRAM File
Deleting Records from a Sequential MIRAM File
Reorganizing a Sequential MIRAM File
Creating a Relative MIRAM File
:
Extending a Relative MIRAM File
Retrieving and Updating Records in a Relative MIRAM File
Deleting Records from a Relative MIRAM File
Reorganizing a Relative MIRAM File

13B-1
13B-2
13B-2
13B-3
13B-3
13B-3
138-3
138-4
13B-4
13B-4
13B-5
13B-5

13B.3.
13B.3.1.
13B.3.2.
13B.3.3.
13B.3.4.
13B.3.5.
13B.3.6.

PROCESSING INDEXED MIRAM FILES
Creating an Indexed MIRAM File
Extending an Indexed MIRAM File
Retrieving and Updating Records in an Indexed MIRAM File
Adding Records to an Indexed MIRAM File during Retrieval
Deleting Records from an Indexed MIRAM File
Reorganizing an Indexed MIRAM File

13B-5
138-6
13B-6
13B-7
13B-8
138-8
13B-8

138.4.

DEFINING AN OS/3 MIRAM FILE

(DTFMI)

13B-8

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

13B.5.
1 3B.5.1.
1 3B.52.
1 3B.5.3.
1 3B.5.4.
13B.5.5.
1 3B.5.6.
1 3B.5.7.
13B.5.8.
138.5.9.
1 3B.5.1O.
1 3B.5.1 1.
1 3B.5.1 2.
13B.5.13.
138.5.14.
1 3B.5.1 5.
13B.5.16.
138.5.17.
1 3B.5.1 8.
138.5.19.
1 3B.5.20.
138.5.21.
138.5.22.
138.5.23.
138.5.24.
1386.
13B.6.1.
138.6.2.
13B.6.3.

DTFMI KEYWORD PARAMETERS
Specifying File Accessing Options
Specifying the Buffer Size for a MIRAMFile
Specifying the End-of-File Handling Routine
Specifying Error Handling Routines
Naming the Main Storage Area for Index Block Processing
Specifying the Index Area Length in Main Storage
Identifying the Primary Data Buffer
Identifying the Secondary Data Buffer
Pointing to the Current Data Buffer
Specifying the Key Argument Field
Specifying the Keys for an Indexed File
Suppressing a File Lock
Specifying Processing Mode for MIRAM Files
Specifying Optional Files
Specifying Type of Operations
Specifying Record Control Byte
Specifying Record Format
Specifying Record Length
Specifying Record Retrieval Purpose
Specify the Location of the Relative Disk Address for
Processing a MIRAM File by Relative Record Numbers
Verifying Output Records
Specifying File Processing with One Volume Online
ataTime
Specifying Record Processing in a Work Area
Nonstandard Forms of the Keyword Parameters
MIRAM KEYWORD PARAMETERS DD JOB CONTROL
STATEMENT SUPPORT ONLY
Variable Sector Support for MIRAM Files
File Recovery Support for MIRAM Files
Automatic Computation of Initial Allocation Percentages
for MIRAM Files

Contents 10

(ACCESS)
(BFSZ)
(EOFA)
(ERRO)
(INDA)
(INDS)
(IOA1)
(10A2)
(lORG)
(KARG)
(KEYn)
(LOCK)
(MODE)
(OPTN)
(PROC)
(RCB)
(RCFM)
(RCSZ)
(RETR)

13B-i3
1 3B-i 3
1 3B-i 3
1 3B-i 3
1 3B-i 3
1 3B-1 4
1 3 B—i 4
1 3 B—i 4
138-15
138-15
13B-15
138-16
1 3 B—i 6
1 38-i 6
i3B—i7
1 3B-1 7
138-17
1 3B-i 8
138-18
1 3B-1 8

(SKAD)
(VRFY)

138-19
138-19

(VMNT)
(WORK)

1 3B-i 9
138-20
138-20

(VSEC)
(RECV)

138-2i
138-21
13B-2i

(AUTO)

138-21

14. NON INDEXED DISK FILE FORMATS AND CONVENTIONS
14.1.

GENERAL

14-1

14.2.
14.2.1.
14.2.2.
14.2.3.
14.2.4.
14.2.4.1.
14.2.4.2.

FILE ORGANIZATION
Partitioning DTFNI Files
Subfiles in DTFNI Partitions
System Standard Labels for Nonindexed Disk Files
Optional Standard User Labels
User Header Labels
User Trailer Labels

i4-2
14-3
14-3
14-4
14-5
14-5
14-6

14.3.
14.3.1.
14.3.2.
14.3.3.

NONINDEXED FILE RECORD FORMATS
Fixed-Length Records
Variable-Length Records
Optional Key Fields With Nonindexed Files

14-6
14-7
i4-8
14-10

Contents l1

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

15. NONINDEXED FILE ACCESS METHODS: FUNCTION AND OPERATION
15.1.

GENERAL

15-1

15.2.

FUNCTIONAL DESCRIPTION, OS/3 SAM

15-3

15.3.

FUNCTIONAL DESCRIPTION, OS/3 DAM

15-4

15.4.

FUNCTIONS OF THE OS/3 NONINDEXED FILE ACCESS
METHOD

15-5

15.5.
15.5.1.
15.5.2.
15.5.3.
15.5.4.

NONINDEXED DISK FILE DECLARATIVE MACROS
Defining a Sequential Disk File
Defining a Direct Access Disk File
Defining a Nónindexed Disk File
Defining a Partition Control Appendage

15.6.
15.6.1.
15.6.2.
15.6.3.
15.6.4.
15.6.5.
15.6.6.
15.6.7.
15.6.8.
15.6.9.
15.6.10.
15.6.1 1.
15.6.12.
15.6.13.
15.6.14.
15.6.15.
15.6.16.
15.6.17.
15.6.18.
15.6.19.
15.6.20.
15.6.21.
15.6.22.
15.6.23.
15.6.24.
15.6.25.
15.6.26.
15.6.27.
15.6.28.
15.6.29.
15.6.30.
15.6.31.
15.6.32.

KEYWORD PARAMETERS FOR DECLARATIVE MACROS
Specifying File Accessing Options
WRITE,AFTER or WRITE,RZERO Macro Issue
Specifying Block Length
Address for Routine on End-of-Input File or Partition
Handling Parity Errors on Sequential Disk Files
Error Processing
Specifying Field for Return of Relative Disk Address
Specifying the Factor for Record Interlace
Specifying Input/Output Buffer
Specifying a Secondary Input/Output Buffer
Specifying Index Register for Current Data Pointer
Specifying Address of Argument for Key Search
Specifying the Length of Record Keys
Specifying Address of Your Label Processing Routine
Suppressing a File Lock
Specifying an Optional Sequential File
Specifying Address of Partitions for DTFNI Files
Specifying Issue of a READ,lD Macro
Specifying Issue of a READ,KEY Macro
Specifying Format of Records in Disc Files
Specifying Size of Records in Blocked Disc Files
Specifying the Form for Relative Addressing
Specifying a Save Area for Contents of General Registers
Specifying Relative Disk Address for Random Processing
Assigning Initial Disk Space to a File Partition
Extending Key Search to Multiple Tracks
Specifying Support of Subfiles in a Partition
Specifying Processing of User Trailer Labels
Defining the Type of File
Specifying Dynamic Extension of a File Partition
Specifying Update Processing Mode for Sequential Files
Specifying Register for Residual Space, Variable
Records
Specifying Parity Check Verification of Output
Specifying Sequential Processing in a Work Area
Specifying Issue of WRITE,lD Macro
Specifying Issue of WRITE,KEY Macro
Nonstandard Forms of the Keyword Parameters

15.6.33.
15.6.34.
15.6.35.
15.6.36.
15.6.37.

15-7
(DTFSD)
(DTFDA)
(DTFNI)
(DPCA)

(ACCESS)
(AFTER)
(BLKSIZE)
(EOFADDR)
(ERROPT)
(ERROR)
(IDLOC)
(LACE)
(IOAREA1)
(IOAREA2)
(IOREG)
(KEYARG)
(KEYLEN)
(LABADDR)
(LOCK)
(OPTION)
(PCA)
(READID)
(READKEY)
(RECFORM)
(RECSIZE)
(RELATIVE)
(SAVAREA)
(SEEKADR)
(SIZE)
(SRCHM)
(SUBFILE)
(TRLBL)
(TYPEFLE)
(UOS)
(UPDATE)
(VARBLD)
(VERIFY)
(WORKA)
(WRITEID)
(WRITEKEY)

15-8

15-11
15-14
15-16
15-20
15-21
15-21
15-22
15-25
15—26
15-26
15—28
15-30
15-33
15-34
15-34
15-35
15-36
15-37
15-38
15—38
15—39
15-40
15-40
15—40
15-42
15-42
15-45
15-46
15-49
15—50
15-50

15—51
15—51
15-53
15-54
15-54
15-55
15—56
15-56
15-57
15—57

UP-8068 Rev. 4

15.7.9.3.
15.7.9.4,
15.7.9.5.
15.7.9.6.
15.7.10.
15.7.11.
15.7.11.1.
15.7.11.2.
15.7.11.3.
15.7.11.4.
15.7.11.5.
15.7.1 2.
15.7.13.
15.7.1 4.
15,7.14.1.
15.7.14.2.
15.7.15.
15.7.16.
15.7.17.
15.7.18.

IMPERATIVE MACROS FOR NONINDEXED DISK FILES
Opening a Disk File
Closing a Disk File
Processing Optional User Labels
Creating Optional User Labels
Retrieving or Updating User Labels
Accessing a Selected File Partition
Processing Subfiles Within a Partition
Initializing Position of a File or Partition
Forcing End-of-Volume Procedures
Setting File Processing Mode
Output of Sequential Disk Files
Creating a Sequential Disk File
Updating and Extending an Existing Disk
File Processed Sequentially
Extending an Existing DTFSD Output File
Output of Blocked Records, Sequential Disk Files
Output of Sequential DTFNI Files With Keys
Optional SeqUential Input Files
Output of Short Variable Blocks to Sequental Disk Files
RandOm Output of Records to Disk
Creating a Random Disk File by Sequential Load
Selecting and Initializing a New Track
Recording the Logical End-of-File
Creating or Updating Blocks by Relative Disk Address
Rewriting Randomly Retrieved Blocks to Disk
Retrieving Records From Sequentially Processed Disk Files
Skipping Records in Sequentially Processed Input Blocks
Random Retrieval From Direct Access Files
Random Retrieval of Records by Relative Disk Address
Direct Retrieval and Updating of Input Blocks by Key
Controlling Disk Head Movement to a Track
Waiting on Completion of I/O to Random Disk Files
Accessing the Current Relative Block Address
Positioning a File or Partition to a Relative Block Address

15.8.
15.8.1.

ERROR AND EXCEPTION HANDLING
FilenameC

15.7.
15.7.1.
15.7.2.
15.7.3.
15.7.3.1.
15.7.3.2.
15.7,4.
15.7.5.
15.7.6.
15.7.7.
15.7.8.
15.7.9.
15.7.9.1.
15.7.9.2.

Contents 12
Update C

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

(OPEN)
(CLOSE)
(LBRET)

(SETP)
(SETS)
(POINTS)
(FEOV)
(SETF)
(PUT)

(TRUNC)
(WRITE)
(WRITE,AFTER)
(WRITE,RZERO)
(WRITE,AFTER,EOF)
(WRITE,ID)
(WRITE,KEY)
(GET)
(RELSE)
(READ)
(READ,lD)
(READ,KEY)
(CNTRL)
(WAITF)
(NOTE)
(POINT)

15-59
15-62
15-63
15-64
15-66
15-67
15-68
15-70
15-72
15-73
15-74
15-75
15-76
15-78
15-79
15-80
15-80
15-81
15-82
15-84
15-86
15-88
15-89
15-90
15-93
15-94
15-96
15-97
15-99
15-101
15-103
15-105
15-106
15-108
15—111
15—111

16. SYSTEM RESOURCE CONTROL
16—1
16—1
16-2
16-2
16-3
16-3
16—3
16-4
1 6—4a

16.1.
16.1.1.
16.1.2.
16.1.3.
16.1.4.
16.1.4.1.
16.1.4.2.
16.1.4.3.
16.1.4.4.

DEVICE ALLOCATION AND FILE ASSIGNMENT
Use of Job Control Statements
Sample Device Assignment Set
Job Control Deallocation Statement
Using the File Lock Feature
Indicating Which Files are Lockable
Setting File Locks for Data Files in BAL Programs
Setting File Locks for Data Files in. Non-Bal Programs
File Lock Feature Summary

16.2.

RENAMING A DISK FILE

(RENAME)

16-6

16.3.

DYNAMIC DEALLOCATION OF A DISK FILE

(SCRTCH)

16-8

16.4.
16.4.1.
16.4.1.1.

DISC SPACE MANAGEMENT AND THE VTOC
Retrieving VTOC Information
Retrieving Specific Format Label Items

(OBTAIN)

16-11
16-12
16-14

(SCR)

Contents 13

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

PART5.PAPER TAPE FILES
17 PAPER TAPE DATA MANAGEMENT
17.1.

GENERAL

17—1

17.2.
17.2.1.
17.2.1.1.
17.2.1.2.
17.2.2.
17.2.3.

HARDWARE AND PAPER TAPE CONSIDERATIONS
The Program Connector Board
Wiring the Program Connector for the Tape Punch
Wiring the Program Connector for the Tape Reader
Paper Tape Leader
Paper Tape Trailer

17—1
17-2
17—2
17-2
17-3
17-3

17.3.
17.3.1.
17.3.2.
17.3.3.
17.3.4.

CHARACTER AND RECORD TYPES ON PAPER TAPE
Null, Delete, and Stop Characters
Letter and Figure Shift Characters
Record Formats in Paper Tape Files
Interrecord Gaps in Paper Tape Files

17—4
17-4
17—6
17—10
17—10

17.4.
17.4.1.
17.4.2.
17.4.3.
17.4.4.

PROCESSING PAPER TAPE FILES
Initializing a Paper Tape File
Terminating Paper Tape File Processing
Reading a Logical Record From Paper Tape
Punching a Logical Record into Paper Tape

17.5.
17.5.1.
17.5.1.1.
17.5.1.2.
17.5.1.3.
17.5.1.4.

DEFINING PAPER TAPE FILES
Basic DTFPT Keyword Parameters
Specifying File Type
Specifying Record Format
Specifying Block Size
Specifying Buffers, Work Areas, and
Double Buffering

17.5.1.5.
17.5.1.6.
17.5.2.
17.5.2.1.
17.5.2.2.
17.5.3.

Specifying Oversized Buffers
Specifying Register for Record Size
Specifying File Processing Mode
Highlights of Binary Mode Processing
Highlights of the Character Mode
Letter/ Figure Shifting and Translation,
Input Files in Character Mode

17.5.3.1.

Character Deletion, Input Files, in Binary
or Character Mode
Translation for Input Files Without Shifted Codes
Specifying the End-of-Tape Routine for Input Files
Translation and Letter/Figure Shifting, Output Files

17.5.3.2.
17.5.4.
17.5.5.

17.5.5.1.
17.5.6.
17.5.7.
17.5.8.
17.5.9.
17.5.10.

Translation for Unshifted Output Files, Either Mode
Specifying the End-of-Record Stop Character for Output
Files
Specifying Optional File Processing
Providing a General Register Save Area
Data Management Error Processing, Paper Tape Files
Processing ASCII Paper Tapes

(OPEN)
(CLOSE)
(GET)
(PUT)
(DTFPT)
(TYPEFLE)
(RECFORM)
(BLKSIZE)
(IOAREAl)
(IOAREA2)
(IOREG)
(WORKA)
(OVBLKSZ)
(RECSIZE)
(MODE)
(MODE=BINARY)
(MODE=STD)
(SCAN)
(LTRANS)
(FTRANS)
(SCAN)
(TRANS)
(TRANS)
(EOFADDR)
(FSCAN)
(LSCAN)
(TRANS)
(TRANS)
(EORCHAR)
(OPTION)
(SAVAREA)
(ERROR)
(SCAN)
(TRANS)

17—15
17—17
17—18
17—20
17-22
17-24
17-28
17—28
17—29
17-29

17—30
17-33
17—35
17-36
17—36
17—37

17—39
17-45
17-46
17-49

17—50
17—58
17-60
17-62
17—63
17-65
17-70

UP-8068 Rev. 4

17.6.
17.6.1.
17.6.2.
17.6.3.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Contents 14

COMPARISON OF OS/3 WITH OTHER PAPER
TAPE SYSTEMS
Compatibility with OS/4
Compatibility with the 9200/9300 Series
Compatibility with IBM System/360 DOS

17-73
17-73
17-74
17-74

PART 6. APPENDIXES
A.

FUNCTIONAL CHARACTERISTICS OF PERIPHERAL DEVICES

ERROR AND EXCEPTION HANDLING

B.1.

GENERAL

B-i

B.2.
B.2.1.

RETURN OF CONTROL
Error Handling with ISAM

B-2

B.3.
B.3.1.
B.3.2.
B.3.3.

SYSTEM ERROR MESSAGES
Data Management Error Messages
Disk Space Management Error Codes
Disk File Extension Error Handling

B.4.
8.4.1.
8.4.2.

ERROR FLAGGING PROCEDURES
FilenameC
Other DTF Fields

B-i

8-2
B-2
B-1O
B-12

8-12
8-13
8-15

CODE CORRESPONDENCES
Cl.

GENERAL

C-i

C.2.
C.2.1.
C.2.2.
C.2.3.

EBCDIC/ASCII/HOLLERITH CORRESPONDENCE
Hollerith Punched Card Code
EBCDIC
ASCII

C-i
C-2
C-2
C-2

C.3.
C.3.1.
C.3.2.

OTHER CARD CODES
Compressed Card Code
Column Binary (Image) Code

C-8
C-B
C-9

C.4.

DATA CONVERSION

C-9

LABELS FOR DISK FILES

D.1.

GENERAL

D-1

D.2.
D.2.1.
D.2.2.
D.2.3.
D.2.4.
D 2 5

VOLUME INFORMATION GROUP
VOL1 Label
Disk Format 4 Label
Disk Format 5 Label
Disk Format 6 Label
Disk Format 0 Label

D-2
D-3
D-4
D-8
D-9
D-i 1

UP—8068 Rev.4

D.3.
D.3.1.
D.3.2.
D.3..

FILE
Disk
Disk
Disk

D.4.
D.4.1.
D.42.

OPTIONAL USER STANDARD LABELS
User Header Labels
User Trailer Labels

D-28
D-28
D-29

D.5.

8413 DISKETTE FILE LABEL

D—30

D-12
D—13
D-18
D-25

INFORMATION GROUP
Format 1 Label
Format 2 Label
Format 3 Label

MAGNETIC TAPE LABELS
OS/3 SYSTEM STANDARD LABELS FOR
MAGNETIC TAPE

E-i

E.2.
E.2,1.
E.2.2.
E.2.2.1.
E.2.2.2.
E.2.3.
E.24.

SYSTEM STANDARD TAPE LABELS
Volume Label Group
File Header Label Group
First File Header Label
Second File Header Label
File Trailer Label Group
Standard User Header and Trailer Labels

E-1
E—2
E-4
E—4
E—7
E—9
E-14

E.3.
E.31.
E311.
E.3.l 2.
E.3.2.
E.3.21.
E.3.22.
E.3.2.3.
E.3.24.

ASCII STANDARD MAGNETIC TAPE LABELS
ASCII Character Code and Processing
Output Processing of Labels in ASCII Magnetic Tape Files
Input Processing of Labels in ASCII Magnetic Tape Files
OS/3 Processing of Certain Fields in ASCII Tape Labels
Accessibility Field
Label Standard Level Field
Expiration Date Field
Systems Code

E-15
E-15
E—15
E—15
E-15
E—16
E—16
E—16
E—16

E.4.

PADDING

E-16

El.

Contents 15
Update B

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

(HDR1)
(HDR2)

CONSOLIDATED DATA MANAGEMENT MIGRATION CONSIDERATIONS
Fl.

F.2.
F.21.
F.2.ii.
F.2.2.
F.2.3.
F.2.4.
F.2.5.

WHAT DO I HAVE TO DO TO MIGRATE
TO CONSOLIDATED DATA MANAGEMENT?
MIGRATION REQUIREMENTS
BAL Programs
OS/3 Sequential DTF Mode to CDI
Macro Converter (DTFCDI3O1)
RPG II Programs
1968 American National Standard COBOL Programs
1974 American National Standard COBOL Programs
FORTRAN Programs

INDEX
USER COMMENT SHEET

F-i
F-i
F-i
F—2
F-2
F-2
F-2
F-3

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Contents 16
Update A

FIGURES
1—1.
1—2.

Organization of Data on Typical Peripheral Devices
Magnetic Tape File Organization

1—4
1—8

2—1.
2—2.
2—3.

Typical Card File Structure
Fixed-Length Unblocked Record Format for Input and Combined Card Files
Card Punch (Output File) Record Formats

2—2
2—2
2—4

3—1.

Schematic Diagram of Card Flow Through 0604 Card Punch

3—20

4—1.
4—2.

Typical Organization of a Diskette Volume
Diskette File Record Formats

4—2
4—5

6—1.
6—2.
6-3.
6—4.

Typical Text Output Example
Sample Table Printout
Sample Forms Printout
Printer Record Formats

6—3
6—4
6-4
6—6

8—1.
8—2.

Reel Organization for EBCDIC Standard Labeled Volumes Containing a Single File
Reel Organization for EBCDIC Standard Labeled Tape Volume: Multifile Volume
With End-of-File Condition
Reel Organization for EBCDIC Standard Labeled Tape Volumes: Multifile Volumes
With End-of-Volume Condition
Reel Organization for EBCDIC Nonstandard Volume Containing a Single File
Reel Organization for EBCDIC Nonstandard Multifile Volume
Reel Organization for Unlabeled EBCDIC Volumes
Label Configuration ASCII Single File Single Volume and Multivolume Sets
Label Configuration, ASCII Multifile Single-Volume Set
Label Configuration, ASCII Multifile, Multivolume Set
Label Configuration Options ASCII Multifile Multivolume Set When
End-of-Volume and End-of-File Coincide
Record and Block Formats for Magnetic Tape Files, ASCII and EBCDIC

8—3

8—3.
8—4.
8—5.
8—6.
8—7
8—8.
8—9.
8—10
8—11.

The Two Partitions of an Indexed OS/3 ISAM File: Cylinder Formats of the Index
Partition and the Data Partition
10—2.
Fixed-Length ISAM Records, With and Without Keys
10—3. Variable-Length ISAM Records, With and Without Keys
10—4.
Layout of ISAM Data Blocks (Prime or Overflow) on Disk, Each Containing
Two Logical Records
10-5.
Schematic Diagram of ISAM Records Chained Into Logical Sequence After Adding
Records to the File
10—6.
Format of Full OS/3 ISAM Index Blocks
10—7.
OS/3 ISAM File Structure
10-8.
Blocks of an ISAM Top Index on Disk and Corresponding INDAREA Table
in Main Storage
10-9.
Logical Aspect of an ASAM File Containing Not More than One Record Chained
in Overflow From Any One Prime Data Record
10—10. Logical Effect of Successively Adding Three Records in Overflow, Chained From
Same Prime Data Record of an ISAM File

8—4
8—5
8—6
8—7
8—8
8—10
8—11
8—12
8—13
8—14

10-1.

10—4
10—6
10—7
10—9
10—10
10—12
10—13
10—17
10—20
10—21

UP-8068 ev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Contents 16a
Update A

1 2—i.
12—2.
12—3.
1 2—4.
1 2—5.
1 2—6.

IRAM Data Records With and Without Keys
IRAM Data Records Spanning Disk Sectors on a Fixed Sector Disk
Typical Fine-Level Index Block of Three Sectors
Typical Coarse- or Mid-Level Index Sector
IRAM Index Partition
Typical Search of 4-Level IRAM Index

12—4
12—5
12—5
12—6
12—7
12—8

1 3A—1.
13A—2.
13A—3.
13A—4.
1 3A—5.

MIRAM Characteristic Data Record Formats
MIRAM Data Record Slots Spanning Physical Block or Sector Boundaries
Fine-Level Index Block
Coarse- or Mid-Level Index Block
MIRAM Index Partition

1 3A—4
13A—5
13A—6
13A—7
13A—8

14—1.
14—2.
14—3.
14—4.

Organization of a DTFNI Disk File Into Partitions and Subfiles
Fixed-Length Physical Record Formats, Nonindexed Disk Files Without Keys
Variable-Length Physical Record Formats, Nonindexed Disk Files Without Keys
Keyed Fixed- and Variable-Length Physical Record Formats, Nonindexed Disk Files

14—4
14—8
14—9
14—12

UP-8068 Rev. 4

15-1.
15-2.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Contents 17

Record Formats and I/O Area Contents for Nonindexed Disk Files
Reading a Sequential Disk File With and Without Record Interface

Tape Leader Paper Data File and Tape Trailer
Undefined Paper Tape Record of Maximum Size for the File:
Relationship of Record Length to BLKSIZE Specification
Undefined Output Record for Standard Mode Paper Tape File in I/O
17—3.
Area and as Punched on Tape
17—4.
Relationships of Record Length, Work Area Length, and I/O Area Length
to BLKSIZE Specification and Content of RECSIZE Register for an Undefined
Record Input From Paper Tape With Shifted Codes
17—5.
Undefined and Fixed, Unblocked Records Followed by lnterrecord Gaps in
Output Paper Tape File, Either Processing Mode
Undefined and Fixed Unblocked Records Followed by Interrecord Gaps in Input
17—6
Paper Tape Files, Standard Processing Mode
17—7.
Fixed, Unblocked Record Followed by Interrecord Gap in Input Paper Tape File,
Binary Processing Mode
17—8
Shifted Undefined Records as They Appear on Paper Tape and in User Work Area
Input File Character Mode (MODESTD)
17—9.
Shifted, Fixed, Uhblocked Records on Paper Tape and in Work Areas: input File, Character
Mode (MODESTD)
17—10. Relationships of Logical Record Length, Work Area Length, and I/O Buffer Length
to the BLKSIZE and OVBLKSZ Specifications for a Fixed, Unblocked Record Input From
Paper Tape With Shifted Codes
17—11. Portion of ASCII Punched Paper Tape, Showing Correspondence Between Hole
Patterns and the Bits of the ASCII Code
17—1
17—2.

15—24
15—31
17—3
17-6
17-7

17-9
17—il
17-12
17-13
17—14
17—15

17—33
17—71

C-i.
C-2.
C-3.

Compressed Card Code
Column Binary (Image) Card Code
96-Column Card Punch Codes

C-B
C-9
c-1i

0-i.
D-2.
D-3.
D-4.
D-5.
D-6.
D-7.
0-8.
0-9.
0-10.
0-il.
D-12.
D-i3.
D-i4
0-15.
0-16.

VTOC Volume Information Label Group
VTOC VOL1 Label
Disk Format 4 Label
Disk Format 5 Label
Disk Format 6 Label
Disk Format 0 Label
File Information Group Label Chain
Disk Format 1 Label
Disk Format 2 Label Nonindexed Files (DTFSD OTFDA DTFNI)
ISAM (DTFIS) File Information Area, Disk Format 2 Label
IRAM/MIRAM File Information Area, Disk Format 2 Label
Library File Information Area Disk Format 2 Label
Disk Format 3 Label
Optional User Standard Header Label
Optional User Standard Trailer Label
8413 Diskette File Label Format

D-2
D-3
D-5
D-8
0-10
D-1 1
0-12
D-1 3
0-i 9
D-20
D-20
0-21
D-26
0-28
0-29
D-30

E-i.

Tape Volume 1 (VOL1) Label Format for an EBCDIC Volume
First File Header Label (HDR1) Format for an EBCDIC Tape VolUme
Second File Header Label (HDR2) Format for an EBCDIC Tape Volume
Tape File EOF1 and EOV1 Label Formats
Tape File EOF2 and EOV2 Label Formats
Optional User Header and Trailer Label Format, ASCII and Standard Labeled EBCDIC
Tape Files

E-3
E-5
E-8
E-iO
E-i2

E-3.
E-4.
E—5.
E—6.

E-i 4

UP-8068Rev. 4

E-7.
E-8.
E-9.
E-10.
E-11.

Contents 18

SPERRYUNIVAC OS/3
BASIC DATA MANAGEMENT

Volume Header Label (VOL1> for an ASCII Magnetic Tape Volume
First File Header Label (HDR1> for an ASCII Magnetic Tape Volume
Second File Header Label (HDR2) for an ASCII Volume
First End-of-File or End-of-Volume Label (EOF1/EOV1>for an ASCII Volume
Second End-of-File or End-of-Volume Label (EOF2/EOV2) for an ASCII Volume

E-17
E—19
E-21
E—23
E—25

TABLES
3—i.

Summary of Keyword Parameters for the DTFCD Macroinstruction

3—13

6—i.

VFB Statement Specification and Interchangeability

‘6—11

7-1.
7-2.
7-3.
7-4.

Device Independent Control Character Codes
Overflow and Home Paper Control Character Codes
Summary of Keyword Parameters for DTFPR Macroinstruction
Device Skip Code Table

7-6
7-8
7-14
7-22

9-1.
.9—2.
9-3.

Summary of DTFMT Keyword Parameters
Variants of DTFMT Keyword Parameters Accepted in OS/3
Effects of Job Control VOL and LBL Statements on Data Management OPEN
Transient, Standard Labeled Tape Files
Summary of Imperative Macros Used with Magnetic Tape SAM

9-4
9-30

9—4.

9-37
9-44

1 1—3.
1 1—4.

Imperative Macro Calls for Processing an OS/3 ISAM File With an Index Structure
Listed by Functions
Imperative Macro Calls for Processing a Nondirectory.OS/3 ISAM File Without
an Index Structure, Listed by Functions
Keyword Parameters of the DTFIS Declarative Macroinstruction
Summary of Filename-Addressable Fields in DTFIS File Table

11-4
11—21
11-49

1 2—1.

Disk-Dependent Factors for Calculating Size of Top-Level Index for an IRAM File

12-13

13—1.

Summary of DTFIR Keyword Parameters

11—1

11-3.

“

11—2.

‘

1 3A—1. Disk-Dependent Factors for Determining Disk Space Requirements

13—16
1 3A—1 3

13B—1. Summary of DTFMI Keyword Parameters

13B-1O

15-1.
15-2.
1.5-3.
15-4.
15—5.

15-9
15—12
15-17
15—25

15—6.
15-7.
15—8.
15—9.

Summary of Keyword Parameters for DTFSD Macroinstruction
Summary of DTFDA Keyword Parameters
Summary of DTFNI and DPCA Keyword Parameters
IOAREA1 Contents
Relative Disk Address (ID> Returned After a READ ‘or WRITE
Macroinstruction When IDLOC Keyword Is Specified
Record Formats for Nonindexed Disk Files
Summary of All Declarative Macro Keyword Parameters Used With the
Nonindexed File Processor System
Summary of Imperative Macroinstructions for Processing Nonindexed Disk Files
Use of IOREG Keyword Parameter for Processing Blocked or Unblocked
Input Disk Files Sequentially With GET Macro.
-.

‘

15-29
1 5--41
15—58
15-61
15-95

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Contents 19
Update C

16—1.

File Lock Summary

16—4a

17-1.
17—2.

Summary of DTFPT Keyword Parameters
Significance of Bits in filenameC, Paper Tape Files

17-27
17—66

A-i.
A—2.
A—3.
A—4.
A—5.
A-6.

SPERRY UNIVAC Card Reader Subsystems Characteristics
SPERRY UNIVAC Card Punch Subsystems Characteristics
SPERRY UNIVAC Printer Subsystems Characteristics
SPERRY UNIVAC Disk Subsystems Characteristics
UNISERVO Subsystems Characteristics
SPERRY UNIVAC 0920 Paper Tape Subsystem Characteristics

A-2
A—3
A-4
A—9
A—b
A—il

B-i.
B-iA.
B—2.
B—3.

OS/3 Data Management Error Messages
Data Management Error Message Subcodes
OS/3 Disk Space Management Error Codes
Significance of Bits in filenameC

B-3
B—9
B—i 1
B—13

C-i.

Cross-Reference Table: EBCDIC/ASCII/Hollerith

C—3

D-i.
D—2.
D—3.
D-4.
D—5.
D—6.
D-7.
D—8.
D—9.
D—iO.
D—i 1.
D—i2.

Contents of V0L1 Label
Contents of Disk Format 4 Label
Contents of Disk Format 5 Label
Contents of Disk Format 6 Label
Contents of Disk Format 0 Label
Contents of Disk Format 1 Label
Contents of Disk Format 2 Label
Contents of Indexed File Information Area, Disk Format 2 Label
Contents of IRAM/MIRAM File Information Area, Disk Format 2 Label
Contents of Library Information Area, Disk Format 2 Label
Contents of Disk Format 3 Label
Diskette File Label Description

D-4
D—6
D—9
D-i0
D—i 1
D—i4
D-2i
D—23
D—24
D—25
D—27
D—3i

E—i.
E—2.
E—3.
E—4.
E—5.
E—6.

Tape Volume 1 (VOL1) Label Format, Field Description for an EBCDIC Volume
First File Header Label (HDR1), Field Description
Second File Header Label (HDR2), Field Description
Tape File EOF1 and EOV1 Labels, Field Description
Tape File EOF2 and EOV2 Labels, Field Description
Optional User Header and Trailer Labels, Field Description for Standard Labeled
Tape Files
Volume Header Label (VOL1), Field Description for an ASCII Volume
First File Header Label (HDR1), Field Description for an ASCII Volume
Second File Header Label (HDR2), Field Description for an ASCII Volume
First End-of-File or End-of-Volume Label (EOF1/EOV1), Field Description
for an ASCII Volume
Second End-of-File or End-of-Volume Label (EOF2/EOV2), Field Description
for an ASCII Volume

E-4
E—6
E—9
E—i 1
E—13

E-7.
E—8.
E-9.
E—10.
E—i 1.

E—i4
E—i8
E—20
E-22
E-24
E-26

-I

m
m

-I

Cl)

-I

-Q

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1-1

Introduction

1.1. THE FUNCTION OF DATA MANAGEMENT
As you know, data processing programs produce desired results by accepting data as
input, processing the data as appropriate, and outputting the results of the processing
performed.
Beca use most data movement and retrieval operations are inherently the same, regardless
of the application involved, generalized, preprogrammed data management packages have
been developed to assist you in performing these tasks.
The degree of assistance you receive from these packages depends on the insight into
your problems by data management developers and the success they achieve in providing
you with the most flexible and convenient data management aids possible. The extent to
which you can inform the data management system of the characteristics of your data and
the specific function you want performed on that data is also integral. Therefore, it is
necessary to establish conventions to communicate, or interface, with your data
management system.
Data management services available to you, the programmer, via OS/3 are varied, flexible,
and powerful. Descriptions of these services and conventions for using them go well
beyond the scope of what a language manual can and should contain. Hence, this and
other manuals dealing exclusively with this subject are provided to facilitate your use of
OS/3 data management.

1.2.

BASIC AND CONSOLIDATED DATA MANAGEMENT

Until recently, the only method of data management available under OS/3 was DTF
(define-the-file) or basic data management. The programmers’ means for interfacing with
this data management system is through certain declarative and imperative macros related
directly to the device from which data is being retrieved or to which data is being moved.
Now under OS/3, another method of data management is available: CDI (common data
interface) or consolidated data management.

UP-8068 Rev. 4

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

1-2
Update A

Consolidated data management generally provides all the services basic data management
does, and then some. The single major difference is that MIRAM (multiple indexed random
access method) files are the only disk files supported by consolidated data management.
Consolidated data management can best be described by answering the following
question: What does consolidated data management provide that basic data management
doesn’t? The answers are:
A single uniform set of declarative and imperative macroinstructions
With basic data management, you must use a specific declarative macroinstruction
(DTF) to define your file and the method used to access that file: DTFMT for a
magnetic tape file, DTFPR for a printer file, DTFIS for an ISAM disk file, and so on.
Also with basic data management the imperative macroinstructions are not the
same for all types of access methods. Different instructions are used to perform the
same functions. For example, to writea record to a tape file you must use a PUT
instruction. To write a record to an ISAM file, you must use a WRITE,NEWKEY
instruction.
Consolidated data management, on the other hand, has a uniform set of declarative
and imperative macroinstructions that you use to define and process all types of files
There are two declarative macroinstructions These are the CDIB and RIB instructions.
The CDIB instruction identifies the file and the RIB instruction describes the file
characteristics and processing requirements. The consolidated data management
imperative macroinstructions are also the same for all types of files. For example, if
you want to write a record, you use the DMOUT instruction regardless of the file type.
Control structures cannot be modified
The control structures for each basic data management DTF macroinstruction are
generated and maintained within your program region. As a result, these structures
can be inadvertently modified and compromise the integrity of the file.
Consolidated data managementeliminates this problem because all control structures
it uses are generated and maintained outside of your program region As a result you
cannot inadvertently modify these control structures. This preserves the integrity of
the file and prevents the distortion of any action taken on that file by data
management. The CDIB and RIB macroinstructions generate parameter passing
structures that are used to communicate information to data management.
A single file access method for all disk files
Basic data management supports a variety of disk access methods SAM DAM ISAM
ASAM, and soion. Thus, you are faced with a decision each time you want to use a
disk file. You must decide how you want to process the file and then select the access
method that meets your needs or is required by the programming language you
intend to use.
Consolidated data management uses one single disk access method, MIRAM, which
provides all the functions provided by the various basic data management disk access
methods. As a result, you only have to decide how you want to process the file.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 -2a
Update A

Enhanced file sharing
With basic data management a file can be shared; that is, it can be used by more
than one program at a time. This sharing, however, is limited because several
programs can read from the file at the same time, but only one program can write to
the file.
Consolidated data management, however, allows complete flexibility; more than one
program can read from or write to the file at the same time.
•

Interactive capabilities
Basic data management does not support interactive capabilities.
Consolidated data management, however, supports a wide range of interactive
capabilities. These allow you to: enter or display data from a workstation; create
workstation screen formats that aid you in entering data or presenting output data;
and develop and include dialogs (question and answer sessions) in your program. In
addition, consolidated data management also supports interactive services that allow
you to operate your jobs from a workstation, perform housekeeping tasks, and
communicate with other workstations in your system.

•

A high degree of device independence
Device independence means that, at program execution time, you can change the
type of device used for a file in your program by changing the job control device
assignment set for that file.
This is not possible with basic data management because changing the device type
requires changing the file definition, recompiling and relinking your program, and
changing the job control stream before you can execute it with a different device.
With consolidated data management, a high degree of device independence is
possible whenever you are processing records sequentially. This is possible because
device assignment takes place when the file is opened based upon the job control
device assignments. As a result, you can change the device that a file is processed on
by changing the job control device assignment set for that file. The file you have
defined must be compatible with the types of devices you want to use. For example, if
you define a file that has an 80-byte record size, the records can be output to a card
punch, printer, tape, disk, diskette, or workstation. If, on the other hand, you define a
file that has a 200-byte record size, the records can be output to a tape, disk, diskette,
or workstation. However, they cannot be output to a card punch or printer without
truncating the data because of the physical limitations of these devices. In addition to
your files being compatible, your program must also be compatible with the devices
you want to use. This means you cannot have any instructions in your program that
are device dependent such as random operations when using a disk or diskette, forms
control operations when using a printer, or screen management operations when
using a workstation.

UP-8068 Rev. 4

SPERRY UNIVAC 0S/3
BASIC DATA MANAGEMENT

1-3
Update A

Use of a particular data management mode is specified at systems generation time. The
capabilities just described are provided when consolidated data management (CDI mode>
alone or in combination with basic data management (CDI/DTF mixed mode> is specified.
This manual specifically describes basic data management. For more detailed information
on consolidated data management, see the consolidated data management concepts and
facilities, UP-8825 (current version) and the consolidated data management macro
language user guide/programmer reference, UP-8826 (current version).
If you want to migrate to consolidated data management, see Appendix F. This appendix
describes the migration requirements for programs written in BAL, RPG Il, 1 968 American
National Standard COBOL, 1974 American National Standard COBOL, and FORTRAN.

1.3.

1 —4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

DATA STRUCTURE

The structural entities recognized by OS/3 data management are illustrated in the
following diagram:
VOLUME
FILE
BLOCK
RECORD

The hierarchy shown is not always followed exactly. The volume concept is not truly
applicable to printers or card devices. On disk, diskettes, and magnetic tape, a file may
sometimes be larger than a volume. A record may sometimes be equal to a block, or a
field equal to a byte. Figure 1—1 illustrates the organization of data on typical peripheral
devices.

A FILE COMPRISES ONE OR MORE SPANS
OF TRACKS ON ALL SURFACES OF PACK

NOTE:
The set of tracks at a specific
radius on all recording surfaces
is called a cylinder.

DISC PACK

Figure 1—1.

Organization of Data on Typical Peripheral Devices (Part 1 of 2)

-t

C)
3,

C)
I

‘1

2
-I

2
-1
2
G)

-U

-n

I
U,

C)
0

C,,

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

1.3.1.

1-6

Definition of Terms

The following is a brief listof terms and definitions to assist you in understanding the
general description of data management in this section:
block
The portion of a file transferred into or out of main storage by a single access.
buffer
An area in main storage for handling a block of data. Must not be smaller than
the blocks to be handled.

direct addressing
Retrieving a specific block or record from disk storage by a single access, using
numeric values given in a field.
extent
A set of contiguous tracks on disk assigned exclusively to one file
extents may be required to provide space enough for a file.

Several

field
One or more contiguous characters, normally comprising a single unit of
information.
file
A delimited storage space having an identifying file name; useful for subdividing
the entire data mass into manageable groups. Also, the data residing in such a
storage space.
partition
A file subdivision, which is required to have uniform block specifications. OS/3
data management provides partition-relative block addressing, and individual
partition extension capabilities.
pointer
A field containing a value for direct addressing. In indexed sequential access
method (ISAM) files, data management introduces pointers between records to
provide for maintenance of logical sequence of records.
record
The collection of contiguous characters designated by the user to data
management as such, for handling as a unit. Record size must not exceed block

size.
volume
The largest physical unit for data storage, such as a tape reel or disk pack.

UP-8068 Rev. 4

1.3.2.

SPERRY UNIVAC 0S/3
BASIC DATA MANAGEMENT

1-7

Punched Card Files

A punched card tile consists of a card deck, input via a reader, or output via a punch.
Records can comprise either a portion of a card or a complete card The records are made
up of fields of related characters. Punched card files must be treated as sequential files
(handled one record at a time insequentialorder).
You must not confuse a deck of cards to be handled as a data management card file with
control stream cards or with data cards embedded in control streams You must place the
data management deck in the card reader when there is a console message calling for
assignment of the reader to the program. You may begin the deck immediately with a data
card, but you must end it with an end-of-data card (/*)• You cannot place an end-of-data
card within the deck.
Details of punched card records and files are presented in Section 2.
1.3.3.

Diskette Files

Diskette files are sequential, unblocked files processed similarly to card files. In fact,
diskettes are intended as rapid replacement media for card processing equipment. Each
diskette is a single-sided, single plate disk with tracks containing fixed sectors. Records
are recorded on the tracks, one record per sector.
4 and 5 discuss the diskette in
more detail.)
1.3.4.

Printer Files

Printer files include standard text listings forms and similar printed ouptut The files are
composed of individual records that are formed in an output area or work area by your
program and then output to the printer in increments of one record (line). The file is
output, character by character, in a serial manner. When the printer buffers are loaded,
the line is then printed. This process repeats, each line in succession, until the entire file
is printed. A printer record can also contain certain control characters which, although
part of the output record, are not printed. The control characters allow you to advance the
paper to a home position, specify a procedure in case of overflow, or select a number of
lines to be skipped by the printer. Section 6 gives details on printer files and records;
Section 7 describes the uses of control characters
1.3.5.

Magnetic Tape Files

Magnetic tape files are also sequential files, and can span more than one voIume (reel).
Each magnetic tape file is identified by two file header labels; each volume of the file has
a volume label. Because most magnetic tape files can be read in both a forward and
backward direction, the file labels are placed both at the beginning and at the end of each
of these file levels.

1-8

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Figure 1—2 illustrates the relationship of the various elements of a magnetic tape file. The
volume label (VOL1) has a standard system format that describes the Contents of the tape
volume. The two file header labels (HDR1 and HDR2) also are in a standard system format.
User header labels (UHL), which are optional, may be in a standard format Or one that you,
as a user, can structure. A tape mark is next in the sequence, and acts as a delimiter to
indicate that data blocks or records follow. After the data, another tape mark, two end-ofvolume (EOV) labels, optional user trailer labels (UTL), and two more tape marks are
provided as delimiters. A complete description of the magnetic tape file organization and
conventions ispresented in Section 8; Appendix E describes the labels for magnetic tape
files

TAPE MARK

TAPE MARKS

LEGEND:
Volume Label
File Header Label 1
File Header Label 2
User Header Labels (optional)
End of-Volume Label
End of Volume Label
User Trailer Labels (optional)

VOL1
HDR1
HDR2
UHL
EOV1
EOV2
UTL

1.3.6.

Figure 1—2.

DIRECTION OF MOVEMENT, FORWARD READ

Magnetic Tape File Organization

Disk Files

Provisions for disk files differ from thosefor sequential devices in that there are several
data management programs from which to choose. You implement your choice by
selecting one of several operation codes at the point in your program where the DTF
(define the file) procedure (proc) is coded. You must consider the services offered by the
programs to determine which is best suited to your needs for the particular file.(There isa
certain amount of overlap in the services available, so it is possible for you to meet a
particular need through either of two programs)The desire for rapid storage and retrieval
is usually paramount In this context several considerations are pertinent
•

Is search-by-key needed?

•

Is appending new data to a series satisfactory, or are insertions necessary?

•

Are direct addressing or sequential access, or both necessary?

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

•

1-9

Is reading or writing blocks sufficient, or is assistance with records needed?

To satisfy these questions, detailed descriptions of the disk file services are presented in
Sections 11 through 13.
1.3.7.

Paper Tape Files

Punched (or perforated) paper tape files are handled at the logical record level by a paper
tape data management system described in Section 1 7. The system provided byOS/3
includes macros, transients, and processing modules with Which you can define paper
tape files and read and write data on paper tape Translation and letter/figure shiftirig
capabilities are provided.
1.4.

PROGRAMMING FOR DATA MANAGEMENT

All users of OS/3 must employ the conventions established for designating existing files
and new files in the job control stream. In using data management, you must also code
appropriately in your BAL program.
•

By issuing a DTF declarative macroinstruction provided by data management,. you
cause a DTF table to be created in a data area. By using keyword parameters, you
describe the file and provide addresses of buffers and work spaces. You must also
indicate your desire to handle all returns inline, or you must give the address of your
routine for accepting control when errors or exceptions occur.

•

By using ordinary, assembler instructions, you must reserve sufficient amoUnts of
main storage buffer space and workspace, and you must provide the error/exception
routine.
.

•

By issuing imperative macroinstructions provided with each access method, you
request data management to perform specific file-processing functions

•

You must realize that general registers 0, 1, 14, and 1 5 are loaded by the imperative
macroinstructions before the contents of your registers are saved. You cannot afford
to have vital data in these registers when you call on data management.

•

You must provide a 72-byte register save area The address of this area can be placed
in the DTF by specifying the SAVAREA keyword pàrãmeter, common to all DTFs;
Failing to do this you must provide the address in register 13 when you enter each
data management imperative macro

•

The storage area you specify with the SAVAREA keyword parameter is often useful to
examine in snaps or dumps of your program region. It Comprises 18 full words, the
first three of which are used by data management. Following these is a display of full
words for 15 of the general registers, presented in the following order: 14, 15, 0, 1, 2,
and so on, through 12. Register 13 is not included.

UP-8068 Rev. 4

1.5.

SPERRY UNIVAC OS/a
BASIC DATA MANAGEMENT

1-10

OS/3DATA MANAGEMENT ENHANCEMENTS

OS/3 data management departs from traditional data management systems in several
areas.

1.5.1.

ISAM Files

In OS/3 ISAM files, inserted records are placed in overflow blocks, forming chains
between Individual prime records This causes all data records to remain where originally
placed and eliminates time consuming record pushdown. Moreover, the stability of records
makes it possible to offer direct addressing to. every record, a convenience for those who
can benefit from this feature.
The ISAM program can also operate on files where the key index structure is never
formed. This precludes the use of keyed instructions, :but leaves the rest of the repertoire
operative. The ISAM load is still effective for file creation. The resulting file is then
susceptible to sequential and direct access without keys
Eliminating the index does not preclude the ability to insert records. The pOsition for
insertion cannot be reached by a key search. However, both direct access and sequential
progression are available to reach any record so that a new record may be inserted after it
1.5.2.

SAM and DAM Files

The flexibility of sequential access method (SAM) and direct access method (DAM)
processing has been augmented in OS/3 by provision of a DTFNI macroinstruction and
processing module. This module supports an extended repertoire of imperative
macroinstructions applicable to a file described by the DTFNI macroinstruction.
Combinations of SAM and DAM imperative macroinstructions may be used; NOTE and
POINT imperative macroinstructions are provided. There is also provision for partitioning a
file using different block specifications for each partition These are supported by
partition-relative block addressing.

1.5.3.

IRAM Files

The indexed random access method (IRAM) is an access method in OS/3 for handling disk
files and is intended for use by programs written in RPG II language, the sort, and data
utilities. The functionality of IRAM is equivalent to that provided by OS/3 ISAM and
ASAM, and by the OS/3 nonindexed access disk methods SAM and DAM (relative record
addressing); however, those modules (ISAM, ASAM, SAM, and DAM) are considerably
larger. The IRAM processor cannot access disk files that have been created by other
access methods nor can IRAM files be processed by other OS/3 disk access methods.

UP-8068 Rev. 4

1.5.4.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1-11

MIRAM Files

The multiple indexed random access method (MIRAM) in OS/3 is used for handling
sequential, relative, and indexed files in programs. These programs are written in the
OS/3 version of the 1974 American National Standard COBOL, and for sequential and
relative (direct) files in programs that are written in FORTRAN IV. MIRAM provides the
same functions as those provided by OS/3 ISAM, ASAM, IRAM, SAM, and DAM disk
access methods. The MIRAM processor can access only MIRAM and IRAM characteristic
files that it has created or IRAM files created by the IRAM processor. It cannot access disk
files that have been created by other access methods nor can MIRAM files be processed
by other OS/3 disk access methods. MIRAM files, however, can be processed by using the
sort/merge and data utilities programs.
1.5.5.

Error and Exception Returns

OS/3 data management differs somewhat from other data management systems in its
method of returning control to your program. Control is always returned, whether or not
an error or exception has been detected. A reply field is always set to indicate the nature
of the exception. If the function is executed with no defects, control is always returned
inline to the instruction following the macro call. If you provide the address of an
error/exception routine in your DTF macroinstruction, control is returned to that address
on all occurrences of errors or exceptions. In the absence of this address, all returns are
made inline (register 14 always contain the inline return address). Appendix B describes
the error and exception handling features of OS/3 data management.
Because data management interprets a zero value in the DTF error field of the DTF file
table as the nonexistence of an error routine, you must hot locate your error routihe at
location 0 relative to the load module.
Errors occurring during file extend operations are always associated with inability to
acquire output space for a buffer and consequent’ loss of output data. On: extend failure
errors,’ file extend procedures now minimize loss of output ‘data to one record.
1.5.6.

Disk Flexibility and Hardware ‘Constraints

The obligation to handle disk devices with different characteristics has influenced the
design of OS/3 data management. It was considered desirable that the disk file processing
modules should be independent of the disk type used and should present the same
interface to you. As a result, OS/3 data management requires, throughout, that all blocks
in a track or partition be uniform in size and format. On the fixed-sector disk devices, it is
also necessary that all blocks be multiples of 256 bytes. Furthermore, spanned records
(those extending beyond a block boundary) are not supported.
Consequently, during sequential blocking of records, block filling continues until a
submitted record will not fit in remaining block space. At that point, the full-size block is
written to disk, and the rejected record is used to begin the next block.

1-12

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

The fixed-sector disk does not provide an RO record for identifying the portion of track
devoted to useful data. Furthermore, the hardware search interrogates the first n bytes of
every 256-byte sector. These characteristics cause some restrictions of relative-track DAM
functions. When employing the WRITE,AFTER macro, you mustf ill each track because the
unfilled portion is: not identified. When employing keyed operations, you must use a block
size of 256 bytes; otherwise, false internal hits could be made in blocks of 512 bytes and
other multiples of 256 bytes.
1.5.7.

Shared Data Management Modules

Under OS/3 all data management modules are shared-code modules There is only one
data management module for each access method and when a particular access method is
requested by a program, one copy of the corresponding module is loaded into main
storage. This module is then used or shared by all programs requesting the same access
method.
DATA MANAGEMENT/USER INTERFACE

1.6.

The interface between you and data management consists of:
•

Declarative macroinstructions

Imperative macroinstructions

1 6 1

Declarative Macroinstructions

Your program must inform the system of the parameters, special conditions, current
status, and options pertaining to a file. You must include a declarative (file definition)
macroinstruction for each file required by your program. As implied by the term
declarative, these macroinstructions generate nonexecutable code, such as constants and
storage areas for variables. Therefore, you should separate these macroinstructions from
the inline file processing coding. The declarative macroinstruction and the selected
keyword parameters in the operand define the file. The first three characters of the
operation code must be DTF. The last two characters usually indicate the type of device or
method of accessing. A keyword parameter consists of a word or code immediately
followed by an equal (=) sign and one specification.
The format of the declarative macroinstruction is
LABEL

filename

OPERATION

DTFcc

OPERAND

keyword-1=x,...,keyword-n=z

UP-8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1-13

The symbolic name of the file must appear in the label field. The name can have a
maximum of seven characters and must begin with an alphabetic character. The
appropriate DTF designation must appear in the operation field. The keyword parnrneters
can be written in any order in the operand field and must be separated by commas.
However, a comma must neither be coded in column 16 of a continuation line nor follow
the last keyword of a string. Appropriate assembler rules regarding macroinstructions
apply to blank columns and continUatiOn statements. Registernumbers are specif ied to the
data management declarative macroinstructions (DTF) by enclosing the number in
parentheses. Certain DTF parameters can be changed at run time via the data definition
job control statement (DD). (See Tables 3—1, 7—3, 9—1, 1 1—3, 13—1, 1 3B—1, 15—1,
15—2, 15—3, and 17—1.)
The DTFs may have the following forms
•

DTFCD
Defines an input output or combined punched card file

•

DTFDA
Defines either an input or output direct access disk file.

•

DTFIR
Defines input or output indexed or nonindexed IRAM disk files.

•

DTFIS
Defines an indexed sequential disk file

•

DTFMI
Defines an input oroutput indexed or nonindexed MIRAM disk files:

•

DTFMT
Defines an input, output, or in/out magnetic tpe file;

•

DTFNI
Defines a nonindexed input and output disk file.
DTFPR
Defines a printer output file.

•

DTFPT
Defines an input or output paper tape file.

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

1-14

DTFSD
Defines an input output or combined sequential access disk file

•

DPCA
Similar to a DTF macroinstruction but defines a partition of a disk file rather than the
entire file.

1.6.2.

Imperative Macroinstructions

Your program must be able to communicate with the data management modules in order
to process files that have been defined by declarative macroinstructions. Imperative (file
processing) macroinstructions included in your program communicate with the transient
routines and logical IOCS shared-code modules. The imperative macroinstructions are
expanded as inline executable code. Not all macroinstructions are available for use on all
devices. Some are specifically input-type macroinstructions and cannot be used for a
device that is exclusively used for output; the opposite is true, also.
The format of the imperative macroinstruction. is:
LABEL

[name]

OPERATION L

xxxx

OPERAND

yyvy,.. .,zzzz

A symbolic name can appear in the label field. The name can have, a maximum of eight
charcters and must begin with an alphabetic character.The appropriate verb or code must
appear in the operation field. The positional parameters (as signified by the name) must be
written in the specified order in the operand field and be separated by commas. When a
positional parameter is omitted, the comma must be retained to indicate the omission
except in the case of omitted trailing parameters Appropriate assembler rules regarding
macroinstructions apply to blank columns and continuation statements.
1.6.3.

Assembler Rules for Operand Field

The operand field of a macroinstruction begins in column 16 and may not extend beyond
column 71. An operand may be continued onto the next line by inserting an arbitrary
nonblank character in column 72. Each continuation line starts in column 16.
The operand field is terminated by the first blank which is not enclosed’Within
apostrophes. As operand specification is usually completed before column 40, columns 41
through 71 are available for comments, but at least one blank space must occur between
the end of operand specification and the beginning of the comments.

UP-8068 Rev.4

1-15

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Comments are not continued by the insertion of a nonbiank character in column 72.
Lengthy comments can be entered by coding an asterisk (*) in column 1. You will note the
applications of these rules in the programming examples throughout this manual.
Operands may be continued onto the next line by placing a comma after the last operand
on the first line and a nonblank character in column 72. However, if you omit the comma
and at least one blank exists between the last operand on the first line and the nonblank
character in column 72, the second line of operands is treated as comments. Because the
second line is treated as comments and not as part of your operand specification, the
assembler does not flag the missing comma as an error. Up to. two comment lines are
permitted.
1.7.

RELATED OS/3 SOFTWARE

Several OS/3 software components are indirectly involved with data management, while
others perform functions related to and required for program operation. These components
include:
•

System service programs (SSP)

•

Job control

•

Supervisor

•

Linkage editor

•

Data utilities

1.7.1.

System Service Programs (SSP)

H..

The service programs. provided to prepare disk and magnetic tape files to accept data
records and blocks are the disk prep program and the magnetic tape prep program.
The disk prep routine performs a surface analysis for the disk tracks and assigns alternate
tracks if defects are discovered. The disk prep also establishes a volume table of contents
(VTOC) for the device so that files can then be placed on the disk.
The magnetic tape prep routine prepares magnetic tapes in standard label format by
writing the initial volume label, dummy file header label, dummy file trailer label, and tape
marks.
...

Other system service programs include dump routines in non-narrative or narrative
formats. The SYSDUMP and JOBDUMP routines provide the resident shared-code
directory and the preamble EXTRN table in narrative format.
These routines are described in detail in the system service programs (SSP) user guide
UP-8062 (current. version).

UP-8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1-16

1.7.2. Job Control
The main functions of job control, as related to data management, are:
‘

Allocation of required peripheral devices

•

File control block (FCB) management

•

Catalog management allowing automatic identification of files by name

•

Loading printer vertical format buffer (VFB) and load code buffers

•

Defining software facilities (SET) needed to support the user program

•

Modifying DTE specifications at run time (DD).

Peripheral devices are assigned through job control statements that specify logical unit
numbers, alternate device types, and information about the file. These job control
statements include:
// DVC Statement assigns device number.
// VOL Statement describes tape and disk volumes.
// EXT Statement provides disk extent information.
// LBL Statement provides additional tape and disk identification information.
// LED Statement links the file defined by the DTE macroinstruction with the file and
device information in the control stream.
Each part of this manual that deals with a particular access method or device type
provides you with job control stream examples that illustrate the relationship between data
management entries coded for program assembly and the job control stream statements
that control the program.
A separate file control block is maintained automatically in main storage for each active
file. This block contains all descriptive information about the file and is used for reference
when the file is being accessed.
OS/3 automatically loads the data management modules needed by your job. However, if
you have written your own shared-code modules, you must use the SFT job control
statement to identify and load these modules. SFT statements are effective only during the
job step in which they are specified.
For details on OS/3 job control, refer to the job control user guide, UP-8065 (current
version).

UP-8068 Rev.4

1.7.3.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1-17.

Supervisor

The supervisor, provides the greatest amount ofsupport for the user program and data
management. This support includes the following:
PIOCS

Those macroinstructions and routines that schedule and monitor execution of channel
programs, controlling theactualtransfer of physical recordsbetween external sources
and main storage. These routines also provide for device I/O error recovery
•

Transient scheduling
The routines that retrieve transients from auxiliary storage and bring them into main
storage for execution. These include file open and close routines.

•

Operator communication
The routines that handle the communications concerning volume mounting requests,
tape mount requests, etc.

•

File protection
Protection of files and records during shared file processing.

•

Timer services
Used as a reference for computing run time, scheduling, etc.

•

Disk space management
Routines for allocating space to disk files and maintaining space accounting through
standard procedures for updating the volume table of contents (\/TOC).

•

System Access Technique (SAT)
An input/output control systems that provides a standard interface for tape and disk
subsystems between OS/3 data management and the PIOCS.

For details concerning the supervisor, refer to the supervisor user guide, UP-8075 (current
version).
1.7.4.

Linkage Editor

The linkage editor is a system service program that constructs a load module from object
modules. The linkage editor control statements that define the load module are contained
in the job control stream beginning with a LOADM control statement and terminated by
another LOADM control statement or by an end of data (/*) job control statement. For
details concerning the linkage editor, refer to the system service programs (SSP) user
guide, UP-8062 (current version).

UP-8068 Rev.4

SFERRY.UNIVAC 08/3.
BASICuDATKMANAGEMENTL’

1.48

C’:

1.7.5. Data Utilities
rThe OS-/3 data utility and service rojtinès are provided to aslist ydu mi manipulating data
files and preparing card decks. Your use of these routines requires only a• minimum
amount of programming effort. You simply code the appropriate job control statements,
together with utility and data statements or control specifications, to exchange infStmation
with OS/3, submit parameters, and start your job
::‘.‘1’3

:;;.i

••.‘

:.‘..

..:

—.
•.

Thft./3 dais utilities and service routines are described in detail. iruthe datacutilities
user guide/programmer reference; UPw8O69, (current version)::;
...:

( ‘)f

•XPs..

f•

••.
.

.n- .::t

:
,

;r—.

t.:

. .

;;&:

‘.i

;,‘:

2.-..

‘

I’,.

-.:.

•.

...

_:.

..-

. .,.

1•

Cl)

2
-I

•0

ill

-I
-I

-1

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

2-1

2. Card Formats and File Conventions

2.1.

GENERAL

This section describes the data formats and file conventions that apply to the card reader
and card punch subsystems supported by the SPERRY UNIVAC 90/30 System and the
OS/3:
•

SPERRY UNIVAC 0604 Card Punch Subsystem

•

SPERRY UNIVAC 0605 Card Punch Subsystem

•

SPERRY UNIVAC 0716 Card Reader Subsystem

•

SPERRY UNIVAC 0717 Card Reader Subsystem

•

SPERRY UNIVAC 0719 Card Reader Subsystem

For the functional characteristics of these subsystems, refer to Appendix A.
2.2.

FILE ORGANIZATION

Your punched card decks may include a start-of-data job control card at the beginning and
must include an end-of-data job control card at the end of the card deck (Figure 2—1).
Punched card files can be input (card read), output (card punched), or combined
(read/punched).
The basic punched cards for subsystems supported by OS/3 are standard 80-column, 12row rectangular tab cards. However, optional hardware features, available on both 0716
and 0717 card readers, allow reading of 51- and 66-column stub cards. The 0716 is
capable of reading 96-column card data files.

ur-ouoo aiev. ‘f

rtrir1T uriavaL.,

BASIC DATA MANAGEMENT

END-OF-DATA JOB
CONTROL CARD
OPTIONAL
51-COLUMN
OR
66-COLUMN
FILE

JOB

COMBINED FILE
(ALTERNATING DATA
AND BLANk CARDS)

(OPTIONAL)

Figure 2—i.

22.1.

Typical Card File Structure

Card Input Files

The card reader handles fixed-length unblocked records, which always have the same
length for your entire file. This length is equivalent to the value you selected for the
BLKSIZE keyword parameter of the DTFCD macroinstruction when defining the file. Figure
2—2 illustrates the fixed-length unblocked format related to card input files; the same
format is used for combined files (8.2.3).

recordn

NOTES:
1.

The record length, A, must be an even number of bytes, at least as many as specified by the BLKSIZE keyword
parameter.

The I/O area must be aligned on a half-word boundary and comprise an even number of bytes.

When 51 -column stub cards are processed, the BLKSIZE keyword parameter may specify a 51-byte length, but the I/O
area must be 52 bytes in length. A work area may be 51 bytes long.

Figure 2—2.

Fixed-length Unblocked Record Format for Input and Combined Card Files

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

2.2.2.

2-3

Card Output Files

The card punch files (output) consist of data that is formed into physical records, usually in
the I/O area, and then output to the card punch, where the records are punched in the
standard 80-column format. The cards are then accumulated in a stacker, which keeps
them in sequence.
2.2.3.

Combined Files

Combined read/punch files are allowed only where the optional read/punch feature is
installed as part of the card punch. This feature allows you to read cards and punch cards
in the same file (deck) on a single pass through the card punch. Reading and punching of
cards can be accomplished in the following ways:
•

Data can be read from a card then punched on the same card. This requires the
nonoverlap mode of processing (3.3).

•

A card deck containing alternating punched and blank cards can be entered; each
punched card is read and data is punched on the blank card following. The overlap
mode of processing must be specified (3.3).

•

Punched cards and blank cards can be grouped; the punched cards are then read, and
the following group of blank card is punched with the new data. The overlap mode of
processing must be specified (3.3).

2.3.
2;3.1.

RECORD FORMATS
Start-of-Data Job Control Statement (/$)

Data management does not check for a start-of-data card. For consistency, you may
choose the /$ card convention as a card file identification. If you do so, your program
should include a check for this card.

2.3.2.

End-of-Data Job Control Statement (/*)

Data management checks for an end-of-data card when you are reading cards. The format
of this card is identical to that required by job control. The first two columns contain /*•
When this configuration is sensed, control is transferred to the end-of-file address
specified for the file. When an output file is punched, the end-of-data card is not punched
by logical IOCS. You must supply the end-of-data card for input and combined files.

UP-8068 Rev. 4

2.33.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

2—4

Card Punch Records

You may form card punch records either in the I/O area or in a designated work area of
main storage The records, illustrated in Figure 2—3, are of three. types:
•

Fixed-length records

•

Variable-length records

•

Undefined-length records

Fixed-Length

data

Undefined

data

A
Variable-Length

data

—

F—
LEGEND:
b

Block size field, four bytes

Record length field, two bytes, binary

u
A

Reserved (two bytes) may be any two characters chosen by the user
Data record length

Variable record length

Record size field

I/O area layout

NOTES:
1.
2.
3.

An I/O area must be so aligned that the first character to be punched falls on a half-word boundary.
Record length, as a binary number, must be placed in the first two bytes of the record length field (r)before punching a variablelength, unblocked record.
An even number of bytes should be allocated for data in I/O areas, even though an odd number of columns are to be punched.
The I/O areas for a file with an odd block size should provide at least block size+1 bytes.
Figure 2—3. Card Punch (Output File) Record Formats

SPERRY UNIVAC 0S/3
BASIC DATA MANAGEMENT

UP-8068 Rev 4

3.1.

3-1

Function and Operation of
Punched Card SAM

GENERAL

The OS/3 includes data management modules that you can use to move and manipulate
sequential access method (SAM) card reader files, card punch files, and combined
(read/punch) files. These modules allow you to configure your program for each particular
application and related device types.
This section contains a brief functional description of punched card SAM operation for
input files, output files, and combined input/output files. Following the functional
description is a detailed explanation of the declarative macroinstructions that define the
three types of files. The section concludes with detailed descriptions of the imperative
macroinstructions that initiate, conduct, and terminate file processing.

3.2.
3.2.1.

FUNCTIONAL DESCRIPTION
Punched Card Input

The card reader is a unit record device and is connected to the integrated peripheral
channel or to the multiplexer channel, if several relatively slow peripheral devices are to
share I/O jointly. The punched card file comprises data in the Hollerith punched card code
(Appendix C). The cards are usually divided into fields; these files, in turn, are combined to
form physical records.
You define, to the system, the type of file, structure of the data, and the operating
environment in which your file will be processed through a define the file (DTFCD)
declarative macroinstruction. At system installation, the system macro library file
($Y$MAC) is loaded with source code modules that are common to several machine
operations. These modules include data management modules that are common to several
device types and access methods.
When assembling the program, you define the files (input, output, or combined) used in
the operation through the DTFCD macroinstruction. The source modules for the particular
data management operation are called in from the macro library during program assembly
by using imperative macroinstructions which place the modules in your program as inline
code. Each macroinstruction available for punched card file processing is described in
detail in 3.3 and 3.4.

UP-8068 Rev. 4

322.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

3-2

Punched Card Output

The punched card output records are constructed in the I/O area or a designated work
area. Processin9 data and creating an output on punched cards are similar to the
procedure described in 3.21 except that the CNTRL macroinstruction can be used with the
0604 Card Punch Subsystem(0604 card punch).
If the punched card deck is to be inserted in a program, you must punch a start-of-data
(/$) job control card and an end-of-data (/*) job control card and add these to the
beginning and end of the punched card deck.

3-3

SPERRY UN1VAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

DTFCD
(card)

3 3

DEFINE A SAM CARD FILE (DTFCD)

Function:
The DTFCD declarative macroinstruction is required for you to define punch card files
that are accessed by OS/3 SAM. Following is a listing, in alphabetic order, of the
required and optional keyword parameters that might appear in the operand of the
DTFCD macroinstruction. A summary of the keyword parameters is provided in Table
3—1.
A comma is shown preceding each keyword parameter except the first to remind you
that all keywords coded in a string must be separated by commas. However, a comma
must neither be coded in column 16of a continuation line, norfollow the last
keyword in the string. Refer, to the coding examples which follow:
Format:

;

LABEL

filename

£OPERATIONt

DTFCD

OPERAND

[ASCIIYES]
[,AUE=YES]
[ BLKSIZE=n]
[,CONTROL=YES]
CRDERR=RETRY]
1
[
i: EOFADDR=symbol]
[ERROR=symbol]
lOAREAlsymbol
[IOAREA2=symbol]
[,IOREG(r)]
[ITBL=symbol]
rMODE=

BINARY
CC

STD

TRANS

[OPTION=YES]
[ORLP=YES]
[,OTBL=symbol]
[,OUBLKSZn]

[RECFORM=
UNDEF
VARUNB

[RECSIZE= ,[(r)
fl

[,SAVAR
r,STuB=15i
66
L

3-4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

LABEL

filename
(cont)

OPERAND

OPERATiON

DTFCD

INFJT
OUTPUT

[TYPEFLE=

[[,WOR KA=Y

ES]

Keyword Parameter ASCII:
ASCII=YES
Specifies processing in American Standard Code for Information Interchange
(ASCII).
For input files, you must specify this parameter if you desire your card data to be
translated into ASCII code for internal processing and storage.
For output files, you must specify this parameter if internal processing is in ASCII and
you desire output in Hollerith punched card code (Appendix C).
The keyword parameter MODE should be written as MODESTD if this parameter is
supplied.
Keyword Parameter AUE
AUE=YES
Inhibits data management error processing when validity check errors are
detected on nonbinary input files.
In punched card input files, a validity check error (also termed a unique unit error) is
the occurrence of more than one punch in rows 1 through 7 of any column in a card,
and usually indicates a mispunch Each time a validity check error is detected the
operator receives a PIOCS message at the system console indicating the problem The
card containing the error is the last card in the stacker. The operator has three
options: He can place the error card in the input hopper and reply “R” to reread the
card, or he can reply “I” or “U”, to indicate that the error is to be ignored or is
unrecoverable. If you have specified AUEYES, and the operator replies “I” or “U”,
data management does not branch to your error routine The error card is skipped (not
passed on to the user).
On the other hand, if you do not specify AUE=YES and a validity check error is
detected data management branches to your error routine if the operator replies U
When your error routine receives cGntroI data management will have set the unique
unft error flag (byte 0, bit 2) of filénameC in your DTFCD file table. Refer to Appendix
B. Data management ignores the AUE keyword parameter if 8413 diskette files are
used.
Keyword Parameter BLKSIZE:
BLKSIZEn
Specifies the length of the I/O area in bytes. If the records in a file are variable
length, n specifies the maximum size for records. For variable, unblocked records,
n includes the block size and record length fields.

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

3-5

The user can specify BLKSIZE=1 to BLKSIZE=96 to readfrom1 to 96columns of
a 96-column card.
A user program that specifies BLKSIZE1 to BLKSIZE=80 can read fro m 1 to 80
columns of 96-column cards. A program that hasa BLKSIZE of 1 to 80 and that
has been used. with 80-column cards,; in any modeexcept binary, can read 96column cards with no program changes.
A program that specifies BLKSIZE1 to BLKSIZE96 to the DTFCD proc cal[ can
be used to read up to 96 columns of a 96-column card. Such a program can also
read up to 80 columns of 80-column cards. The DMCS Will blank out (insert the
appropriate blank character, based on data mode) bytes in the user’s I/O and
work areas for columns beyond 80. At OPEN time, DMCS checks for 80-column
cards being read with BLKSIZE from 81 to 96. If such a cohdition exists, a
message is Issued to the operator with a required reply
If omitted, the block size is determined from the keyword parameters MODE,
RECFORM and STUB
Keyword Parameter CONTROL
CONTROL=YES
Specifies that your program will issue one or more CNTRL imperative macros to
control stacker selection on the 0604 card punch; used only for output or
combined card files.
The use of the CNTRL macro which applies neither to input card files nor to the 0605
card punch, is explained in 3.4.4. If you specify CONTROL=YES in the DTF for an
input file, the parameter is ignored, and a diagnostic message is printed in the DTF
expansion in your assembly listing.
Keyword Parameter CRDERR:
CRDERR=RETRY
Specified if card punch error recovery should be attempted on hole-count errors
for 0604 and 0605combined read/punch files or on the 0604 card punch output
files with stacker selection. Error cards are automatically selected. into the error
selectstacker. Iferrorrecovery is not successful, the logical IOCS returns control
to the address of the user’s errorroutine (ERROR). If keyword parameters
CRDERR and ERROR are not specified, the card system returns to your program
inline when a punch error (hole count error) is encountered. See 3.6.2.
Error recovery is provided for hole-count errors on 0604 combined read/punch card
files, 0604 card output files with stacker selection, and punch checkrerrors on 0605
combined read/punch card files. If the 8413 diskette is used, the CRDERR=RETRY
parameter is ignored
Keyword Parameter EOFADDR:
EOFADDR=symbol
Specifies the address to which control is transferred when the end-of-data card
is sensed. This keyword parameter is required for all input and combined files.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

3-6

Keyword Parameter ERROR:
ERRORsymbol
Specifies the address of your error handling routine. When a fatal hardware or
detectable logical error occurs on a file, you may have control transferred to a
special error handling routine If not specified errors return inline (see 3 6 and
Appendix B).
Keyword Parameter IOAREA1:
lOAREAlsymbol
Specifies the address of an I/O area that each input or output file must have
reserved for its individual use. Keyword parameter IOAREA1 specifies the input
area for a combined file; IOAREA2 must also be used to specify the combined
file’s output area. I/O areas must contain an even number of bytes for data to be
punched or read. Odd numbers of columns can be read or punched. If the
BLKSIZE specification is an odd number of bytes, the I/O areas must be at least
BLKSIZE + 1 bytes long; this means, for example, if you are using all of the 51column stub card and have therefore specified BLKSIZE=51, that the length of
the storage area you define for IOAREA1 must be 52 bytes. The first data byte
(character read or to be punched) must be aligned on a half-word boundary. The
length of the area is specified by the keyword parameter BLKSIZE.
Keyword Parameter IOAREA2:
IOAREA2symbol
May specify a secondary I/O area for standby processing; must be used to
specify the output area for a combined file. You must allocate I/O areas that
provide an even number of bytes of data. The first data byte must be aligned on a
half-word boundary.
Keyword Parameter IOREG:
IOREG(r)
Specifies the number of the general register (2 through 12) used to reference
current data If SAVAREA is specified register 13 may be used for IOREG If a
work area is not required this keyword parameter must be specified when there
are two I/O areas This parameter may not be specified if either a work area or a
combined file is specified through the DTFCD macroinstruction Do not specify
WORKA if this parameter is specified.
Keyword Parameter ITBL:
ITBLsymbol
Specifies the addrss of the 256 byte translation table in your problem program
when records in an input or combined file are to be translated on input. If the
keyword parameter MODE=TRANS is specified, the keyword parameter ITBL
must also be specified.

UP-8068 Rev. 4

SPERRY UNIVAC 0S/3
BASIC DATA MANAGEMENT

3-7

Keyword Parameter MODE:
This keyword parameter is used to specify the input/output mode of the file and is
required as part of the DTFCD macroinstruction. There are four forms of the keyword
parameter which can be used with all types of files:
MODE=BINARY
This form is used for cards read on the card reader in binary mode or for cards
read or punched on the card punch in column binary (image) mode. An I/O area
of 160 bytes is required for one 80-column card.
The binary mode is not available for 96-column cards. This parameter is ignored
if the 8413 diskette is used

MODE=CC
On thecard punch, thisform must be specified for cards read or punched in
compressed code An I/O area of 80 bytes is required for one 80-column card
MODE=STD
Should be specified for cards to be read or punched in EBCDIC. This keyword
parameter must be specified if the ASCII=YES parameter is specified. If no
MODE keyword is supplied this option is assumed
MODE=TRANS
You should specify this option to have cards read in EBCDIC and translated by
your ITBL translation table, or translated by your OTBL translation table and then
punched in EBCDIC. Each position of your 256-byte translation table contains a
bit-pattern youhave assigned to it.
On reading a byte or card column in the record to be translated, data
management places into the receiving byte of your I/O area the bit-pattern it
finds in the position of your translation table which cOrresponds to the position
which the bit- or hole-pattern to betranslated occupies in Table C—i (Appendix
C). For example, on reading 1 2-0-9-8-1 hole-pattern, which occupies position 0
in the EBCDIC column labeled Hollerith Punched Card Code in Table C—i, data
management will place into your I/O area the bit-pattern it finds in position 0 of
your ITBL translation tabIe. If you move to your I/O or work area the bit-pattern
which occupies position 1 of your OTBL translation table, data management will
punch the hole-pattern (12-9-i) which occupies position 1 in the EBCDIC column
labeled Hollerfth Punched Card Code in Table C—i, and so on.
Do not use the Hollerith Punched Card Code column in the ASCII portion of Table
C—i for this translation table feature.
Keyword Parameter OPTION:

OPTION=YES
Specifies an optional file: one which you anticipate will not invariably be required
for every execution of your program.

SPERRY. UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

3-8

When the OPTION keyword parameter is used, optional file processing is performed
by data management:
u

if the OPT positional parameter is included in your DVC job control statement
and the device is not avaialble at execution time; or

•

when no device is assigned to the file by your job control statements (i.e., no
=
DVC-LFD device assignment set).

Optional file processing:
•

For an input or combined file, which you issue a GET imperative
macroinstruction, data management branches to your end-of4ile routine
(EOFADDR). No cards are read. You should close the card file.

•

For an output or combined file, if you issue a PUT or a CNTRL imperative
macroinstruction, data management disables these and immediately returns
control to your program at the normal point. No I/O is performed.

If, you do not specify OPTION=YES, and one of the foregoing conditions occurs, the
file is not opened. Data management branches to your error routine, if you have
supplied one or to the normal return point in your program if you have not You will
not be able to perform further processing on the file.
Keyword Parameter ORLP:
ORLP=YES
May be specified for combined files processedin overlap mode, whenyou are
using a card read/punch unit with the prepunch read station feature installed.
In the overlap mode, each GET or PUT macro processes a different card. Use this
mode to read a. card and then punch data on the following card In the nonoverlap
mode you can read and punch the same card If you issue a GET macroinstruction
you cause a card to be read If you issue a GET macro and then a PUT macro you
punch data on the same card that was read by the GET macro. In either mode of
operation, you can issue a series of GET macros or a series of PUT macros. Five
successive GET macros read five cards; five successive PUTmaäros punch five cards.
Three possible combinations for issuing GET and PUT macroinstructions are:
1.

Alternating GET and PUT macroinstructions, when used with alternating
prepunched and blank cards, produce valid results if overlap is specified. Each
GET macroinstruction applies to prepunched input data cards, and each PUT
macroinstruction applies to punching data into a blank card.

Multiple GET macroinstructions between single PUT macroinstructions, when
used with multiple prepunched cards between single blank cards, produce valid
results if, in every case, the number of GET macroinstructions corresponds to the
number of prepunched cards between each of the blanks that the PUT
macroinstructions reference.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

3-9

Multiple GET and multiple PUT macroinstructions, when used with multiple
prepunched cards between multiple blanks, produce valid results if the number
of GET macroinstructions and PUT macroinstructions and the number of
prepunched and blank cards are consistent through the program.

Keyword Parameter OTBL:
OTBLsymbol
Specifies the address of the 256-byte translation table in your program when
records in an output or combined file are to be translated on output. A
translation table is required if the keyword parameter MODE=TRANS is
specified
Keyword Parameter OUBLKSZ:
OUBLKSZn
Specifies the length (in bytes> of the secondary I/O area (IOAREA2) for a
combined file. If OUBLKSZ is omitted, the size of the output block is assumed to
be the same length as BLKSIZE.
Keyword Parameter RECFORM:
RECFORM=FIXUNB
Fixed-length unblocked records are assumed by the. logical IOCS when this
keyword parameter is omitted. For input or combined files, this option
(RECFORM=FIXUNB) must be used.
RECFORM=UNDEF
Used for undefined records in output files only. You must specify the RECSIZE
keyword parameter when this option is used. If the 8413 diskette is used, this
parameter specification causes the generation of an invalid DTF field message,
DM61.
RECFORM=VARUNB
Used for variable-length, unblocked records in output files only.
Keyword Parameter RECSIZE:
RECSIZE(r)
Specified for output files with undefined record format; (r) indicates the number
(2 through 1 2) of the general register that holds the length of the output record
The record size must be Chterêd into the general register before the PUT
macroinstruction is issued. If SAVAREA is specified, register 13 maybe used for
RECSIZE.
RECSIZEn
Specifies the record size in bytes used in conjunction with the BLKSIZE
parameter value. Data management uses both values to invoke multi-sector I/O
operations in processing diskette files.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

3-10

Keyword Parameter SAVAREA:
SAVAR EAsymboI
Specifies the label of a 72-byte register save area, aligned on a full-word
boundary.
Specified for each card file defined for a program. Only one user register save
area is needed for each program.
If you have a program written for the SPERRY UNIVAC 9200/9300 Series Ifl which
register 13 is employed it may be converted to OS/3 specifications by adding a 72byte labeled save area (aligned on a full-word boundary) and by specifying the
SAVAREA keyword parameter. Refer to 1.4 for the content of this area.
If SAVAREA is not specified, register 13 must be loaded with the address of a 72-byte
register save area, aligned on a full-word boundary, before any imperative macros are
issued.
Keyword Parameter STUB:
This keyword parameter is used with 0716, 0717, and 0719 card readers and must
be supplied when the stub card read feature is to be used. If the 8413 diskette is
used, both the STUB=51 and STUB=66 parameter specifications are ignored.
STUB=51
The stub card read feature applies to cards with 51 columns.
STUB=66
The stub card read feature applies to cards with 66 columns.
The block size specified (BLKSIZE=n) must
columns in the card; however, because of
bytes in the length of the I/O buffer, you
defining it with a DC or DS statement in
columns of a 51-column stub card.

be less than or equal to the number
the requirement for an even number
must reserve 52 bytes for the buffer
your program when you are reading

of
of
in
all

If omitted, standard 80-column cards are assumed.
Keyword Parameter TYPEFLE:
TYPE FLE=INPUT
Describes an input file only This option is assumed if this keyword parameter is
not specified.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

3-11

TYPE FLE=OUTPUT
Describes an output file only.
TYPEFLE=CMBND
Describes the combined file when both the read and punch features are to be
used.
Keyword Parameter WORKA:

WORKA=YES
Specified if I/O records are to be processed in a work area rather than in the I/O
area. The address of the current work area must be specified with each GET or
PUT macroinstruction. If this keyword parameter is specified, the keyword
parameter IOREG must not be specified.
The following are examples of coding the DTFCD macroinstruction.
Examples:
LABEL

tOPERATiONI

iiiIii

i
t
1
ir
I

—

T
1
RD’IO
I
liii

—

PUJIj-I
I

Iii

D
I
1
rtrrIb4 1-

OPERAND

—

I
)f1

ts’PJReA I AiRI&AI
I

I
I

—

i
I
I

—

I
I
i

—

I
I

L X

I
I

i...... X

III

I L
I

C.
C

.1.....

j___ L

E=IrrD
1
rD
,

I
I

—

111111

I
I
I

gil

tItEii’
ECi
T
1
,
I’)
i
= .rl rPciT
1
F’ PEFIL.
,I
1
I

11111

—

.1. . .

I
I

.1....
I 1.X

t2ARE1AI AI&A I
E
2.
ARIeA
2. = 1

-IA’1rP
L
1
E

I_i.____j_

L ‘
.l.. (

—

Iii

I
I

L
L

IIL, D 1
EF
r
t
-Lrfltr4

—

3-12

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table 3—1.

Summary of Keyword Parameters for the DTFCD Macroinstruction (Part 1 of 2)

Files
Keyword

Specification

Remarks

Input

ASCII

YES

AUE*

YES

BLKSIZE**

CONTROL*

Output

Cmbnd

Specifies processing in ASCII;
MODE=STD must be specified

used,

Skip cards containing validity check errors.
X

The maximum block size in bytes

YES

Specified if CNTRL macro is to be issued to file

CRDERR*

RETRY

EOFADDR

symbol

ERROR

symbol

IOAREA1

symbol

IOAREA2

For card punch error recovery;
CONTROL must not be specified

used,

End-of-file routine for input and combined files

Address
routine

Address of input/output area; output area for a
combined file

symbol

Address of alternate input/output area; output
area for a combined file

IOREG

(r)

ITBL

symbol

MODE

BINARY*

of the

user’s

unrecoverable error

General register (2—13) that contains the
address of the current record when processing
in two I/O areas. Omit WORKAYES. Must not
be used for a cOmbined file
X

Address of input translate table required when
MODE=TRANS is specified

Specifies cards are tobe read or punched in
column binary

Specifies records are to be read or written in
compresed code

STD

Specifies records are to be read and written in
EBCDIC

TRANS

For records to be read or written in EBCDIC and
translated by the table specified in the ITBL or
OTBL entry respectively

OPTION

YES

Specifies an optional. file

ORLP

YES

Specifies that a combined file is to be processed
in an overlap mode

OTBL

symbol

Address of output translate table; required when
MODE=TRANS is specified

OUBLKSZ

Specifies the length of IOAREA2 for a combined
file

RECFORM**

FIXUN

For fixed length records

UNDEF*

For undefined records

VARUNB

For variable-length records

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MNAGEMENT

Table 3—1.

3-13

Summary of Keyword Parameters for the DTFCD Macroinstruction (Part 2 of 2)

Files
Keyword

Specification

Input

Remarks
Output

RECSIZEt

(r)

Cmbnd

For undefined records; general register (2—1 3)
contains record size
Specifies recordsize in bytesand is used vith
BLKSIZE for multi sector I/O on diskette

SAVAREA

YES

STUB*

Stub card read for51-column cards

Stub card read for 66-column cards

3NPIJT

For input files

TYPEFLE

OUTPUT

YES

Specifies 72 byte register save area

For output files

CMBND,
WORKA

For conibihed read/punch file

Records are to be processed in work area. Omit
IOREG

LEGEND:
Required
R
Optional
X
One option required
V
*Not appliable for diskette files
**parameter may be changed on DD job control statement.
f Parameter may be changed on DD job control statement for diskette only.

3.4.

IMPERATIVE MACROINSTRUCTIONS

There are five imperative macroinstructions available to you for processing punched card
SAM files:
Macroinstruction

Use

OPEN
GET
PuT
CNTRL
CLOSE

File control
Record processing
Record prpcessing
Output and combined file record contro[
File control

The following paragraphs provide you with a detailed description of these
macroinstructions and provide coding examples with explanations when required to
clarify use.

3-14

SPERRY UNIVAC OS/3
BASIc DATA MANAGEMENT

UP-8068 Rev. 4

OPEN

3.4.1.

Open a Card SAM File (OPEN)

Function:

Before a file can be accessed by the logical IOCS, you must issue an OPEN
macroinstruction. The transient routine called by the OPEN macroinstruction performs
certain validation checks and initiates file processing. A check is made to determine
that you have supplied all the necessary keyword parameters defining the file. The
device allocation performed by the job control program is determined.
The actions performed by the OPEN transient routine depend on whether the file you
are dealing with is an input or an output file. For input files, the first data record is
not available to you until a GET macroinstruction is issued. For output files, no data is
written; however, the data area is made available for use. Only one file per card
reader should be open at any one time during execution of a program.

Format:
OPERAND

L\OPERATIONL

LABEL
4r

(filename-i [,...,filename-n]
(i)
(i

OPEN

[name]

t
Positional Parameter 1:

filename
Is the label of the corresponding DTF macroinstruction in the program. The file
name may have a maximum of seven characters; the maximum number of file
names is 16.
(i)orl
Indicates that register 1 has been preloaded with the address of the declarative
macroinstruction.
Example:

I
IL-

OPERAND

AOPERATION

LABEL

10
1
jbIPetI%i

ril
1
P &cJVPl&.JV ,L_t.ISr t
’)iri
1
r4
c

Enters the transient routines necessary to prepare the DTF macroinstructions whose
labels are INPUT, OUTPUT, and LISTING. Checks that they are prepared to access
these files with the next imperative macroinstruction (GET, PUT, etc.).

3-17

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

PUT

3.4.3.

Output a Record (PUT)

Eu nction:
The PUT macroinstruction delivers an output record to the logical IOCS in either the
output area or a work area specified by you.
Data management delivers the records singly to your output peripheral device. A
general register (2 through 13) must be supplied (by means of the IOREG keyword
parameter) when a standby area (IOAREA2) is specified and when no work area is
used. This register provides the logical IOCS with a place to put the address of the
current output area. Records processed in an I/O area can be referenced directly by
means of the name you have given to that area (IOAREA1). The output areas aie not
cleared after the current output data is sent to the device. You should exercise care to
clear the area before use or to supply records, including blanks, which completely fill
the output area to the logical IOCS to prevent spurious characters from appearing in
the data.
When records are processed in a work area, the logical IOCS moves the record into
the I/O area. This frees the work area for your subsequent processing.
When punching a record containing an odd number of characters, data management
places a nonpunching character in the I/O area at the very end of the data you
supplied.
Format:
LABEL

[name]

OPERAND

LOPERATIONL

PUT

filename
{1

workarea

} [{w
,

3—18

SPERRY: UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

(0) or 0
Indicates that register 0 has been preloaded with the address of the work area.
If omitted, indicates you have Chosen processing either by means of a register (IOREG
keyword parameter) or by directly accessing the data relative to the name of the I/O
area.
NOTE:

When the work area is specified the keyword parameter WORKAYES must be present in
the DTF statement.
Example:

LABEL

LOPERATION

[

OPERAND

11 J J(I
1 1P(L

Programming Considerations:
•

Variable-Length, Unblocked Records
You must determine the size of the Output recOrd and must insert the size at the
beginning of the record before issuing the PUT macroinstruction. Record size includes
the 4-byte record length field. YoU may not access the first four bytes, which are
reserved for block size.

Undefined Output Records
RECSIZE=(r) must be specified; you must determine and place the record size in this
register before issuing;each PUT macroinstruction.

UP-8068 Rev. 4

SPERRY UNIVAC CS/3
BASIC DATA MANAGEMENT

3—19

cNTRL

34 4

Controlling Stacker Selection on the Card PuncFi (CNTRL)

Function:
The CNTRL macroinstruction allows you to control stacker selection on the 0604 card
punch for output or combined files In processing a combined file you may read a
card process the data read from a card and then select an output stacker in
accordance with the data on the same card If you issue the CNTRL imperative macro
in your program you must specify the CONTROL keyword parameter in the DTFCD
declarative macro (3.3).
The CNTRL macro is ignored if you issue it to a card file processed on the 0605 card
punch because its small error stacker is not designed for selecting cards.
Format:
LOPERATiON

LABEL

[name]

CNTRL

OPERAND

filename

}

2
Li’

Positional Parameter 1
filename
Is the label of the DTFCD declarative macro defining the output or combined file.
(1) or 1
Indicates that you have.preloaded register 1 with the address of the DTFCD
declarative macro.
Positional Parameter 2:
sS
Specifies stacker selection on the 0604 card punch
Positional Parameter 3:
1
Specifies selection of the normal stacker
2
Specifies selection of the select (error) stacker. If the third positional parameter is
omitted, specification of the select stacker is assumed: If the third positional
parameter is specified, but is not specified as 1 or 2, specification of the normal
stacker is assumed; an error flag appears in your program listing.

3;4.41.

3-20

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Using the CNTRL Imperative Macro

You issue the CNTRL macro after any PUT or GET imperative macro that punches or reads
the card you want to select, and before any PUT or GET macro that processes the
following card. If you issue several CNTRLmacros in succession, the last one you issue
controls which hopper the card goes into the next time card motion occurs.
A look at the following schematic diagram of card flow through the 0604 card punch may
be helpful in visualizing what•the CNTRL macro does for you. In Figure 3—1, a card moves
from left to right,frorn the input hopper, past the optional prepunch read station, to the
punch station. It then passes into one of the two output hoppers: either the normal stacker
or the select stacker, according to the position of the deflector. The 0604 card punch
subsystem itself autornaticallydeflects error cards into the select stacker; it is the deflector
that can be controlled by the CNTRL macros issued in your program.

PUNCH
STATION
DEFLECTOR

Qç
\
INPUT
HOPPER

PREPUNCH
READ
STATION
(OPTIONAL)

POSTPUNCH
READ
STATION
SELECT
STACKER

Figure 3—i.

NORMAL
STACKER

Schematic Diagram of Card Flow through 0604 Card Punch

The normal sequence is that a card in the postpunch station passes into the normal
stacker when the following card enters the punch station; if you have set the deflector by
issuing the CNTRL macro, however, it passes into the select stacker when the card
following it moves (is fed or punched). Stacker selection for a card that has gone through
the punch station thus takes effect when a macro is executed that moves the following
a GET or PUT macro, depending on file type and your processing.
card
—

When a card file is opened, then, cards passing the punch station are sent to the normal
output stacker until you issue:
•

CNTRL filename,SS; or

•

CNTRL filename,SS,2.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

3-21

Then, the following imperative macro (GET or PUT) that causes card mOtion results in one
card being placed in the select stacker. If you do not issue any further CNTRL macros,
cards following the card that went into the select stacker are sent intO the nórmàl stacker.
Thus, a CNTRL macro to send a card to the select stacker applies only to one card: To send
10 cards to the select stacker,you must issue 10 CNTRL macros, properly interleaved with
PUT or GET macros. Note that the CNTRL macro causes no card motion itself.
For an output file, each PUT macro causes a card to be fed into the 0604 card punch and
a card to be directed into an output hopper. You must issue the CNTRL macrO after the
PUT macro that punches the card you want selected and before your next PUT macro
Example
LABEL

A0PERAT10NA

1
I

1.1

—

1
P
I
,..)
JC 1—Il

1
iPEtJ

OPERAND

I
I

-1_ -1

—-I-

—

i__

—

__________

U-1
L
C
N
ci. 1

—

III

—

III

—

l..J1
I
1
C
Ii

---i

HL
I

[

1
I

-I

Punches card 1.

Punches card 2 card 1 is sent to the normal stacker

Punches card 3; card 2is sent to the select stacker.

Punches card 4; card 3 is sent to the normal stacker.

Punches card 5; card 4 is sent to the select stacker.

iii
I

1ZLiLLi.t

I
I

-i

I
I

[1111111111-Il
I

Y-PEFiLE 1
1
t
,I
1
OUiT PUT
I

—

LILiJI LiJii
I

I
I

I._)f’LC.I—Ii, 5S
2..i
111
-

171
1
t.J
[
C
5
1
1I,
\i I I-S

aU
—

’
1
PIL..J
L
CIi1I
S

—

?iL.JT
1
ILSE

rJCI—i
1
P(.,J

—

T
1
i1..)

—

CI—It,..SS, I2.I
1
P__)Ii

—

.._if4t1
L
R
1
..
1
I_..Ji1

Ii . 55

i
1
‘ii...i

1__.J__.i..__1____l___..1_.L_
I

PII_)I1’%IIC.

—

I
i

tIt%IIlTIl_..

—

NTL
i

i1_JL’

iii
1

3-22

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Punches card 6; card 5 is sent to the normal stacker.

Punches card 7; card 6 is sent to the normal stacker.

On closing the output file card 7 is sent to the normal stacker

PUNCH is the logical file name of the output card file being processed.

When you are processing combined files (TYPEFLE=CMBND), you have two processing
modes, overlap and nonoverlap. The overlap mode is specified with the ORLP keyword, as
you recall from 3.3; if you omit the ORLP keyword from the DTF of a combined card file,
you process the file in the nonoverlap mode. The action of the CNTRL macro is slightly
different in each of these modes; consider the overlap mode first.
For a combined card file with overlap, eaóh GET or PUT macro advances a card, and the
CNTRL macroapplies to the card processed by the previous GET or PUT macro. The
sequence of instructions in the following coding example processes a combined file deck
named COMBO, in which each punched card is followed by one blank card. A punched
card is read data is processed and some resulting data is punched into the blank card
following it.
Example:

_I_1

Iii
I

—

OPERAND

AoPERATIoN

LABEL

—

Iii

...I.....i__j____._j.._._

—

.___i.j..___i..j.__I:

i
I

it.J1

—

..Iii1
I

—

Ct
)I’t
F
1

—

r’’ 1
EFII._..E
P
I

—

I
I

liii

i
I

I
—

I
I

—

_I__1

—

:iI\jiDilit.....l

11111111

—

iii

1
1B
1
C
i
1

ti
1
iPE

Iii

I
I

SPERRY UNIVAC 0S13
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

3—23

The instruction sequence shown causes all the prepunched cards to be sent to-the
select stacker and all of the newly punched cards to be sent to the normal stacker.
Processing continues until an end-of-data (/*) card is detected (2.3.2); at this point,
the end-of-file routine ENDFL closes the file, and the job terminates.
On the other hand, consider the nonoverlap mode of processing a combined card file:
A single card may be processed by a GET and a PUT macro. A CNTRL macro may be
issued after any macro that processes a card. If a card is processed by both a GET
and a PUT -macro, CNTRL may be issued after;either the-GET or-the PUT macro to
control stacker selection of that card If several CNTRL macros which apply to a
single card, are issued, the last CNTRL determines which stacker is selected.
The following coding example reads three cards from a combined card file named
COMBO2, processed in nonoverlap mode and containing no blank cards. It punches data
on all three cards; the first issent to the select stacker, and the other two cards are sent
to-thenormalstacker.--

Example:

LABEL

AOPERATiONL
10

—

IIiIIIIIlIt_1

IP
E
1
.t.1

C
O
1
M.B2

—

CLOItBI2I

—

till

—

C
B
M
1
i2

—

lii

i1....O
1
.
S
E

2
,
1
IOL
.
L
,

I
I

—

I
I

—

iii

IIll

III

I ‘I

III

I-

-l

III

I-I

—

t 1
C
F
1
DaT
T
P
Y
EFLE= 1
C
M
iBND,

D
B
i
1
t_I2.

1
O
i
1
B
,
SS
2
1

—

I:11

-1

—

)it_.)I1I

1111111
III

—

OPERAND

III

I
I--I

1_j___..j.

I-

I
I

liii

3-24

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Close a Card SAM File (CLOSE)

3.4.5.

Function::
TheCLOSE macróinstruction initiates the termination procedures for your card SAM
file When all the data in a file has been processed, a CLOSE macroinstruction should
beissued.
Format:
H

[name]

OPERAND

tOPERATION

LABEL

filename-i [,...,filename-n]
(1)
1
*ALL

Positional Parameter 1:
filename
Is the label of the corresponding DTF macroinstruction in your program Filename
may contain a maximum of seven characters the maximum number of filenames
isl6.
(1) orl
Indicates that register 1 has been preloaded with the address of the declarative
macroinstruction.
*ALL
Specifies that all files currently open in the job step are tO be closed.
Example:
LABEL

ii’
t%.DR
[e
e
1
F

OPERAND

AOPERATION1

I
Ic’
&
I1
ii

frlr.%II2lL..—r—I

Enters the transient routine which closes the file described in the DTF macroinstruction
whose label is INPUT.

UP-8068 Rev. 4

3.5.

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

3-25

ERROR AND EXCEPTION HANDLING

3.5.1.

FilenameC

When certain errors or exceptions to file processing performance are detected by OS/3
data management it will make appropriate entries in specific fields of the DTF file table
which your program may address in order to learn of these conditions and take the proper
course of action on regaining control. One such field is filenameC, a 1-byte field which
you may access by concatenating the character C to your 7-character logical filename and
using the test-under-mask (TM) instruction.
Refer to Appendix B for the meaning of the bits in filenameC of the DTFCD file table which
are set to binary 1 by OS/3 data management for certain error and exception conditions.
3.5.2.

FilenameS

When you have specified CRDERR=RETRY on a card punch file DTFCD and six successive
attempts to punch a card have failed OS/3 data management sets the hardware error bit
in filenameC (see Appendix B) and also places the image of the card which is in error in
filenameS of the DTFCD file table FilenameS which you may address in the same way as
filenameC is an 80-byte field for all modes except the binary (image) mode and a 160byte field for that mode FilenameS does not contain the error card image if the file is a
combined file Software punch retry applies to the 0604 card punch For the 0605
(integrated) punch the operator can repunch erroneous cards
3 6

SAMPLE PROGRAMS

The following examples have been constructed to illustrate typical uses of card input
output and combined files in BAL programs They also provide examples of the OS/3 job
control statements you need toimplement your programs.

Ill

Ii
* ERiR
1
*1 I
I i i
I

jLi..j_

1111111

III

11111

LIII

—

III

I
—

—

1111

Ill

—

1I11

—

till

i’J
1
)fE

t..1L_.L..J_

t
’JI3
.
1
t..1i
t

1111111

—

I
I

III

LIII

I
I

[

I
I

III

II
II

III

i._i..._.i__._i..1

I
I

t’J
1
E

I__Il

I
I

..L....J_.._..i.......L
1... .._l._..._.I_.._....L_._.I

LIII

.1....

.LJ_J

I...L._..i.h..__L........_...JL

........

LIII

I
1.1

1 .L I

11111

L_L1 I L

I_I_Li.

I_...1_.LIiI_..I......

I___I__...j____j__1__._I_J_._J..___I.._.I_ .1_I.

FIL.iE,CLOtdE

LIII

I..._._._l..._....___._______..I_...__J...__._II.__.l.__..i_..___L.J_

J_JLJ..JLLL.Li.i..LJLIi.

11111111111

REEi

.L._

LIII

i....L

.L._.L.._L.. I

L...1 I

1111111

J_i_.L

....L._.J..L. IL__LI.

L_L._.I_LliI

J.... 1.

LIII

... ...

i_LI....

.t._i....___.I_.___.i____ii

—

.i.

.L...L_.LL...L.I....±

—

._.

—

iLii

i
Lli.._....L..J

L.. LI

iil..._

. L_L i i ii
.b
..AP
iI
t&T
EA
1
j
11 1
.
1
AVI_
I
I._.J_.L.J....._.L.J..J...1.__..I._.
E
1
FIiL_
i4tRD
C
E 1
P\J
I
1
I
I
I
I I I I
I
D
1
R
111
EI4 III iC
R
D
1

LIII

72.

Liii1itIiii

ILl

i.i

jj±

1E
i\’ 1
C
R
1
21E
T
6
R
L_ii E
1
D

1_I.

.;
IjL
.
1

1111

L_LJ_..L

III

11111]

COMMENTS
..

1111111 i__.I__._..J.____I._____L_.i I. i_._,I___.___i_. . . i i. .__._i_. ._. I._._.
II
I
1111
II III
.J 11
tUtT
P
LL.j. .,L
1
F
Jm CA
D1 1
1
IEMENA
M,4J
G
A .4TA 1

III
I

Iii

L....L .11

I
II

till

....i. t i

NJ
1
I

11111111

1 RE,A
11 iATA
iC
P
1
1
E

1111

Il1’lIl

111111

III

111111111

l
AMiLL...J
4
!J
l

191

9IDl

III

1111

I
I

MLER
A
E
CiUTE 1
EX
E
EAM T 1
T
R
1

OPERAND

IllI

11111

xA P
E
1
LE biF ri4E UE
1

—

I•

LLJJ..

OPEHATIONA

111111

1I
JJ4ipT

.__..._..i._._.i.__._.[__._.____._.i___.

II
f.L
r
1
P

Ill

LABEL

/l$I

C..)

0
m
m

> c
0
C,

>
-l <
> c

w
>
cncn

0
0)
0)

111111

—

,FL1tL

/‘.LIIIII

If’I
1
i

—

Ii_

111111I

IIiIII

i/ 1
VIC 3
D

-I

/1*1

111111

cip C
4
*
1

IIII

E
1
4.G
11

—

LIII

1111

t
C
F
1
)iT

I
I

—

COMMENTS

I
I

1111

I
I

1111

III

11111
I

LIII

I
I

II
I

:!iI
11
I
1
I

11111_Ill

jL.IL

I
I

1111111111111111

It!_,

III

TREAM T E(ECUT,E
1

LI;__LIFiDLlIk4L[i_I

LIII

s
1
Lj

I
I

II
I

I_.I

11111

I__I

j__J.

IiI

1..

I
I...
iJ..

1_i

il_I

I
__

.1.

III

—

11111

I
i.L
II

i_ii

1J._.LIII

;;I_IIIIIII

Il_i_Il

—

IIIIII_

I_.L__1

1111

i_.1__tI_A.IiI.i_.

..__L__LI__I___II

1..

I
ii

L__L_LI

i_i

, i
EiST
1
D
D

.1_I__I

1.I__L1

I..i......L..L

III

jI_j__j_.

DR
1
CARD REA
1

I_t_L__J___L__

1111111

S
A
1
I
GNiN.Ti.

LI__LI

.L__i_._.I__.j.__L
II

lJ_LJ_L_L_LJ_L_LLJ.i.L_L_L1

L_L_LL__L_1.

III

EIdII
1
I1I/”0I I,I

11111!

IsJIJE G
1
SCt1T
I
I
4J
E
C
11
lPR
1
I
1
RIAII 1
biTt4
1
E
11
.
C
ICA1%1
E
IL_i.

L
k
1
ER.:EjR,, ,IAREALLI
1
I
PEAL=IIJiPUT ArE
I
i
I

I[T,P1A(
JLIJAtLcxLJ&4JcK 1

111111

11111

1111111

III

I_L__[I__I_1_I

I
1

TEIM
1
)?CAIrDMIYS
,

—

OPERAND

LaQLLLII

L_L_J__I1IIII

—.1Lbt%1L.IELI

Jjaj

)I I I
1 1 I
11
1
1
i
1
%R
1
)

ILL

D
1
T
iA
4
* 4

iii

R
1

t1OPERATIONt

LABEL

1J_L_

I
I__I_i
i_I

1
I

L..

III

L_J.

.I_I_.._.1

1111111

1.11.111

1111111

liii

I
1

I_LI

iiL. I

._a

L.I_L. .1

LJ_L_I

III

1111111

lL_.L_LIII

IL11a1J

CA)

LABEL

1111111

—

III

IL1I

III
-

—

IJLJLJJt
I 1_.L1
I
I I
I

I
I

I_Ii,,j
i

I
i
t

lI_I
I

I
i

I
1

LIIL

III

1_II

—

tI.:

.-1-

I
L

-±L-’

•

L. J.

i i
I i
L I
I
I t i
L i.±i 1 ii
. i . L± i

i .i L1

i_LLLL

±J

I
i

..i_ i

i
i

I.L.

i..L

1111

111

LLiZLL

Il-i

iI:i

Lii

1..

I.1

I
I

—

L I

1 d

I
I

I J

iJI

1111111

[

LIII

III

1111111

i.I
I

I J
I

I
I

iii

—

Li_LL I

111111.1

—

1
1

L ± ..
1

Li j

1111111

—

111111

..L..

.1.1

III

I
I

I J

1
I

LIII

I.. I_L.

I
i

il.L_L.

± i

jflj R

JLL JLLL L
ii

I._

I11It;ii

lI_JIIa_L 1

iIF

LL.i

JPLLtLcJriL L__iCAiR±

I’II

AQ
1
4

a
..

[

jJ.

I
i

LJi

COMMENTS

IDATA MAf.JAGiME,.Jrfl CARD LJIfPQ]E FJ1

J_.LLL
LIII

IiL.L!

I_1_I

1111111111111

111111

X
]i
1
AMT
Q

(JkZ
1
RK

QL_Jfl

*1)191

L
I
1
LJ[

—

QL
91
1
9

—

B
1
J
I

1AiLJRL

—

OPERAND

E) A 1 LE iF TJ-4Ei UE f
I 1
i
I t i i i I
i
i i i
[ I
i
i
i
I
i

—

JLLILL_

Iii

R
1
E

*1111

jill

iT&

LL±L

L
1
P

_16

A0PERATIONA

1......L..

U1P I
b
1
T
1 I I .i i

1111111

!iI

4ILL

/i
1
±

Cr)
F’.,
a,

liii

Jj_
1
jIJ

(__l.._i
4

DIL±_

LLL

IJ__

FIN,
11
/J

LIII!

LILL.IPLLCLIf 0

* 1
Cii
ti.’
b

RJc.L±.

LALLL

IALtLI

*_jjj_

iJPri]1L

I
I

lJJLi

OPERAND

1
1

Li±

L
I

LII
I

III

II
I

III

TREAM Ti

III

I
I

JLLAL

I!I

11111

I
I

£L
II

1±

11
I
1

I A

L L

i
I

LJI

I
I

—

I
ii
I

111111111

—

±j

iAAI

A A I

i A I

—

ILL

£ i

i i i

I i i I I
iilit.ii

A.. I

I
I

III

I
I

Li ± I I ± ± A I
AL2jM:Dj-IiTa, X
t

I LLA

.IiIIlIIIILII

I__A J

I1 A

L±

i A

iL±.

L I

I LA

LL_L

JL 1

I L

I AA±J

1J±L

liii
±

±±L

III

_i__LA_L
1

ALAA

4jEA
RGIilE I’”E 1

Ji.J_.LLL.J.IILA.LI_I.L.LLJ.JLL_I

IAA.

L
LLLLll

A iLI

LUJJLA
LL1LJ_LJ JJ_JJJ

COMMENTS

AJJJLLILJLLiJLI&JA.

’
iS
1
S
1
iEit”
(’

JLL

Ri k,TI jLjQ
L
4
REILT9uTJ CRDEIREffi

C.
1
RiD
R 111

IIII

c4I8LL

lQLLJAJ

I81

cAkct.

LLLJ

LJJJL±

LiLLiLLLtJLLJ_J iLLJ

L EJLLLTL_LLJL_LJ

—

L
1
iA1LC

RR_
g
_
_
1
L

AOPERATIONA

LABEL

F%)
CD

cI)

Iii

—

• i

III

jjjjj

—

[

1
i

I_I_Il
—

I
i

Ii
I

IIjJ1L

jjjjLjj_jj I

±rnL

.. I

—

I
I

•

Ji.

IJ.

iL.LJ

jLj

—

1 2
IIJT I / AA

.1.

tILj

I
I

i
.

1
.

I
I

i
i

1._.._.L..__.I._____i_...

I
1

i
L

.1.IIIaI

i.
—

i
.t

1:1111

I
i

—

1.1

111

I
1

.11111

I
I

i.iii

IL.

ttii.

zLi.

I J

±. I

:Ii

CM8Ii{ED IEIILE

iLi. iiL

l_JIREAD LCAg1DL

LJJ__L I IJ_
Li.

COMMENTS

A ThATA M4AMEt..L1i CA

PRtCE DATAiREA

III

L_iJ.I

—

LLLjIJJLLJ_ILLZ_IiA
1
J

11IJiL LL

i±i

L,E DIE rn4Ei IJE iE
I
ii
I ii
I
1_I

—

qLQLLI

—

T:i
J3 rEiAM 1
1
B

OPERAND

1
ALR

L,E,XA

Li .‘‘

1
AR
1
iI
E

III

_j_i
1

tsOPERATIONA

LJ_..1LJ_L_L__II

LII

‘

Iii

LLi

LLL_

LABEL

mu
m

>fl

> C

Ct,

—

IL_I

liii

L_.

.Lll

tO’Li 4 ) iJ
/
1

I’jlL

SiL

-i

/IJIIEIThLI

Iii

III

/&Li

E
1
L8

Ji.

—

ilLIIiL.Ii

,..

I...ILII

OPERAND

I...

I
IL.

I..
-

1,11

.
..

ii
-

III

1iI

I,.

ATF.B ,.TREAr4Th ExECYrE

1
RD MRINE
I

JbEjAj7XE
]
1
ZE

C4t

i
..

INKA
.

COMMENTS

.1.

_L
.

i
.

..,.

QU’BL.KS?. 18P,

L.L1l:LI

/ A
1
I
E
1

Li.

AREA2 IA ,fr DE.=TjD,PTL1 .2N ‘f
iPEELE=.cMpDAVAREASv:E.

CILJaQI

_JIL_

LI.

III

ILL

/1 “I

/*,

crai±& :

LJLJ

IAJ.
1
IA

11
C
1
RIRll
,
AiCEL

i.i

OPERATIONA

LABEL

III

Iii

III

Ill

ct)

3f.
t
!‘.:

I..

Ii
•

—•
•

C- -•
-

•-.

•:;•

-:.:-u._:

;-:.

:•‘

••

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

4-1

4. Diskette Formats and
File Con’iénticns

4.1.

GENERAL

This section describes the data formats and file conventions that apply to the 8413
diskette subsystems files supported by OS/3. The 8413 diskette is a rapid replacement
medium for card processing devices and provides multifile volume and multivolume file
exchange capabilities.
4.2. FILE ORGANIZATION
The 8413 diskette is a single-sided, fixed-sector storage medium used for sequential file
processing as a substitute for punched card equipment The diskette subsystem handles
single or multivolume input, output and combined files. A maximum of 19 files is allowed on
a single diskette volume. A summary of the 8413 diskette volume characteristics follows:
Tracks
Tracks (usable)
Sectors per track
Sectors (records) per volume
Sector size
Files per volume
Number of volumes

77
(0—76)
(1—73)
73
26
1 898
1 28 bytes
19 maximum
1 52 maximum per file

Figure 4—1 illustrates the track and sector organization of an 8413 diskette volume.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

SYSTEM
SCRATCH

VOLUME
LABEL

ERMAP

—-

L1
\

\
‘

4-2

FILEDEsCRIPTIONLABELS

I
I’

SECTORS

‘
‘

‘

‘
‘

‘

TRACK

INDEX TRACK

‘

DATA FILES

not used

spàe or
alternate
76

Figure 4—1.

Typical Organization of a Diskette Volume

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

4-3

File description labels are written on the first track (track 0) of each volume of a diskette
DTFCD file by data management. The maximum number of files that can be written to a
volume is 19 The simple 1 28-byte diskette file label format is
°
0

iabei ID

—

.—

LABEL DATA

—

NOT USED

—9
-I

124

NOTE
Details on the diskette file description label are presented in D.5.
4.2.1. Diskette Input Files
Diskette fiIes can be contained on one volume or can span severalvolumes (multivolume
file) Information on a diskette volume is organized Into two areas the index track (track 0)
and the data files (tracks 1 through 73) Track 74 is not used tracks 75 and 76 are
alternates or spares (See Figure 4—1).
The index track (track 0) contains a volume label(VOL1) in sector 7. Sectors 8 through 26
are used for the file description labels One file can be described in each sector therefore a
maximum of 1 9 file description labels can be entered in the track index

The data portion of the diskette files contain punch card :images (EBCDIC) with one record to
each diskette sector Each sector is 1 28 bytes long and any unused space in the sector after
the record is hardware padded
All diskette input files are read-only sequential files. Multivolume files require. that the
volumes be mounted in the proper sequence standard mount messages provide prompting
to ensure that the volumes are mounted in the correct order.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

4-4

42.2. Diskette Output Files
Diskette output files are read/write sequential files allocated on a sector basis. All files
must reside in a contiguous area. When the file description label is written, it includes a
pointer to the beginning of the file. Card images that are read to diskette are entered
sequentially, one record (card image) per sector; unused space after the record in each
sector is padded with binary zeros.
4.2.3. Combined Files
Diskette combined files are read/write files that are used mainly for updating records. A
record is read, updated, and then written back into its original location; this is the
nóhoverlap mode of processing. You should exercise extreme care when using combined
files, because destruction of the initial contents of the record read may result when writing
back into that location. The overlap mode of processing for combined files is not supported.
4.3.

RECORD FORMATS

Diskette records fall into two categories: fixed-length unblocked records and variable-length
unblocked records. Records are contained one to a sector within a file. There is no record
blocking of diskette records.
4.3.1. Fixed-Length Records
Fixed-length diskette records are all of equal length for a given file. Diskette records are
generally the length for a given card type image (51, 66, 80, or 96); however, the records
can be any length from 1 to 1 28 bytes. Figure 4—2 illustrates the fixed-length record
characteristics.
4.3.2. Variable-Length Records
When yoU Use variable-length records, data management preempts the first four bytes of
every block (in this case record) for use as a record descriptor word (Figure 4—2) Data
management calculates the length of the record and inserts this for you in the first two
bytes; the other two bytes are used by data management.
Data management, again reserves the final two bytes of the record descriptor word (RDW)
for its own use but the first two bytes must contain the length of the record of which the
RDW is a part.
When you specify that yoUr records are variable and unblocked, data management will write
out one block for each logical record you submit, regardless of the amount of available space
remaining in the I/O area.
You must not use the RECSIZE keyword parameter in your DTF for a file containing variable
length records, because data management expects to find the record size in the first two
bytes of RDW.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

4-5

FIXED-LENGTH

LOGICAL RECORD

H
I

A
128 BYTES
C
128 BYTES

III
itj

VARIABLE-LENGTH

LOGICAL RECORD

—H

B
124 BYTES

4 BYTESF

II.’

C
128 BYTES
LEGEND:
r
A
B
C
P

Record descriptor word (ROW)
Data record length plus padding to fill out the sector
Variable record length
I/O area layout
Padding

NOTES:
1.

For input files, data management passes to the user the record length and data portion of the record.

BLKSIZE=n specification on DTF macro and file label block length determines the size of record processed during
OPEN processing. The maximum block size of multisector I/O is 1024 bytes.

Unused sector space is hardware padded.

Under multisector I/O, user IOAREA contains multiple records in either fixed unblocked or variable unblocked formats.
Figure 4—2. Diskette File Record Formats

UP-8068 Rev. 4

SPERRYiJNiVAC0S/3
BASIC DATA MANAGEMENT

5-1

5. Function and Operation
of Diskette SAM

5.1 GENERAL
This section contains a brief description of the data management modules that apply to
SAM operation. for input files, outputfiles, and combined files Used With diskette operation.
Following the functiónaT description is a. detailed explanation of the declarative
macroinstructions that define :the three types of files. This sectiOn concludes with the
imperative macroinstructions that initiate, conduct, and terminate file processing.

NOTE:
The 8413 diskette processor does not handle compressed code translation
5.2. FUNCTIONAL DESCRIPTION
5.2.1. Input Record Processing
Diskette input files, like punched card input files (2,2.1),use the fixed unblocked record
format (RECFORM=FIXUNB). Diskette records range from a fixed length of 1 to 1 28 bytes
per sector. In addition, diskette Input files can be in variable unblocked record format
(RECFORM=VARUNB).
Data management accesses diskette Input files in read mode only Once data management
locates a diskette file label at open time, it saves the fileIabel address and certain fields of
information from the label such as file extent boundaries, i.e. beginning of extent (BOE), end
of data (EOD) and end of extent (EOE) Data management then compares file label
information with DTF specifications to determine if the file shoUld be processed under
single-sector or multisector I/O Itis the user’s responsibility. here to providel/O areas of
adequate size to handle the block length specified

UP-8068 Rev. 4

5-2

SPERRY UNIVAC’ OS/3
BASIC DATA MANAGEMENT’

5.2.2. Output Record Processing

Data management accesses an opened diskette output file in both read and write modes.
Using the file-id on the job control // LBL statement, data management searches the index
track to locätë the correspcindiig ‘file label and saves the file label address to be used at
close time. Files can be extended or overwritten on output only if the expiration date has
been surpassed or ifINIT is specified on the // LFD statement.
If specified on the // LBL statement for the output file, the new creation date is then
inserted in the file label; otherwise, the system date is used as the creation date.
If INIT is specified on the // LFD job control statement for an output file, the file expiration
date is ignored and the file is overwritten, If EXTEND is specified on the // LFD statement,
the expiration date is checked and if still valid, the file is extended. If neither INIT or EXTEND.
is specified, a normal check of expiration date occurs.
If no major file errors occurred to that point, data management writes the label back to the
index track in its original sector location positioning occurs if EXTEND mode was specified
and data management marks the DTF as opened and.passes control to the next instruction.
Data management writes output files via the PUT imperative macro either by single-sector
or multisector I/O (determined by BLKSIZE or RECSIZE DTF specifications). When data
management closes output files, it writes all necessary buffers to the diskette to avoid loss
of user records, and updates the EOD field of the file label by reading the label, updating it,
and writing it to its original sector location on the index track. Finally, data management
resets indicators and fields in the DTF and marks the DTF closed.

5.2.3.

Combined File Record Processing

Data management handles combined files (files capable of GET/PUT functions) at open
time the same way it handles input files (5 2 1)
Likewise, during close operations, .data management handles combined files as output files
(5.2.2) with one exception. If the current EOD is less than the original EOD, i.e., partial
update occurred, data management does not update the EOD field on the file label. If the
current EOD is greater thanthe original EOD, i.e.,file extension occurred, data management
updates the EOD.field in the file label: :
,.

Data management processes GET and PUT diskette operations for combined files under
single-sector l/O.The IOAREA1 receivesthe input record via the GET macro.The user must
mOve the record to. IOAREA2 and. then update it. The äontënts of IOAREA1 are
superimposed on the updated record in lQAREA2 If an invalid character results, the original
character in IQAREA1 will be substituted in IOAREA2. From there, the PUT macro writes it
to the diskette at the sector from which the original record was read. Data management
repositions back one sector before each write so that the PUT writes directly to the record’s
original location. When a series of PUT macros occurs, however, no backward sector
repositioning occurs after the second and all succeeding PUT macros. The user must take
care in moving updated records to avoid loss of existing data.

UP-8068 Rev. 4

5 2 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

5-3

Multsector I/O

Multisector I/O is allowed for the diskette up to a mãximuml/O byte count of 1024. This
means that up to 8 full 128-byte sectors (records) can be read or written with one physical
I/O. Many more sectors can be handled,if record size is less than 128 bytes. Forexample, if
record size is 80, the maximum blocksize that can evenly process multiple sectors is 960
bytes and the number of sectors accessed in a single physical I/O is 12.
To process smaller records using multisector I/O, the BLKSIZE and RECSIZE parameters of
the DTFCD declarative macro must be specified with the blocksize value being an integral
multiple of the record size. To determine the actual number of sectors to the processed,
divide your BLKSIZE length DTF spècificatións by block length field in the file label (positions
23 through 27 in the file label sector).
The result must be an integral number of sectors There is no remainder Records are in
blocked format in I/O areas; therefore, tO facilitate record by record processing, you must
specifiy either the IOREG or WORKA parameters on your DTFCD macro.
In addition, the IOAREA buffer space allocation must be increased to equal the new larger
blocksize specification in the DTFCD macro and reprogramming and reassembling of
existing card file programs is necessary to use diskette multisector I/O.
In multisector processing, the initial logical GET brings in a block of sectors and either
points toa record or moves a record to your work area. When all recordsfrom a block of
sectors have been processed, another physical multisector I/O occurs and processing
continues until the file is exhausted and EOD is reached. Control then passes to your end of
file routine (EOFADDR=syrribol).
5.2.5. Specifying 8413 Diskette Use:
The following steps are required to use the 8413 diskette:
•

The supervisor which supports the diskette must be generated. See the system
installation user guide/programmer reference, UP-8074 (current version).

•

The DSKPRP system utility routine and diskette space management must be applied to
the diskette to initialize the allocate file space before user program execution. See the
system service programs (SSP) user guide, UP-8062 (current version).

•

The appropriate job control statements must be provided to enable diskette recognition
and scheduling. The // DVC statement specifies logical unit numbers 130, 131, 132,
or 133 for diskette. The ALT option of this statement allows you to specify multivolume
processing (using two drives). The // VOL statement supplies the diskette volume
serial number. On a first run, the // EXT statement allocates sectors. The // LBL
statement identifies the file (this name should match positions 5—1 2 on the file label
of the diskette).

UP-8068 Rev. 4

SPERRY UNIVAC OS/a
BASIC DATA MANAGEMENT

5-4

Only the first eight positions of the field are used for the file name. The // LBL
statement can also specify the file creation date, and file expiration date. Finally,
the // LFD statement specifies the name given for the file description (DTFCD).
For further detail, see the job control user guide, UP-8065 (current version).
5.2.6. Diskette Limitations
The following limitations exist for the 8413 diskette
•

All diskette files are created and retrieved sequentially

•

Data management requires that each diskette file be opened via an OPEN imperative
macro before accessing the file and closed via a CLOSE macro when file processing is
finished. Data management also recognizes a virtual device on an OPEN macro

•

The CNTRL imperative macro is ignored when issued to a diskette file.

•

If an error occurs during file processing in output mode and control passes to the
user’s error routine, the user must close the file. in error to permit data management to,
update the EOD pointer in the file label.

•

Maximum block size allowable with multisector I/O is 1024 bytes and file processing is,
limited to tracks 1 through 73

•

Within the same job step, only one logical file (DTF) may access a diskette volume.

•

Data management cannot process, in a normal GET/PUT sequence, combined files that
contain logically deleted data records containing ‘D’ in. the first position of the record.

•

Data management PUT operations do not. use multisector processing if spooling out.
The output writer provides this feature.

•

All data management mount messages are suppressed in a spooling environment.

•

If spooling is in operation a CLOSE macro does not attempt to access the diskette

5-5

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP 8068 Rev 4

DTFCD
(Diskette)
5.3. DEFINE A SAM DISKETTE FILE (DTFCD)
Function:
The DTFCD declarative macroused to define punched card files is also used to define
diskette files (3.3). Except for the undefined record format specification
(RECFORM=UNDEF) which generates an invalid DTF field message (DM61; see Table
B—i), if issued for a diskette, the following DTFCD parameter specifications do not
apply to diskette files and are ignored if specified for diskette files:
AUE=YES
CONTROL=YES
CRDERR=RETRY
MODE=BINARY
RECFORM=UNDEF
STUB=51
STUB=66
The format of the DTFCD macroinstruction as it applies to diskette files follows:
Format:
LABEL

filename

LOPERATION t

DTFCD

OPERAND

[ASCII=YES]
[,BLKSIZEn]
[,EOFADDR=symbol]
[,ERROR=symbol]
lOAREAlsymboI
[,lOAREA2symbol]
[,IOREG= (r)]
[,ITBL=symbol]
E ,MODE=(CC
(TRANS
L
[,OPTION=YES]
[,ORLP=YES]
[,OTBLsymbol]
[,OUBLKSZn]
I ,RECFORM=J1!XtS
VARUNB
L

5-6

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

OPERAND

t0PERATIONL

LABEL

DTFCD (cont)

[,RECSIZE=

{(r)}]

[,SAVAREA=symbol]
rTYPEFLE= (INPUT
OUTPUT
I
(CMBND
L
[,WORKA=YES]
For a complete description and summary of each keyword parameter refer to 3 3 and Table
3—1.

5.4.

IMPERATIVE MACROINSTRUCTIONS

There are four imperative macroinstructions available to you for processing diskette SAM
files:
Macro instruction

Use

OPEN
GET
PUT
CLOSE

File control
Record processing
Record processing
File control

The following paragraphs describe these macroinstructions in detail and provide coding
examples with explanations.

5-7

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

OPEN

5.4.1. Open a Diskette SAM File (OPEN)
Eu nctio n:
The OPEN macroinstruction is used toopen a file for processing:The transient routine
called by the OPEN macroinstruction makes certain validation checks and then
proceeds to access the diskette file. The OPEN transient routine accesses input and
combined files in read only mode (5.2.1). It accesses output files in read and write
modes (5.2.2).
Format:
OPERAND

LOPERATIONL

LABEL

OPEN

[name]

Jfilename 1
1(1)

[filename n]

Positional Parameter 1:
filename
Is the label of the corresponding DTF macroinstruction in the program. The file
name may have a maximum of seven characters; the maximum number of file
names is 16.
(1)

Indicates that register 1 has been preloaded with the address of the declarative
macro instruction.

Example:
AOPERATIONL

LABEL

OPERAND

1
?M

Enters the transient routines necessary to prepare the DTF macroinstructions whose
labels are INPUT and OUTPUT. Checks that they are prepared to access these files with
the next imperative macroinstruction (GET, PUT, etc.).

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

5-8

GET

5.4.2. Retrieve Next Logical Record (GET)
Function:
The GET macroinstruction makes the next logical record in the input diskette file
available to you. The data is accessible either in an I/O area or in a work area you have
specified Data records must be in fixed unblocked or variable unblocked format (4 3)
If yoU specify ähly one I/O area and require single-sector i/O processing, yoU access
records relative to the name of the I/O area. Otherwise, you must specifya register
(IOREG keyword parameter) used by the card processor to supply the starting address
of the current record or must specify a work area in the DTF declarative macro,
WORKA=YES.
If you use multisectorprocessing, to determine the number of sectors read by one
physical I/O as a result of a GET macro, divide your DTF blocksize length by the block
length field in the file label (positions 22—26). The result must be an integral number
of sectors. There is no remainder. The GET macro reads a block of sectors and points to
a record or moves it to a work area until reaching end of data (EOD). Data management
then passes control to your EOFADDR=symbol routine indicated on, the DTF macro.
Format:
LABEL

[name]

LOPERATIONL

GET

OPERAND

5 filename
1.(1)

[j workarea

fL1o

Positional Parameter 1:
filename
Is the label of the corresponding DTF macroinstruction in the program
(1)
Indicates that register 1 has been preloaded with the address of the declarative
macroinstruction.
Positional Parameter 2
workarea
Is the label of an area into which the current record is moved for processing.

UP-8068 Rev. 4

SPERRY:UNIVACOS/3
BASIC DATA MANAGEMENT.

3-15

GET

3.4.2.

Retrieve Next Logica[ Record (GET)

Function:
The GET macroinstruction makes the next logical record in an Input file available to
you. The data is accessible either in the !/Q area or in a work area you :have
specified. The macroinstruction is used for all record types.
If you specify only one I/O area, you may directly access data relative to the name of
the I/O area. Otherwise, you must specify a register (through the IOREG keyword
parameter) to be used by the logical IOCS to give the starting address of the current
record, or you must specify a work area in the declarative macroinstruction. More
than one work area may be employed, since the address of the area is specified to the
logical IOCS with each GET macroinstruction. Each GET macroinstruction may specify
a different work area, if necesary.
Format:

LABEL

[name]

zOPERATiONt

GET

OPERAND

(filenamé
(1

F ( workarea
j (O)
)L(o

Positional Parameter 1:
filename
Is the label of the corresponding DTF macroinstruction in the program.
(1) or 1
Indicates that register 1 has been preloaded with the address of the declarative
macroi nstruction.
Positional Parameter 2:
workarea
Is the label of an area into which the current record is moved for processing.
(0) or 0
Indicates that register 0 has been preloaded with the address of a work area.
If omitted, indicates the user has chosen processing either by means of a register
(IOREG keyword parameter) or by directly accessing the data relative to the name of
the I/O area.
NOTE:
When a work area is specified, the keyword WORKA=YES must also be specified in
the DTF statement.

3-16

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Example:
LABEL

OPERAND

tOPERATIONt

JILrIvLc.rI—J,Itr.4.%IIR1<

the next record of the file described in the DTF macroinstruction, whose label
is INPUT, into the area whose label is INWORK. The optional label HERE may be used
to reference this point in the program
Places

SPERRYUNIVAC U/
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

(0)
Indicates that register 0 has been preloaded with the address of a work area.
If omitted, indicates the user has chosen processing either by means of a register
(IOREG keyword parameter) or by directly accessing the data relative to the name of the
I/O area.

NO TE:
When workarea is specified the keyword WQRKAYES must also bespecified in the
DTF statement.
Example:
LABEL

OPERATiON

OPERAND

Places the next record of the file described in the DTF macroinstruction, whose label is
INPUT, into the area whose label is INWORK. The optional label HERE may be used to
reference this point in the program.

U[’-Ub

hey.

I•

ornn i

BASIC DATA MANAGEMENT

PUT

5.4.3.. Writing a Diskette Record (PUT)
Function:
The PUT macroinstruction delivers an output record to the card processor. In singleSector processing, each PUT macro writes a record to diskette. In mUltisector
processing, you use the IOREG orWORKA specifications in the DTF and the PUT macro
to control the release and writing of individual records from a block of sectors held in
the output buffer to the output file on the diskette.
To prevent occurrence of unwanted information in the data you must be careful to
clear output record buffer areas before each use or, to supply complete records
including blanks on each logical PUT
Format:

[name]

OPERAND

t2OPERATiON L:

LABEL

PUT

f filename
(1)

F,Jworkarea
(°)

I [

Positional Parameter 1:
filename
Is the label of the corresponding DTF macroinstruction in the program.
(1)
Indicates that register 1 has been preloaded with the address of the declarative
macroinstruction.
Positional Parameter 2:

workarea
Is the label of the work area from which the record may be obtained.
(0)
Indicates that register 0 has been preloaded with the address of the work area.
If omitted, indicates you have chosen processing either by means of a register (IOREG
keyword parameter) or by directly accessing the data relative to the name of the I/O
area.

u—i

SHHY UINIVPL U/.I

UP-8068 Rev. 4

BASIC DATA MANAGEMENT

NO TE:
When the work area is specified, the keyword parameter WORKA=YES must be present in
the DTF statement.
Example:

OPERAND

AOPERATIONA

LABEL

Programming Considerations:
I

Variable-Length Unblocked Records
You must determine the size of the output record and must insert the size at the
beginning of the record before issuing the PUT macroinstruction. Record size includes
the 4-type record length field. You may not access the first four bytes, which are
reserved for block size.

ur-buo hey.

rMMY UINIVM1.

‘f

BASIC DATA MANAGEMENT

5.4.4. Closing a Diskette File (CLOSE)
Function:
The CLOSE macroanstruction transfers control to a data management CLOSE transient
routine which validates devices. If devices are diskette, a new diskette close transient
receives control and determines the close prncessing required according to file type. It
marks the DTF of an input file closed and resets indicators and fields in the DTF where
applicable (2.4.3). For output files, it writes all necessary buffers to diskette, updates
the EOD indicator in the file label, and resets indicators in the DTF before closing the
file (2.4.4). The diskette close transient closes combined files like output files except.
when updating or not updating the EOD field for partial updates of files or extended
writes to files (2.4.5).
Format
OPERAND

tOPERATIONL

LABEL

[name]

(filename-i [,...,filename-n]
(i)

Positional Parameter 1:
filename
Is the label of the corresponding DTF macroinstruction in your program. Filename
may contain a maximum of seven characters; the maximum number of filenames
is 16.
(1)
Indicates that register 1
macroinstruction.

has been preloaded with the address of the DTF

*ALL
Specifies that all files currently open in the job step are to be closed.
Example:
LOPERATiONLk

LABEL

r
O
E
1

lLS tum

Enters the transient routine which
macroinstruction whose label is INPUT.

OPERAND

closes

the

file

described

the

DTF

UP-8068 Rev. 4

6.1.

6-i

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Printer Formats
and File Conventions

GENERAL

The section describes the data formats and file conventions that apply to printer
subsystem files supported by OS/3. The SPERRY UNIVAC 0773 Printer Subsystem, an
integrated printer, is intended primarily for use with OS/3. However, the SPERRY UNIVAC
0768, 0770, and 0776 Printer Subsystems are also supported by OS/3.
A number of terms, used in what follows, are explained here:
line spacing
Advancing the paper (or forms) to be printed under the control of a line counter,
i.e. a specified number of lines.
line skipping
Advancing the paper to a line on the form that is specified by a code placed in
the vertical format buffer (VFB) by the user (or by a punch made by the user in
the forms control loop).
paper advance
Vertical movement of the form or paper in the printer either after printing or
without printing.
vertical format buffer
A buffer in the 0773, 0770, 0768, and 0776 printers. The buffer contains a
location for each line on a form. A code may be placed in the location that
corresponds to a particular line. Your program can then advance the form to that
line by issuing a skip command and specifying the appropriate code. The paper
tape loop on the 0768 printer is used in conjunction with the VFB.
load code buffer
A buffer located in the printer that allows the specification of any 8-bit code for
any graphical symbol on the print band or drum. Thus, you can load the EBCDIC
codes for the graphical characters on the print band into the load code buffer in
the proper sequence and then print EBCDIC data.

SPERR’UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

6.1.1.

6-2

0773 Printer Subsystem

The 0773 printer has a standard print line of 120 print columns. You can expand this to
144 print columns through available hardware options. Line spacing (6 or 8 lines per inch)
is accomplished through a switch on the printer. Paper advance (up to 15 lines) is
controlled by the VFB and, can be accomplished after printing or without printing.

6.1.2.

0770 Printer Subsystem

The 0770 printer allows you to use print lines of up to 160 print columns. The line spacing
(6 or 8 lines per inch) and paper advance (up to 15 lines) are accomplished through the
VFB. As with the 0773 printer, paper advance can be accomplished without printing or
after printing.
6.1.3.

0768 Printer Subsystem

The 0768 printer allows you to print lines of up to 132 pr’nt columns Line spacing (6 or 8
lines per inch) is controlled through a punched paper tape loop (forms control loop), and
paper advance (up to 15 lines) can be accomplished without printing or after printing.
6.1.4.

0776 Printer Subsystem

The 0776 printer allows you to print lines of up to 136 print columns. Lihe spacing (6 or 8
lines per inch) and paper advance (up to 15 lines) are accomplished through the VFB. As
with the 0773 prInter paper advance can be accomplished without printing or after
printing

6.1.5.

0778 Printer Subsystem

The 0778 printer has a standard print line of 120 print columns. You can expand this
optionally to 132 print columns. Line spacing (6 or 8 lines per inch) is accomplished
through a switch on the printer. Paper advance (up to 15 lines) is controlled by the VFB
and can be accomplished after printing or without printing
6 2

FILE ORGANIZATION

A print file can be best described as a collection of rëlätêd data that is output to a printer
device, one line at a time (band or drum printer). Line printers assemble the contents of a
complete line (including blank spaces) before actual printing occurs
Line printers are provided with the 90/30 system, and operate through OS/3. Therefore,
not Only are you responsible for organizing the data you want printed within each line, but
you must also consider the vertical separation bëtweOn lines and pages.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

6-3

Print files described in this section fall into three categories:
a

general text;

•

tabular data; and

•

data printed on forms.

6.2.1. Text
The simplest printer file to understand and use is probably one which consists of plain
text. For example, assume that each input record is punched card and each output record
IS formed in the I/O area or in a work area you have specified The records are output to
the printer buffer by the physical IOCS Each time that the printer buffer is full a print
command is issued and the line is printed Figure 6—1 is a typical example of text output
the annotations point out the record where the home paper instruction should be issued
and the home paper position necessary to begin printing the lower portion of the text at
the top of a new page.

LINE TRUNCATED (BIT 0)
VERTICAL

SPACING

6 LINES/iNCH

FIXED LENGTHS UNBLOCKED RECORDS: THE LINE TRUNCATED BIT IS SET
DURING OPEN PROCESSING IF THE USER HAS SPECIFIED A BLOCK SIZE
WhICH INDICATES A PRINT LINE LONGER THAN THE MAXIMUM PRINT LINE
WHICH CAN BE PRINTED ON THE ASSIGNED PRINTER. OPEN PROCESSING IS
COMPLETED AND THEN A BRANCH TO THE USER ERROR ROUTINE OCCURS. IF
THERE IS NO ERROR ROUTINE, THE OPEN ROUTINE RETURNS TO THE USER
AT NORMAL RETURN POINT. IF THE USER CONTINUES PROCESSING EACH
PRINT LINE JLL CONTAIN THE MAXIMUM NUMBER OF PRiNT

HOME PAPER

INSTRUCTION

HOME PAPER
POSITION

90/30 PRINTER SYSTEM/USER INTERFACE

PAGE
HEADING

PAGE
NUMBER

POSITIONS WHICH CAN BE PRINTED ON THE ASSIGNED PRINTER.

VARIABLE LENGTH, UNBLOCKED RECORDS AN DEFINED RECORDS:
IF THE USER TRIES TO PRINT A LINE LONGER THAN THE MAXIMUM LINE
LENGTH INDICATED BY THE BLOCK SIZE SPECIFICATION, A LINE EQUAL
IN LENGTH TO THE MAXIMUM iNI3ICAT!D BY BLOcK SIZE WILL E PRINTED,
AFTER THE LINE IS PRINTED, THE LINE TRUNCATED BIT WILL BE SET AND
A BRANCH TO THE USER ERROR EXIT OCCURS. IF THERE IS NO ERROR EXIT,
THE PUT ROUTINE RETURNS TO THE INSTRUCTION AFTER THE PUT MACRO
INSTRUCTION. NOTE: THE OPEN ROUTINE ADJUSTS’ BLOCK.SIZEIF A PRINT
LINE LONGER THAN THE MAXIMUM PRINT LINE ON THE ASSIGNED PRINTER
IS INDICATED BY THE BLOCK SIZE SPECIFICATION. IN THIS CASES BLOCK
SIZE IS ADJUSTED TO INDICATE A MAXIMUM PRINT LINE EQUAL IN LENGTH
TO THE MAXIMUM PRINT LINE ON THE ASSIGNED PRINTER.

Figure 6—1.

Typical Text Output Example

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BAS1C.DATA MANAGEMENT

6-4

6.2.2. Tabular Data
Tabular data and reports generally require a more complex printer file structureSince
there is a more varied spacing requirement, both vertical and horizontal (Figure 6—2).
Also, column headings and similar repetitive items require a more complex program if the
file is lengthy. The output records are formed in the same manner as those of regular text
files (in the I/O area or work area) and are output to the printer one lineat a time.

HOME PAPER POSITION

COLUMN
HEADINGS

—

T_DAlLY ACTIVITY REPOaT
TRANSQUAN

PART

ITEM

jJBR
000lOE
0001OF
000IOG

P.RJtW.t
CAPACITOR
ROTOR
POINT, IGN

ACTION
ORDER
ORDER
ORDER

Figure 6—2.

6.2.3.

ON-HAND

REORf /DEPARmENT
P0

‘BILLED
7(PRODuCTION
PRODUCTION
‘
MAINTENANCE

)

Sample Table Printout

Printer Forms

Printer files that complete or that are added to document forms are usually simple to use
once they are organized (Figure 6—3) By using the control and overflow
macroinstructions you can achieve desired vertical positioning By forming your records
properly in the I/O area or work area you can achieve the required horizontal positioning
to place the data on the form where it belongs

E RY+ UNIVAC
COMPUTER

SYSTEMS

P. a. BOX 500
BWE BELL PA. 18422

HOME
PAPER
POSiTiON

INT
SITE 3-1

ATTN:

HOME PAPER
iNSTRUCTiON

UMS

——

—

_D6866M

CATHY SMITH

8598

8071

ADDRESS CORRECTiON REQUESTED
RETURNPOSTAGE GUARANTEED
UDI-527

Figure 6—3.

Sample Forms Printout

00851

UP-8068 Rev. 4

6.3.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

6-5

RECORD FORMATS

You have the option of specifying, in the DTFPR macroinstruction, that a control character
is to be included in the data records. This character specifies line spacing or skipping
when the file is printed. The character itself is normally not printed, but is a part of the
record in storage. If the record is sent to a printer and the user has not specified that the
record contains a control character, the character is handled as data and printed. I/O
areas must be large enough to include this character.
When fixed-length or undefined record formats are used, the control character is the first
character in the record (Figure 6—4). It is the first character following the record length
specification in a variable-length unblocked record format. The block size of the output
area must include the byte for the control character. If variable-length, unblocked records
are to be processed, the block size must account for the initial eight characters as well as
the control character (nine bytes total) in the output area. Although these characters do
not appear in the output, the output area must be large enough to accommodate them.
When a control character is specified, every record must contain a control character.
When a PUT macroinstruction is executed, the control character in the data record is
translated to the appropriate command code. (For the character required, see the CTLCHR
keyword parameter under the DTFPR macroinstruction, 7.3.) The first character in the
output data after the control character is the first character printed. Logical input/output
control system (IOCS) modules also automatically issue certain printer control instructions.
These involve printer àverf low conditiàns and vertical format control. Parameters available
with the macroinstructions that call the IOCS modules into the program allow you to tailor
them for each particular task. In this manner, the complex vertical movement and overflow
sensing functions are made easy for you to control.
lf the CNTR.L macroinstruction is to be issued for the printer, the CONTROL keyword
parameter is specified and CTLCHR must be omitted.

6-6

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Fixed-Length
cc

data, fixed length

irj

Undefined

data, variable length

A
Variable-Length

data, variable length

A_______

ftoH
C

LEGEND:
b
cc
r
u
D
A
C
F

Block size field, four bytes
Control character, one byte, optional
Record length field, two bytes, binary
Reserved (two bytes); can be any two characters you choose.
Record size field
Data record length
Variable record length
I/O area layout

NOTES:
1.
2.

You must align an I/O area so that the first character to be printed falls on a half-word boundary.
You must place record length, as a binary number, in the first two bytes of the record length field (r) before printing a
variable-length, unblocked record. The record length includes the 4-byte record length field and the control character,
if any.

You should allocate an even number of bytes for data in I/O areas, even though an odd number of columns are to be
printed. To print an odd number of columns, allocate data areas one byte larger than the number of columns to be
printed.

Figure 6—4.

Printer Record Formats

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

6-7

6.4. VERTICAL FORMAT AND LOAD CODE BUFFERS
In OS/3, you use the job control LCB statement to specify the load code buffer (LCB) and
the VFB statement to specify the vertical format buffer (VFB) of the following printer
subsystems:
SPERRY UNIVAC 0768 Printer Subsystem
•

SPERRY UNIVAC 0770 Printer Subsystem

•

SPERRY UNIVAC 0773 Printer Subsystem

•

SPERRY UNIVAC 0776 Printer Subsystem

•

SPERRY UNIVAC 0778 Printer Subsystem

Refer to Table A—3 for operational characteristics of these printers, and to the job control
user guide, UP-8065 (current version).
6.4.1.

Load Code Buffer Interchangeability

There is no interchangeability of printer load code buffers across devices; an LCB job
control statement you have specified for a particular printer and print band or drum cannot
be used for any other.

6.4.2.

LCB Statement Specification

You specify the codes to be assigned to each graphic symbol on the print band or drum by
using the X (hexadecimal) or the C (character) positional parameters of the LCB statement.
You must specify a character code or a hexadecimal specification for each symbol on the
band or drum, and you may intermix X and C specifications. Each X or C specification
must be complete on a single card. As many specifications as are necessary to specify an
entire band or a single repeated font may be made.
The space or nonprinting code should be specified through the SPACE keyword parameter,
and not included in the sequence of codes specified through the positional parameters.
If the number of charactErs is specified with the NUMBCHAR keyword, it should include
only the number of codes specified for graphic symbols and should not include the space
code.
If the CARTNAME keyword is specified, the operator receives a message to mount the
specified band, and program execution is suspended until the operator replies to the
message. If the CARTNAME keyword is not specified, no operator message is issued.

UP-8068 Rev. 4

6.4.2.1.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

6-8

LCB Specification for the 0773 and 0778 Printers

You may specify 48, 63, 64, or 256 characters for the 0773 and 0778 printers; however,
any band having more than 64 characters requiresthe specification, of 256 characters. A
1 28-character cartridge requires the specification of 256 characters. A 128-character
cartridge requires that the 128 characters be specified twice on the LCB statement.
Dualing applies to 48-character bands only; you specify dualing with the DUAL keyword of
the LCB statement. Four dualing characters may be specified for the 0773 and 0778
printers; these correspond to the 39th, 40th, 44th, and 47th characters on the band.
The CARTID specification is optional for the 0773 and 0778 printers.
6.4.2.2.

LCB Specification for the 0770 and 0776 Printers

You may specify from 24 to 384 characters for the load code. buffer of the 0770 and 0776
printer. For repeating fonts ranging from 24 to 192 symbols, your need only specify the
characters for a single font: for example you would specify only 128 characters through
the LCB statement for a repeating font of 1 28 characters.
Dualing for the 0770 and 0776 printers involves specifying up to four pairs of codes with
the DUAL parameter Each pair consists of one code that has been specified for the load
code buffer followed by one code that has not Assuming for example that a band
contains the question mark symbol (?), but not the vertical bar (I) you could substitute ? in
your printout for I by specifying DUAL = C? I’. Every time your program outputs the EBCDIC
code for a vertical bar to be printed, a question mark appears on the printed listing.
For the 0770 and 0776 printer, you must specify the CARTID parameter, and the code you
specify must be the correct one for the cartridge you intend to use.
You may also specify a mismatch character for the 0770 or 0776 printer: that is, you may
specify what character; other than blank (space), is to be prihted whenever a character
mismatch occurs.
‘

6.4.2.3.

LCBSpecification for’the 0768 Printer

You need only specify the string of codes for the load code buffer and the MISM, SPACE,
and TYPE parameters You may also specify the optional NUMBCHAR parameter but the
other parameters of the LCB statement do not. apply to the 0768printer.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

6-9

6.43. Vertical Format Buffer Interchangeability
Table 6—1 summarizes the conditions under which a properly specified VFB statement for
one printer may be used with other devices. There is no difference in the appearance of
the printed results if the same VFB statement is used from machine to machine under
these conditions.
6.4.4. VFB Statement Specification
Specifying a VFB job control statement involves visualizing the form with numbered lines.
An 11-inch form to be printed at a density of 8 lines per inch has 88 lines. At 6 lines per
inch, an 11-inch form has 66 lines. The first printable line on a form is line 1. The last line
on an 11-inch form, printed at 8 lines per inch, is line 88.
The vertical format buffer can be specified and the program designed so that most printing
occurs between the home paper code position and the overflow code position on the form.
The position of the home paper code determines the amount of unprinted space at the top
of the form, and the overflow code position approximates the amount of unprinted space at
the bottom of the form.
Because lines may be printed (and the form advanced) beyond the overflow position, you
must provide enough space between the overflow code position and the bottom of the
form for any lines (and form advances) that must fit on a page. Note that you must provide
at least four lines between the overflow code position and the bottom of the form. This is
particularly important for VFBs that are used to print dumps, librarian runs, assemblies.
etc.
6.4.4.1.

Specifying Home Paper Position

The HP code specified on the VFB job control statement gives the lines number location of
the home paper position: The specification HP=5 places the home paper position on the
fifth line of the form.
6.4.4.2.

Specifying Forms Overflow Position

You use the OVF keyword of the VFB job control statement to specify the forms overflow
position to printer SAM. You should not specify the OVF keyword if you do not intend to
use it.
When an overflow code is placed in the buffer, a space form operation (advance paper n
lines) which would move the form to or beyond the overflow position causes forms
overflow to be detected. On detecting forms overflow, printer SAM takes action according
to your specifications of the PRINTOV keyword parameters in the DTFPR declarative
macro.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

6-10

No indication of overflow is returned to you, except that printer SAM transfers control to
your overflow routine if you have so specified. In this routine, you may take such actions
as skipping to the top of the next page, printing page numbers, printing subtotals, and so
forth.
You must specify the overflow code position so that enough space is left between the
overflow position and the bottom of the form to print and space all of the lines that are to
appear on the page. Printer SAM may print a line on or below the overflow code position
and perform spacing before branching to your overflow routine.
If a PUT appears in the overflow routine, the effect will be to perform spacing and/or print
a line between the overflow position and the bottom of the form.
If the user does not specify the PRINTOV keyword in the DTF, data management takes no
overflow action; in this event, the BAL programmer who is not counting lines in his
program runs some risk of tearing the form by printing on or too near the perforations.
Table 6—1 summarizes the combinations of device-independent control character codes
permitted when using each type of printer with or without the TYPE parameter
specification on the VFB job control statement. Because it describes the allowable use of
device-independent control character codes, Tables 6—i, 7—i, and 7—2 should be used
conjunctively. Table 7—i interprets the control character codes associated with each of
four printer functions: print and space, print and skip, spacing, and skipping. Table 7—2
interprets overflow and home paper control character codes.
Note that the 0770 printer has two overflow codes (9 and 12) that the data management
PRTOV imperative macro can detect selectively. You should specify a secondary overflow
code (hexadecimal code 9, specified through the OVF2 keyword) only with the 0770 printer
and only if you are using the PRTOV macro, or (if you are not using data management) its
PIOCS equivalent.
6.4.4.3.

Specifying Special Forms

If you specify the FORMNAME keyword in the VFB job control statement, the operator is
issued a message to mount the specified form, and program execution is halted until the
operator replies.
6.4.4.4.

Paper Tape Loop, 0768 Printer

For the 0768 printer, you must provide both a paper tape loop and a VFB job control
statement. The paper tape should be punched to agree exactly with the VFB statement,
with the following exceptions:
1.

A 7 should not be punched on the tape. Home paper should be punched either as 15
(for 8 lines per inch spacing) or as 14 (for 6 lines per inch). Only one home paper
code may be punched on the tape.

Channel

should

Table 6—1.

Specification of
TYPE Keyword

=0773
(or keyword
omitted)

6-11

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Statement May
be Used lN
Printer Types
(Note 2)
0768
0770 “
0776)
0773
0778

TYPE
keyword
omitted

not

punched

the

tape.

VFB Statement Specification, and Interchangeability

Other Keywords that the User May Specify (Note 1):
—

CD2

CD3

CD4

CD5

CD6

OVF

OVF2

CD1

CD7

C08 J’CD9

IcDb0IcDhhI12IcD13fr14k15

0768

=0768

0770 1
0776

=0770

0770

Note 3

Note 4

=0776

0768
0770

TYPE
keyword
omitted

0776

LEGEND:
X

Keyword may be specified.
Keyword may not be specified.

NOT ES:
1.

This table is concerned with only the keywords shown; the user may always specify the LENGTH, DENSITY, FORMNAME. and USE keywords.

The TYPE keyword should be specified only if a particular printer type must be used. A VFB statement designed for a particular printer (using the
permitted keywords shown for that printer in Table 6—1) may be used with other printers only if the TYPE keyword is omitted.

The user should specify TYPE=0770 only if he specifies a secondary overflow code (OVF2) or if he specifies multiple home paper positions.

If the user does not specify the OVF2 keyword, he may use the VFB statement (TYPE keyword omitted) with the 0768, 0770. and 0776 printers.

The secondary overflow code (OVF2) should be specified only by a data management user who issues the PRTOV imperative macro. Refer to the PRINTOV
keyword parameter of the DTFPR and PRIO declarative macros.

UP-8068 Rev. 4

6.4.4.5.

SPERRY UNIVAC•OS/3
BASIC DATA MANAGEMENT

6-12

Vertical Format Buffer Statement Example

The following example might be a typical VFB statement used to set up the forms spacing
and skipping required for a printed report

LABEL

/ / VFi U

/ /1

OPERATIONt

OPERAND

COMMENTS

‘Ib

FMMAMmE

mY1PE=otr70 ,HLiFEES2L1
1

1_Lu

Line 1 specifies that the operator use a form called TESTPR The total number of lines per
page is 66 at 6 lines per inch. The 0770 printer is being used. The home paper position is
on line 1 and the overflow area of each page begins on line 52. Note that this includes the
4-line space between the overflow code position and bottom of page used if a dump,
librarian run, or assembly is executed. The number 52 is used by data management to test
for page overflow conditions Then according to your PRTOV imperative macro
specifications data management skips to the overflow routine or register to handle your
overflow routine address
Line 2 specifies a channel code of CD2 with a line number of 6. This means that
whenever a CNTRL filename,SK,2 imperative macro is issued in the program, the printer
immediately skips 6 lines on the page Here a detail line of a report might be printed On
the other hand, if .a CNTRL filename,SK,,2 macro is issued in the program, the printer
skips 6 lines after printing the detail line. The first macro use illustrates immediate
skipping and the second, delayed skipping.
A second channel code of CE53 indicates 46 lines. Similarly, the CNTRL macro could
specify an immediate or delayed skip of 46 lines where a final total might be printed.
It is important to realize that the CD number (VFB parameter) relates to a channel code
and the value indicated on the right of the equal sign indicates the line number to which
the printer skips.

UP-8068 Rev. 4

SPERRY UNIVACOS/3
BASIC DATA MANAGEMENT

7. Function and Operation
of SAM Printer Files

7.1.

GENERAL

The OS/3 includes data management modulesthatcan be used to move and manipulate
sequential access method (SAM) printer files. These modules can function with five
different printer subsystems:
•

SPERRY UNIVAC 0773 Printer Subsystem

SPERRY UNIVAC 0770 Printer Subsystem

SPERRY UNIVAC 0768 Printer Subsystem

SPERRY UNIVAC 0776 Printer Subsystem

•

SPERRY UNIVAC 0778 Printer Subsystem

This section contains a brief functional description of printer file SAM operation. This is
followed by a detailed description of the declarative macroinstruction that is used to define
a printer file and of the imperative macroinstructions that initiate, conduct, and conclude
file processing.

7.2.

FUNCTIONAL DESCRIPTION

At system installation time, the system macro library ($Y$MAC) is loaded with source code
modules that are common to several machine operations. These modules include data
management modules that are common to several device types and access methods.
When assembling the program, you define the characteristics of printer file involved in the
operation, using the define the file (DTFPR) declarative macroinstruction. This
macroinstruction creates a table of file characteristics in main storage that is referenced
by your program

UP-8068 Rev. 4

SPERRY UNIVACOS/3

7-2

BASIC DATA MANAGEMENT

The source code modules that are required for your program are called in from the system
macro library at program assembly time by using imperative macroinstructions. These
imperative macroinstructions are included in the program you are assembling and result in
the creation of inline code at the point where the assembler encounters the
mâcroinstruction. Positional parameters contained in the imperative macroinstructions
allow you to modify the basic assembled module so that
meets your particular
requirements.
it

When the file is opened, the characteristics in the file control table set up by the DTFPR
are examined to determine that they are valid and, if required, that they are present. The
output records are formed either in the I/O area or a work area. A form of overlap
processing can be achieved by assigning either two I/O areas or an I/O area and a work
area. In this way, records can be constructed in one area while others are simultaneously
being output to the printer from the other area.
Logical input/output control system (IOCS) modules also automatically issue •certain
printer control instructions. These involve printer overflow conditions and vertical format
control. Parameters available with the macroinstructions that call the IOCS modules into
the program allow you to tailor them for each particular task. In this manner, the complex
vertical movement and overflow sensing functions are made easy for you to control.
A typical printer SAM operating sequence is described in the following example, which
show the sequence and function of each macroinstruction. The macroinstructions are
discussed in detail in 7.3 and 7.4.
Example:
LABEL

.OPERATION.

OPERAND

COMMENTS

P.LE
1
JJI,EXAi
.
t._._._i

‘

1•L.

1
i.

5Jv3O
1
A

...

---.--

I..

-_--.

----_.j--.-

tarfda+

LLi

Jbfa±

i1..__

TAPEIN

ape lnpuf #ite and *h
-KeyWbd ?aaree + ckLflL rnane+Lc 4
cLphys ca c,ec+th+rc
p& o___

ç*

I
-

)iPl’JL.

p-j--j-

—

IiLLLN

•L_.L_

)

LL.L
*1

)__________________________________________________

.LJL.Li.i.
I

DiTFt4T

a-y
jIc

2SintPf1he$ -tçh€ck DTFMT DTFPR-fk±
uppLie4 &nd v&i. The phycI
I hpu1 recd ct +ke I/ area.

)

TAP.VAA.3
tLi.

iiLt.
-----.i.

f’\ake 4h
pi.jf

b1 4
8
cf rec-d /(

PthLinkep5’

ueI-

w4c-res,eted WQJ or by directly accessing the data relative to the name of
the I/O area.

NOTE:
When the work area is specified, the keyword parameter WORKA
the DTF statement.

YES must be present in

7-19

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Examples:

LABEL

AOPERATIONL

10
I

liii

—

OPERAND

f
1
‘l(...’
I

—

R
i
1
.1rl

—

—IAI

r
1
PI.’

—

Print a line, or space the paper. The record is located in an output area. The file
characteristics are contained in the DTF table labeled PRNT1.

Move the record in the work area WORK1 to an output area and print, space
paper, or both.

Move a record from the work area whose address is stored in register 0 and
print, space paper, or both.

Programming Considerations:
When WORKAYES is used, a work area must be specified with each PUT
macroinstruction. When only one I/O area is specified, you may move the records to
be printed directly into the I/O area. If you specify two I/O areas, you must use the
I/O register (IOREG keyword parameter) to move records to be printed into one of the
I/O areas before issuing each PUT macroinstruction.
When printing variable-length, unblocked records, you must place the record length
(as a binary value) in the first two bytes of the record size field. Undefined-length
records require that you place the record length in the required register (specified by
the RECSIZE keyword parameter) before issuing each PUT macro instruction.
When you want to use control characters to position the form only (no printing) for
variable-length, unblocked, or undefined record formats, you can indicate that the
record contains no characters to be printed.
When you are printing records in undefined or variable, unblocked format, printer
SAM checks whether the number of columns being printed is greater than zero every
time. If you try to print zero columns, data management normally issues error
message DM18 (RECORD SIZE INVALID), sets the record size invalid error flag (byte
0, bit 7) in filenameC, and branches to your error routine. Refer to Appendix B.
However, this error processing does not take place when you are performing an
advance-only operation using control characters; you may then indicate that there is
no data to be printed. With either undefined or variable, unblocked records, you must
place the record size in either the RECSIZE register or in the record size field in the
record before issuing each PUT macro. To indicate that you have no data to be printed
when your records are variable, unblocked, you may place a record size of five bytes
provided that you limit this to advance-only operations.
in the record size field
—

UP-8068 Rev. 4S

SPERRY UNIVAC 0513
BASIC DATA MANAGEMENT-

72O

When you are printing a record containing an odd number of characters to bepriritad
data management places a nonprinting character in the 1/0 area after the last byte of
user-supplied data..
-

,,:t

-•

...

‘:L

—

.2..

H-:::-

:;.;

:-:

:‘

•.‘

•?-.

:--q’

:4;

‘t.’

_z.

-;--.

-_.

.,.

‘‘-)

.:.

-:.

.i(..

.bj

i.,

‘i

1•

..-.-!

i:rt;t: :-

‘.

‘-?

‘:j3
-

.•

,:;

-;.-

,..

-.4..

-..-

•.;.,4.f
‘•‘$

-;?::..h

-tk.
C.

b-4

4..: P

.:-.-

.‘

‘‘‘I

•;--•

-S-.—

—..t

‘l

!j.•e”

...

•-

.fr

••.

:--“-

-‘1)

•;!..

4
-*--

:s:h

7-21

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT:

UP-8068 Rev. 4

CNTRL

Control Printer Forrn (CNTRL)

7.4.3.

Function:
The CNTRL macroinstruction controls printer forms spacing and skipping. Forms
motion can occur before after or both before and after a line is printed
Format:
LABEL

[name]

OPERAND

tOPERATiONL

CNTRL

(filename, (SKi [,m] [ni
c(1)
1SPJ
(1

Positional Parameter 1:
filename
Is the label of the corresponding DTF macroinstruction in the program.
(1)orl
Indicates that register 1 has been preloaded with the address of the declarative
macroi nstruction
Positional Parameter 2:
SK
Indicates that forms skipping is desired.
SP
Indicates that forms spacing is. desired.
Positional Parameter 3:
m
Specifies either the: number of lines (0 through 15) for immediate spacing, or the
channel code (1 through 15) for immediate skipping. The PUT macro performs
spacing after printing. The number of lines spaced is determined by the PRAD
keyword parameter (default causes advance of one line). Immediate CNTRL
spacing is in addition to any spacing performed on a previous PUT
macroinstruction It should be noted that forms overflow processing can be
initiated after CNTRL processing (immediate or delayed) is performed

UP8068 Rev. 4

SPERRY UNIVAC OSt3
BASIC DATA MANAGEMENT

7—22

Positional Parameter 4:
n
Specifies either the number of lines (0 through 1 5) for delayed spacing, or the
channel code (1 through 15) for delayed skipping.
Exa mples:
LABEL

7\OPERATIONA
10
16

DlbdltoTI

I
I

—

OPERAND

T
1
‘lL)

.I1liTiRi(...

tItTIZ
I
9
J%ffJJJiiL[

TR
1
t’J
L

—

NUIZ,WZRII
3.

If an overflow code 9 was detected on a previous PUT or immediate CNTRL
macroinstruction execution, skip to the home paper position.

If an overflow code 12 (0770 printer only) was detected on a previous PUT or
immediate CNTRL macroinstruction execution, branch to routine OVFLOB.

If an overflow code is detected, a skip to home paper position will occur.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

7-26

Programming Considerations:
When you use the PRTOV macroinstruction in your program, you must specify the
PRINTOV=YES keyword parameter in the DTF macroinstruction for the file. The
PRTOV macroinstruction can be used with the 0770 printer to selectively check for a
code 9 or code 12 forms overflow condition.
When the PRTOV macroinstruction is used, the logical IOCS performs either a skip to
the home paper channel or a branch to your forms overflow routine when a forms
overflow condition is detected on the preceding print or space command. The forms
overflow code is not recognized during a skip operation.
OS/3 data management executes one user-issued CNTRL or PUT macroinstruction
after the immediate CNTRL or PUT instruction on which forms overflow is detected. If
the imperative macro issued after the macro on which overflow was detected results
in a forms advance to a skip code (VFB or paper tape code), your overflow options will
not be executed.
The PRTOV macroinstruction may be issued after each CNTRL or PUT
macroinstruction, or, it can be issued after only a PUT macroinstruction. It is also
permissible to issue a CNTRL, PUT, PRTOV macroinstruction sequence.
If an overflow routine is specified, the printer carriage is not automatically restored to
the home paper position.
The address of the instruction after the PUT macroinstruction, which detected the
overflow condition, is stored in register 14. If imperative macroinstructions are issued
in your overflow routine, register 14 should be stored before issuing the instruction,
and restored after execution of the instruction.

7-27

SPERRY ‘UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Close a Printer File (CLOSE)

7.4.5.

Function
The CLOSE macroinstruction is issued when all the data in a file has been processed
This macroinstruction calls a transient routine which checks for errors that may have
occurred in the final output operation and then prevents further access to the file.
Format
tOPE RATION

LABEL

OPERAND

filename-i [,...,filename-n]

[namel

(1)
1
*ALL

Positional Parameters
filename
Is the label of the corresponding DTF macroinstruction in your program. The
maximum number of filenames is 16.
(1) or 1
Indicates that register 1hasbeen preloaded with the address of the declarative
macroinstruction.
*ALL
Specifies that all files currently open in the job step are to be closed.
Examples:

1. 1
tv18
‘
7
I

OPERAND

.AoPERATiONL

LABEL

I
I

—

ria

—

rrl
,PR
1
e
I

Close print files labeled PRNT2 and PRNT4.

Close print file labeled PRNT1.

UP-8068 Rev. 4

7.5.
7.5.1.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

7-28

ERROR AND EXCEPTION HANDLING
FitenameC

When certain errors or exceptions to file processing performance àrê detected by OS/3
data management, it will make appropriate entries in specific fields of the DTF file table,
which your program may address in order to learn of these conditions and take the proper
course of action on regaining control. One such field in the DTFPR file table isfilenarneC,
a 1 -byte field which you may access by concatenating the character C to your 7-character
file name and using the assembler language test-under-mask (TM) instruction
Refer to Appendix B for the meanings of the bits in filenameC of the DTFPR file table
which are set to binary 1 by OS/3 data management for certain error and exception
conditions.

7 5 2

Truncation of Print Line

When OS/3 data management detects that the execution of a PUT macroinstruction has
resulted in the printing of a truncated line, it sets the line truncated flag in filenameC (bit
0, byte 0) (Appendix B). However, it does not pass control to your error routine until after
the printer file has been closed, by which time other truncated lines may have also been
printed. Depending on your requirements, you may find it useful in your program to test
for setting of the line truncated bit after each execution of the PUT màóro and provide for
a flag character to be printed with the next line to speed visual location of all truncation
errors on your printout

7.6. SAMPLE PROGRAM
The following sample program, constructed to illustrate a typical use Of the OS/3 data
management printer system in a BAL program, also indicates where toplacethe OS/3 job
control statements needed to implement it.

CsC cz z 2
t t i :
3 ?
r

I-

L
m
I-

T
-

:c:
:.

-Z7i.

-L

————

‘I

cc C C
-1-1

1
——___L

[‘

I4rn•1ç-•

rn
,

-I

1-ti

c
-I,
1i

(7L

-1 3
cn
I-

ru
0
m
-

ic
D

I’

-1

H r

rp H

(En

-i

-1

-1
M

fri

L
3

r
z

rQo1r

(

:
2: H
•11

n qi

> lCD :r.

:
z

‘En

r
H

cfr.

7:
ru

‘ml

-I

C’)

LIL

L
1

fir

fr-I

-1

H
-

—

— —

—

E:::E1:::E::E______

F-H

-a

-F-

-Ffr-

IN3LN39VNW’i V1VG3ISV
17 AOJ

s/SO DVAINfl A)i3dS

61-L

8908dfl

r
11

1
F

1111111
1

I
F

I
I

T ]]T’

I
I

I
F

F
I

‘

I
F

F
F
F

11ll[l
F

I
F

I
T

F
I

1
F

rJr
TF

1 1FT

I
T T

j9j

I
IjI

—

95T

T
9iTh

l:j3I±IvIQlIQIJI

III

W
v
1

III

—

1111111

IIJIlT.1

[

Yf
9
T

III

[

TTj

1]H9

iIITIIY

rjrri

TTTT5(11

TTFflE

T Try

TT1

TTTf

‘T

1111

—

I7NOIIVH3dO17

T Tjl

J.- 9’iID
j
T
[
1

—

Tlli5rNTD

9JV’ QL’I
1
3

TTTTf T

rTmmTr

TT
5
T
_flri
9
]f

1 mrfT1rrTrT

1
y

IiIIjFilIllTII

‘3’j jy
I

Y Tç
1

ON’H3dO

TTj 1mTrp 1TrTrrTT

1111

TrrT

j
1
r

r r

rrr 1

r
1
j
T

Ij
9
1

1T1

03ANT

III

unique key; and the starting location of the key must be the same in each record. You specify the length of the
key with the KEYLEN keyword parameter; minimum length is 3 bytes, maximum is 253.

Key location. The starting locatiOn of the key must be the same in êãch record. You may specify the number of bytes
of data preceding the key With the KEYLOC keyword parameter. If keyword is omitted, ISAM assumes the key starts in
the first byte of a fixed record.

Data portion of your logical record

Length of logical fixed-length record (key plus data), You specify this length, measured in bytes, with the RECSIZE
keyword parameter; it must never exceed the value of data block size, less seven bytes.
Figure 10—2.

Fixed-Length ISAM Records with and without Keys

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

10-7

Key at Head of Record

)i4

Key Internal to Record

data

key

data

K
LV

Without Key

D
V

LEGEND:
F

A 2-byte record length field. You insert the length of each variable record into this field in binary; the length includes
this 2-byte field and is equivalent to V in this figure.

Data portion of your logical record

Length of a variable record. Includes key plus data, plus two bytes for the record length field. You never specify this
length with a keyword parameter but place it in the leading two bytes of each variable record (in the field represented
by F in this figure).

Record key. All keys in a keyed file must have the same length; each record in a keyed file must have one (and only
one) unique key; and the starting location of the key must be the same in each record. Minimum key length is 3 bytes;
the maximum is 253. You specify the length of the key with the KEYLEN keyword parameter.

Key location. The starting location of the key must be the same in each record. You may specify the number of bytes
that precede the key with the KEYLOC keyword parameter. If you omit the keyword, SAM assumes the key begins in
the third byte of a variable record.
Figure 70—3.

Variable-Length ISAM Records with and without Keys

10.2.2.

10-8
Update A

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

ISAM Data Block Format

When OS/3 ISAM writes your records to the disk, it blocks them into data blocks, the size
of which you specify. (This data block length is the same as the length of your I/O area, or
data buffer, and may contain unused space, for reasons discussed later.) All data blocks
begin with a 2-byte field called the block header, which states the number of bytes in the
block that are currently occupied. Because every logical record is accompanied by the 5byte data pointer just mentioned, the maximum size of any logical record is thereby limited
to data block size minus seven bytes. And, because the effective data length of a variable
record is further reduced by its own 2-byte record length field, the number of bytes of data
that your longest variable record may contain is no more than data block size less nine
bytes.
Although you should use as large a block as you can afford to have in main storage, data
buffer size is not entirely up to you. It may never be less than 256 bytes, for example,
because this is the length of the index blocks, and ISAM handles these through the I/O
buffer (whose length you specify when you specify data block size to data management).
Furthermore, you should set data block size at some multiple of 256 bytes if you are using
the fixed-sector 8415, 8416, or 8418 disks at your installation. If you do not specify a
multiple of 256 bytes, ISAM increases your specification to the next higher multiple. If
your data block size is less than 256 bytes, then you must specify a BLKSIZE length of 256
bytes or more. Finally, whether you are using this or the variable-sector 8411, 8414,
8424, 8425, 8430, or 8433 disks, the block size you specify must not exceed the track
size for these devices:
SPERRY UNIVAC Track Size,
in Bytes
Disk Subsystem
8411
8414
8415
8416
8418
8424
8425
8430
8433

3625
7294
10,240
10,240
10,240
7294
7294
13,030
13,030

Figure 10—4 illustrates the layout of two ISAM data blocks on disk, one containing two
fixed-length records, and one containing two variable-length records. The legend relates
the segments shown to various keyword parameters you will use in the DTFIS declarative
macroinstruction to define your file to OS/3 ISAM. (The DTFIS macro and its keyword are
described in detail in Section 11.)
Note that Figure 10—4 shows some unused space at the end of each data block. You
should avoid this (if you can) when you specify data block size for a file containing fixed
records, by ensuring that the sum of your logical record size, plus five bytes for the record
not forgetting that block
pointer following each record, divides evenly into the block size
size must always include the 2-byte block header field.
—

On the other hand, it is generally not possible for you to avoid some unused space in the
data block when your ISAM file contains variable records.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

10-9

Fixed Records

—

P—

Variable Records

*BIhl

[P_l4

LEGEND:
B

Block header, written by data management inthe buffer. This is always two bytes long and céntains (inbihary)
the number of bytes in the data block which hold usable information In the example shown this figure would
equal (I) minus (U); it includes the total space occupied by the records themselvesand the 5-byte data pointers,
one of which follows each of the records Because data management appends the block header in the buffer
and it is placed in the buffer with the block when it is retrieved, you must allow forthis 2..byte header in
calculating the data block size which you specify with the BLKSIZE keyword parameter However it is not
moved to your record work area (the address of which you specify with the WORK 1 keyword parameter) where
data management presents your records one by one

Record key. This may be internal to the record instead of being located (as shown) at the head of the
record. All keys in a file must have the same length; each record in a keyed file must have one and
only one unique key; and the starting location of the key must be the same in each record of the file.
You specify the starting location of the key with the KEYLOC keyword parameter, and its length with
the KEYLEN parameter; minimum key length is 3 bytes and maximum is 253. (When you present a key
that you want ISAM to match by search you load it in an area of your program specified by the
KEYARG keyword parameter.)

Data portion of your logical record

A 2-byte record length field of a variable record

Record pointer, a 5-byte divider which follows every record that data management writes into the data
block. The record pointers are written by data management, but you must allow space for them in
calculating your I/O area length, which you specify with the BLKSIZE keyword parameter. Data block
size and I/O buffer size may differ; the buffer must be at least the size of the data blocks, but may be
greater, The record pointer contains, in binary, the block number and byte position in that block of the
next sequential logical record in the file, in the form rrrbb, where: rrr is the block number, relative to
the data partition; and bb is the displacement, measured in bytes, of the record into that block (a record
preceded by 125 bytes will have a displacement value of 125). You will use this 5-byte “address” when
you retrieve records directly, rather than by key. (This address is always returned to you by data
management after each record is loaded or added to your file; it is your responsibility to access it and
store it for later use, if you plan tO use it. Data management lacês this 5-byte value in the field of
your DTF called filenameH.)

Figure 10—4.

Layout of ISAM Data Blocks (Prime or Overflow) on Disk Each Containing Two Logical Records (Part 1 of 2)

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

10-10

LEGEND (cont):
U

Any unused space at the end of a data block. Usually unavoidable in data blocks containing variable-length
records, thisdead space may also occur in files of fixed records, if the sum of the logical record size (R) plus five
bytes for the record pointer (P) does not divide evenly into (I), the data block size you specify.
Length of logical fixed-length record (key plus data). You specify this, measured in bytes, with the RECSIZE
keyword parameter. This must never exceed the value of the data block size, less seven bytes.
Length of logical variable-length record (2-byte record length field, plus key, plus data). You never specify this
length with a keyword parameter; you place it in the 2-byte record-length field at the head of each logical
record. Like the length of a fixed record, it may never exceed the value of data block size, less seven bytes.
Length of I/O area, which you specifywith the BLKSIZE keyword parameter. It includes the 2-byte block header
length, plus the record length of each logical record in the block, plusthe 5-byte record pointer that must follow
each record It also includes such unused space as you have been unable to avoid

Figure 1O—4.

Layout of ISAM Data Blocks (Prime or Overflow) on Disk Each Containing Two Logical Records (Part 2 012)

Figure i0—5 is a schematic diagram of OS/3 ISAM’s method of chaining records in
logical sequence. The upper tier of records represents those placed intothe prime data
area by an initial load of the file in ascending order of record keys (keys being represented
by the numbers). After the initial lóäd, the record pointer that follows each record
contained the hexadecimal pattern FO AA AA AA AA, indicating that the next record in
physical sequence was also the next in logical sequence in the file. (The record pointer
after the record whose key is 750 still points in this way to the start of the one whose key
is 809, for example.) After the lower tier of four records was added (to the overflow area),
data management rewrote some record pointers as necessary to chain the new records
into their logical sequence. The record pointer following record 827 originally contained
the pattern pointing to record 902, which is the next record in sequence in the original file
and happens to be the first record in the next data block. After the addition of record 901,
data management rewrote this to point to the new record; the new record pointer
following 901 is now the one pointing to 902.

Figure 10—5. Schematic Diagram of ISAM Records Chained into Logical Sequence after Adding
Records to the File (Part 1 of 2)

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

10—il
Update A

LEGEND;
bh

Block header, a 2-byte field atthe head of each physicaldata block. Written by data management to indicate the
number of bytes in the block that are devoted to usable data.

Record pointer, a 5-byte field inserted by data management following each logical record written to a
data block. Originally, after initial load, contains hexadecimal pattern FO AA AA AA AA, pointing to next
sequential record in the file. Rewritten by data management as necessary to point to records “inserted”
by addition after initial load.

Logical records submitted by you in ascending order of keys. The top tier represents prime data records
submitted by an initial load; the lower tier representsfour records submitted by a subsequent operation, placed
in overflow, and chained into logical sequence by OS/3 ISAM.
Supplied by OS/3 ISAM

Unused space in physical data block
Figure 10—5. Schematic Diagram of ISAM Records Chained into Logical Sequence after Adding
Records to the File (Part 2 of 2)

10.2.21.

Calculating Space Requirements for the File

To calculate the number of cylinders required for data in an ASAM or ISAM file, you may
proceed as follows:
1.

Calculate r, the number of logical records per data block (r is an integer):
r

—

number of records to be loaded
r

Then calculate d, the tota number of data blocks (prime plus overflow):
d
—

(block size)
2 bytes
(average record size) + 5 bytes

From this, calculate b, the number of prime data blocks required for the initial ISAM
load:
b

—

100

—

lOOb
(percent overflow)

Calculate the cylinder capacity of the disk subsystem you are using:
cylinder capacity

(number of surfaces per disk unit) (track capacity)

The number of surfaces and the track capacity for the various disk subsystems are
shown in Table A—4.
5.

Calculate the number of data blocks of the desired size each cylinder can hold:
number of data
blocks each cylinder
can hold

cylinder capacity
block size

—0

10-1 2
Update A

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Finally, convert d into Cd, the number of cylinders required for data:
d
Cd= (number of data blocks each cylinder can hold>

10.2.3.

ISAM Index Blocks

The index area of your ISAM file is, as we stated previously, entirely devoted to 256-byte
index blocks, which are written for you on the index tracks by OS/3 data management.
The format of these blocks is shown in Figure 10—6; they contain keys and 3-byte
pointers to the prime data blocks and are hardware-searchable.
ISAM Index Block on a Fixed-Sector 8416 Disc

256 bytes

ISAM Index Block on a Variable-Sector Disc

HKJ (gap)

sum

1
P

1
K

256 bytes

LEGEND:
HK

High key of the block.

Pointer following the high key of the block

A 3-byte pointer to next level below

—

points to next level below

Unused space in index block
K are ascending keys, < HK
2
,
1
K
,
...Kn

Figure 10—6.

Format of Full OS/3 ISAM Index Blocks

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1O—12a
Update A

Note that all the entries are fixed-length and that the index block has no block header
field. If the final block of an index level happens to be a full block, it will have the form
shown in Figure 10—6, and the high key of the block will contain all 1 bits. If the final
block is not full, its form will differ in that the top entry with a key of all 1 bits will be
repeated between the last record pointer and the unused space. As a result, a scan of a
final index block in main storage will search only valid information; there is no possibility
of its running on into the spurious information contained in the unused space.
Each scan of index blocks in main storage begins at the K
1 position. In the ordinary full
block, the result may be a hit on or before K,,; if it is a miss, the search uses the PH
pointer to locate the next index block to scan.

UP-806& Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

10-13

Note that, like the ISAM data blocks, the index blocks may also contain unused space if
the sum of the key length (measured in bytes and uniform for every key in the file), plus
three bytes for the track or block pointer that follows each key, does not divide evenly into
256. If your keys are 40 bytes long, for example, you can fit only five of them (and their
accompanying 3-byte pointers) into 256 bytes and will have 41 unusable bytes left over. If
you are designing a file, therefore, and have some latitude in choice of key length, it is
wiser not to establish it arbitrarily, but to choose a key length that will give you the least
wasted space in the index blocks. Figure 10—7 recapitulates much of what has been
discussed so far: it shows the layout of an index partition and a data partition of an
indexed ISAM file as they appear on disk:
256 bytes

I I

1
K

LFhi

2
K

5
K

INDEXBLOCKON
FIXED SECTOR DISC

6
K

iTh___

2
P

INDEX
PARTITION

—

UP TO FOUR
TRACKS OF
TOP INDEX

0U1[]UL1L1LZU1E1EZUUE1UE1EZ
--

N H

SUM

1
r

1
P

3LK4

256 bytes

2
r

3
r

3
P

4
r

4
P
“-

Ui
DATA
PARTITION

ON VARIABLE

FORMAT OF
PRIME AND
OVERFLOW
BLOCKS

iThi_______________ui______

—

Prime Data Blocks

1U1
Overflow Blocks

Figure 10—7.

OS/3 ISAM File Structure (Part 1 of 2)

t0CR

]

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

10-14
Update A

LEGEND:
K

Record key

Pointer

Block header
Logical record
Unused space at block end

COCR Cylinder overflow control record; written by data management
System-supplied pointers, headers, and count fields on disk

Figure 10—7.

10.2.4.

OS/3 ISAM File Structure (Part 2 of 2)

Calculating Space for the ISAM Index Area

You may calculate your disk space requirements for the block index of your ISAM file by
the process shown below. Because the space needed to hold your index is inversely
proportional to the size of your data blocks, you should favor larger over smaller data
blocks when you design your file, to avoid excessive index space.
To calculate the number of cylinders (Ci) that your block index will need, you start with
your block size, the average size of your records (if they are variable), the total number of
records in your file, and the size of keys in the file. These are the five steps we suggest
you take; they can, of course, be compressed into one calculation:
1.

Calculate r, the number of logical records per data block (r is an integer, naturally):
r

—

total number of records to be loaded
r

Calculate e, the number of entries data management will make per index block (e is
also an integer):
e=

2
blocksize
+ 5
size
record
average

Calculate b, the number of prime data blocks you require:
b

256
keysize + 3

The next calculation gives i, the number of index blocks you will have:
b

UP-8068 Rv. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

10-15
Update A

Dividing this by the number of index blocks each cylinder may hold (a constant
depending on the disk subsystem) gives C
, the number of cylinders your block index
1
will require:
C
—

number of index blocks per cylinder

These are the numbers of 256-byte ISAM index blocks that each cylinder may hold on
the disk subsystems used by OS/3:
SPERRY UNIVAC
Disk Subsystem

Number of 256-byte
Index Blocks per Cylinder

8411
8414
8415 fixed
8415 removable
8416
8418
8424
8425
8430
8433

100
340
120
80
280
280
340
340
551
551

The foregoing calculations hold good for the second level of your ISAM index: the block
index. For a useful approximation of the disk occupied by the entire index (when there is
no intermediate index), you need add only the number of tracks that ISAM sets aside for
the first level, which is the top index: two tracks for an ISAM file residing on an 8415,
8416, or 8418 fixed sector disk, and four tracks for the variable sector 8411, 8414, 8424,
8425, 8430, and 8433 disks supported by OS/3.
The calculation of the amount of disk space actually occupied by your top index (without
the repetition pattern mentioned in 10.2.3) is more complex. Of course, you can readily
figure the maximums:

Disk Subsystem
on Which ISAM
File Resides

Maximum Number
of Tracks for
Top Index

Track Capacity
in 256-byte
Top Index
Blocks

Maximum Number
of Bytes for
Top Index

8411
8414
8415
8416
8418
8424
8425
8430
8433

4
4
2
2
2
4
4
4
4

10
17
40
40
40
17
17
29
29

10,240
17,408
20,480
20,480
20,480
17,408
17,408
29,696
29,696

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

10-16

However, these maximums are rarely reached in practice; few files require more than 3K
bytes for the top index.
The most convenient procedure for learning the size of the top index is to access
filenameS after issuing the ENDFL imperative macro that terminates the initial file load or
each subsequent extension of it (11 5.2.3). ISAM places the number of bytes required to
hold the top index of a file in main storage in this 2-byte field, which is half-word aligned
and addressed by concatenating the character “S” to your 7-byte file name. This is the
figure you need to know for subsequent random operations on your file, because you can
improve the speed of your keyed search operations (for add and retrieval) by providing
main storage space for some or all of the top index.

10.2.5.

Loading the Top Index into Main Storage

To speed random retrieval or record insertion operations in an ISAM file, you may specify
that data management is to place as much as possible of your top index in the index buffer
(INDAREA, 11.4.5) for subsequent search there. Doing so minimizes the hardware search
of this part of your index on disk; if you can allow enough space in main storage for the
entire top index, a search of it on disk is eliminated altogether. Only top index entries may
be brought into main storage.
As explained in 11.4.5, when you specify random retrieval operations, or record insertion
operations, or both, you may direct ISAM to bring your top index into main storage by
proper specification of the INDAREA and INDSIZE keywords.
When your ISAM file is first opened for random retrieval or record insertion, if you have
specified that your top index is to be brought into main storage, the OPEN transient
computes the number of top index blocks that can be held in a table of the size you have
specified with the INDSIZE keyword, reads this number of top index blocks (commencing
with the trailing block and working toward the start of the index), and transfers these
blocks to the INDAREA buffer. Although the top index blocks are not reformatted, ISAM
eliminates any unused space in each 256-byte index block. The appearance of your top
index in main storage is then as depicted in Figure 10—8. Notice that the part of your top
index that is in main storage always includes at least the last block, which contains the
high key (hexadecimal FF). Including this key guarantees that an equal/high comparison
will result when the index is searched in main storage.
The search of the index in main storage is initiated by a READ, KEY; ADD; or WRITE,
NEWKEY macro issued to the file. First, the search compares the key argument (KEYARG,
11.4.9) to the low key of the top index segment in the INDAREA table. If the argument is
equal to or greater than the low key of the INDAREA table, then a comparison is made
against the high key of each block of the top index in the table until an equal/high
comparison results. Then each entry in the block thus located is searched on an
equal/high basis, to isolate the index entry that corresponds to the key argument. The
search next turns to the block index on the disk (via the intermediate index, if one is
present on disk) and from there todirect access of the prime datablock sought.

3
K

1
K

Top Index Block

9
K

Top Index Block

2
K

‘

Top Index Block

1 0—i 7

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

‘

8
K

10
K

12
K

Top Index Block

11
K

14
K

13
K
13

Top Index Block 6

Top Index Block 5

Corresponding INDAREA Index Table in Main Storage,
Assuming IN DSIZE Specification Accommodates Three Blocks:
Block 2

Block 1

—

(Block 2)’I

Block 3

sr-I

LEGEND:
K

Record key

3-byte pointer to next index level below
Unused space in top index block on disc

Figure 10—8.

Blocks of an ISAM Top Index on Disk and Corresponding INDAREA Table in Main Storage

UP8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

10-18

Referring again to Figure 10—8 consider that the KEYARG field contains the key 135
The search follows the following logic
1.

10
K
10 low key of the INDAREA index table: KA > .
K
Compare KEYARG (KA) to ,
Therefore continue search in table.

12 high key of block 1: result low.
K
Compare KA: ,

15 high key of block 2 result high
Compare KA K

14 Search of INDAREA table in
Therefore search block 2 each entry result is hit on K
14 points to next lower level of index, on disk.
main storage is complete; P

On the other hand, if the key argument is lower than the low key of the INDAREA table,
the search moves the disk where a hardware search of the top index begins in the usual
manner as described in 10 2 The part of your top index that you have placed in main
storage is not searched again on disk.

10.3.

ALTERNATE SEQUENTIAL ACCESS METHOD (ASAM)

OS/3 ISAM provides the usual ISAM capabilities of retrieving sequentially or by key; and
provides the additional capability of retrieving by address. The coding necessarily includes
the simpler coding required for SAM processing and relative record DAM processing.
Therefore, it was not difficult to provide handling for unkeyed sequential files wherein the
index structure is omitted and keyed functions are avoided. This alternate sequential
access method is called ASAM.
Some of the reasons for using ASAM files are:
1.

A program is required to retrieve from a keyed file and from a sequential file. If these
are specified respectively as ISAM and ASAM files, the same data management
coding handles both.

Direct addressing into an essentially sequential file is desired, and ASAM handling is
found to fulfill the need.

It is desired to insert new data between records of a previously formed file, and to
retain direct access capabilities. The inserted data may be additional records of the
same nature as the original records, or they may be addenda to the record from
which they are chained.

The important things to remember about ASAM files are these:
No index or index space is provided; hence records may not be retrieved by key
search.
•

Records may be retrieved randomly (as in ISAM) by providing the record address that
was returned to you at the time the record was placed in the file. You must make
your own arrangements for retention of addresses; alternatively, you may calculate
addresses, if your records are of fixed size. In this case, remember that there is one
dummy record at file start.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

10-19

•

Any block may be retrieved by providing the 3-byte number, followed by the 2-byte
fiel.d containing binary 2 (the address of the first record of the block).

•

Sequential retrieval is the same as in ISAM except that the SETL, KEY and SETLG;
KEY imperatives cannot be used to start the sequence.

•

If records are not to be added, you may specify zero overflow space. Nevertheless, the
5-byte pointers will be appended to records.

•

It may be desirable to have prime records of one size and addenda of other sizes.
Remember that all records must have variable record formats, if there is to be any
variance in size.

•

In order to add records, you must provide ASAM with the address of the record that is
to be followed by the new record.

•

ASAM files will usually be defined as unkeyed. If keys are specified, ASAM will reject
duplicate and out-of-sequence keys during LOAD. When such checking is necessary,
you may save some coding by having ASAM do it

•

As in ISAM, you must use the SETL and ESETL imperatives to start and end a
sequential progression. While you are in sequential mode you may not perform
random functions

Figure 10—9 shows the logical aspect of an ASAM file in which not more than one
addendum record in overflow has been chained from the prime record to which it relate&
Because you may logically insert new records at any point in the ASAM file, it is possible
to subordinate or connect several addendum records in overflow to each prima data
record. A file you may structure this way may be of more interest or use to you than one
based on the one-to-one relationship suggested so far. If you add your new records to
overflow and provide ASAM with the address of the same prime data record for each of a
group of, say, three records that you want related to it, these are chained in the sequence
shown in Figure 10—10. The same chaining can be obtained by successive adds on three
separate occasions
a point to remember, therefore, is that when you retrieve these
sequentially, the order of retrieval is inverted. The last record of a string added to overflow,
chained from a given record, is the first retrieved.
—

This “last in, first out” (LIFO) retrieval sequence results automatically when you chain a
series of overflow records from one prime record and is satisfactory for some applications.
However, when you want some other order in sequential retrieval, you may set up the file
for this when you provide ASAM, for each new record, with the address of the record
(which may be overflow or prime) from which it is to be chained.
Note that there is no pushdown or relocating of records added to the overflow area; the
physical location of a new record blocked into overflow is not determined by the position of
the prime record from which it is chained nor by the relative location of other records
chained from the same prime record.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev4

10-20

To start of next
prime record

LEGEND:
bh

Block header, a 2-byte field written by data management at the head of each physical data block to indicate
the number of bytes of usable data in the block.

Record pointer, a 5-byte field inserted by data management following each logical record in the data block.
Those inserted following the prime records initially loaded into the ASAM file were originally dummied and
contained the hexadecimal pattern FO AA AA AA AA. This pattern indicated that no related record had been
added in overflow, chained from this prime record, and that the next record in logical sequence was therefore
the next in physical sequence. When the overflow records were added, data management rewrote the record
pointers following those prime records from which an overflow record was chained. The pointer following the
first prime record, for example, points to the start of its addendum record in overflow; the pointer after the
second prime data record (for which no overflow record was added) still contains the dummy pattern pointing
to the next sequential record, in the prime data area.

Logical data records, prime and overflow, provided by the user.

Supplied by OS/3 ASAM

Unused space in physical data block.

Figure 10—9.

Logical Aspect of an ASAM File Containing Not More than One Record Chained in Overflow from Any One
Prime Data Record

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

10-21

RESULT OF FIRST ADD
Prime Data Area

first
prime data
record

next
prime

j
Overflow Area

first addendum
chained from
first prime

unrelated to
first prime

RESULT OF THIRD ADD:
Prime Data Area
bh

first
prime data
record

—

next
prime

Overflow Area

first addendum
chained from
first prime

—

unrelated to
first prime

second addendum
chained from
first prime

third addendum
chained from
first prime

4
Figure 10—10. Logical Effect of Successively Adding Three Records in Overflow, Chained from Same Prime Data Record of
an ASAM File

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

10.3.1.

10-22

ASAM Data Formats

The formats of the ASAM data records and data blocks are the same as in OS/3 ISAM,
and separate figures of those for ASAM are not necessary. Figures 10—2, 10—3, and
10—4 illustrate both keyed and nonkeyed records. Bear in mind, when you review these
figures for ASAM, that you will be most likely to omit record keys when you want to omit
the construction and use of an index structure. If you key in your ASAM file, your records
will look like the keyed examples illustrated.
10.4.

MULTIVOLUME ISAM FILES

You may split an ISAM file across several disk volumes. It is important to remember that
all volumes of a multivolume ISAM file must be mounted online for all file processing.
During your load operations, data management monitors continually to ensure that it does
not exceed the prime data area you have allocated. If your load fills the prime area of a
volume, data management continues the load onto the succeeding volume, if there is one.
If there is no other volume, it seeks additional space on the current volume and notifies
you if there is no additional space available. When you terminate the load, data
management saves the progress point for later use if you should extend the file.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11.1

11-1

Functions and Operation of ISAM

GENERAL

In the previous section, the discussion of the OS/3 indexed sequential access method
(ISAM) aimed primarily at describing file organization, data record and data block formats,
and the format of the index blocks in the index structure that is characteristic of the
traditional ISAM file. The salient feature of processing an ISAM file that you have
constructed with a directory or index structure is the search-by-key function, which is
used to retrieve your records by key.
We also pointed out the option for creating a nondirectory ASAM file, in which your
records need not be keyed, and for which data management builds no index structure.
Accessing records directly without use of an index is accomplished by providing record
pointers, rather than keys. Sequential processing of either type of ISAM file is essentially
the same. In our discussion of the structure and content of 05/3 ISAM files, we gave you
a certain insight into the means OS/3 provides for processing them.
This section builds on that foundation, presenting first an overview of OS/3 ISAM
functions. It then presents a declarative macroinstruction, DTFIS, of a specific type, with
which you define your file to OS/3 data management and outline to OS/3 ISAM some of
your intentions for processing it. The DTFIS macro establishes a file control table that data
management uses, during its processing of your file, to keep you and itself informed of the
characteristics of the file and the results of processing. (Both the macro and the file table
it creates are frequently termed the “DTF,” from the initials of the phrase define the file
we use to distinguish this type of declarative macro from others.)
You describe significant characteristics of your ISAM file, and provide OS/3 data
management with certain particulars it needs for processing it, by means of some 27
keyword parameters that you specify as operands of the DTFIS declarative macro. Two of
these keywords, which provide the size and symbolic name of the input/output area (or
I/O buffer) that every OS/3 data management file needs for its exclusive use, are always
required. Most of the other keywords are mandatory under certain conditions or for certain
processing functions. Others you wili specify entirely at your option. The greater part of
the DTFIS macro discussion concerns its keyword parameters.

UP-8068 Rev. 4

SPERRY UNIVAC 0S/3
BASIC DATA MANAGEMENT

11-2
Update A

Following the detailed descriptions of the keywords, this section then presents the set of
12 imperative macroinstructions that make up the OS/3 data management repertoire for
processing your ISAM files. Each macro is detailed individually, and the discussion of each
one points out any way in which your use of it will change when you use it with the
indexed form or the nondirectory form of OS/3 ISAM.
Next, we explain the methods you have of linking your program to the OS/3 ISAM
processing modules. An explanation of OS/3 ISAM’s system for handling error and
exception conditions follows this, and recapitulates certain points made during
descriptions of the imperative macros. A number of programming examples conclude the
section.
11.2.

FUNCTIONAL DESCRIPTION, OS/3 ISAM

Perhaps the best way to obtain a quick overview of the functions for which OS/3 ISAM
has been designed is to look at the imperative macros you will issue in your basic
assembly language (BAL) program to process your ISAM files. But, before studying each of
these macros in detail (they are described fully in 11.5), it may be more useful to consider
their functional groupings; these are discussed in the next two paragraphs.
11.2.1.

—0-

Processing an Indexed ISAM File

As you have noted in Section 10, OS/3 ISAM is provided primarily to enable you to
organize and process disk files from which you will have frequent need to retrieve records
directly by key, but for which sequential processing is also important to you. ISAM
facilitates the search-by-key function by providing a key-based index structure; it
implements this function through a repertoire of key-related imperative macros. OS/3
ISAM also provides you with a set of imperatives for sequential processing. Table 11—1
lists the imperatives available for processing an indexed ISAM file. The imperative macro
calls are grouped in sets according to functions and are repeated to point out that some
are used in more than one setting. Note that those you would expect to call many times in
your BAL program have been indented in the list to identify them. (The name of the ISAM
possibly a master file of employees at some
file in the illustration is “EMPLMST”
installation.)
—

UP-8068 Rev. 4

SPERRY UNIVACOS/3
BASIC DATA MANAGEMENT

11-3

Table 11—1. Imperative Macro Calls for Processing an OS/3 ISAM File with an Index Structure, Listed by Functions

Imperative Macro Calls

Functions
Initiating and Terminating
Processing of the File

OPEN
CLOSE

Loading or Extending
the File

SETFL
ENDFL

EMPLMST
EMPLMST
EMPLMST
WRITE EMPLMST, NEWKEY
EMPLMST

Inserting New
Records

WRITE EMPLMST, NEWKEY
WAITF EMPLMST

Random Processing.
Retrieval and Updating
if WRITE is used

READ EMPLMST, KEY
WAITF EMPLMST
READ EMPLMST, ID
WAITF EMPLMST
WRITE EMPLMST, KEY
WAITF EMPLMST
(BOF
KEY
EMPLMST,
GKEY
)
“ID
GET EMPLMST, (0)
PUTEMPLMST
EMPLMST

Sequential Processing.
Retrieval and Updating
if PUT is used

SETL

;

ESETL

NOTES:

11.2.2.

The ADD imperative macro is equivalent to the WRITE,NEWKEY
macro for inserting new records.

The UPDT imperative macro is equivalent to the WRITE,KEY macro
for random updating.

Processing an ISAM File without an Index Structure

When you specify a nondirectory ISAM file, you can no longer locate records by presenting
a key to data management. Three of the standard imperative macros are no longer
available to you:
READ, KEY
SETL, KEY
SETL, GKEY
Otherwise, the function repertoire is the same. Despite the fact that keys are not used,
some macro calls retain the KEY operand.
The WRITE, KEY macro, for example remains available to you for inserting a trailer record
in overflow, but you provide this macro with the relative address of the header record from
which the trailer depends, not its key.
Sequential processing is the same as for indexed files, except that no index is available for
selecting the starting point for a sequential retrieval sequence. Here again, you will
provide a relative record address to the SETL macro.

11-4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4.

Table 11—2 lists the calls for the imperatives available for processing a nondirectory ISAM
file. The calls are grouped in sets according to functions and, as in Table 11—1, are
repeated to indicate that some operate in more than one setting. Those calls that you
should expect to use many times in your BAL program are indented to identify them.
(Again, the 7-character file name ‘of the nondirectory ISAM file ‘being processed in the
illustration is “EMPLMST.”)
Table 11—2.

Imperative Macro Calls for Process/hg a Nondirectory OS/3 ISAM File without an Index Structure, Listed by
Functions

Imperative Macro calls

Functions
Initiating and Terminating
Processing of the File

OPEN
CLOSE

Loading or Extending
the File

SETFL

‘

“

ENDFL

‘

EMPLMST
EMPLMST
EMPLMST
WRITE EMPLMST, NEWKEY
EMPLMST

Adding Trailer
Records

WRITE EMPLMST,NEWKEY
WAITF EMPLMST

Random Processing.
Retrieval and Updating
if WRITE is used

READ EMPLMST, ID
WAITF EMPLMST
WRITE EMPLMST, KEY
WAITF EMPLMST

Sequential Processing,
Retrieval and Updating
if Put is used

{B0F}

SETL

EMPLMST,

ESETL

GET EMPLMST, (0)
PUT EMPLMST
EMPLMST

NOTES:
1.

The ADD imperative macro is equivalent to the WRITE,NEWKEY
macro for inserting new records.

The UPDT imperative macro is equivalent to the WRITE,KEY macro
for random updating.
‘

11,2,3,

Deleting Records from an ISAM File

A function for which OS/3 ISAM does not provide you a specific imperative
macroinstruction is record deletion. However, to help you in this aspect of managing a file,
OS/3 ISAM establishes a 2-byte field in the DTFIS file table (half-word-aligned) in which
your ‘program may keep a count of the number of records you have tagged for deletion.
You may address this field, which is available for the life of the file, by concatenating the
character ‘7” to your 7-character file name; this field will be termed filenameT in this
manual.
‘

‘

You, of course, must establish your own convention for tagging records in your file that
are to be deleted; there is no field in the OS/3 ISAM data formats dedicated to this use
(nor, if you recall, does OS/3 ISAM provide for user file labels in which you might record
deletion statistics instead of using fl/enamefl
,

‘

UP-8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11-5

Because tagging a record for deletion will most likely be part of a rewrite operation (for
which you issue the WRITE, KEY macro), it would be logical also to increment the count in
filenameT either before or after the rewrite operation. Because your count of records you
have tagged for deletion is always available to you in the DTF, you can access it as an aid
in deciding when to reorganize your ISAM file.
Thereis no way to avoid retrieving recordsyou have tagged for deletion; they will always
be read by a READ or GET imperative macro. For this reason, to tag reôords that. you have
decided should be removed from the file is an important part of your processing them. You
should, of course, also. provide in your program for checking against the presencepf this
flag whenever you retrieve a record

UP8O68 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 1—6

DTFIS
11.3.

DEFINING AN OS/3 ISAM FILE (DTFIS)

In order to process a file by OS/3 ISAM, you must define it to data management by
issuing the DTFIS declarative macro in your BAL program. (The macro call is derived from
the phase define the file for indexed sequential.)
The symbolic name of your file (filename) may contain no more than seven characters and
must begin with an alphabetic character. This file name is also used by the OS/3 [SAM
imperative macros to identify the file to be processed. It must be the same as the file
name you have included in the LFD statement in the device assignment set of OS/3 job
control statements by which you allocate the file. (See the job control user guide, UP-8065
(current version) for the details of OS/3 job control statements.)
The DTFIS declarative macro generates a file table that data management uses to keep
itself and you informed of the characteristics of the file and of the results of your
processing it with the ISAM imperative macros. The DTF generator assures that the file
table is automatically aligned on a full-word boundary. The size of this file table varies
according to the processing to be performed (which you may specify via the IOROUT
keyword parameter, 11 .4.8):
DTF File Table Size,
in Bytes

IOROUT Specification

332
372
396
396

LOAD
RETRVE
ADD
ADDRTR

As you execute each imperative macro, data management places an informative reply,
indicating normal completion or exceptions (including unrecoverable error conditions) in a
special field of the DTF file table. If you have not provided an error exit, you must
remember to access this field when control returns inline to you after execution of each
imperative.
You address this field (called filenameC) by concatenating the character “C” to the name
of your file. Some of the imperative macros also pass information to you in other special
fields of the DTF file table, which you may address similarly by concatenating a specific
character to your file name (details are given for each macro separately in 11 .5, and these
are recapitulated in 11 .7). Because the maximum length for symbolic names throughout
OS/3 is eight characters, data management therefore limits you to a maximum of seven
for file names.
In addition to the file table just mentioned, the DTFIS declarative macro also generates
certain references so that you may link a BAL program with a DTFIS file table you have
generated in a separate assembly:
An ENTRY definition for filename. You must specify a corresponding EXTRN definition
for filename within your program.

UP-8068 Rev. 4

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

11—7

An EXTRN definition for each symbolic name you have supplied with certain of the
DTFIS keyword parameters described in what follows. You must specify a
corresponding ENTRY definition for each of these symbolic names.
Following is a listing of the required and optional keyword parameters you will specify as
operands of the DTFIS declarative macroinstruction. These are listed here in alphabetic
order, but you may specify them in any convenient order, just so you separate them with
commas. The paragraphs following this format statement discuss the use of each keyword
parameter, and a table summarizing the keywords follows the descriptions.
Refer to the preface of this manual for OS/3 data management format statement
conventions and to 1 .6.3 for rules concerning continuation of statements. A comma is
shown preceding each keyword parameter except the first, to remind you that all keywords
coded in a string must be separated by commas. However, a comma must neither be
coded in column 16 of a continuation line, nor follow the last keyword in the string. Refer
to the coding examples which follow.
Format:
LABEL

filename

AOPERATIONA

OPERAND

DTFIS

EXC
EXCR
SRD
SRDO
BLKSlZE=n
[,E R RORsymboll
[,l NDAR EA=symbol]
[,INDEXED=NO]
[,INDSIZEn]
,IOAREA1=symbol
[,IOAR EA2symbol]
[,IOREG(r)]
flOROUT= LOAt
ADD
RETRVE
ADDRTR
L

I
I

[,KEYARG=symbol]
[,KEYLENn]
[,KEYLOCnJ
[,LOCK=NoJ
[,PCYLOFLnnJ

11-8
Update A

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

LABEL

filename

OPERAND

LOPERATIoN

DT F IS

(cont)

[REC FORM=$FIXBLK
1VARBLK

[

[,R ECSIZE=n]
[,SAVAR EAsymbol]
[TYPEFLE=

( RANDOM
RANSEQ

(SEciNTL

[,UPDATE=NOJ
[,VERI FY=YES]
[,WOR K 1 =symboll
[,WOR KS=NO]

11.4.

DTFIS KEYWORD PARAMETERS

The following is a discussion of the use of each of the keywords that you may specify as
operands of the DTFIS declarative macroinstruction; the discussions are arranged
alphabetically for ease of reference. Table 11—3, following these descriptions, summarizes
all of the keywords.
11 .4.1.

4’

Specifying File Accessing Options (ACCESS)

of
In a multitasking environment, the file lock feature can prevent the loss or destruction
read/write
the
(specify
data. This feature allows you to control the sharability
requirements) of a file while you are using it. This feature only applies to those files you
in
specified as lockable. The procedure for specifying which files are lockable is described
16.1.4.
You can specify the sharability of a lockable file by using either the ACCESS or LOCK
keyword parameter (11 .4.1). It is recommended that you use the ACCESS parameter
because it provides greater flexibility (more read/write options available) than the LOCK
DTF
parameter. If both the ACCESS and LOCK parameter are specified in the same
macroinstruction, the ACCESS specification will override the LOCK specification.

Keyword Parameter ACCESS:
ACCESS=EXC
Specifies exclusive read/update/add use of the file. No other jobs can access the
file while it is being used.
NO TE:
This specification is equivalent to the default value for the LOCK parameter; that is,
LOCK=NO is omitted.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11-9
Update C

ACCESS=EXCR
Specifies read/update/add use of the file and also allows other jobs to read from
the file while it is being used. (Only ACCESS=SRD can be specified for other
jobs.>
ACCESS=SRD
Specifies that only the read function is allowed for the file and allows other jobs
read/update/add use of the file. (Only ACCESS=EXCR, SRD, or SRDO can be
specified for other jobs.)
ACCESS=SRDO
Specifies that only the read function is allowed for the file and also allows other
jobs to read from the file. Writing to the file is not allowed from the job
associated with this DTF or from other jobs. (Only ACCESS=SRD or SRDO can
be specified for other jobs.)
11.4.2. Specifying Size of Data Blocks (BLKSIZE)
To specify the size of the physical data blocks in your ISAM file, you must supply this
required keyword parameter in your DTFIS declarative macro. (See 10.2.2 for a discussion
of ISAM data block formats; these are shown in Figure 10—4.)
Keyword Parameter BLKSIZE:
BLKSIZE=n
Specifies the size of the blocks in the file, where n is the size in bytes. This
keyword is always required. Size may not be less than 256 bytes nor exceed
the track size for the disk subsystem on which the file resides:
SPERRY UNIVAC Track Size,
Disk Subsystem in Bytes
8411
8414
8415
8416
8418
8424
8425
8430
8433

3625
7294
10,240
10,240
10,240
7294
7294
13,030
13,030

When you specify fixed-length records (by default, or by specifying
RECFORM=FIXBLK), your BLKSIZE specification n should equal record size + 5 bytes,
multiplied by the number of records per data block, adding two bytes for the block
header. The block size need not be the same as your I/O buffer allocation, which may
be specified with a define storage (DS) statement elsewhere in your program, but it
must not exceed the length of the buffer.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP8068 Rev. 4

11-10

When 841 5 disks are used, the ISAM blocksize is restricted. For each cylinder, ISAM
requires at least two blocks of space reserved for overflow. The following algorithm
calculates b, the total number of overflow blocks per cylinder:
b

blocks per track x tracks per cylinder

A minimum of one block per track may be specified and two tracks per cylinder (841 5
removable) or three tracks per cylinder (8415 fixed). The number of blocks per cylinder is
then multiplied by the percentage of overflow (maximum 80%) and rounded up to the next
integer value. If less than two, the resulting overflow block count is set to 2. The overflow
block count is then subtracted from the total number of blocks per cylinder to calcUlate d,
the data blocks per cylinder, a value which must be nonzero.
d

—

overflow block count

When applied to the 841 5 disk (fixed or removable) the algorithm for calculating number of
overflow blocks per cylinder (b) can result in a value identical to the total number of blocks
per cylinder, thus leaving no space for data. If this óondition occurs, the OPEN imperative
macro generates the message DM61 INVALID DTF FIELD PARAMETER OR PARAMETER
COMBINATION. This restriction condition can occur only with large block sizes (one or two
blocks per track) and large overflow percentages (70 to 80%).
1 1.4.3.

Specifying Your Error Exit (ERROR)

When a fatal hardware or detectable logic error occurs on an ISAM file, or an exception is
detected to exact performance of the function you have requested, data management
returns control to your error-handling routine, if you have coded one and provided its
address with the ERROR keyword parameter. If you have no error routine, control returns
to you inline, at the instruction in your program next after the imperative macroinstruction
that initiated the transfer of control.
It is your responsibility to interrogate the error/status codes and take appropriate action. If
you choose to continue processing, it is useful to know that data management provides
you an inline return address in register 14; this iljne return is to the instruction in your
program next following the imperative macro that initiated the transfer of control to your
error routine.
When 05/3 data management transfers control, the addressable field filenameC in the
DTFIS file table contains information on the reasons for the error. (See 11.7 and Appendix
B.)
Keyword Parameter ERROR:
ERRORsymbo[
Specifies the address of your errorhandIing routine, to which data management
transfers control for all conditions of error or exception to exact performance of
the function you have requested. When data management transfers control,
filenameC contains information on the reasons for the error.
If omitted, control returns to you inline.

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

11.4.4.

1 1 -1 1

Describing an Index Area in Main Storage (INDAREA, INDSIZE)

This pair of keyword parameters is required when you are loading an indexed file but
optional at other times (It is not used when your file is a nondirectory ASAM file and has
no index) You specify a main storage location into which ISAM may load part of your top
index by the INDAREA keyword and you specify the length of this area in bytes with the
INDSIZE keyword. Like the I/O area, your index area must always be half-word aligned.
For loading operations, the length of the index area must always be at least 256 bytes
because ISAM uses this space to create the 256-byte index blocks as loading proceeds.
(See 10.2.3.)
An optional OS/3 ISAM facility, by which ISAM places all or part of the top index in main
storage to speed random retrieval or record insertion, may be invoked by specifying the
INDAREA and the INDSIZE keywords under the following conditions:
‘

The KEYARG and KEYLEN keywords are also specified (11.4.9, 11.4.10).

•

IOROUT=ADD, IOROUT=ADDRTR, or IOROUTRETRVE is also specified (11.4.8).

•

TYPEFLE=RANDOM or TYPEFLE=RANSEQ is also specified (11.4.15).

The INDSIZE, INDAREA, and KEYLEN parameters define the size and address of the index
buffer and the amount of the top index that may be brought into main storage
automatically when the file is opened. ISAM determines the size of the top index table
entries from the length of keys specified by the KEYLEN keyword and ensures that the
length of the INDAREA table (specifiedby the INDSIZE keyword) will accommOdate at least
one block of top index entries. If your INDSIZE specification is less than this minimum,
your attempt to invoke this facility is negated, and appropriate diagnostic messages are
printed in the DTFIS macro expansion in your assembly listing. ISAM automatically rounds
your INDSIZE specification down to an integer multiple of oneblock of top index entries.
To ascertain the total number of bytes actually required to hold the entire theentire top
index in table form in the INDAREA buffer, you may access filenameS ih the DTF on
completion of a file load sequence; refer to 10.2.4.
For a description of the operation of the ISAM index-in-main-storage facility, refer to
10.2.5.
Keyword Parameter INDAREA:

I NDAREA=symbol
Specifies location in main storage in which ISAM builds index blocks during load
operations, or where ISAM places top index table for random retrieval or record
insertion, where symbol (address) is the location, Must be haIfwórd aligned.
Required for load operations; optional for others. Length of area specified by
INDSIZE keyword.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

1 1-1 2

Keyword Parameter INDSIZE:
INDSIZEn
Specifies length of index area in main storage where n is the length in bytes
For load operations the length must be at least 256 bytes excess space is
unused For random processing length greater than 256 bytes is optional ISAM
ensures that INDAREA accommodates at least one block of top index entries
(three bytes greater than KEYLEN specification).
11.4.5.

Eliminating the Index Structure (INDEXED)

This keyword is used when you want to eliminate construction of the ISAM index
structure
Keyword Parameter INDEXED:
INDEXED=NO
Specifies that you have elected the option to create a nondirectory ISAM file and
to reference its records by relative addresses, rather than by keys. Data
management does not construct the index; key-based processing functions are
inoperative.
If omitted, the index structure is provided.

11.4.6.

Specifying I/O Buffers (lOAREA1, IOAREA2)

All ISAM operations require at least one I/O area half-word-aligned and at least 256
bytes in length. You specify its address with the IOAREA1 keyword. You may specify a
second area, of equal size, which must also be aligned on a half-word boundary, with the
optional IOAREA2 keyword. To do so will increase the speed of your processing; you will
notice that the benefits are more pronounced for load and sequential retrieval than for
random operations.

Keyword Parameter IOAREA1:
IOAREA1 symbol
Required to specify location of input/output area, where symbol (address) is the
location. Must be half-word aligned. Length must equal or exceed the number of
bytes specified with BLKSIZE keyword.
Keyword Parameter IOAREA2:

IOAREA2=symbol
Specifies location of optional additional input/output area, where symbol
(address) is the location. Must also be half-word aligned and will be same size as
the required area specified by the IQAREA1 keyword. You may improve the speed
of sequential I/O operations if you specify this keyword.

UP-8068 Rev. 4

11.47.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1113

Specifying Current Record Pointer (IOREG)

When you are referencing your records in the I/O areas rather than in the work areas,
you need to specify a general register to be used to point to the current I/O area.
Registers 2 through 12 are always available; if you have specified the SAVAREA keyword
parameter, general register 13 is also available. (See 11.4.18 for details on the use of
record work areas.)
Keyword Parameter IOREG:
IOREG(r)
Required to specify the general register to be used to point to the current I/O
area when you are not referencing records in the work areas, where r is the
number of the general register. Registers 2 through 12 are available, and register
13 is also available if you have specified the SAVAREA keyword.

11.4.8.

Specifying the Type of File Processing (IOROUT)

You may specify the type of processing to be performed on your file with the optional
IOROUT keyword; this parameter has four forms. Note that you may also specify the type
of retrieval with the TYPEFLE keyword (11.4.15).
A file-loading operation (IOROUT=LOAD) may end with the final data block only partly full,
When this occurs, data management stores the exact location of unused file space in the
disk volume table of contents (VTOC) for later recovery and use as needed.
You may add records (IOROUT=ADD) with keys higher than the final prime data record,
which is contained in the data block marked as the logical end of file. As data
management places these in overflow, they do not affect the location of unused prime
space.
If you should introduce new records by resuming load operations (IOROUTLOAD), these
must be submitted in ascending order of keys; all must have higher keys than the current
highest key (whether in a prime record or an overflow record already on disk).
If you add enough records to an ISAM file, some cylinder ovef low space will become filled,
and data management will be unable to place added records on the cylinder where they
belong. When this occurs, data management resorts to using space on the earliest cylinder
having available overflow and adds records at the earliest possible point of the following
sequence:
1.

On the cylinder reached by prime search

On the cylinder having the current COCRS*

On a cylinder newly set as having the COCRS (discovered by progressing through
COCR blocks to one showing space available)

*The COCRS is a special cylinder overflow control record that data management writes and maintains in the DTF and
VTQC to control remaining overflow space on the cylinder that is currently used to accept overflow records from other
cylinders.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

11-14

Keyword Parameter IOROUT:
IOROUT=ADD
Specifies that new records are to be inserted into a file. You may not specify the
ADDform of this keyword unless you have allocated an overflow area with the
PCYLOFL keyword parameter (11.4.12).
IOROUT=ADDRTR
Specifies that new records are to be inserted in the file and that records will also
be retrieved and updated randomly or sequentially. You may not specify the
ADDRTR form of this keyword unless you have allocated an overflow area with
the PCYLOFL keyword (11 4 12)

I OR OUT=LOAD
Specifies that either a new file is tO be created or an existing file is to be
extended. ISAM assumes that the LOAD form has been specified if you omit the
IOROUT keyword parameter.
IOR OUT=R ETRVE
Specifies that your records are to be retrieved or updated randomly or
sequentially.
If omitted, IOROUT=LOAD is assumed. Type of retrieval may be specified with the
TYPEFLE keyword (11 4 15)

11.4.9.

Specifying Location of Retrieval Search Argument (KEYARG)

Whether yoU are referencing records by key (as when you are using ISAM with the index
structure) or by relative address (as with the nondirectory form of ISAM), you need a field
in which to present data management either with the key it is to match by the search-onkey function or with the relative disk address at which it is to access your record directly.
You specify this field with the KEYARG keyword parameter.
You should avoid presenting ISAM with either the address or the all-zero key of the
dummy record at file start as a search argument. The dummy record is not available for
you to use, and efforts to retrieve or overwrite it result in the error processing described
under the variousimperative macros involved.You may, on the other hand, safely specify
an all-zero key in the KEYARG field when you issue the SETL, GKEY imperative: data
management prepares to give you the first record after the dummy, and no error
processing results.
The length of the KEYARG area will be five bytes when you use it only for relative
addressing, but it must equal the actual length of the keys in your records (specified by the
KEYLEN keyword) when you are using the indexed form of ISAM. You may omit the
KEYARG keyword parameter when you are not retrieving records.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11-15

Keyword Parameter KEYARG:
KEYAR Gsymbol
Specifies the field in your program where you will place addresses or keys to
effect retrieval of your records, where symbol (address) is the location in this
field. The length of the KEYARG area is five bytes when you use it for relative
addressing and equal to key length (KEYLEN keyword parameter) otherwise. May
be omitted when you will not retrieve records.

11.4.10.

Specifying Length and Location of Records Keys (KEYLEN, KEYLOC)

When your records have keys (as they must when you use the indexed form of ISAM, and
may when you are using the nondirectory form), all keys in the file must have the same
length, and every record must have a key. The key need not begin at the head of the
record; it may be internal to the record, in fact, but the starting place for the key must be
the same in every record. The minimum length for a key is 3 bytes; the maximum is 253.
Each key must be unique. No byte of any record’s key may contain the hexadecimal value
FF, nor may any of your keys duplicate the all-zero key or the dummy record that ISAM
creates and inserts at the start of the file.
You specify the length of the key in bytes with the KEYLEN keyword parameter and the
number of bytes of data that precede the key with the KEYLOC keyword. You must specify
the KEYLEN parameter for an indexed ISAM file; you need not specify it for a nondirectorty
file unless you want ISAM to check the sequence of your keys during the load operation
(remember that sequence checking is done automatically only when you are loading your
records for an indexed ISAM file, to which you present them in ascending order of keys).
You need not specify the KEYLOC keyword if the key is at the head of the record. When
you omit this keyword, ISAM assumes that you have specified KEYLOCO for fixed records
or KEYLOC=2 for variable records (each of which, as you recall, contains its record length
in the leading two bytes).
Keyword Parameter KEYLEN:
KEYLENn
Specifies the length of keys in an ISAM file, where n is the length in bytes. All
keys in an ISAM file must have the same length; the minimum length is 3 bytes,
and the maximum is 253. Required for indexed ISAM files; optional otherwise. If
specified for a nondirectory ISAM file, causes data management to check
sequence of keys during a record load.
Keyword Parameter KEYLOC:
KEYLOCn
Specifies the number of bytes that precede the key of an ISAM record, where n
is this number. The location of the keyfield must be the same within all records
of the file.
If omitted, ISAM assumes that you have specified a value of zero for fixed records or
two for variable records.

UP-8068 Rev. 4

SPERRY UNIVAC 0S/3
BASIC DATA MANAGEMENT

11-10

Update A

11.4.11. Suppressing a File Lock (LOCK)
As we mentioned earlier, there are two ways to specify the sharability of your disk files. We
have already discussed the ACCESS keyword parameter and now we will discuss the other
way: that is, the LOCK keyword parameter.
Two options are available with the LOCK parameter:
1.

The file is exclusively locked when it is opened during the execution of your program.
You have exclusive use of the file. You can read, update, and add to the file. No other
user can open the file until you close it.

A read-only lock is applied to the file when it is opened. You can only read from the
file and all other uses can only read from the file.

Keyword Parameter LOCK:
LOCK=NO
This is equivalent to specifying ACCESSSRDO. It should not be used in the
same DTF as the ACCESS keyword parameter. If it is, the ACCESS keyword
parameter will override it,
If you omit both LOCKNO and the ACCESS keyword parameter, this is equivalent to
specifying ACCESS=EXC.

1 1.4.12.

11-17

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Providing Cylinder Overflow Area (PCYLOFL)

For both the indexed and the nondirectory ISAM file, you specify the
space of each cylinder that data management is to reserve for overflow
keyword parameter. You will recall that it is to the overflow area that
writes records added after your Initial load The maximum percentage

percentage of the
with the PCYLOFL
data manàgèment
is 80

If you specify a zero value or if you omit the PCYLOFL keyword altogether, you may not
add records to the file; any you attempt to insert will be rejected.
Keyword Parameter PCYLOFL:

PCYLOFLnn
Specifies the percentage of each cylinder that data management is to reserve for
overflow, where nn is the percent. The value of nn may range from 00 through
80. If you specify PCYLOFLOO, records presented later for insertion will be
rejected.
If omitted, data management assumes thatyou have specifiedPCYLOFL=00.
11.4.13.

Specifying Record Size and Format (RECFORM, RECSIZE)

Records in an ISAM file are fixed or variable in length and are blocked by data
management. You may specify the format with the RECFORM keyword parameter; if your
records are fixed length, you must specify this length with the RECSIZE keyword. All fixed
records must have the same length in an ISAM file.
Keyword Parameter RECFORM:

RECFORM=FIXBLK
Specifies that your records are fixed-length, blocked. You must also specify the
RECSIZE keyword.
RECFORM=VARBLK
Specifies that your records are variable-length, blocked. You do not specify the
RECSIZE keyword.
If omitted, data management assumes that you have specified RECFORMFIXBLK,
and you must specify the RECSIZE keyword parameter.
Keyword Parameter RECSIZE:

R ECSIZE=n
Specifies the length of fixed records, where n is this length, measured in bytes.
Required for fixed-length records only; must be specified if you omit the
RECFORM keyword. Not used for variable records.

SPERRY UNPJAC OS/3
BASIC DATA MANAGEMENT

UP8O68 Rev.4

11.4.14.

11-18

Specifying a Save Area for Contents ofGeneral Registers (SAVAREA)

Before you issue an imperative macro for processing any OS/3 data management file, you
may first load general register 13 with the address of a 72-byte labelled save area
in which data management will expect to save
always aligned on a full-word boundary
the contents of your registers If you do not want to provide this information with every
call, you may place the location of the save area in the DTF file table by specifying the
SAVAREA keyword. Refer to 1.4 for the content of this area.

—

Keyword Parameter SAVAREA:
SAVAREAsymboI
Specifies the address of a 72-byte labeled save area for the contents of general
registers full-word-aligned where symbol (label) is the address Used only when
register 13 is not loaded with save area address before each issue of imperative
macros to the file.
If omitted, data management assumes that you have preloaded register 13 with
address of a save area before issuing each imperative.

11.4.15.

Specifying the Type of Retrieval (TYPEFLE)

When you are performing retrieval operations on your ISAM file, indexed or nondirectory
(and therefore have specified IOROUT=RETRVE or IOROUT=ADDRTR (11 4 8)) you may
specify the type of processing (random or sequential) with the TYPEFLE keyword
parameter You do not use the TYPEFLE keyword unless you are retrieving records
Keyword Parameter TYPEFLE:

TYPEFLE=RANDOM
Specifies that random (direct) retrieva[ operations are to be performed.
TYPE FLE=SEQNTL
Specifies that sequential retrieval operations will be performed.
TYPEFLE=RANSEQ
Specifies that both random and sequential retrieval will be peformed.
If omitted data management assumes that you have specified WPEFLESEQNTL Not
used unless records are to be retrieved. IOROUTRETRVE or IOROUTADDRTR must
also be specified (11.4.8).

UP8O68 Rev.4

11 4 16

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11-19

Forestalhng Use of Update Functions (UPDATE)

When you want to avoid the possibility of inadvertently writing to anISAM file thatyou
intend to be a read-only file, you may specify the UPDATE keyword parameter in the DTFIS
macro This keyword sets a bit in the DTF file table that causes data management to set
the invalid macrd error flag (byte 0, bit 6) in filenameC if you should issue a PUT or WRITE
imperative macro to this file, and you then may take no action on the file other than to
close it (See Appendix B)
Keyword Parameter UPDATE:

UPDATE=NO
Specifies that data management is to flag a subsequent issue of the PUTor
WRITE macro as an invalid macro (byte 0, bit 6 of filenameC); no further
reference to the file, other than to close it, is possible.
If omitted, the possibility of inadvertent updating of the file is not forestalled.

11.4.17.

Specifying Parity Check of Output Records (VERIFY)

When you need data managemeht to make a parity check of your records after it has
written each one to disk you must specify the VERIFY keyword parameter; otherwise, no
check reading will be done. You should remember that specifying a parity check will
necessarily increase the execution time required for the PUT and WRITE macros byabout
one rotation period per block. You must weigh this overhead against the advantage of
immediate notification of problems within your file.
Keyword Parameter VERIFY:

VERIFY=YES
Specifies that data management is to check parity of output records after they
have been written to disk. Necessarily increases execution time for PUT and
WRITE macros. If bad parity is detected, data management sets output parity
check flag (byte 2, bit 2) in filenameC and transfers control to your error routine
or to you inline.
If omitted, no oUtput parity verification will be done

11.4.18. Specifying Location of Record Work Areas (WORK1, WORKS)
For loading and adding functions (that is, when you have specified IOROUT=LOAD,
IOROUT=ADD, or IOROUT=ADDRTR, 1 1.4.8), you must provide ISAM with the location of
a record work area by specifying the WORK 1 keyword parameter. FurthermOre, unless you
have selected a general register to be the current record pointer (IOREG keyword 1 1.4.7),
you must also specify a record work area for random retrieval.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

1 1-20

For sequential retrieval, you do not specify the location of a record work area in the DTF,
and data management ignores the WORK1 keyword if it is present. You have two other
options for sequential retrieval:
1.

Working in the input buffer. To do this, you specify the IOAREA1 and IOAREA2
:keywords and both the IOREG and the WORKS keyword parameters.

Transferring records to the work area. To do this, you do not: specify either the IOREG
or the WORKS keyword parameter; you specify the location of the work area in the
second positional parameter of each GET imperative macro you issue (11 .5.5.2).

An important point to remember is that the record work area, however you specify it, holds
one record at a time. An obvious point is that its size is governed by your record length; if
1 the size must accommodate the largest of these.
your records are variable
Keyword Parameter WORK 1:
WORK1 symbol
Provides the location of a record work area, where symbol (address) is the
location. Required for load and add functions (when IOROUTLOAD,
IOROUT=ADD, or 1OROUT=ADDRTR has been specified). Also required for
random retrieval unless you have specified the IOREGkeyword parameter. Is
ignored for sequential retrieval.
Keyword Parameter WORKS:
WORKS=NO
When IOREG keyword is also specified for sequential retrieval, indicates that you
will process records in the current input buffer.
If omitted, and IOREG keyword is not specified, data management expects to transfer
seqUentially retrieved records (one at a time) to the work area you specify as an
operand of each GET macro you issue (11.5.5.2).

11.4.19.

Nonstandard Forms of the Keyword Parameters

When the assembler is preparing your DTF, it uses a specific list of keywords. Discovery of
a keyword that is not on the list results in an assembly error. In order that existing
programs may require minimal changes for assembly in OS/3, the list of acceptable
keywords has been expanded beyond those listed as standard. The acceptable variations
are:

OS/3 Standard

Acceptable

BLKSIZE
ERROR
INDAREA
INDSIZE
IOAREA1
IOAREA2
IOREG

BKSZ
ERRO
INDA
INDS
lOAl, IOAREAL, IOAREAR, IOAREAS
IOA2
(ORG

UP-8068 Rev.4

SPERRYUNIVAC OS/3
BASIC DATA MANAGEMENT

OS/3 Standard

11-21

Acceptable

IOROUT
KEYARG
KEYLEN
KEYLOC
PCYLOFL
RECFORM
RECSIZE
SAVAREA
TYPEFLE
UPDATE
VERIFY
WORK1

IORT
KARG
KLEN
KLOC
PCYL, CYLOFL, CYL
RCFM
RCSZ
SAVE
TYPE
UPDT
VRFY
WRK1, WORKL, WORKR

Note that there are no acceptable variations for the INDEXED or the WORKS keywords and
that none of the completion values (the values to which you equate these keywords) may
vary from the 0St3 standards given in the preceding paragraphs.

11 4.2O.

Recapitulation of DTFIS Keyword Parameters

Table 11—3 lists all of the keyword parameters that may be used as operands of the
DTEIS declarative macroinstruction An example of coding the DTEIS declarative macro
follows the table.

Table 1 1—3. Keyword Parameters of the DTFIS Declarative Macro Instruction (Part 1 of 2)
File Function
Keyword
ACCESS*

Specification

Remarks

—

AIS

This DTF: read/update/add use
Other jobs: no access

EXCR

This DTF: read/update/add use
Other jobs: read use

SRD

ThisDTF: read use
Other jobs: read/update/add use

SRDO

This DTF: read use
Other jobs: read use

EXC

BLKSIZE*

ERROR

symbolic label

Address of subroutine to handle errors and exceptions

INDAREA

symbolic label

Address of main storage area to contain index

INDEXED,

Specifies that file is not to be indexed

INDSIZE

n (in bytes)

Size of index area in main storage: minimum size
is 256 bytes,

IOAREA1

symbolic label

Address of I/O area in main storage

11-22

SPERRY UNIVAC OS/3
BASIC DATAMANAGEMENT

UP-8068 Rev. 4

(Part 2. of 2)
Table 11—3. Keyword Parameters of the DTFIS Declarative Macro Instruction

Specification

Keyword
IOAREA2

symbolic label

IOREG

(r)general register

GROUT

File Function

ADD

ADDRTR

Address of a secondi/O area in main storage to speed
processing

Contains address of the I/O area in main storage.
Insert new records td file.
Insert new records-and retrieve records randomly
or sequentially,

Create new file or extend existing file

LOAD

KEYARG

Remarks

RETRVE

Retrieve and/or update randomly or sequentially,

symbolic label

Address of field containing key of desired record.

Key length in bytes for SAM file. When specified
for nonindexed files, a sequence check of keys is made.

Location, in bytes, of the key within a record. If
omitted, KEY LOC=O for fixedlength records;
KEY L0C2 for variable-length records.

LOCK

-O

Requests fire lock not be-set on a lockable file at OPEN

PCYLOFL

RECFORM

FILK

Specifies fixed blocked records

VARBLK

Specifies variable-blocked records

Size, in bytes, of fixed records to be processed

SAVAREA

symbolic label

Address of general register save area

TYPEFLE

RANDOM

KEYLEN

KEYLOC

RECSIZE

* *

(00 to

: SEGN’EL

VERIFY

YES

WORK1

symbolic label

-O

Eliminates update capability

Specifies a parity check of data records is to be
made after being writsen to output disc

Address of work area for records being loaded,

reloaded, extended, or inserted

Specifies random/sequential file processing function

No record work area available for sequential

retrieval

LEGEND:
L
A
S
T
O
R
S

Specifies sequential file processing function

WORKS

Specifies random file processing function

RANSEQ

UPDATE

Percentage of cylinder (blocks) available for overflow

80i

File creation or extension
Record insertion
Sequential retrieval
Random retrieval
Optional
Required
Select one
Value assumed if keyword is not specified.
-

*Parameter may be changed by DD job control statement.
**Parameter may be changed by DD job control statement, indexed mode only.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11—23

Example:
A

OPERAND

AOPERATIONA

LABEL

COMMENTS

LLiDLF

&Ai

I±t.t
AaPLl_L

iLij.

t4LL N:EWEtI,

1 L1

LiiLL

PRECE1E
FR. A

REC3RV

iiL

Lit

)E’Yl

I
L
iii

tE
I.m
P
1
t

WITE

11.5.

X
1
E

i_i

I
SLc.KIED,

15 SYTE F
L.i

A YAKIIALEj ANp
1
LRER

M-VAL
ErfLi%

iLLJi

D
1
T

1L
J

iLO
1
J

1 1
li±.
JJi

LL
1

Jjj

i L
I
RLLAND ET LEr/ALL. L
QltT1AL
1
M
R
I/ AA ttL }4A114 TRAGE

iTiEti4
i

jiJt:

1.1

iii

j1i1

ILl

IMPERATIVE MACROS FOR ISAM FILES

To process your ISAM files, you will issue imperative macros in your BAL program to
communicate with OS/3 data management. These imperative macros expand as inline
executable code to set up linkages, pass required parameters, and initiate transfer of
càntrol to thevarious ISAM transients and logic modules.
As explained in further detail in 11.7 and Appendix B, data management sets a flag in a 4byte addressable field in your DTF file table (labelled filenameC), after the execution of
each imperative macro you issue, to inform you of the normal completion of the
processing you have specified or of error or exceptional conditions. If you do not provide
an error/exception handler routine, it is your responsibility to interrogate filenarneC after
each inline return and to take appropriate action in your program.
Certain of these imperative macros also provide other useful information to you, in
different fields of the DTF file table (fllenameH, filenameP, and sà on). These actions are
pointed out in the individual macro descriptions and also recapitulated in 11,7.
The imperative macro descriptions are grouped according to the file processing functions
involved:
Basic macroinstructions: OPEN and CLOSE
•

File loading and extending macros: SETFL; WRITE, NEWKEY; and ENDFL

•

Random processing macros: READ, KEY; READ, ID; WRITE, KEY; UPDT; and WAITE

•

Record insertion macros: WRITE, NEWKEY; ADD; and WAITE

•

Sequential processing macros: SETL, GET, PUT, and ESETL

11.5.1.

Basic Macroinstructions

You must use the OPEN and CLOSE macroinstructions to initiate and terminate action on
an ISAM file. They call transient routines into main storage to perform the necessary
preparation and close-out. The OPEN macroinstruction must be issued before any other
macro function can be performed.

11-24

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

OPEN

lnitiahzing an ISAM File (OPEN)

11 5 11
Format:

LABEL

OPERAND

AOPERATIONA

(filename-i [,...,filename-n]
(i)
(i

OPEN

[name]

IL
Positional Parameter 1:

filename
Is the label of the corresponding DTFIS declarative macroinstruction in the
program. The maximum number of file names is 16.
(1) or I
Indicates that you have preloaded register 1 with the address of the DTFIS file
table.
Examples:
LABEL

I
I
I

-_-

iPt.1

L
I

OPERAND

A0PERATIONA

—

)
L
1
c
—

—

I
I

11-25

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

11.5.1.2.

Terminating an ISAM File (CLOSE)

Function:
You must use the CLOSE macroinstruction to terminate processing of your file. The
CLOSE macroinstruction calls on a transient routine that performs required
termination operations, such as updating the format 2 label. Once your file is closed,
no other macroinstructions can be executed for the file until it is reopened by the
OPEN macroinstruction.
Format:
OPERAND

AOPERAT1ONA

LABEL

filename-i [,...,filename-n]
(1)
1
*ALL

[name]

Positional Parameter 1:
filename
Is the label of the corresponding DTFIS declarative macroinstructio-’
program. The maximum number of file names is 16.

n your

(1) or 1
Indicates that you have preloaded register 1 with the address of the DTFIS file
table.
*ALL
Specifies that all files currently open in the job step are to be closed.
Example:
AOPERATiONA
16
10

LABEL

I
I

OPERAND

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev,4

11-26

Programming Considerations:
When you have issued a CLOSE macro, you may access filenameS, if desired, to
ascertain the number of bytes required to hold the top index in main storage (11 6.2).
1152.

Loading and Extending an ISAM File

Whether a new ISAM file is to be loaded (created) or an existing one is to be extended by
adding records at the end, the file processing functions are the same. Both functions are
indicated in the DTFIS declarative macroinstruction when you specify IOROUTLOAD.
Records for the file are supplied in a work area to be blocked by data management.
The imperative macroinstructions you require are the same in either case. The two
processing functions are differentiated by the disk format 2 label. Once a file has been
loaded successfully and a CLOSE macroinstruction has been executed for it, subsequent
processing of a file for which you have specified IOROUTLOAD extends, rather than
creates, the file,
The three imperative macroinstructions are:
SETFL, which initiates the processing sequence:
WRITE, NEWKEY, which loads a record to the file; and
ENDFL, which terminates the processing sequence.
You do not follow the WRITE, NEWKEY macro with the WAITE macro for a load operation,
although the WAITE macro is required after all other uses of the WRITE macro and all
uses of the READ macro in OS/3 ISAM.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8O68 Rev. 4

11-27

SETFL

11.5.2.1.

Initiating the LoadSequence (SETFL)

Function:
The SETFL (set file load) macroinstruction calls on a transient routine which sets up
controls in the DTFIS file table and in the indexes on the disk to prepare file for
loading(orextendihg).
Format:
LABEL

LS OPE RATION

[name]

SETFL

OPERAND

filename

}

Positional Parameter 1
filename
Is the label of the corresponding DTFIS file table in your program.
(1) or 1
Indicates that you have preloaded register 1 with the address of the DTFIS file
table.
Example:
LABEL

AOPERAT1ONL\

OPERAND

-_-_______

—

I
i

Il-Lb

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

WRITE, NEWKEY

Writing Initial Records to the File (WRITE, NEWKEY)

11.5.2.2.
Function:

The WRITE, NEWKEY macroinstruction (that is, WRITE is the operation code, and
NEWKEY is positional parameter 2) writes a logical record to a file being loaded or
extended. Specifically, it transfers a record from the working storage area to the I/O
area. Before issuing the WRITE, NEWKEY macroinstruction, you must have stored the
logical record in the work area.
Format:
LABEL

/xOPERATiONL

[name]

WRITE

OPERAND

(filename ) ,NEWKEY
(1)
(i

Positional Parameter 1:
filename
Is the label of the corresponding DTFIS declarative macroinstruction in the
program.
(1) or 1
Indicates that register 1 has been preloaded with the address of the DTFIS file
table.
Positional Parameter 2:
NEWKEY
Indicates that a new record is to be loaded into an ISAM file.
Examples:

10
i

I
I

OPERAND

AOPERATIONtx

LABEL

1
i

IrT
1
JrR
11.1.—I

I
I

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11-29

Programming Considerations:
The WRITE, NEWKEY macroinstruction causes the following actions:
The key in the work area is checked against the key of the last record transferred
into the I/O area, and if it is not greater, either a duplicate key or a sequence
check error has occurred. Data management sets the appropriate flag in the

filenameC field of the DTFIS file table and returns control to your error-handling
routine, if you have one, or to you inline. The record in error is not transferred to
the I/O area, and you may resume normal processing with another valid logical
record.
•

The record and its key are transferred from the work area to the I/O area.

•

When the I/O area cannot accommodate the entire record, a block is written into
the prime data area on the disk, and the given record is used to start the next
block.

•

When a block is written, a key-pointer entry is formed for the block index,
provided that you have specified an indexed file. For an ASAM file
(INDEXEDNO), this action is omitted.

•

Following execution of the WRITE, NEWKEY macroinstruction, the disk address of
the logical record is available to you in a DTFIS addressable field labeled
f/IenameH. You may save these addresses during load and present them later for
direct accessing. A 3-byte count of the total number of logical records in the
prime data area (contained in filenameP of the DTFIS file table) is also available
to you
You may not overwrite the dummy record at file start, which is not available to
you for storing data. If you issue the WRITE, NEWKEY macro with a search key of
all binary 0’s in your KEYARG field (this being the key reserved for the dummy),
error processing results. Data management sets the invalid ID error flag in
fi/enameC, issues error message DM24 (INVALID REQUEST (ID)
OUTSIDE FILE
LIMITS), and branches to your ERROR routine. Refer to Appendix B.
—

Exa mples:
LABEL

LOPERATIONA

OPERAND

I
I

_P%f1ItI•t••IE

1
I.LI

ILI

I.Iii

IJJ1Li.lIi
I

I
I
I

Iii..JLJ._.

Assuming register 1 has been preloaded with the EMPLMST address, and the
WRITE, NEWKEY macroinstruction has been executed successfully, the field in
the DTDIS file table labeled EMPLMSTH holds the logical record address.

If an error or warning condition has occurred, the field in the DTFIS file table
labeled EMPLMSTC contains an indication of this condition.

11-30

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

ENDFL

11 5 2 3

Terminating the Load Sequence (ENDFL)

Function:
The ENDFL (end file load) macroinstruction calls on a transient routine that
terminates your file loading or extending functions for the file and writes the final
block on the disk. Also, file parameters are tested and any required index processing
is performed.
Format:
LABEL

A OPERATION A

[name]

ENDFL

OPERAND

(filename
(1)
(i

Positional Parameter 1:
filename
Is the label of the corresponding DTFIS file table in your program.
(1) or 1
Indicates that you have preloaded register 1 with the address of the DTFIS file
table
Example:
LABEL

I
I

F
.._.
V
1
Ei(.1
t

OPERAND

AOPERATIONA

PL_.
rE
1

1
fbi

I
I

UP-8068 Rev. 4

11.5.3.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11-31

Inserting New Records in an ISAM File

Once an ISAM file has been created, you can add new records to the file, providing that
you allocated overflow space on disk during load. Each nevi record is placed in the
overflow area and chained into logical sequence. You specify this file processing function
by specifying IOROUTADD (or IOROUT=ADDRTR If retrieval is also desired) Ifl the DTFIS
declarative macroinstruction and use either the ADD or the WRITE,NEWKEY imperative
macro to add each new record.
You supply new records in a work area
, as you did during file creation. However, keys of
1
added records need not be in ascending sequence. For ASAM files, the area specified by
the KEYARG keyword parameter must contain the address of the record from which the
current item is to be chained The DTFIS keyword parameters must be equated to the
same specifications as when the original file was created
You issue the imperative macroinstructions WRITE, NEWKEY (or ADD) and WAITF to add
records to an .ISAM file. The form of the WRITE, NEWKEY macroinstruction for adding to a
file is the same as you use for loading or extending a file, although the functions
performed are different.
In ISAM there is no restriction preventing the adding of records with keys lower than the
key of the first record loaded, except the key of all binary zeros. ISAM has begun the file
with a dummy record having this key; so error processing will result if you attempt to add
a record whose key is binary 0. This is described under the WRITE, NEWKEY macro
description in 11.5.2.2.
In the course. of adding records to a file, overflow areas may become filled. After each
WAITF macroinstruction, the conditions are reflected in the program-addressable fields in
the DTFIS file table. These fields areas follows:
•

Fi/enameA
A 2 byte field indicating the number of prime data cylinders having full cylinder
overflow areas. This field is set to zero if you have not specified cylinder overflow
with the PCYLOFL keyword.

•

Filename 0
A 2-byte field indicating the total number of overflow records.

•

FilenaméP
A 3-byte field indicates the tOtal number of prime data records in the file.

11-32

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

WRITE, NEWKEY

11 5 3 1

Adding a New Record to Overflow in an Existing File (WRITE NEWKEY)

Eu nction:
When you specify IOROUT=ADD or IOROUTADDRTR, the WRITE, NEWKEY
macroinstruction logically inserts a new record in an existing file. You cannot use this
macroinstruction unless you have allocated cylinder overflow area during load with
the PCYLOFL keyword (11.4.12). Before issuing the WRITE, NEWKEY
macroinstruction, you must have stored the logical record in the working storage area
in the logical record format.
In response to this macroinstruction data management does the following
1.

Searches through the index to locate the record’s prime data block. This block or
the overflow chain is then searched to determine the position into which the
new record should be inserted

Places the new record in overflow.

Installs chaining in the blocks as necessary to maintain logical sequence.

Eor ASAM files, thea index search is replaced bya direct access to the proper block;
you provide data management with the 5-byte file-rOlátive address of the record from
which the new record is to be chained by loading it into the KEYARG field before
issuing the WRITE, NEWKEY macro (11.4.9).
To ensure that all the actions initiated by the WRITE, NEWKEY macroinstruction have
been completed, you must execute a WAITE macroinstruction. When control is
returned to you from the latter, the work area isavaiIable for further insert records.
The record just inserted is no longer in WORK 1.
Format:
LABEL

OPERAND

tOPERATIONi

WRITE

(filename’
(1)
(1

NEWKEY

ur--ouoo

ruv.

tMhT UPJIVMi, U/

‘+

I I—

BASIC DATA MANAGEMENT

Positional Parameter 1:
filename
Is the label of the corresponding DTFIS declarative macro in your program.
(1)orl
Indicates that you have preloaded register 1 with the address of the DTFIS file
table.
Positional Parameter 2:
NEWKEY
Indicates that a new record is to be written into an ISAM file.
Examples:
LABEL

tOPERATIONA

10
I

OPERAND

IL%11?It._r_&1

I
I

i
I

Programming Considerations
If an error or warning condition has occurred, the field in the DTFIS file table labeled
EMPLMSTC will contain an indication of the condition.

rtri uiiv’. oi
BASIC DATA MANAGEMENT

UP3Ub3 Key. 4

ADD

11.5.3.2.

Adding a New Record to Overflow in an Existing File (ADD)

Function:
The ADD imperative macro, exactly equivalent to the WRITE, NEWKEY macro used
when IOROUT=ADD or IOROUT=ADDRTR is specified, adds a new record to the
overflow area of an existing ISAM or ASAM file and chains it into the appropriate
logical sequence.
As with the WRITE, NEWKEY macro, you must have previously provided an overflow
area with the PCYLOFL keyword (11.4.12) when you originally created the file, and
you must specify the IOROUT keyword as Just stated You store the logical record in
the work area before you issue the ADD macro, and you issue a WAITE macro after it,
before issuing another function to the file.

is an ASAM file, the ADD macro does not conduct a search
the data block (prime or overflow) containing the record
accesses
directly
the new one is to be chained. You provide data management with the
relative address of this record by loading it into the KEYARG field before
ADD macro (1 1.4.9).
If your file

on key but
from which
5-byte file
issUing the

Format:
LABEL

A OPERATION A

[name]

ADD

OPERAND

ç filename i

Positional Parameter 1:
filename
Is the label of the corresponding DTFIS declarative macro in your program.
(1) or 1
Indicates that you have preloaded register 1 with the address of the DTFIS file
table.

UP-8068 Rev. 4

SPERRY UNIVAC OS/a
BASIC DATA MANAGEMENT

11-35

WAITF

11.5.3.3.

Ensuring Completion of Record Transfer (WAITF)

Eu nction:
The WAITF macroinstruction ensures that the transfer of a record between main

storage and disk has been completed. It must be issued after you issue one of the
following macros and before you attempt to process another record: ADD;
WRITE,NEWKEY; READ,ID; READ,KEY; or WRITE,KEY. Any exceptional (error or status)
conditions detected during the execution of the WAITE instruction are reflected in the
DTEIS fi/enameC field when control is returned to you.
Eormat:
LABEL

1OPERATON

WAITF

[name]

OPERAND

Ifilename
(1)

Positional Parameter 1:
filename
Is the label of the corresponding DTEIS file table in your program.
(1) or 1
Indicates that you have preloaded register 1 with the address of the DTEIS file
table.
Example:
LABEL

AOPERATIONA

10
1111
I

11.5.4.

Ii
i

OPERAND

16
Ii

t
1
A

Iii

17(..1v’)i
1
Ej’1

ii
I

III

Processing an ISAM File Randomly

You can retrieve individual logical records in random order for processing and updating.
The record to be retrieved from the file is designated by its key or address and, in the case
of an updating operation, is written back into the file.
You indicate the random retrieval (and updating) file processing function in the DTFIS
macroinstruction by specifying IOROUT=RETRVE (or IOROUTADDRTR if new record
insertions are also to be performed), and TYPEELERANDQM (or TYPEFLERANSEQ if
sequential processing functions are also to be performed).

The following imperative macroinstructions are used in the random processing of an ISAM
Ne READ ID READ KEY UPDT WRITE KEY and WAITF

ii -3b

SPERRY UNIVAC 05/3
BASICDATA MANAGEMENT

UP-8068 Rev. 4

READ, ID
READ, KEY

11.5.4.1.

Retrieving a Record (READ, ID and READ, KEY)

Eu nction:
The READ macroinstruction initiates the retrieval of a single logical record from an
ISAM file. Before issuing the instruction, you must have stored the keyór the address
of the record to be retrieved in the main storage area equated to the KEYARG
keyword parameter of the DTFIS declarative macroinstruction
For indexed files, data management Uses the argument for an indexed search and
retrieval of a record with a matching key. ASAM files treat the argument as a relative
address and retrieve the block and record. If a work area has been specified in the
DTFIS macroinstruction, the logical record is transferred to the work area designated.
If the IOREG keyword parameter is used, the address of the first character of the
logical record is placed in the general register specified by IOREG.
To ensure that the retrieval operation has beencompleted, you must execute a WAITE
macroinstruction before attempting to access the logical record retrieved.
Format:
LABEL

£OPERATION

[name]

READ

OPERAND

(filename
(1)

,lD
tKEY

Positional Parameter 1:
filename
Is the label of the corresponding DTEIS file table in your program.

(1) or 1
Indicates that you have preloaded register 1 with the addres of the DTFIS file
table.
Positional Parameter 2:
ID
Indicates that random retrieval by location is performed.
KEY

Indicates that random retrieval by key is performed

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11-37

Examples:
LABEL

A0PERATI0NA

I
I

JRIE.P
i

OPERAND

i—I——i

J
i:::i

)c’E rt’

j&i’iz_..
1m’1I1L._

I
I

Programming Considerations:
When control is returned to you after execution of the WAITF macroinstruction, the
logical record associated with the argument in the area specified by KEYARG is
available in either the work area or the I/O area, depending upon the DTFIS
macroinstruction specifications. If the record is available in the I/O area, the register
specified by the IOREG keyword parameter contains the address of the first character
of the logical record. The disk address of the physical record is available at the
address EMPLMSTG in the DTFIS file table. Indications of any exceptional (status or
error) conditions are available at EMPLMSTC.
The dummy record containing an all-zero key and inserted by data management at file
start is not available for you to retrieve. If you issue the READ, ID macro with the
address of the dummy specified in the KEYARG field (11 .4.9), data management sets
the invalid ID error flag in filenameC and issues error message DM24 (INVALID
REQUEST (lD)—OUTSIDE FILE LIMITS). If you issue the READ, KEY macro with a key
of all binary 0’s specified in the KEYARG field, data management sets the record not
found flag in filenameC and issues error message DM31 (RECORD NOT FOUND FOR
RANDOM FUNCTION). In either case, control transfers to your ERROR routine if you
have specified one; otherwise, errors return to you inline. Refer to Appendix B.

UP-8068 Rev. 4

1 1—38

SPERRY UNIVACOS/3
BASIC DATA MANAGEMENT

WRITE, KEY

11.5.4.2.

Updating a Record (WRITE, KEY)

Function:
The WRITE,KEY macroinstruction initiates rewriting (updating) of the last record
retrieved with a READ macroinstruction., You must not alter the key field or the record
length field (for variable records) ifl any way
Format
LABEL

A OPERATION A

[name]

WRITE

OPERAND

filename
{l”

,KEY
}

Positional Parameter 1
filename
Is the label of the corresponding DTFIS file table in your program
(1) or 1
Indicates that you have preloaded register 1 with address of the DTFIS file table.
Positional Parameter 2:
KEY
READ,KEY

Indicates that the last record retrieved by
macroinstruction is to be rewritten in the file.

READ,ID

Example:
A

OPERAND

A0PERATI0NA

LABEL

—

L±j
I I
I a
I
I

I__Itt

—

‘a

—

I’
I°I

Lt4T
1
M1’

I
II

—

I
I

I_I_Ill
i

ur-u iev.

‘

SIhHY UNIVAC OS/3
BASIC DATA MANAGEMENT

11-39

Programming Considerations:
In response to a WRITE, KEY macroinstruction, the updated logical record from the
work area is moved to the correct location in the I/O area, and the block is rewritten.
If the record is updated in the I/O area through the use of the IOREG keyword
parameter, no move is required since the record is already in its correct location.
You must use a WAITF macroinstruction following the WRITE macroinstruction to
ensure completion of the rewrite function. When control returns to you after the
execution of your WAITF macroinstruction, the logical record last retrieved by a READ,
KEY or READ ID macroinstruction as well as the block that contains it will have
been rewritten onto your disk file Any indications of exceptional conditions (error or
status) detected during the write and wait operations are available to you at address
EMPLMSTC in the DTFIS file table
If you have tagged the record for deletion according to your own conventions you
may increment the 2-byte tagged-for-deletion field at address EMPLMSTT in the
DTFIS file table either before or after the rewrite operation. This count is available for
the life of the file to help you decide when file reorganization is beneficial.

ii-4U

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

UPDT

11.5.4.3.

Updating Last Record Retrieved (UPDT)

Function

You issue the UPDT imperative macro (which is exactly equivalent to the WRITE KEY
macro for updating randomly processed files) to rewrite to its original disk location in
an ISAM or ASAM file the updated logical record last retrieved by a READ ID or
READ,KEY macroinstruction. You do not use the UPDT macro Unless you have
updated the record; in updating, you must neither alter the key nor change the length
of the record. Like the WRITE,KEY macro, the UPDT macro must be followed by a
WAITF macro before you issue another function to the file
Format:
LABEL

LOPERATIONI

[name]

UPDT

OPERAND

(filename
• (1)
(i

Positional Parameter 1:

filename
Is the label of the corresponding DTFIS declarative macro in your program.
(1) or 1
Indicates that you have preloaded register 1 with the address of the DTFIS file
table.
11.5.5.

Processing an ISAM File Sequentially

You may also retrieve and update logical records sequentially. The first record to be
retrieved may be designated by the beginning of the file, by a relative record disk address,
by a specified key, or by any key greater than or equal to a specified value. The SETL
macroinstruction specifies which kind of starting point is desired. Individual records are
then retrieved in sequence by the GET macroinstruction. Where an updating operation is
to be performed, the individual records are rewritten into the file by means of the PUT
macroi nstruction.
You indicate the sequential retrieval (and updating) file processing function in the DTFIS
declarative macro by equating the IOROUT keyword parameter to RETRVE (or to ADDRTR if
new record insertions are also to be performed), and the TYPEFLE keyword parameter to
SEQNTL (or to RANSEQ if random processing functions are also to be performed).

UP—8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11-41

To terminate a retrieval sequence, you issue an ESETL macroinstruction. This ensures that
logical records committed to output by the PUT macroinstruction are written onto the disk.
After the ESETL macroinstruction has been executed, another retrieval sequence may be
initiated by executing a SETL macroinstruction. Also, if you have specified
TYPEFLE=RANSEQ in the DTFIS declarative macro, the READ,KEY; READ,ID; and
WRITE,KEY macroi nstructions may be issued, once you have terminated the sequential
mode.

11-42

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

SETL

1 1.5.5.1.

Initializing a Retrieval Sequence (SETL)

Function:
The SETL macroinstruction initializes a retrieval sequence. It specifies the file from
which the records are to be retrieved and the point at which the retrieval is to start.
For the starting point, the SETL macroinstruction can select the beginning of the file
or other file locations. When control is returned to you from the SETL
macroinstruction, the retrieval sequence may start.
Format:
LABEL

OPERAND

LOPERATIONL

[name]

SETL

(filename 1

)

BOF
GKEY
ID
KEY

BOF
Indicates that the retrieval sequence is to begin with the first logical record of
the file.
GKEY
Indicates that the retrieval sequence is to start with the first logical record whose
key is greater than or equal to the value in the area equated to the KEYARG
keyword parameter of the applicable DTFIS macroinstruction. Used only for
indexed files.
ID
Indicates that the retrieval sequence begins at the location given in the KEYARG
keyword parameter in the applicable DTFIS macroinstruction.

UP8O68 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

11-43

KEY

Indicates that the area equated to the KEYARG keyword parameter in the
applicable DTFIS macroinstruction holds the key of the first logical record to be
retrieved. Used only for indexed files.
Exa mples:
LABEL

AOPERAT1ONA

IleiTiL._

IETL

OPERAND

16
I

LM4T,I in a single compact string of bytes; and, an index partition,
containing blocked index entries at two or more hierarchic levels. Each data record in the
data partition contains a key, a character string specified bythe user, that uniquely
identifies the record. All keys in the IRAM file are of the same length; a key may start at
the head of the record it identifies, or it may be elsewhere within the record, but the
location of all keys must be the same for all records in one file. For details on the structure
of keyed records arid the IRAM index, refer to 1 22.

If the. index partition is activated during processing, data records may be referenced
randomly or sequentially by the values ‘of their keys. When the index partition is inactive,
data records may be accessedconsecutively (in the. physical order In whichthêy occur oh
disk) or randomly, according to their relative positions in the data partition. However,
records may not be added unless the index is active. Activating the index is a specific
detaiIof file definition, performed beforethe file is opened.
A multivolume indexed IRAM file may be ereatedfor processing with all volumes online,”or
with only one vOlume online at a time, and it must always be processed in the mode for
which it was created. When a multivolume file: is created for, single-volume processing;
random processing must always use the keyed retrieval functions, for which the index
partition must be active; random retrieval by record number is not pbssibIe
Both multivolume and single-volume indexed: IRAM files may be created in au orderly or
disorderly load. In an ordered load, records are submitted to IRAM in ascending order of
key: values; an out-of-sequence record is rejected,..; and ‘an error is reported. In an
unordered load, no checking of key sequence is performed by IRAM. In both types of load,
however, IRAM’ checks for duplicate keys; a recordwhose key duplicates a key already in
the file is rejected, and an error is reported.
A new data record with a key duplicating one already in the file maynot be :added to the
file at any time No sequence checking of keys may be specified during file extension
operations. All IRAM files may be processed randomly with a tag file containing relative
record numbers of ‘the records selected for processing. Such a disk file may be prepared
from the IRAM file by using the ADDROUT option of the independent sort/merge program;.
for details, see the sort/merge user guide, UP-8342 (current version). In addition, an
indexed IRAM file may be processed sequentially with a file containing record key limits.
Alternatively, the lower limit may be set within the RPG II program.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13-10

The following subsections discuss, in general terms, procedures for creating and extending
an indexed IRAM file; for adding, retrieving, updating, and deleting records; and for
reorganizing an indexed IRAM file. For detailed programming specifications, refer to the
RPG II programmer reference, UP-8044 (current version).
13.2.1.

Creating an Indexed IRAM File

You define your IRAM file as an indexed output file and present each data record to IRAM
in a predefined record work area (of a size equal to one record length) before you issue the
output function to write it to the data partition. All data records are of a uniform length,
and each contains a unique record key. You must specify the record length, the key length,
and the fixed location of the key in all records when you define the file.
Other specifications you must make in defining the file include:
•

the size and address of your primary data buffer;

•

the sizeand address of your index buffer; and

•

the address of a field in your program that is to contain a search key.

For calculating the minimum data buffer size you may specify, follow the same procedure
described in 13.1.1.1. The primary data buffer
used for creating a sequential IRAM file
the
index buffer in main storage. You may
to
contiguous
and
aligned
is half-word
for update operations); this must be
(except.
buffer
optionally specify a secondary data
contiguous to the primary buffer and of exactly the same size. The secondary data buffer
follows the primary buffer in main storage.
—

The index buffer in main storage is also half-word aligned and has a minimum length of
256 bytes; if larger, its size must be a multiple of 256 bytes. The RPG II compiler specifies
this minimum length for you and provides you with means forincreasing the size of the
index buffer (by one or more (up to nine) 256-byte increments) to enhance the
performance of your programs: not only the load program itself, but all programs
subsequently accessing the indexed IRAM file when its index is active. You should do so if
you can afford the main storage, bearing in mind that all subsequent programs that use
keyed functions must specify the same index buffer size you used to create the file. (They
need not use the same data buffer size, however; see 13.1.11.)
A good rule of thumb in determining your index buffer size is to multiply the sum of your
specified key length plus three bytes by 20, rounding the result upward to the next
multiple of 256 bytes. This figure is used in calculating disk space required for an indexed
IRAM file (see 12.2.4).
The length of the field you must predefine in your file creation program to hold a search
key is your specified key length plus three bytes. This field is required in any program that
uses keyed functions. IRAM uses this field itself, arid sometimes overlays it. Your
programs should avoid this field except for placing a search key in it, just prior to
requesting a random read.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 3-1 1

In defining the file for creation, you may specify that IRAM is to check that the sequence
of the keys in your submitted data records is in ascending order. If you do so, you must
submit them in this order for the load (but not necessarily in subsequent file extensions);
an attempt to load a data record containing an out-of-sequence or duplicate key is rejected
immediately, and an error is reported.
If you do not request key sequence checking, you may submit your data records to IRAM in
any key order; only duplicate keys will be rejected. Depending on the bias of your key
distribution in this disordered load, you should expect the process to be less than half as
fast as an orderly load with sequence checking.

13.2.2.

Extendingan Indexed IRAM File

Once the file is created it may be extended in the same manner we have Just described
for creating the file. IRAM appends new records to the end of the data string. If you have
specified sequence checking in creating the file,. you are not constrained to extending the
file with an orderly sequence of added record keys, but if you do specify sequence
checking for extending the file, the key in each record submitted must be successively
higher than any in the file or volume. Duplicate keys are rejected. You may also add new
records while you are retrieving existing records from the file; see 13.2.4.
Once you have successfully added a new record to an indexed IRAM file, it is immediately
available for retrieval. This is true because IRAM updates the index structure on a recordby-record basis during load, extend, and add operations. It does not sort the index
following a disorderly load but maintains the fine-level index in unbroken ascending key
order at all times. Refer to 1 2.2 for details.

13.2.3.

Retrieving and Updating in an IRAM File with Index Active

When a multivolume indexed file has been created for single-volume processing, random
retrieval from each volume must always be performed with the index marked active, using
the key of the desired record as a search argument. It is not possible to retrieve records
from the mounted volume at random by relative record number.
Random retrieval from a single-volume indexed file is not limited in this way. You may
retrieve records at random by key when the index is active, and at random by relative
record number when it is not. The same is true for multivolume files created for
multivolume processing When the index is marked inactive IRAM files may be processed
only in retrieval and update modes as described in 13 2 5 When the index is marked
active, all retrieval from an IRAM file is done by key.
To retrieve randomly by key, define the file as an input file for random mode processing
and specify that the index is active. Your program predefines a field in which you provide
IRAM with the key of the desired record as a search argument before you issue the input
function. The length of this field is three bytes greater than the key length specified for the
file. No search key may contain a byte with the hexadecimal value ‘FE’.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13-12

if you have specified update mode, random retrieval may be followed by an output function
to update the record retrieved. IRAM prevents you from issuing the update function if the
desired record has not been found. In updating a keyed record, you should take care not to
alter its key in any: way. IRAM does not check for alteration of the key nor does it prevent
your update from being issued if the key of the updated record duplicates one already in
the file. IRAM updates without reference to the index; therefore, if an updated record is
written back to the file with a key that has been changed, subsequent retrieval by key is
either impossible or unreliable.
Sequential retrieval by key requires that the file be defined as an input file for sequential
processing and that the index be marked active. Before you issue the input function to
retrieve the first record, you must establish the value of the record key at which the
retrieval sequence is to begin. This is done by issuing a function to set the lower limit for
retrieval and providing a key value in a predefined field of your program. IRAM will then
search for a record containing a key equal to or greater than this value.
If the value you supply is zero, the record retrieved by your first input fUnction is the
record containing the lowest key in the file (This is the first record in the data partition
only if the file was created with an orderly load) If the value you supply is gteater than the
highest key contained in the fine index, no retrieval sequence can begin. In this case,
IRAM reports a “no-find”.
Once
until

sequential-by-key retrieval sequence has been successfully started, it continues

you reach end of file or end of volume;
I

you specify a new lower limit to start a new sequential retrieval sequence;

•

you reset file processing mode from sequential to random; or

•

the file is closed (by your program or by IRAM as in case of I/O error)

A sequential-by-key retrieval sequence is not terminated when you add a new record
during retrieval operations, but is resumed with your next input function (see 13.2.4).
If your updating operations include provisions for flagging records (by your own
conventions) that are to be deleted from the file your retrieval programs should include
coding to check for the presence of this delete flag and to bypass or process each record
accordingly IRAM does not recognize your deletion code and will not avoid retrieval of a
flagged record
13 2 4

Adding Records during Retrieval

—

Index Active

Provided that you have marked the index active and have specified that you intend to add
during retrieval you may provide a new record to IRAM in a predefined work area in your
program and request that it be appended to the file. IRAM refuses the action if the key of
the new record duplicates a key already in the file, but the value of the key may be lower
than or greater than any key in the file, or fall within the range of the existing keys. You
may not specify that IRAM is to check key sequence when you add during retrieval.

UP8O68 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13-13

If YOU append a new record in this manner during a sequential retrieve-by-key operation,
the retrieval sequence is not terminated, but resume with your next issue of an input
function. A record may not be added to an indexed tRAM file unless its index is active.
132.5.

Retrieval and Update when Index Is Inactive

An indexed IRAM file may be processed only in retrieval or retrieval-and-update modes
when the index is marked inactive. Update is not possible without prior retrieval. Programs
accessing such files may not issue any keyed function, nor may they add new records.
Attempts to extend the data partition are disallowed and result in an error report with
status flags set to indicate an invalid macro issue. IRAM does not use an index buffer for
the nonkeyed retrieval or update functions allowed for an indexed IRAM file processed
with an inactive index, and therefore, your program does not require or define an index
buffer.
When its index is inactive, random retrieval and retrieval-with-update of an indexed IRAM
but only if the file is a 1-volume file or
file may be performed by relative record number
was created for multivolume processing and all volumes are mounted. Define the file as
an input file for random processing mode, with update if desired. The file may not be
defined as an output file. Your program predefines the field where you provide the relative
record number of the desired record before you issue the input function to retrieve it. An
input request with a file-relative record number higher than the highest number recorded
for the file results in transfer of control to your error routine, with status flags set to
indicate an end-of-file condition. To terminate random retrieval, you close the file. For
update, you may use a work area (length equal to one record length), or one data buffer to
present the updated record to IRAM. Two buffers may not be specified for update
processing.
—

The other method for retrieval or retrieval-with-update, from an indexed IRAM file with its
index inactive, is consecutive processing. For this, define the file as an input file for
sequential mode processing (with update if desired) and mark the index inactive.
If yours is a 1-volume file, or was created for multivolume processing and all volumes are
to be mounted, you may set the lower file limit for consecutive retrieval. Your program
predefines a 4-byte field in which you supply IRAM with the file-relative record number
where consecutive processing is to begin; you move this number into the field before you
issue the function to set the lower processing limit. Your first input function then retrieves
the record at this file-relative address, and your successive input functions retrieve the
remaining records in their consecutive, physical order on disk. If you do not set a lower
limit, consecutive retrieval starts with the first record in the file. Retrieval terminates when
IRAM detects end-of-file; it detects end-of-volume conditions automatically and issues
mount messages to the operator for subsequent volumes.
If your file is a multivolume indexed file created for single-volume processing, you do not
have the option of setting a f//e-relative lower limit for consecutive retrieval. If you are to
provide a record number to IRAM intended to be a lower limit for retrieval, you must
the first record in the
realize that IRAM treats this as a vo/ume-relative record number
volume data partition being record number 1. (This is the first record retrieved if you do
not set a lower limit.) Consecutive retrieval terminates when end-of-volume is detected by
IRAM.
—

UP-8068 Rev.4

13.2.6.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13-14

Deleting Records from an Indexed IRAM File

Because IRAM does not provide a function for deleting records from your files, you must
tend (yourself) to whatever is necessary for this purpose in your programming. A common
method of logically deleting a record from a file that is being updated is to mark it with a
deletion code: for example, a specific character in a specific data byte. Records so marked
or flagged for deletion may later be physically removed from the file when it is reorganized
offline from IRAM processing. In the meantime, your retrieval programs should be
coded so as to check for the presence of your conventional deletion flag in each record
retrieved so that a logically deleted record may be recognized and bypassed. IRAM has no
provisions for recognizing your deletion flag and avoiding the retrieval of records
containing it.

—

In establishing your own convention for logical deletion, restrict your flagging to one or
more data bytes, recalling the unpredictable results of changing the key of a record in an
indexed IRAM file during update (12.2.3). The index of the IRAM file is not available to you
for marking index entries that refer to records you intend to be logically deleted, and you
should not attempt this.

13.2.7.

Reorganizing an Indexed IRAM File

You may have occasion to reorganize an indexed IRAM file: for example, to compress it by
physically removing data records tagged for deletion, or to resequence the data records for
more efficient or convenient processing. If you have created or extended your file with the
disorderly load option, but then find increasing need to scan it in key sequence, you would
improve your sequential retrieval program’s performance as a result of dumping the file
and reloading it in an ascending key order.
To reorganize an IRAM file, you will generally need to use other processors: either the
independent sort/merge program, or the data utility program. Either of these, for example,
will accept your IRAM file as input and delete or omit records as specified in the process
of sorting or copying and recreating the file. These procedures are documented in the
current version of the sort/merge user guide, UP-8342 and the data utilities user
guide/programmer reference, UP-8069.
When your multivolume indexed IRAM file has been created for single-volume processing,
you. may find a need to regroup data records onto different volumes for more convenient
processing. You cannot perform this task with thedata utility program, however, because
the utility is not parameterized to allow you to select the volume onto which a given record
is to be copied. For this sort of reorganization, therefore, you would need to prepare a
specific RPG II program.

UP-8068 Rev. 4

13.3.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13—15

DEFINING AN OS/3 IRAM FILE (DTFIR)

The DTFIR declarative macro is used to define an IRAM file to data management It
establishes a 240-byte nonindexed file table or a 307+KEYSIZE-byte indexed file table.
Normally, you do not need to know what the format of the DTFIR macro is because the file
definition statements you use in your program to define the file are effectively translated
into a DTFIR macro.
If, however, you want to temporarily change your file definition at run time by using a DD
job control statement, you must know what the format is. To help you in these cases, the
DTFIR Macro format and a summary of the keyword parameters (Table 13—1) that
indicates which parameters can be changed by the DD job control statement are provided.
Examples of typical DTFIR macros follow Table 13—1 and detailed descriptions of the
individual DTFIR keyword parameters are provided in 13.4.
Format:
LABEL

filename

OPERATION

OPERAND

/xc

DTFIR

5 SRD
)

SRDO

[ADD=YES]
,BFSZ=n
[,EO FA=symbol]
[,E RROsymbol]
[,l NDA=symbol]
[,INDS=n]
[,l NDX=Y ES]
,lOAl =symbol

[,l 0A2=symbolj
[,IORG(r)]
[,KARG=sym boll
[,KLEN=n]

[,K LOCnI
[LOCK=NO]

13—16

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

LABEL

filename

I2 OPERATION

OPERAND

G
r MODE=5SE
1RAND

DTFIR (cont)

[OPTN=YES]
,RCSZn
[,SKAD=symbol]
[SQCK=YES]

F ,TYPE 5

1OUTPUT

[,UPDT=Y ES]
[,VR FY=Y ES]
[,VMNT=ON El
[,WOR K=Y ES]

Table 13—i. Summary ofDTFIRKeyword Parameters (Part 1 of 2)

Keyed Operations
Keyword

Nonkeyed Operations
Restrictions

Specification
INPUT

Remarks

OUTPUT

INPUT

OUTPUT

EXC

This DTF: read/update/add use
Other jobs: no access

EXCR

This DTF: read/update/add use
Other jobs: read use

SRD

This DTF: read use
Other jobs: read/update/add use

SRDO

This DTF: read use
Other jobs: read use

ADD

YES

Used only with keyed operations

Indicates new records are to be added
toafile

BFSZ

Always required

Supplies data buffer size

EOFA

symbol

Required if MODE=SEQ

Address of end-of-file routine

EARO

symbol

INDA

symbol

Used only with keyed operations

Address of main storage area to
contain index

lADS”

Used only with keyed operations

Indicates size of index area

INDX

YES

Used only with keyed operations

Indicates keyed operations

lOAl

symbol

Always required

Address of primary buffer

10A2

symbol

Not permitted when UPDT=YES

Address of secondary buffer

ACCESS

Address of error-handling routine

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13-17

Table 13—i. Summary of DTFIR Keyword Parameters (Part 2 of 2)

Keyed Operations
Keyword

Nonkeyed Operations

Specification

Restrictions
OUTPUT

(rl=general register

Not permitted when WORK=YES

Indicates /0 buffer index register

KARG

symbol

Used only with keyed operations

Address of field containing key of
desired record

KLEN

Used only with keyed operations

Indicates key length

KLOC”

Used only with keyed operations

Indicates the byte number location
of the key within a record

LOCK

Indicates file lock

MODE

SEQ

Sequential file processing (defaultl

RAND

Random file processing

OPTN

YES

RCSZ

Always required

Indicates record size

SKAD

symbol

Required if MODERAND

Address of seek address field

SOCK

YES

Used only with keyed operations

Indicates that sequence of keys for
ordered load should be verified

ORG

TYPE

INPUT

OUTPUT

Optional file for sequentially
processed files.

INPUT

Indicates input file type Idefaultl

OUTPUT

Indlcates output file type

UPDT

YES

Input only

Indicates update capability

VRFY

YES

Used for TYPE=INPUT and
permitted only when ADD=YES
orUPDT?YES

Read/check of output records
to be performed

VMNT

ONE

Not permitted when MODE=RAND Defines file to be processed with
unless INDX=YES
only one volume online at any tithe

WORK

YES

Also required for keyed
operations when TYPE=INPUT
and ADD=YES. Not permitted
in conjunction with ORG

LEGEND:

O
R
S
X

Remarks

INPUT

=
=
=
=

Optional
Required
Select one
Not used

Parameter may be changed on DD job control statement.
Parameter may be changed on DD job control statement for index mode Only.

Indicates that the record processing
is in a work area

13—18

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP—8068 Rev. 4

Example (IRAM Output File):
AOPERAT!ONA

LABEL

OPERAND

b1Ar

I
I 41.

COMMENTS

_
jJ
J
1

ErP bTi
At..i I
1

LAEL1rFILE 1

iii

LLEaJT

IEL

iiiilii

F5I2,

L±LLJLLLLX

I
titIti

liii

Itttitl

tAI—iTII,

itillil

i1iii

I
liii

i L

J±JiL±±L
LiiLLILJ

iii

iiIiiiiI.._

ili_li li,IiiiI

1111111

liii

ii_

j_i_iiL_

IIiLLLL_i_JJ_L

JL_J_I_J_L_LJ_LLLJ_J_J_tLL_J_LJ

I
I

iiti

LLLL

—

Example (IRAM Input File):

FJi
.iAEL

liii

1111111

FLLEJ.J

LLPLr4uT FLE

TfL 2MAm F2 P2
iLNj
j
1
i±
P
±

LilJl

FA-i LD

Jj
I

J
-

NPIP

Aj_j

—

tIcLI,I

J-_LLJ_J_L_L_J_LLJ_J

kpg AEA I It

I
t

III

t JLLi

III

—

cI=c,

III

?4=IiI

13.4.
13.4.1.

IllIlilill

j_LL

LLJJLJLJ

-I

±1

iJLl_LJL

LLL_LL_LJ

III

JJLL

LLiIL

J
1

JJ11

Iii
-

LJ_L LlLJL

LLLJ± I

t1FL1

COMMENTS

OPERAND

AOPERATIONA

LABEL

III

DTFIR KEYWORD PARAMETERS
Specifying File Accessing Options (ACCESS)

See 11.4.1 for a detailed explanation of each ACCESS keyword parameter.

Note that indexed files should not be shared in an environment that permits only one
writer to a file but any number of readers. If a file is shared, readers may get
unpredictable results; that is, DM24, DM39 error messages or no-find errors may result
when attempting to read records that were previously accessible. Consequently, the
ACCESS=EXCR or ACCESS=SRD specification should not be made for an indexed file in
either the DTFIR declarative macroinstruction or the DD job control statement.

UP8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13-18a
Update C

Records added by the writer (ACCESS=EXCR) to a nonindexed file, in a shared
environment that permits one writer and any number of readers, are not available to the
reader (ACCESS=SRD). Once the writer closes the job, any added records will be available
to users who subsequently open the file.

UP-8068 Rev. 4

13.4.2.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13-19

Specifying the Addition of Records to IRAM Input File (ADD)

The ADD parameter indicates that records may be added to. an input file during record
retrieval. These additions may be made only to indexed files processed by key.
Keyword Parameter ADD:
ADD=YES
If specified, the DTFIR declarative macro must also contain the INDX=YES
keyword parameter.
13.4.3.

Specifying the Buffer Size for IRAM File (BFSZ)

The BFSZ parameter indicates the size of the data buffer in the tRAM file.
Keyword Parameter BFSZ:
BFSZn
Is always required. n represents the number of bytes in the data buffer. The size
must be at least 256 bytes as well as a multiple of 256. To calculate minimum
buffer size, see 13.1.1.1.
13 4 4

Specifying the End-of File Handling Routine (EOFA)

When data management senses the end of data while processing an IRAM input file
sequentially by key or consecutively, it looks for the symbolic address of the user’s end-ofdata routine and transfers control there.
Keyword Parameter EOFA:
EOFAsymbol
Specifies the symbolic address (name) of your required routine that handles the
end-of-data condition for IRAM input files. This parameter is required if
MODE=SEQ is included in the DTFIR declarative macro however it is optional
for randomlyprocessed input files.
13.4.5.

Specifying Error Routines (ERRO)

When data management detects any error or exception in processing, it looks for the
symbolic address of your error-handling routine.
Keyword Parameter ERRO:
ERRO=symbol
Specifies the symbolic address (name) of the user error-handling routine. When
data management transfers control to the error routine, filenameC contains
information on the reasons for the error.(SeeTables B—i and B—3.) If ERRO
parameter is omitted, control returns to your program inline.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13.46.

Naming Main Storage Location for Index Block Processing (INDA)

13-20

During keyed operations IRAM processes index blocks in a main storage index area
Keyword Parameter INDA:
IN DA=symbol
Specifies the symbolic address of this index block processing area in main
storage. The specified area must be half-word aligned and its length must be
specified in the INDS parameter. The location of the index arëä in main storage
must immediately precede the primary I/O buffer area (lOAl). This parameter is
required for all keyed or indexed IRAM file processing.
13.4.7.

Specifying the lndexAréa Length in Main Storage (INDS)

When data management processes indexed (keyed) IRAM files, it uses an index area in
main storage. The length of this area must be defined.
Keyword Parameter INDS:
INDSn
Indicates the number of bytes used in main storage for the index area named in
the INDA parameter. The index area length must be at least 256 bytes and, in
addition, a multiple of 256 bytes. Both INDS and INDA parameters are required
specifications for IRAM indexed files.
13.4.8.

Indicating Processing by Key (IN DX)

Data management processes nonindexed and indexed IRAM files.
Keyword Parameter INDX:
INDEX=YES
Indicates that IRAM file processing is to be performed by key. This parameter is
required for input and output indexed IRAM files. In addition, the parameters
INDA, INDS, KARG, KLEN, and KLOC must be specified if INDXYES is used.

13.4.9.

Identifying the I/O Area (IOA1)

When data management processes nonindexed or indexed IRAM files, it always uses at
least one required I/O area.
Keyword Parameter IOA1:
IOA1=symbol
Specifies the symbolic address of the I/O processing area. IOA1 must be half
word aligned and greater than or equal to 256 bytes, a multiple of 256, and
consistent with the BFSZ specification. IOA1 must immediately follow the index
buffer (INDA), if specified, and must immediately precede the secondary I/O
buffer (lOA2), if specified.

UP-8068 Rev. 4

13.410

SPERRY UNIVAC 0S/3
BASIC DATA MANAGEMENT

13-21

Identifying an Additional I/O Area (10A2)

An additional I/O area may be indicated optionally for double buffering.
Keyword Parameter lOA2:
I OA2symbol
Specifies the symbolic address of secondary I/O area. Similar to IOA1, the 10A2
parameter must be half-word aligned, the same size as the required IOA1
parameter, and immediately follow the primary I/O buffer. lOA2 may not be
specified if the UPDTYES parameter is specified.
13.4.11.

Pointing to Current I/O Area (IORG)

When you are not referencing records in work areas, you must indicate an I/O buffer
index register number.
Keyword Parameter IORG:
IORG=(r)
Indicates the register number used to point to the current I/O area. Registers 2
through 12 are available. Either the IORG or WORK parameter may be specified,
but not both. If both parameters arespecified, the WORK parameter specification
is used.
13.4.12.

Naming a Place for Key Retrieval (KARG)

When using indexed (keyed) operations, the user must name and define a location in his
program where keys are placed for retrieval of IRAM records.
Keyword Parameter KARG:
KARGsyrnbol
Provides the symbolic address of the field in the user’s program where keys are
placed. The length of KARG must be equal to the specification in the KLEN
parameter plus 3. The KARG parameter is required for all keyed operations.
13.4.13.

Specifying Key Lengths for IRAM Files (KIEN)

In processing indexed IRAM files, data management must have the length of keys in an
IRAM file.
Keyword Parameter KLEN:
KLEN=n.
Specifies the number of bytes in a key for an IRAM indexed file. All keys must be
the same length; the minimum length is 3 bytes and the maximum, 80 bytes.
This parameter is required for all keyed operations.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

13.4.14.

13-22

Specifying Number of Bytes Preceding Keys (KLOC)

Often keys do not appear at the beginning of a record; when they do not, the number of
bytes offset must be indicated.
Keyword Parameter KLOC:
KLOCn
Indicates thern number of bytes preceding the key of an IRAM record. The key
location must be the same within all records of the file. If the key begins in the
first byte of the record, KLOC=O should be specified. This parameter is required
for all keyed operations. If the KLOC parameter is omitted, IRAM assumes a
value of zero; i.e., the keys begin in the first byte of each record.
13.4.15.

Suppressing a File Lock (LOCK)

For a detailed explanation of the LOCK keyword parameter, see 11.4.11.
13.4.16. Specifying Retrieval and Load Modes for Indexed andNonindexed IRAM Files
(MODE)
Data management can process IRAM files sequentially or randomly according to the
MODE keyword parameter specification.
Keyword Parameter MODE:
MODE=SEQ
Specifies sequential retrieval operations for an indexed IRAM file and sequential
retrieval or sequential load operations for nohindexed IRAM files. Sequential
mode is assumed if no MODE parameter is specified.
MODE=RAN
Specifies random (direct) retrieval operations for an indexed file and random
retrieval or random load operations for a nonindexedfile.
13.4.17.

Specifying Optional Files (OPTN)

Sometimes you will not need to use a file on every program execution. In this case, the
file is considered optional. Only sequentially processed input or output IRAM files can be
optional files.
Keyword Parameter OTPN:
OPTN=YES
Specifies that the sequential input or output file defined by the DTFIR macro is
an optional file. When this parameter is specified for an input file not allocated to
a device by the DVC job control statement data management transfers control to
your EOFA routine on the first issue of an input operation. When the OPTN
parameter is specified for an output file, data management transfers control to
your program inline and with no error.

UP-8068 Rev. 4

13.4.18.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13-23

Specifying Record Length (RCSZ)

This parameter is always required and specifies the length of each record in bytes.
Keyword Parameter RCSZ:
RCSZ=n

13.4.19.

Locating Relative Disk Address for Processing IRAM File by
Relative Record Numbers (SKAD)

When data management randomly processes files defined by the DTFIR macro, you must
specify the SKAD parameter.
Keyword Parameter SKAD:
SKADsymbol
Specifies the symbolic address of an area in your program into which you load
the relative disk address for use in processing nonindexed files by relative record.
number. The form of a record address is a 4-byte value, and the first record is
relative record 1
13.4.20.

Verifying Ascending Record Key Order during File Creation (SQCK)

Data management can verify that record keys are in ascending sequence during file
creation. This check is possible only on keyed operations, i.e., indexed files.
Keyword Parameter SQCK:
SQCK=YES
Specifies that data management should verify ascending key sequence on file
creation for indexed files.
13.4.21.

Specifying the File Type (TYPE)

The DTFIR declarative macro describes input and output files. The TYPE parameter
designates input or output file types
Keyword Parameter TYPE:
TYPE=INPUT
Specifies a read-only DTFIR file.
If omitted data management assumes the TYPE=INPUT specification You may not
issue an output function to this file unless:
•

you specify either the UPDTYES or ADDYES parameter; or

•

you close the file, reset the file processing direction, and reopen the file.

SPERRY UNIVAC 0S/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

13-24

TYPE=OUTPUT
Specifies a write-only file.
You may not issue an input function to this file unless you close, reset, and
reopen the file.

13.4.22.

Updating Records (UPDT)

When you wish to update a nonindexed or indexed input file and you have also specified
TYPE=INPUT, you specify the UPDT parameter. if this parameter is omitted, you cannot
update a file.
Keyword Parameter UPDT:
UPDT=YES
13.4.23.

Verifying Output Records (VRFY)

Data management can check parity of output records after they have been written to disk
If it detects bad parity, data management sets the parity check flag (byte 2, bit 2) in
filenameC and transfers control to your error routine or to your program inline if you have
no error routine. Specifying this parameter results in an increase in execution times for
update and file. addition operations.
Keyword Parameter VRFY:
VRFY=YES

13.4.24.

Specifying File Processing with One Volume Online at a Time (VMNT)

IRAM files created with one volume online at a time must be processed in the same
manner.
Keyword Parameter VMNT:
VMNT=ONE
Specifies that only one volume be processed online at any time. This parameter
cannot be used if the MODE=RAND parameter is specified unless the INDX=YES
parameter is also specified.
13.4.25.

Specifying Input or Output Record Processing in a Work Area (WORK)

To specify that input or output records are to be processed in a work area rather than an
I/O buffer area you specify the WORK parameter

UP8O68 Rev. 4

SPERRY UNIVAC OS/3
BASIC DAtA MANAGEMENT

13-25

Keyword Parameter WORK:
WORK=YES
May not be specified ifl the same DTFIR with the IOREG parameter When you
Issue the input output or file addition operations you specify the address of the
work area The WORK parameter is required for indexed files when
TYPE=OUTPUT or when TYPE=IN PUT and ADD=YES.
13.4.26.

Nonstandard Forms of the Keyword Parameters

OS/3 data management accepts certain variant spellings for the keyword parameters
described in this section. These variations are:
DTFIR
Spelling

OS/3
Standard Form

BFSZ
EOFA
ERRO
IN DA
INDS
IN DX
IOA1
l0A2
IORG
KARG
KLEN
KLOC
0 PTN
RCSZ
SKAD
TYPE
UPDT
VRFY
WORKA

B LKS IZE/B KSZ
EOFADDR
ERROR
INDAREA
INDSIZE
INDEXED
IOAREA1
IOAREA2
IOREG
KEYARG
KEYLEN
KEYLOC
OPTION
RECSIZE
SEEKADDR
TYPEFLE/TYPF
UPDATE
VERIFY
WORKA

13.5.

IRAM KEYWORD
SUPPORT ONLY

PARAMETERS

—

DO JOB CONTROL STATEMENT

The following keyword parameters can be specified only by using a DD job qontrol
statement.

___

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

13.5.1.

13-26

Variable Sector Support for IRAM Files (VSEC)

In IRAM files, both the data and index partitions in the DTF specify a fixed sector size of 256
bytes. This is required for the sectorized devices (841 5, 8416, and 8418 disk subsystems),
which are formatted for a 256-byte sector. The selector channel devices (8411, 8414, 8424,
8425, 8430, and 8433 disk subsystems) have no such constraint. However, they are
preformatted at OPEN time to accept the 256-byte sector size. This sectorization requires
hardware overhead and thus decreases the effective capacity of the disk.
Variable sector support eliminates the problem. It allows you to create IRAM files with data
partition sector sizes larger than 256 bytes on the selector channel devices. Since the
hardware overhead remains constant, the use of the larger sector size increases the
effective capacity of the disk.
To use variable sector support, you must specify it in a DD job control statement that you
include in your job control stream when the file is created. The format of this DD job control
statement is:
// DD VSEC= çn
WES
where:
VSECn
Specifies the sector size (number of bytes) to be used in creating the file.
VS EC=YES
Specifies that the sector size is to be computed at OPEN time, based upon record
size and buffer size. The computed sector size will be the largest multiple of record
size that does not exceed the buffer size.
If you use a DD statement to specify a sector size for a file, the statement must be used in
all subsequent job control streams that access the file, unless you specify the ACCEPT
parameter in the LFD statement for the file. If you do, the DD statement that specifies
variable sector support may be omitted.
The message DM17 INVALID BLOCK SIZE SPECIFICATION is displayed if you use the VSEC
parameter incorrectly in a DD job control statement. This occurs if:
•

a sector size other than 256 bytes is specified for a sectorized device;

•

the VSEC parameter specifies a sector size that is different from the sector size used to
create the file; or

UP-8068 Rev. 4

•

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13-27

changing the sector size results in the buffer size being less than the minimum buffer
size required To compute the minimum buffer size the following rules apply
If the record size divides evenly into the sector size, the minimum buffer size is
equal to the sector size.
—

—

13.5.2.

If the record size is a multiple of the sector size, the minimum buffer size is equal
to the record size
If neither of the preceding rules apply, add the sector size to the record size,
subtract 1, and then round up to the next multiple of the sector size to find the
minimum buffer size.

File Recovery Support for IRAM Files (RECV)

When you perform operations such as adding or updating records to a file, the physical file
structure constantly changes during execution of your program If your program runs to
completion and the file is successfully closed, the file limits information contained in the file
labels is updated. If a system failure occurs, the file is not closed and the file limits
information is not updated. The effect of a system failure on a nonindexed file is that the file
reverts back to its original state before it was opened For example added records are lost
In the case of an indexed file system failure may cause the file to be compromised that is it
must be recreated.
File recovery support eliminates these problems It allows you to create IRAM files that can
be reopened after system failure. It does this by updating the file limits information and
writing it on the disk each time an operation that affects the information is performed. If you
have specified file recovery and there is a system failure, you can reopen your file because
the file limits information was saved
To use file recovery support, you must specify a DD job control statement that you include in
your job control stream when the file is created The format for this DD job control
statement is:
// DD RECV=YES
This statement is only valid at file creation time. It should not be included in the job control
stream for subsequent jobs that process the file after creation.
If a system failure occurs during file creation, you will have to start over because the file
creation program must run to completion and the file must be successfully closed before
you can use the file recovery facility. If file creation is successful, the file recovery facility is
activated each time you open the file.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

1328

If you are processing an indexed file (created with file recoveryj where the physical file
structure is changing and the structure modification process is interrupted by an operator
cancel, HPR, or a hardware I/O error, the file may be compromised. If the file is
compromised and you attempt to reopen it the error message DM66 FILE COMPROMISED
is displayed to inform you that the file should not be used. If you want to open the file solely
for reading its data contents in order to recreate the file, the file recovery support facility
allows you to override the error condition. This is accomplished by including the appropriate
DD job control statement in the job control stream when you reopen the file. The format for
this DD job control statement is:

// DD RECV=FCE
This statement causes the file compromised error to be ignored. The message DM66 FILE
COMPROMISED does not appear when the statement is present. The statement should not
be used unless you receive the error message, and then only if you want to reopen the file
to read its data contents in order to recreate the file.
13.5.3.

Automatic Computation of Initial Allocation Percentages for IRAM Files
(AUTO)

Normally when an indexed IRAM file is created 50% of the initial allocation is assigned to
the data partition, and 1% is assigned to the index partition. The remainder is left as
unassigned space to be used for logical extensions to the file. As the file is loaded, the data
partition and the index partition are filled at different rates. This results in the two partitions
extending on an alternating basis which, for large files, tends to rapidly use up the extent
table entries. This causes the extent table to be exhausted and the error message DM45
EXTENT TABLE EXHAUSTED to be displayed.

—

Automatic computation of initial allocation percentage helps minimize the problem It
causes the entire initial allocation to be assigned to the index and data partitions in a
calculated ratio based upon the record and key sizes.
To use the automatic computation of initial allocation percentage you must specify it in a
DD job control statement that you include in your job control stream when the file is
created. The format of this DD job control statement is:
// DD SIZE=AUTO
This statement is only valid at file creation time and has no effect at other times When it is
encountered in the file creation job control stream for an IRAM file, this statement causes
n% of the initial allocation to be assigned to the data partition and (100—n)% to the index
partition. The value n is calculated at file open time and is dependent upon the record and
key sizes.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 3-29

There are two major factors that determine the accuracy of the calculated ratio:
1.

The manner in which the file is loaded: Space in the index partition is used more
efficiently if the records are loaded in ascending key sequence rather than in unordered
key sequence.

The size of the file: Due to possible roundoff in the computation, the result is more
accurate for relatively large files than for smaller files. For example, a given set of
record and key lengths may yield a ratio of 3 to 1. For a 100 cylinder file, the allocation
would be 75 cylinders for the data partition, 25 cylinders for the index partition. For a
10 cylinder file, the allocation would be 8 cylinders for the data partition, 2 cylinders for
the index partition.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13A.

13A.1.

13A-1

MIRAM Formats
and File Conventions

GENERAL

The multiple indexed random access method (MIRAM), a sixth disk access method in
OS/3, is used for handling sequential, relative, and indexed files in programs that are
written in the OS/3 1974 American National Standard COBOL language, and for
sequential and relative (direct) files in programs that are written in FORTRAN IV language.
MIRAM provides the same functions as those provided by OS/3 ISAM, ASAM, IRAM,
SAM, and DAM disk access methods. A MIRAM file may reside on any of the disk
subsystems used with OS/3, and it may occupy from one to eight disk packs, which must
be of the same type.
The MIRAM processor can access only MIRAM characteristic files and IRAM characteristic
files that it has created or IRAM files created by the IRAM processor. It cannot access disk
files that have been created by the ISAM, ASAM, DAM, or SAM access methods, nor can
MIRAM files be processed by these access methods. MIRAM files can be processed by
using the sort/merge program, however, and by the data utilities program.
A MIRAM characteristic file is one that meets any of the following conditions:
I

More than one key per record is permitted.

‘

The file contains variable-length records.

•

Records may be logically deleted from the file (RCB is present).

•

Duplicate record keys are permitted, or key changes are allowed on update.

The length of a key in a record is one or two bytes.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

13A—2
Update B

An IRAM characteristic file differs from a MIRAM characteristic file in that it meets none
of the conditions required for the latter; that is:
•

Onlyone key per record is permitted.

•

The file contains fixed-length records.

•

Records cannot be logically deleted from the file (RCB not present).

•

Duplicate record keys or key changes during update are not permitted.

•

The minimum length of the record key must be three bytes.

Note that IRAM characteristic files can be accessed by all programs that access IRAM
files.
The discussions that follow deal with MIRAM characteristic files. For information on IRAM
characteristic files, refer to Section 1 2.

13A.1.1.

MIRAM Concepts

MIRAM has a number of features and concepts that distinguish it from other disk access
methods.
•

The data record slots in MIRAM files for either fixed- or variable-length records are
of uniform size ani may span physical blocks, sectors, tracks, and cylinders as
required. They may even extend from one volume to another (unless the file was
created for processing only a single volume at a time).

•

Data records are written on disk compactly as a continuous string of bytes.

•

The string of data records can always be accessed sequentially (consecutively) or by
relative record number. In addition, the data can be specified to be indexed by up to
five keys; this causes MIRAM to build a suitable index structure for each key type in a
partition separate from the data.

•

An indexed MIRAM file can be accessed by the additional random-by-key or
sequential-by-key modes using a given key of reference, which can be changed.

•

Indexed MIRAM files, either multivolume or single-volume, may be created by means
of an orderly load (records submitted in ascending key order) or a disorderly load
(records submitted in no particular key order) and they may be extended by appending
records in either manner. MIRAM does not sort the index at the completion of a
disorderly load, but maintains the index current on a record-by-record basis.

•

MIRAM files are always extended unless the INIT parameter is specified on the LFD job
control statement of the device assignment set. The EXTEND parameter is not
supported for MIRAM files.

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

13A-3

•

Duplicate keys are permitted.

When a new record has been added to an indexed or nonindexed file, it is
immediately available for retrieval.

Multivolume MIRAM files may be created for processing with either one volume
online at a time, or with all volumes online. They must be processed in the same
manner as they were created.

All programs that access a MIRAM file need not use the same data buffer size for
input/output as was used to create the file. Those that access an indexed MIRAM
file, however, must use the same index buffer size.

MIRAM allows you to logically delete recordS in your files; that is, it allows you to
mark records so that in subsequent processing they will be ignored.

MIRAM’s restrictions are:
—

—

The maximum key length is 80 bytes.
No byte of a record key may contain the hexadecimal value ‘FE’.
The minimum size for the index buffer is 256 bytes.

13A.2.

MIRAM FILE ORGANIZATION

All MIRAM characteristic files contain two partitions: the data partition, which MIRAM
defines to the system access technique (SAT) as containing 256-byte unkeyed physical
blocks, and the index partition, which is defined as containing 256-byte keyed blocks. If
the file is a nonindexed file the index partition is not used that is no entries will be
placed in it and no space will be allocated to it. If the file is an indexed file, entries will be
placed in the index partition and space will be allocated to it.
For indexed files, the data partition precedes the index partitions, which begins on a
separate cylinder.

1 3A.2.1.

The Data Partition

The data partition is arranged in the same way for both nonindexed and indexed files. It is
cylinder-aligned and consists of a single compact string of data records that may be keyed
or unkeyed. The formats of the MIRAM data records are shown in Figure 1 3A—1
.

1 3A-4
Update B

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

FIXED-LENGTH WITHOUT KEYS

c
b

data,

‘:

R
S

-4

FIXED-LENGTH WITH KEYS

key 1

c
b

key 2

data

2
—L

data

‘“1
R—

S
VARIABLE—LENGTH WITHOUT KEYS

RDW

4—

—Ii-

VARIABLE-LENGTH WITH KEYS

key 1

key 2

data

4—

RDW

—H

2
L

LEGEND:
Record control byte (optional). Used to indicate that a record has been logically deleted from the file. For MIRAM
fixed-length records, this byte is placed at the beginning of each record. For variable-length records, the third
byte of the record descriptor word (RDW) is used as the rcb.

rcb

Length of the logical record (RDW plus keys plus data). You specify this length as the number of bytes. For
variable-length records, this value, expressed in binary, must be placed in the first two bytes of the RDW.

Figure 13A—1.

MIRAM Characteristic Data Record Formats (Part 1 of 2)

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13A—4a
Update B

RDW

4-byte record descriptor word for variable-length records. The first two bytes contain the logical record length (r)
expressed in binary; the third byte may be used as the rcb; the fourth byte is not used.

L n

The starting location of record key n (n = 1 through 5) of a MIRAM file data record when the key does not start
in the first byte of the record. L n represents the number of bytes (RDW plus data) that precede key n. The
starting location of key n must be the same in each record. Key n must have the same length in each record (a
minimum of 1 byte and a maximum of 80), and no byte may contain the hexadecimal value ‘FE’.

Slot size. All records are written into fixed-size slots. Slot size equals the record size + 1 for fixed-length
records with a record control byte; otherwise, slot size equals the record size. Slot size for variable-length
records equals maximum record size + 4-byte record descriptor word.

Padding.
Figure 13-.--1.

MIRAM Characteristic Data Record Formats (Part 2 of 2)

UP8068 Rev. 4

13A—5

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

When data records are stored in a MIRAM file, the records are placed in uniform size
record slots and are arranged in the same order you originally presented them to the
MIRAM processor. These data records are stored in 256-byte physical blocks or sectors on
your disk packs. Since the record slot size does not have to conform to the physical block
or sector size, the records may span these physical boundaries as shown in Figure 13A—2.
EXAMPLE 1
PHYSICAL BLOCK 1 OR SECTOR 1

PHYSICAL BLOCK 2 OR SECTOR2

PHYSICAL BLOCK 3 OR SECTOR 3

*
2

EXAMPLE 2
PHYSICAL BLOCK 1 OR SECTOR 1

PHYSICAL BLOCK 2 OR SECTOR 2

PHYSICAL BLOCK 3 OR SECTOR 3

------

—---------

—------

EXAMPLE 3
PHYSICAL BLOCK 1 OR SECTOR 1

PHYSICAL BLOCK 2 OR SECTOR 2

PHYSICAL BLOCK 3 OR SECTOR 3

NOTES
1.

All physical blocks or sectors are 256 bytes.

1, 2, 3

Record slots in Example 1 are approximately 190 bytes each.

Record slots in Example 2 are approximately 300 bytes each.

Record slots in Example 3 are approximately 70 bytes each.

...

n represent record slots.

Figure 13A—2.

MIRAM Data Record Slots Spanning Physical Block or Sector Boundaries

Your data records may also span track boundaries, cylinder boundaries, and volume
boundaries (except when a multivolume file is created for processing with only one volume
online at any one time). When new records are added to a file, they are appended to the
existing data record string; that is, they are added at the end as a continuation of the
original string.

1 3A.2.2.

13A-6

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Entries in the Index Partition

If you have keyed records, entries are placed in the index partition as these records are
loaded into the data partition. MIRAM extracts all the keys from each record (a maximum
of five keys is permitted) and constructs a 3-byte pointer for each of the keys from the file
relative record number of the position the record was written to. From these it forms an
index entry for each of the keys in the record and stores them in the index partition. The
index entry for each key consists of the key plus three bytes (it is equal to the specified key
length plus threebytes) and it is stored in an area of theindex partition, which is called a
fine-level index. If you had three keys ift each record, the index entryfor each key would
be stored in a separate fine-level index; that is, the entry for key 1 would be stored in the
fine-level index for key 1, the entry for key 2 would be stored in the fine-level index for key
2, and the entry for key 3 would be stored in the fine-level index for key 3.
A fine-level index is not formatted for hardware search, unlike the other levels of index
that will be described subsequently. It is treated as a chain of multisector blocks where
each sector is 256 bytes long. All entries in a fine-level index are maintained in ascending
key order. Figure 1 3A—3 shows a typical fine-level index block of three sectors.

FLAGBYTE
CURRENT NUMBER OF ACTIVE BYTES

CHAIN TO NEXT
FINE BLOCK

—

CONTROL AREA
ISLASTSIX
BYTES OF INDEX
BLOCK

INACTIVEAREA
ACTIVE ENTRIES
-

[
CONTROL AREA
Figure 13A—3.

Fine-Level Index Block

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13A-7

When a fine-level index is created, another hierarchical level of index is always created
the coarse-level index. This is hardware searchable and is composed of 256-byte blocks
that contain entries similar to those in the fine-level index. They differ, however, in that
the 3-byte pointer in each coarse-level entry does not represent the file-relative number of
a record in the data partition Instead it points to another index block at a lower level
either a fine-level block or a block in what is called a mid-level index. Another difference is
that instead of having a 6-byte control area, each coarse-level block uses its final byfe to
indicate the number of active entries. The entries in a coarse-level block are filed in
descending key order. The high key of the block is the first one encountered by the
hardware search and its length is equal to the longest key in the group plus four bytes.
Both the coarse-level and mid-level blocks have the same format (Figure 13A—4).
—

—

ACTIVE ENTRIES

iNACTIVE AREA

FINAL
BYTE
SECTOR

Figure 13A—4

13A.2.3.

Coarse or Mid Level Index Block

MIRAM Index Structure

As you know, you can specify up to five keys for a file. For each key that you specify, the
MIRAM processor will build a separate index structure. In those cases where you have
more than one key, these separate index structures will allow you to use any of the key
types as the key of reference to access your data records when you subsequently use the
file in a program.
When the MIRAM processor builds an index structure for your file, it creates a minimum
of two levels of index: a fine-level index and a coarse-level index, If your file is very large,
one or more mid-level indexes are created as needed. The fine-level index consists of one
entry for every record in the data partition of your file. The fine-level entries are filed in
ascending key order until an index block (256 bytes) is filled. At this time, one coarse-level
entry is made that points to the high key entry of that filled fine-level block. As each finelevel block is filled, another coarse-level entry is made. This process continues until all
your records are on file.
The coarse-level index is automatically allocated by MIRAM. Its size is always one track
regardless of the type of disks being used. If the coarse-level index is filled before all your
records are on file, a mid-level index is created. The MIRAM processor allocates two
tracks, designates them as a mid-level index, and copies the entries from the coarse-level
track onto these tracks. It then places two entries in the coarse-level index. Each entry
points to a high key in one of the tracks in the mid-level index. In this manner the entries
on the coarse-level track are replaced by two entries. As new fine-level entries are
recorded, one entry is made in the coarse-level index for each filled index block in finelevel index and when the coarse-level index is filled a new mid-level index is created just
as before. This process continues until all records are on the file. Figure 1 3A—5 shows the
structure of a MIRAM index.

134-8

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

COARSE LEVEL

1 TRACK

MID LEVEL
(IF NECESSARY)

ADD 2 TRACKS AT A
TIME AS NEEDED

ONE ENTRY FOR
EVERY RECORD IN
DATA PARTITION

FINE LEVEL

Figure 13A—5.

1 3A.2.4.

MIRAM Index Partition

Retrieving Records from an Indexed MIRAM File

To show how records are retrieved from an indexed MIRAM file, assume that a file with a
4-level index has been created. A search for a specific data record by key in this case
would proceed as follows:
•

the search begins in the coarse-level index;

•

a hit is made that points to the first mid-level index

•

the new mid-level is searched;

•

a hit is made that points to the second mid-level index;

•

the second mid-level is searched

•

a hit is made that points to the fine-level index

•

the fine-level is searched

•

a hit is made that points to the data record in question; and

•

the data record is retrieved

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

13A.2.5.

1 3A-9

Estimating Disk Space Required for an Indexed MIRAM File

The following procedure will allow you to estimate the number of cylinders for your
primary allocation of disk space to an indexed MIRAM file. The result is a good
approximation that you can use in specifying the EXT statement in the job control device
assignment set that allocates disk space for an indexed MIRAM file to be created by your
program. This procedure can also be used to determine the number of cylinders to be
allocated for an indexed MIRAM file that is to be generated from another file by the OS/3
data utility program.
The: number of cylinders required for an indexed MIRAM file includes those occupied by
the data partition and the index structures for each key type in the file. To estimate the
number of cylinders the file will require proceed as follows
First, calculate D, the number of sectors required for your data records (the data partition).
Step 1:
D

record-length

number-of-records
S

where:
S is the sector size. The default size is 256 for all types of disk subsystems. For 8411,
8414, 8424, 8425, 8430, and 8433 disk subsystems, this value can be greater than
256.
Next, calculate B
, the number of index blocks required by your fine-level index for key.
1
Step 2:
B

number-of-records (keylength
1 + 3)
(256’m)—6

where:
the factor of 4/3 is used because the average fine-level index will be 3/4 full.
m is the number of 256-byte sectors in the index buffer. (See 138.3.1.)
Then calculate F, the number of 256-byte sectors required by your fine-level index for
.
1
key
Step 3:
F

1
B

Repeat steps 1 through 3 as many times as necessary and then calculate F, the number of
256-byte sectors required by your fine-level indexes for all keys in the file.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

13A-1O

Step 3a:
n
1
F= F

where:
n is the number of keys in the file.
Then perform the final calculation. This calculation, which is the sum of the data
requirements and the fine-level index requirements, represents over 95 percent of the
space required for an indexed file. Once this is determined, it is a simple matterto figure
out what your space requirements are for a given file.
Step 4:
F
C=U.N
145

D
+AN
L2

where:
C

Is the number of cylinders to allocate to the indexed MIRAM file.
Is the disk dependent number of 256-byte sectors per track for data partition
(Table 13A—1).

D
Is the number of 256-byte sectors required for the data partition.
F

Is the number of 256-byte sectors required by all the fine-level indexes in
the file.
Is the disk-dependent number of 256-byte sectors per track for index
partition (Table 13A—1).

N
Is the disk dependent number of tracks per cylinder (Table 13A—1).

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 3A-1 1

Example:
Assume that you want to calculate the number of cylinders to allocate for an indexed
MIRAM file and the following conditions apply:

‘

Number of records

77,500

Record length

512 bytes

1
Keylength

28 bytes

2
Keylength

30 bytes

Sector size (data partition>

256 bytes

Index buffer length

512 bytes

Type of disk

8433

1
B

record length

512

155,000 sectors for data partition.

1
F

2
B

number-of-records
256

77,500
256

number-of-records (keylength
1 + 3)
(256m)-6
77500
(256

(28+3)
2) 6
-

(4
3

6331 index blocks required for the fine-level index for key
.
1

1
mB

26331

1 2 662 sectors for the fine level index for key
1

number of records (keylength
2 + 3)
(256m)-6
77,500 (30 + 3)
(2562)-6

6739 index blocks required for the fine-level index for key
.
2

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

2
F

2
mB

26739

1 3A-1 2

13,478 sectors for the fine-level index for key
.
2
F
F
=

F+F

12,662 + 13,478

26,140 sectors for all the fine-level indexes for all keys in the file.

The maximum coarse-level index on an 8433 disk can contain 132 sectors. As you
can see, this number is too small to contain all of the index blocks for either of the
keys.
—

F
UN

D
AN

(26,140 + 58 + 2090)
2919

155,000
3319

299 cylinders to be allocated to the file.

NOTE:
After you have calculated your disk space requirements and you proceed to create your
file, you must provide enough volumes to hold the file. This must be considered because
the amount of space available is not the same for all types of disk. Refer to Table A—4 to
determine how many volumes you will need based upon your calculations and the type of
disk you intend to use.

‘13A.2.6.

Estimating Disk Space Required for a Nonindexed MIRAM File

The following procedure will allow you to estimate the number of cylinders required for
your primary allocation of disk space to a nonindexed MIRAM file. First, you must calculate
D, the number of 256-byte sectors required for your data records (13A.2.5). Then, divide by
the product of A times N (from Table 13A—1):
D
C=A

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table 13A— 1.

SPERRY UNIVAC
Disk Subsystem

13A-13

Disk-Dependent Factors for Determining Disk Space Requirements

U
(Number of 256-byte
sectors per disk track
for index partition)

A
(Number of 256-byte
sectors per disk track
for data partition

N
(Number of tracks
per disk cylinder)

8415

2*
3**

8416

8418

8411

8414

8424

8425

8430

8433

*Removable portion
**Fixed portion

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 3B.

13B.1.

13B—1

Functions and Operations
of MIRAM

GENERAL

Before you create a MIRAM file (a MIRAM characteristic file unless noted otherwise) you
must carefully consider how you will use the file in subsequent programs because this
governs how it should be created. If you expect to process unkeyed records consecutively
or you need to access specific records quickly without processing the preceding ones, the
file should be created as a nonindexed file. If you intend to process keyed records either
consecutively or randomly, the file should be created as an indexed file.
After you have created a MIRAM on file, you can perform retrieval, update, and other
operations either consecutively or randomly, or you can switch back and forth between
consecutive and random operations. Both nonindexed and indexed MIRAM files that span
two or more volumes can be created with only one volume online (mounted) at a time, or
with all volumes online. A multivolume file must always be processed in the same way it
was created; only one volume is online at a time, or all volumes are online.
The discussions that follow are at a general level. For details of the actual programming
statements you use for creating and processing MIRAM files in OS/3, refer to the OS/3
1974 American National Standard COBOL programmer reference, UP—8613 (current
version), or the OS/3 FORTRAN IV supplementary reference, UP—8474 (current version).

13B.2.

PROCESSING NONINDEXED MIRAM FILES

A nonindexed file is one that is organized consecutively. Its records are written on the disk
in the physical order they are presented to the MIRAM processor. The records are
processed consecutively in the order they appear on the disk. A nonindexed file can also
be one that is organized relatively; each record in the file is written on the disk in a
specific position relative to the beginning of the file (independent of the order in which
they are presented to the MIRAM processor). This allows any record in the file to be
retrieved directly without processing any preceding records when the location of the
record is specified.
The following subsections describe the general procedures for creating and processing
nonindexed files.

UP-8068 Rev. 4

13B.2.1.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 3B—2
Update B

Creating a Sequential MIRAM File

If you want to create a file for sequential processing, you must define the file as a
sequential output file in your program You must also specify the uniform size of your
record slots and the size and address of your data buffers (I/O areas). If you have variablelength records, the slot size must be large enough to hold the maximum size record plus
the required 4-byte record descriptor word (RDW). You may use two data buffers, each
half-word aligned, but they must be contiguous and the same size. The minimum data
buffer size that you can specify for your program is determined as follows:
If the slot size divides into 256 without remainder, the minimum buffer size is 256
bytes.
If the slot size is a multiple of 256, the minimum buffer size is equal to the slot size
If the slot size does not divide into 256 without rèmàinder and is not a multiple of
256, add 255 to the slot size and roUnd this sum upward to the next multiple Of 256
(Note that for fixed-length records, the slot size + 1 mustbe used in your buffer
calculation: This is required because space must be provided in the buffer for the extra
byte, the RCB, that is appéñded to the front of:eachfixedlength record by the MIRAM
processor and is not counted when you specify your slot size.)
This calculation also applies when you create relative or indexed files. If you specify data
buffers larger than the minimum, you may improve your program’s performance. Note that
when a file is processed in subsequent programs, you do not have to speäify the same
data buffer size that you used to create the file but it must be at least the minimum
After you open the file, you submit your records, one after the other, until you have no
more recOrds. The records are stored in the data partition in the order you submitted them.
When the file is subsequently processed, it is processed in the same Order. The MIRAM
processor records the relative record number of the last record written in the file control
table and the volume table of contents.
13B.2.2.

Extending a Sequential MIRAM File

Once a sequential file has been created, it can be extended (enlarged) only by appending
new records at the end Of the existing data string. Records cannot be inserted between
existing records nor can they be appended during retrieval or update operations
Extending a sequential file is essentially the same process as creating the file because the
same specifications are made. The difference is that you must define the file as a
sequential file that is to be extended rather than a sequential output file. After you open
the file you submit the new records, one after another, as in file creation, and they are
stored in consecutive order starting after the last record of the existing data string.

UP-8068 Rev. 4

13B.2.3.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13B-3

Adding Records to a Sequential MIRAM File

If you wantto enlarge a sequential file by inserting records between existing records or
appending records at the head of the existing data string, you must use some other
processor. A way to solve this problem is to sort the new records into the consecutive
sequence you expect to process them, and then use them as an input file (together with
you sequential MIRAM file) to the sort/merge program or the data utilities program to
create a new sequential file with the new records in the proper order. Refer to the
sort/merge user guide
UP—8342 (current version) or the data utilities user
guide/programmer reference, UP-8069 (current version) for details.
13B.2.4.

Retrieving and Updating Records in a Sequential MIRAM File

You can retrieve records or retrieve and update records in sequential (consecutive) order in
a sequential file. For sequential retrieval, you must define the file as a sequential input file
in your program. For sequential retrieval and update, you must define the file as a
sequential file for update. You can provide two data buffers. If you do, the lengths of these
buffers need not be the same as the data buffer that was used to create the file. However,
if two buffers are used, each one must be the same size as the other.
The MIRAM processor will provide the records in the same order that they were written on
disk when the file was created or extended. Consecutive retrieval will continue until you
close the file or the end of file is reached If the file is to be terminated by end of file you
must have specified the address of a routine for handling this situation in your program
Records may not be appended during retrieval operations or retrieval and update
operations.
13B.2.5.

Deleting Records from a Sequential MIRAM File

If a MIRAM file is defined as a sequential file in your program, you cannot logically delete
records from your file (mark specific records so they will be bypassed when the file is
processed in subsequent programs). To delete records, the file must have been created as
a relative file.
13B.2.6.

Reorganizing a Sequential MIRAM File

At some point you may want to reorganize a sequential file. Perhaps your experience in
using the file has shown that a different physical sequence of records would be more
convenient. There are two methods that you can use to reorganize your file
the
sort/merge program or the data utilities program. Either of these will accept your file as
input and resequence the data records. For details, refer to the sort/merge user guide,
UP—8342 (current version) or the data utilities user guide/programmer reference,
UP—8069 (current version).
—

UP-8068 Rev, 4

13B.2.7.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 3B-4

Creating a Relative MIRAM File

If you require a file in which each data record is to be assigned to a specific position on
disk, you must create a relative file. You do this by defining the file as a relative output
file. You must also specify the uniform size of your record slots and the size of your data
buffer. The minimum data buffer calculation is the same as that described for a sequential
file in 13B.2.1.
After you open the file, you present each record, one by one, to the MIRAM processor in a
work area you have defined along with the file relative position the record is to occupy.
This position is not a disk address. It is a 4-byte file-relative number (relative to the
beginning of the file; position 1 is relative record number 1, etc) that you supply in a field
you have defined before you issue the output function to write the record to disk.
The method you use to determine the relative record number that you assign to each
record is up to you. It can be a potential source of trouble if you are not careful; the
method you use may generate a relative record number of a record that has already been
placed on the file, If an output function is issued in this situation, the attempt to place the
new record in an occupied position will be rejected and an error condition will result.
13B.2.8.

Extending a Relative MIRAM File

Extending a relative file is essentially the same as creating it. You provide each record to
be placed in the file in a work area, and you supply the relative record address for the
record in a predefined field before you issue the output function. If you direct a record to a
point beyond the current file end (established at file creation: that is, the relative record
address of the last valid record on the file), any gap will be filled with void records. If you
direct a record to a position short of the file end, the operation will be rejected if it is
occupied by a valid record,
13B.2.9.

Retrieving and Updating Records in a Relative MIRAM File

You can retrieve records or retrieve and update records in a relative file sequentially
(consecutively> or randomly by relative record number. You also have the ability to switch
retrieval methods (between sequential and random retrieval), and to specify at what point
you want to commence sequential retrieval.
For sequential retrieval, define the file as an input file for sequential processing. For
retrieval with update, define the file as an update file. When you issue an input function,
retrieval begins automatically with the first record position in the file.
If you do not want to begin your sequential processing with the first record, you can issue
a function that establishes the starting point. This must be done after the file has been
opened and before you issue an input function. To establish a starting point, you must
place a relative record number in a predefined field in your program and then use the
starting point function to specify where the starting point is to be; that is, the starting
point is equal to, greater than, or not less than the relative record number you have
supplied. Your first input function retrieves the record at the starting point. The
subsequent input functions will retrieve the records in consecutive order. You can change
the starting point at any time while the file is open.

UP-8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13B-5

For random retrieval by relative record number, define the file as an input file for random
retrieval. For retrieval with update, define the file as an update file. For random retrieval,
you must supply the relative record number of the desired record in a predefined field in
your program before you issue an input function. If you update a retrieved record, the
output function to rewrite this record does not require you to supply a relative record
number.

13B.2.1O.

Deleting Records From a Relative MIRAM File

If you want to logically delete records from a relative file, you must define the file as an
update file. After the file is opened, you can delete a record by first issuing an input
function for that record, and then following this with a delete function. The delete function
logically deletes the record by marking it as a void record. (The record is not physically
removed from the file.> The marking process consists of setting the high order bit in the
RCB.
When a deleted record is encountered in subsequent sequential processing, it is bypassed.
If you are retrieving records randomly and you specify the relative record number of a
deleted record, it is treated as a no find.
13B.2.11.

Reorganizing a Relative MIRAM File

If you want to reorganize a relative file, you cannot do it in a straightforward manner. For
example, if you have logically deleted records in a relative file and you use the data utility
program to remove the invalid records and recopy the file, the relative position of the valid
records will change. This occurs because the valid records are copied in the same
consecutive order that they appeared on the old file. As a result, any subsequent
processing of the new file may prove unsatisfactory because the valid records will not be
where they originally were.
A possible solution would be to use the data utility program to remove the invalid records
and copy the valid records to a sequential file. This sequential file could then be used as
input to a relative file creation program that will place the valid reóords in the positions
you want them to be.
13B.3.

PROCESSING INDEXED MIRAM FILES

An indexed MIRAM file contains a data partition with the data records ordered
consecutively in the order that you submitted them, and an index partition that consists of
one or more index structures arranged in ascending key order. The number of index
structures is governed by the number of keys specified for the file. Each data record can
contain from one to five keys (uniform length character strings that uniquely identify the
record). A key may start at the head of the record or may be embedded within it; however,
the location of each key type must be the same for all records in the file. Duplicate key
values are permitted.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13B-6
Update D

When you create an indexed file for processing one volume online at a time or with all
volumes online, you can submit your records to the MIRAM processor as an orderly load
or a disorderly load. The former means that the data records are submitted in ascending
key order and the latter that the records are submitted in any other order. In both cases,
the records are placed in the data partition in the order submitted; however, the keys are
always arranged in ascending key order in the index structures. The following subsections
describe the general procedures for creating and processing indexed files.
13B.3.1.

Creating an Indexed MIRAM File

To create an indexed MIRAM file you must define the file as an indexedoutput file in your
program. You must also specify the following:
•

uniform size of your record slots;

•

the size and address of your data buffers;

•

the length and location of all keys in your records;

•

the size and address of your index buffer; and

•

the address of a field in your program that is to contain a search key.

If you have variable-length records, the slot size must be large enough to hold the
maximum size record plus the required 4-byte record descriptor word (RDW) You may use
two data buffers (each half-word aligned), but they must be contiguous, the same size, and
they must immediately follow the index buffer. The minimum data buffer calculation is the
same as that described for a sequential file in 13B.2.1.

The index buffer is also half-word aligned and must be at least 256 bytes in length. It
can be larger; however, if it is, it must be a multiple of 256 bytes up to a maximum of
32,512 bytes. The index buffer must immediately precede the primary data buffer. A
good rule to apply when determining your Index buffer size is to multiply the sum of the
largest specified key pIus 3 bytes by 20, rounding the result up to the next multiple of
256.
The length of the field that is to contain a search key must be equal to the length of the
largest key in your file plus three bytes.
After you open the file, you present each record to the MIRAM processor in a work area
you have defined, and then you issue an output function to write the record to disk.
13B.3.2.

Extending an Indexed MIRAM File

Extending an existing Indexed file is essentially the same process as creating the file As
in creating the file, you present each record to the MIRAM processor in a work area you
have defined and then you issue an output function to write the record to disk. The
records are appended to the end of the data string in the data partition. Your records can
be submitted as an orderly load or a disorderly load. In either case, the records are placed
in the data partition in the order submitted and the record keys are placed in the index
structures in ascending key order. After a record has been successfully added to the file, it
is immediately available for retrieval because the index structures are updated each time a
record is added to the file.

UP-8068 Rev. 4

13B.3.3.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

13B—7

Retrieving and UpdatingRecords in an Indexed MIRAM File

You can retrieve records or retrieve and update records in an indexed file sequentially
(consecutively) or randomly by key. You also have the ability to switch retrieval methods
(between sequential and random) and to specify at what point you want to commence
sequential retrieval.
For sequential retrieval; define the file as an input file for sequential processing. For
sequential retrieval with update, define the file as an update file.
After the file is opened, the sequential position is established at the lowest key value in
the key index structure. If you want a different starting point, you must establish a new
starting point (the value of the record key at which retrieval is to begin). To do this, you
must place a key value in a predefined field in your program and then use the starting
point function to specify where the starting point is to be; the starting point is equal to,
greater than, or not less than the key value you have supplied. Your first input function
retrieves the record at the starting point and the subsequent input functions will retrieve
the records in consecutive order.
After a sequential-by-key retrieval sequence has been started, you can continue it until:
•

you reach the end of file or the end of volume;

•

you specify a new starting point;

•

you change the file processing mode from sequential to random; or

•

you close your file or it is closed as the result of an error.

For random retrieval by key, define the file as an input file for random retrieval. For
retrieval with update define the file as an update file For random retrieval you must
supply the key of the desired reóord in a predefined field in your program before you issue
an input function. If you update a retrieved record, the output function to rewrite this
record does not require you to supply a key value.
If you are performing a sequential retrieval sequence and you interrupt it to perform a
random retrieval operation, the sequential retrieval sequence cannot be resumed at the
point it was interrupted (unless random retrieval with hold is requested)
If you have specified that duplicate keys are permitted and you are performing a sequential
retrieval sequence, records with duplicate keys will be retrieved in the order they were
presented to the file during file creation. If you perform a random retrieval, the first record
encountered in a duplicate key series that contains a key equal to the search key will be
retrieved.

UP-8068 Rev. 4

13B.3.4.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 3B—8

Adding Records to an Indexed MIRAM File during Retrieval

You can add records to an indexed file during retrieval if you have defined the file as an
update file. To add a record during retrieval you must provide the new record in a
predefined work area in your program, and then issue an output function to place it in the
file. The record will be placed in the file if the value of the record key is less than: or
greater than any key in the file, or it falls within the range of the existing keys. If you have
specified that duplicate keys are not permitted, the record will be rejected if its record key
duplicates the key of a record that is already in the file.
If you interrupt a sequential retrieval sequence to add a record, the sequence will be
resumed at the point it was interrupted when you issue the next input function.

13B.3.5.

Deleting Records from an Indexed MIRAM File

If you want to logically delete records, you must define the file as an update file. After the
file is opened, you can delete a record by first issuing an input function to retrieve the
record and then follow this by a delete function. The delete function logically deletes the
record by marking it as a void record. (The record is not physically removed from the file.)
This marking consists of setting the high order bit in the RCB.
When a deleted record is encountered in subsequent sequential processing, it is bypassed.
If you are retrieving records randomly and you specify the key of a deleted record, it is
treated as a no find.
13B.3.6.

Reorganizing an Indexed MIRAM File

Your experience in processing an indexed file may indicate that the file should be
reorganized. For example, your processing may have logically deleted a large number of
records and you want to compress the file by physically removing these records. Another
reason to reorganize is that the file was created or extended with disorderly load and you
want to improve your program s performance because the majority of your processing
involves sequential retrieval.
In the former case you can use the data utility program to delete the invalid records In
the latter case, you can use the sort/merge program to sort your data records in
ascending key order. For details refer to the data utilities user guide/programmer
reference, UP—8069 (current version) or the sort/merge user guide, UP—8342 (current
version)
13B.4.

DEFINING AN OS/3 MIRAM FILE (DTFMI)

The DTFMI declarative macro is used to define a MIRAM file. It establishes a 388-byte file
table.
Normally, you do not need to know what the format of the DTFMI macro is because the
file definition statements you use in your program are effectively translated into a DTFMI
macro.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 3B-9

If, however, you want to temporarily change your file definition at run time by using a DD
job control statement, you must know what the format is. To help you in these cases, the
DTFMI macro format and a summary of the keyword parameters (Table 13B—1) that
indicates which parameters can be changed by the DD job control statement are provided
Examples of typical DTFMI macros follow Table 1 3B—1 and detailed descriptions of the
individual DTFMI keywordparameters are provided in 13B.5.
Format:
LABEL

filename

LOPERATION t

DTFMI

OPERAND

EXC
EXCR

ACCESS=

SRDO

,BFSZn
[,EOFA=symbol]
[,ERROsymbol]
[,l NDA=symbol]
[,INDS=n]
,lOAl=symbol
[,lOA2=symbol]
[,IORG(r)]
[,KARG=symbolj
[KEYn(ss[l1

[{NDuP}] [{NCHG}])]

[,LOCK=NO]

r,MODE= (SEQ
RAN
I

[

(RANH

{*}]

[,OPTN=YESI
[PRoc=

[,RCB=NO]
[RcFM=

{R}1

,RCSZn

rI,RETR
[

(1NF?.
MOD
(REP

,SKAD=symbol
[,VMNT=ONEJ
[,VRFY=YES]

[,WOR K=Y ES]

13B—1O

SPERRY. UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table 13B—1.

Summary of DTFMI Keyword Parameters (Part 1 of 2)

Keyed
Operations

Nonkeyed
Operations

EXC

This DTF read/update/add us
Other jobs: no access

EXCR

This DTF: read/update/add use
Other jobs: read use

This DTF: read use
Other jobs: read/update/add use

SRDO

This DTF: read use
Other jobs: read use

BFSZ*

EOFA

symbol

Address of end-of-file routine

ERRO

symbol

Address of error handling routine

INDA

symbol

Used only with keyed
operations

Address of index buffer

INDS**

Used only with keyed
operations

Indicates size of index buffer

IOA1

symbol

Always required

Address of primary data buffer

lOA2

symbol

Only allowed with sequential
output or unkeyed sequential
input

Address of secondary data
buffer

IORG

(r)=general
register

Not permitted when
WORK=YES

Indicates I/O buffer index
register

KARG

symbol

Used only with keyed
operations

Address of field that contains key
of desired record

KEYn

Used only with keyed
operations.
n>1, key length <3,
duplicate keys, or changes
to keys not permitted
for IRAM characteristic
files.

Indicates key length, key
location, and whether duplicate
keys or changes to keys are
allowed

LOCK

Indicates file lock

MODE

SEQ

Sequential file processing
ldefaultl

RAN

Random file processing

RANH

Random file processing lhold sequential
position)

OPTN

YES

Optional file

PROC

KEY

Keyed lindex and data) operation
Idefaultl

UNK

Nonkeyed Idatal operation

Keyword

ACCESS

Specification

.SRD

Remarks

Restrictions

Always required

Supplies data buffer size

UP-8068 Rev. 4

Table 138—1.

Keyword

RCB

1 3B-1 1

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

•f•

Summary of DTFMI Keyword Parameters (Part 2 of 2)

Keyed
Operations

Nonkeyed
Operations

Remarks

Restrictions

Required for IRAM
characteristic files

No record control byte
-

Fixed-length records (default)

FIX

VAR

Not permitted for IRAM
characteristic files

Variable-length records

RCSZ

Always required

Indicates record size

RETR

INF

Update not allowed

Retrieval for
information (default)

MOD

Retrieval for modification

REP

Retrieval for replacement

SKAD

symbol

VRFY

YES

VMNT

ONE

Nonkeyed random operations
and random output
operations not allowed,

Defines file to be processed
with only one volume
online at a time

WORK

YES

Required for all output,
keyed update, and delete
functions

Indicates that record processing
is in a work area

RCFM

Always required

Address of seek
address field
Check parity of output records
after they have been written

LEGEND:
= Optional
O
R
=Required
S
= Select one
X
=Notused
*parameter may be changed on DD job control statement.
**parameter may be changed on DD job control statement for indexed file only.

13B-i2

SPERRY UNIVAC OS/3

UP-8068 Rev. 4

BASIC DATA MANAGEMENT

Example (MIRAM Output File):
OPERAND

AOPERATlONL

LABEL

RfrATfl FtR EATLN A4
1
F
1 XUT7
1, s < 3, DUP, and CHG are not permitted.
13B.5.12.

Suppressing a File Lock (LOCK)

See 11.4.11 for a detailed explanation of the LOCK keyword parameter.

13B.5.13.

Specifying Processing Mode for MIRAM Files (MODE)

MIRAM files can be processed sequentially or randomly as specified by the MODE
keyword parameter.
Keyword Parameter MODE:
Specifies sequential file processing. This is the default case.
MODE=RAN
Specifies random file processing.

MODE=RANH
Specifies random file processing (hold sequential position).

UP-8068 Rev. 4

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

13. B.5 .14.

13B-17

Specifying Optional Files (OPTN)

If your program does not need to use a particular file each time you execute the program,
the file is considered an optional file. Only sequentially processed files can be optional
files.
Keyword Parameter OPTN:
OPTN=YES
Specifies that the sequentially
parameteris specified for afile
statement, control is transferred
operation Control is transferred
issue an output operation

13B.5.15.

processed file is an optional file. When this
not allocated toa deviceby a DVC job control
to your EOFA routine when you issue an input
to your program inline with no error when you

Specifying Type of Operations (PROC)

When you process a file you must specify the type of operations you are going to perform
(keyed operationsor. nonkeyed operations).
Keyword Parameter PROC:

PROc=KEY
Specifies keyed operations. This is thedefault case.
PROC=UNK
Specifies nonkeyed operations.
.

1 3B.5.1 6.

Specifying Record Control Byte (RCB)

When a file is created, a record control byte (RCB) is appended to the beginning of each
record unless you specify that you do not want this.
Keyword Parameter RCB:
RCB=NO
This specification only applies to files that are being created. It is required for
IRAM characteristic files and it specifies that each record is not to contain a
record control byte. If this parameter is specified, delete functions will not be
permitted when the file is subsequently processed. The default case is that each
record will contain an RCB. When the file creation program is completed and the
file is closed, the format label is marked to indicate whether or not the RCB is
present. Once the file is created, this format label indication cannot be changed;
that is, if you subsequently process the file and attempt to use the RCB
parameter, the format label indication will override it.

SPERRY UNIVAC OS/a.
BASIC DATA MANAGEMENT

UP-8068 Rev.4

13B.5.17.

13B-18
Update B

Specifying Record Format (RCFM)

This parameter specifies the record format, either fixed-length or variable-length.
Keyword Parameter RCFM:

RCFM=FIX
Specifies fixed-length records. This is the default case.

RCFM=VAR
Specifies variable-length records. The first four bytes of a variable-length record
is the record descriptor word (RDW). The first two bytes of the RDW contain the
effective record size that you supply on output and data management supplies on
input. The record size includes the 4-byte RDW. Variable-length records are
contained within a fixed-size slot that is equal to the RCSZ specification.

13B.5.18.

Specifying Record Length (RCSZ)

This parameter is always required. It specifies the length of each record in bytes.
Keyword Parameter RCSZ:

RCSZn
Specifies the length of each record in bytes. If you have variablerecords, this
parameter should specify the maximum size plus the 4-byte record descriptor
word (RDW) required for variable-length records. (See Figure 1 3A—i.)
13B.5.19.

Specifying the Record Retrieval Purpose (RETR)

If you are going to retrieve records for other than information purposes, you must use this
parameter.
Keyword Parameter RETR:

RETR=INF
Specifies that records are to be retrieved for information purposes only. This is
the default case
RETR=MOD
Specifies that records are to be retrieved for modification
RETR=REP
Specifies that records are to be retrieved for replacement

UP-8068 Rev. 4

13B.5.20.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 3B-1 9

Specifying the Location of the Relative Disk Address for Processing a
MIRAM File by Relative Record Numbers (SKAD)

This parameter is always required. It specifies where the relative disk address is placed in
your program for use in processing by relative record number.
Keyword Parameter SKAD:
SKADsymbol
Specifies the symbolic address in your program where you place the relative disk
address for use in processing files by relative recordnumber. The form of the
relative disk address is a 4-byte value. The first record is relative record 1.
1 3B.5.21.

Verifying Output Records (VRFY)

You can specify that data management is to check the parity of output records after they
have been written to disk.
Keyword Parameter VRFY:
VRFY=YES
Specifies that data management is to check the parity of output records after
they have been written to disk. If it detects bad parity, data management sets the
parity check flag (byte 2, bit 2) in filenameC and transfers control to your error
routine, or to your program inline if you have no error routine. If you specify this
parameter, it will result in an increase in execution times for output operations.
13B.5.22.

Specifying File Processing with One Volume Online at a Time (VMNT)

If you want to process a file with one volume online at a time, you must specify this
parameter.
Keyword Parameter VMNT:
VMNT=ONE
Specifies that the file is to be processed with only one volume online at any time.
A file that is created in this manner must be processed in this manner. Nonkeyed
random operations are not permitted. If a file was not created for processing with
one volume online at a time, it cannot be processed in this manner.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

1 3B 5 23

1 3B—20

Specifying Record Processing in a Work Area (WORK)

You can use this parameter to specify that your records are to be processed in a work area
rather than in a data buffer (I/O) area.
Keyword Parameter WORK:
WORK=YES
Specifies that input and output records will be processed in a work area rather
than a data buffer area. The IORG parameter should not be specified when the
WORK parameter is specified. If both are specified; the WORK parameter is used.
When you issue input, update, output, or delete operations, you specify the
address of the work area. The WORK parameter is required for all output, keyed
update, and delete operations.
13B.5.24.

Nonstandard Forms of the Keyword Parameters

OS/3 data management accepts certain variant spellings for the keyword parameters
described in this section. These variations are:
DTFMI
Spelling

OS/3
Standard Form

BFSZ

BLKSIZE/BKSZ

EOFA

EOFADDR

ERRO

ERROR

INDA

INDAREA

INDS

INDSIZE

IOA1

IOAREA1

10A2

IOAREA2

IORG

IOREG

KARG

KEYARG

OPTN

OPTION

RCFM

RECFORM

RCSZ

RECSIZE

SKAD

SEEKADR

VRFY

VERIFY

WORK

WORKA

UP-8068 Rev. 4

13B.6.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

MIRAM KEYWORD PARAMETERS
SUPPORT ONLY

—

1 3B-21

DD JOB CONTROL STATEMENT

The following keyword parameters can be specified only by using a DD job control
statement.
13B.6.1. Variable Sector Support for MIRAM Files (VSEC)
The detailed explanation of this facility for IRAM files (13.5.1) also applies to MIRAM files.
13B.6.2. File Recovery Support for MIRAM Files (RECV)
The detailed explanation of this facility for IRAM files (13.5.2) also applies to MIRAM files.
1 3B.6.3.

Automatic Computation of Initial Allocation Percentages for MIRAM Files
(AUTO)

The detailed explanation of this facility for IRAM files (13.5.3) also applies to MIRAM files
except that normally 0% of the initial allocation is assigned to the index partition for MIRAM
files.

UP-8068 Rei”

SPERRY UNiVftC 05/3
BASi&bAtA.MANGEMENT’

14-1

14. Nonlndexed Disk .!.!!e.Fonats
and Convcfl.tlons..

•

:‘

•

!‘.

•

‘“

•

-t

.r.t.

14.1. GENERAL
This section describes the disk file formats and conventions that are part of the indexed
fife proáess& syetéth- bf OS,’3 data m’añageinenf. the syêtérvl coffiprises thréè basic
methods for proceésing or accessing disk filéi Withotkt ihdexèt’thflequential accesA
method (SAM); the çijrect access method (DAM); and a combination of these two, termed
ft
simply the “nonindexedméthod;” ‘ikhiÔh has floactonth.
.

•.

‘The three ‘rñthods of -prôdessing are e,plained in detail in Section 15,’Which .describá:
C

‘.

.;•Th

‘

,,atfc:

‘:tI

! ••

•r

the 1tiical inpótibutput onttbl-’ 5fltem (IOCS)?br proceáSoi,’ that .GS?’3 data
management fôrnistiew’yo& for each method,
.

•

“the” iñ’ipèrative th &f ctiI%
i
pt&essinà tdhctioiih’dváflable to yäá

the actual t1epèñoire of

.fjI

‘
‘:

the define-the-file (DTF) ‘declarative macros you will use to inform data management
how your files are to be accessed and how you have structured them.

Jn.both this ection and Sectiqnl 5, the..tprrn “DTF”. is appljed bçth to, tbis type of
døpjat9ti%e mcro ap tb the fil fable that acti Dli pets up for data management to use
While ypu are procesbihg 9our file
-j

•

‘-‘

t’

•

f’’!’

‘“

‘

t)’.

•

:•

•

‘

•

‘:

-•

•

‘

•

YoU deline your sequeittilly rocessed disk files to iata managenierif with the DTFSD
Ies dre often called DTPl) fileI Dfrdct “access, tr
6
declarative macrd, conséqtient, these’
randomly processed, files (these trths ate dyñohympus in this manGal) ate defined t3 the
DTFDA declarative macrà and are termed DtFDA files FiFes ‘that’ypu want to process by a
combination of bOth seiuentiai e}d ‘ahdoni’tedhriipiéi ydu Will ‘liefihé .tb ‘data
maragernent.with the DTFNI dQclarative:maro. You may subdivide your DTFNI files iqto
s many as seJen filq )artilions, you defibe Certain dtai1s of each partl&in With yet a
1
of DTF dedaratlS,& macro the DPCArnacrcr
•

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

14-2

To summarize:
Three access methods:
Sequential access meth od (SAM)

•

Direct access method (DAM)
Nonindexed access method (a combination of SAM and DAM techniques)
Four define-the-file (DTF) declarative macros:
DTFSD

defines a sequentially processed, nonindexed disk file

—

DTFDA

—

defines a randomly processed (direct access), nonindexed disk file

defines a nonindexed disk file that is to be processed sequentially randomly
DTFNI
or by a combination of both techniques
—

DPCA

—

defines certain particulars of a partition of a DTFNI file

The various access methods and nonindexed disk file descriptions share certain concepts
of file organization, file labelling, record formats, and record addressing; these are
described generally in this section, although some, details are further developed in Section
15. You will notice some differences from the OS/3 indexed sequential access method
(ISAM), described in earlier sections of this manual; chief of these, of course, is the
absence of any index structure. Another difference is that ISAM does not allow you to
have your own header and trailer labels A third point of difference lies in the concept of
keys (14.3.3).
14.2.

FILE ORGANIZATION

All DTFSD DTFDA and DTFNI files in the OS/3 nonindexed processor system may reside
on one or more disk volumes and may be termed multivolume files Multivolume DTFNI
and DTFDA files must have all volumes of the file mounted and online for processing and
may consist of no more than eight volumes. Multivolume DTFSD files are maintained in
only one of your disk packs being online at any time there is no
single-volume mode
limit imposed by OS/3 on the total number of volumes you may have in a DTFSD file
Data management communicates with the operator for you automatically to request and
validate mounting of the successive ‘olumes of a multivolume DTFSD file
—

All OS/3 nonindexed disk files are terminated by a logical end-of-file (EOF) pointer to the
block one after the highest block in the file in which you have placed a data record The
address of this block is file- or partition-relative; that is, its nUmbering is related to the
if you are considering a partition of a file
address of the block that begins the file or
begins this partition. The significance of the logical EOF pointer lies in the actions that
occur when the address is accessed during sequential processing of an input file.
—

—

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

14-3

In DTFSD files (which have only one volume moUnted online at a time), the EOF pointer
also indicates the logical end-of-volume (EOV) for the online volume. When you have
finished creating such a file and issue the CLOSE imperative macro to terminate
processing, data management stores the address of the block next after the current block
as the EOF/EOV pointer or end-of-data ID (EODID) in the DTF file table and on the disk
format 2 label for the file. No special flag or notatiori is written in the data area at this
relative disk address. When data management encounters the EOF address during input of
your file, it transfers control to a routine you have prepared to handle the end-of-file
condition. (This routine, called the EOFADDR routine from the keyword parameter by
which you specify it in your DTF, is described in 15.6.4; see 15.7.2 for the CLOSE macro.)
You should remember that, for multivolume DTFDA and DTFNI files (all volumes of which
are mounted and online at all times when you are processing), there is no EOV in the
DTFSD sense and no need for an EOFADDR routine except for input DTFNI files you
process sequentially.
14.2.1.

Partitioning DTFNI Files

You may subdivide each DTFNI file into as many as seven file partitions, each with its own
partition name, record size, block size, and other characteristics. You define the overall file
characteristics, name all the file partitions, and describe the first partition in the DTFNI
declarative macro; you then use separate DPCA declarative macros for each partition to
define the characteristics of the partition. Every DTF file table has a length of 242 bytes,
but the table established by the DPCA declarative macro is only 82 bytes long; it is termed
the partition control appendage. You access a file partition for processing by name, using
the SETP macro (15.7.4).
14.2.2.

Subfiles in DTFNI Partitions

You may further subdivide each partition of a DTFNI file into as many as 71 serial subfiles,
which you must create in sequence. (They need not be processed sequentially, and you
may access them for processing in any order, once you have created them.) Unlike a file
partition, which may. differ in certain characteristics from the basic DTFNI file, a subfile
must not differ from the partition in any respect. Another difference between a subfile
and a partition is that a subfile has no name; you address one by using its partition
relative serial number asan operand of the SETS macro by which you access your subfiles
(the SETS macro is described in 1 5.7.5). To help it keep abreast of your processing of
subfiles, data management maintains subfile tables; it reserves one track of the first
volume of a file for these when you so instruct it by specifying the SUBFILE keyword
parameter in your DTFNI or DPCA declarative macro (15.6.26). Figure 14—1 depicts the
organization of a DTFNI file into partitions and subfiles.

14-4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

FILE

Characteristics defined by DTFNI
declarative macro instruction
-

Characteristics defined by
DTFNI
declarative
macro
instruction;
selected by
SETP imperative
macro

FILE
PARTITION-2

FILE
PARTITION-i

Characteristics defined by DPCA declarative macro instru tions
selectedby SETP imperative macro

FILE
PARTITION-n
(maximum of
7 partitionsl

SUBFI LE
SUBFILE
Characteristics are
those of parent
partition. Supported
via SUBFILE keyword
parameter in DTFNI
or DPCA macros,
Accessed (after partition is
selected by SETP macrol
via SETS macro.
Created serially; may
be accessed randomly.

Figure 14—1

14.2.3.

SUBFILE
2

(maximum
of 7 i)

UBFILE

Organization of a DTFNI Disk File into Partitions and Subfdes

System Standard Labels for Nonindexed Disk Files

In processing your DTFSD, DTFDA, and DTFNI files, data management uses the OS/3
system standard labels for disk files. The system standard labels comprise the OS/3
standard volume label (VOL1). and seven types of disk format labels, designated format 0,
format 1, and so on, located in a directory called the volume table of contents (VTOC). Data
management accesses these standard labels to retrieve information it needs about your
file and to add information on certain file characteristics to thern All are described in
Appendix D
For example,.data management retrievesthé VOL1 label to find the location Of the VTOC.
Here, it will read the first record. in the VTOC (the format 4 label) to obtain the address Of
the last active format 1 :label and will search the VTOC up to that address to locatethe
format 1 label for the current file. It needs this format 1 label, and any format 3 labels it
may point to for information about the extent space and secondary allocation for the file
If your file is an output file, data management will rewrite the format 1 label to add to it
some of the file characteristics you have defined in your DTF. If your file is currently an
input file, data management retrieves and checks these characteristics. In addition, data
management maintains a format 2 label to control file partitions and save information on
existing and newly created files.

UP—8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

14-5

A look at Appendix D will make the foregoing clearer when you need to go into it. For the
moment, however, it may be more important for you to know that these actions of data
management are automatic and that you will rarely need to be concerned with the details.
(Section 16 has further information on management of your disk resources.)

14.2.4.

Optional Standard User Labels

Unlike OS/3 ISAM, which does not allow them, the non indexed file processor system does
support standard user header labels (UHL) and user trailer labels (UTL). These are optional,
unblocked records, which you may process on the opening or closing of a volume with a
routine you make available to data management by specifying its address in the LABADDR
keyword parameter in your DTF (1 5.6.14).
14.2.4.1.

User Header Labels

If you have UHL, data management writes these on the first track of each volume of a
DTFSD file, and on the first track of the first volume of a DTFDA or DTFNI file. You may
have no more than eight UHL, and they may not be blocked. This is their simple 80-byte
format:
Byte

Label ID

I-

Label Data

‘1—
76

Field

Bytes

Code

Description

Label ID

0—3

EBCDIC

Contains 4-byte label identifier:
UHL, followed by a label number
which ranges from 1 through 8

Label Data

4—79

User option

Contains 76 bytes of user-specified
header label data

14-6

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

User Trailer Labels

14.24.2.

Data management writes your optional UTL On the first track of each volume of a DTFSD
file and on the first track of the first volume DTFDA or DTFNI files; your UTL follow your
UHL. You may have no more than eight, and they may not be blocked. This is their 80-byte
form:

Byte

LabeliD

4
I-.

14.3.

Label Data

Field

Bytes

Code

Description

Label ID

0—3

EBCDIC

Contains 4-byte label identifier:
UTL, followed by a label number which
ranges from 1 through 8

Label Data

4—79W

User option

Contains 76 bytes of user-specified
trailer label data

NONINDEXED FILE RECORD FORMATS

The nonindexed •processor system handles four record formats:
•

Fixed-length, blocked

•

Fixed-length, unblocked

Variable-length blocked

•

Variable-length, unblocked

DTFSD and DTFNI files may comprise records in any of these four formats, but DTFDA files
may not be specified as having blocked records (that is, physical blocks containing more
than one logical data record, fixed- or variable-length).

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

14-7

It might be well at this point to review three OS/3 definitions:
block
The portion of a file transferred into or out of main storage by a single access.
buffer
An area in main storage for handling a block of data. Must not be. smaller than
the blocks to be handled.
record
The collection of contiguous characters, designated as such to data management
by the user, for handling as a unit. Record size must not exceed block size.
The system does not handle undefined records; if you do not specify the record format in
your DTF, data management assumes that your records are fixed and unblocked (that is,
you have only one fixed-length logical record in each physical block). No record may
occupy more than one block, nor may any record or block span from one disk track to
another.
14.3.1.

Fixed-Length Records

Fixed-length logical records are all of equal length for a given file or partition. When you
specify that your fixed-length records are unblocked (or leave this specification to data
management’s default assumption, just mentioned), you do not need to specify the
RECSIZE keyword parameter because data management takes the nUmber of bytes per
records as being what you specified with the BLKSIZE keyword. However, when you block
your fixed-length records, you must specify both the BLKSIZE and RECSIZE keywords, and
the value of BLKSIZE must be an exact multiple of RECSIZE.
When you are using thevariable-sector SPERRY UNIVAC 8411, 8414,8424, 8425, 8430,
or 8433 Disk Subsystems, your BLKSIZE specification governs exactly the number of
bytes of data read or written. On the other hand, if you are using the fixed-sector SPERRY
UNIVAC 8415, 8416, or 8418 Disk Subsystem and do not specify a blocksize that is a
multiple of 256 bytes, the block written will always be larger than the specified block size;
this is because the system writes or reads only in multiples of 256 bytes to the 8416 disk
Your BLKSIZE specification controls the number of bytes treated as data within a logical
block, which is a multiple of 256. (For example, if you specify BLKSIZE=400for a file that
is to reside on an 8416 disk, data managementwill write out a block Of 512bytOs.) You
must be sure to reserve adequate buffer space for this:circumstance,because a512-byte
block will be read into the buffer during retrieval
Figure 14—2 illustrates the two fixed-length record formatsand their relationship to the
I/O area and DTF keyword parameters.

14-8

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

FIXED-LENGTH, UNBLOCKED RECORD

logical record

—D—

FIXED-LENGTH, BLOCKED RECORDS

D—

LEGEND:
D

Length of data in each logical record; you specify this length only when your records are blocked, using the RECSIZE
keyword parameter in your DTF macro.

Length of I/O area; you always specify this with the BLKSIZE keyword parameter of your DTF macro instruction. If
your file is to reside on an 841 6 disc, I must be a multiple of 256 bytes, and therefore the length of the blockmay
exceed the nearest multiple of fixed-record length.

NOTE:
In preparing the illustration of blocked records, the arbitrary choice was made to show four logical records per physical block. The
actual number you choose is a matter of file design. Remember that blocking snot specifiable for DTFDAfiles.
Figure 14—2.

Fixed-Length Physical Record Formats, Nonindexed Disk Files without Keys

14.3.2. Variable-Length Records.
When your records re variable-length, OS/3 data management preempts the first four
bytes of every block for use as a block descriptor word (BDW) Data management
calculates the effective length of the block and inserts this for you into the first two bytes
of the BDW; it reserves the last two bytes of the BDW for its own use. You need not be
concerned with the BDW, therefore, other than to allow for the fact that it reduces by four
bytes the block space availablefor yôür logical records.
You are concerned, however, with the first four bytes of every logical record; these are
also needed by data management for control and constitute the record descriptor word
(RDW).
Data management, again, reserves the final two bytes of the RDW for its own use, but the
first two bytes must contain the length of the record of which the RDW is a part. Before
submitting a new record to be blocked, you must place the proper binary value in this 2byte field.

UP-8068 Rev. 4

14-9

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

When you specify that your records are variable and unblocked, data management will
write out one block for each logical record you submit, regardless of the amount of
available space remaining in the I/O area. If you have specified blocked records, data
management will pack as many complete records as possible into each block before
writing it. In either case, the length of the block it writes will be the number of bytes you
have specified with the BLKSIZE keyword parameter, unless more must be written
because of roundup for the 8416 disk.
Unless your logical records follow some unusual pattern, there will always be varying
amounts of unused space at block ends.
You must not use the RECSIZE keyword parameter in your DTF for a file containing
variable-length records because data management expects to find the record size in the
first two bytes of the RDW.
Figure 14—3 illustrates the layout of both formats for variable records and relates these to
the length of the I/O area.
VARIABLE-LENGTH, UNBLOCKED RECORD

VARIABLE-LENGTH, BLOCKED RECORDS

41
—
4
j

D
V

—

-4

LEGEND:
B

Block descriptor word, four bytes. You must reserve space for this in your I/O area; it is also part of the block on
disc. Data management calculates the block length in bytes and writes this in the first two bytes of the BDW; the last
two bytes are reserved.

Record descriptor word, always first four bytes of each variable-length record. You determine the length of each
logical record in bytes, including this 4-byte RDW, and place it in the first two bytes of the RDW. The last two
bytes are reserved.

Figure 14—3.

Variable-Length Physical Record Formats, Nonindexed Disk Files without Keys (Part 1 of 2)

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

14-10

LEGEND (cont):
0

Variable length of the data portion of your record.

Length of the variable record (measured in bytes); includes four bytes for the RDW. You insert this number into the
first two bytes of the RDW, in binary form.
Length of the physical block, both on disc and in the I/O area. The I/O area length you specify via the BLKSIZE keyword
parameter must accommodate the largest variable-length block in your file.
Unused space

F I

Supplied by data management

NOTE:
In preparing this illustration of blocked records, an arbitrary choice was made to show two logical records per physical block.
The actual number you choose is a matter of file design, Remember that you may not specify blocked record format for
DTFDA files. This does not mean that OS/3 DAM does not handle the block format in which the unblocked variable-length
record is shown here and actually exists on disc. It does. The point is that DAM does not block or deblock records for you. If
what you can only describe to DAM via the DTFDA macro as an unblocked record is actually a block of logical records, you
must provide for blocking and deblocking them yourself.
You will probably find the DTFNI file the better alternative; for one thing, the PUT and GET imperative macros may
be issued to a DTFNI file for record level access; but they cannot be issued to a DTFDA file. In random processing
of a DTFNI input file containing fixed, blocked records, data management provides you with the displacement of the
desired record in the block, loading this into filenameD after the READ/WAITF macro sequence.

Figure 14—3.

14.3.3.

Variable-Length Physical Record Formats, Nonindexed Disk Files without Keys (Part 2 of 2)

Optional Key Fields with Nonindexed Files

Up to this point, our discussion of record formats has ignored an optional feature you may
want to include in the design of your DTFDA and DTFNI files: a leading key to identify each
physical block.
A key in the nonindexed file processor system is simply a character string, unrelated to the
disk location of a physical block, which you specify and write with the block to uniquely
distinguish that block from all others in the area of search. Search can be confined to a
single track or can run from starting point to end of cylinder. Key length has certain limits,
but key content is almost entirely up to you. The only restriction is that no byte of any key
may contain the hexadecimal value FE. This value may produce erratic results during
keyed retrieval. Otherwise, keys to your files may be constructed according to any scheme
meaningful in the context of your file-processing needs, although uniqueness within the
search area is assumed to be necessary because you will search for one specific block in
the area, seeking to identify it by its key alone. Keys may be used with DTEDA and DTENI
files, and partitions of DTFNI files; they are not used with DTESD files.*

*QS/3 data management does not provide you with a means for using keys in processing your DTFSD files because, in
sequentially constructed files like these, each block is afready uniquely identified by its relative location. OS/3 assumes that
your reasons for organizing the file for sequential access only do not include a need to identify a block by some other means.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT,

14-11

If you are familiar with OS/3 ISAM, YOU might note at this point that, in the nonindexed
file processor system, you associate a key only with a physical block, whereas in ISAM
each of your logical records may have a key.
Sequential processing does not necessarily preclude the presence of keys. A DTFNI file or
partition, for example, which you may always process sequentially, may have a key
associated with each block of data. If it does, moreover, you must take the key into
account when you issue the sequential access PUT and GET imperative macros to process
the file. (This point is developed further in 15.7.9.5.)
A point to note here, perhaps, is that processing a file with the OS/3 sort/merge program
is quite different from sequential processing in the data management sense. With
sort/merge, you are concerned only with sequential organization of files and use the term
key in a very different sense: a record may contain a number of fields, located anywhere
within it, which sort/merge uses to resequence the file. Each of these fields is considered
a sorting key; these may overlap and need not be unique. In the data management
nonindexed system, however, keys are used only in direct access files and only with
blocks; each block has only one key, always unique, and always located in front of the
block.
You have noted that the length of the key has certain limits in the nonindexed processor
system: the minimum key length is 3 bytes, and the maximum is 255 bytes. Another point
to remember is that all keys in any one file must have the same length; the only exception
to this rule is the partitioned DTFNI file, in which each partition may have its own unique
key length, uniform throughout the partition. You may not include blocks without keys in a
file of keyed blocks.
When you are processing blocks with keys, you inform data management of the actual key
length it will find or place with your blocks on disk by specifying the KEYLEN keyword
parameter in the DTFDA, DTFNI, or DPCA declarative macro.
The various forms of the READ and WRITE imperative macros are designed to give you a
useful set of options for retrieving records by key and writing or updating the key and data
portions; these are described in Section 15.
The effects of keys on the physical block length and, consequently, on the layout of your
blocks on disk and in the I/O buffer are illustrated in Figure 14—4 for both fixed and
variable records.

14-12

SPERRY UNIVACOS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

FIXED-LENGTH, UNBLOCKED RECORp

key field

logical record

FIXED-LENGTH, BLOCKED RECORDS

logical record
1

key field

logical record
2

—D

—

VARIABLE-LENGTH, UNBLOCKED RECORD

key field

bdw

logical record

rdw

e—B-—ø

R
—V
I

—

VARIABLE-LENGTH, BLOCKED RECORDS

4—

._44_ R

Figure 14—4.

—

D
V

Keyed Fixed- and Variable-Length Physical Record Formats, Nonindexed Disk Files (Part 1 of 2)

UP-8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

14-13

LEGEND:
K

Key field, supplied by you. Minimum 3 bytes, maximum 255. All keys in same partition or file must have same
length. Notice that only a block has a key; individual records within a block do not.

Block descriptor word, always four bytes. You reserve space for this at the head of the block, after the keyfield; data
management calculates and inserts block length into first two bytes. Last two bytes are reserved.

Record descriptor word, always the first four bytes of your variable-length record. You determine the length of each
logical record in bytes, including this 4-byte ROW, and place it in the first two bytes of the ROW. The last two
bytes are reserved.

Length of the data portion of your logical record; varies for variable-length records. Always the same for each fixedlength record throughout file.

Length of a variable record; includes four bytes for the ROW. You insert this number (measured in bytes) into the
first two bytes of the ROW, in binary form.

Length of the physical block, both on disc and in your I/O area. The I/O area length you specify via the BLKSIZE
keyword parameter must accommodate the largest physical block in a file of variable-length records.
Unused space, if any

Supplied by data management

NOTE:
In preparing these illustrations of blocked records, an arbitrary choice was made to show two logical records per physical
block, in both the fixed- and variable-length formats. The actual number you choose is a matter of file design. You may not
specify that records are blocked for DTFDA files.

Figure 14—4.

Keyed Fixed- and Variable-Length Physical Record Formats, Nonindexed Disk Files (Part 2 of 2)

UP-8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15.

15.1.

15—i

Nonindexed File Access Methods:
Füflction and Operation

GENERAL

This section describes the nonindéxed file processor system used with OS/3 data
management. Tha nonindexed file processor system is a generalized input/output control
system (IOCS) that enables you to create and maintain data files on all disk subsystems
supported byOS/3 and toprócess these files in a sequential order, a random order, or by
a combination of both sequential and random file processing techniques. It offers standard
techniques for processing sequentialaccess method (SAM) files and direct access method
(DAM) files, as well as enhanced capabilities for processing nonindexed files by a
combination of both methods
The nonindéxed processorsystemoperates on disk files that you describe to OS/3 data
management through DTF (define the file) declarative macroinstructions:
•

SAM files are defined by the DTFSD declarative macro;

•

DAM. files by the DTFDA declarative macro; and

nonindexed files through the DTFNI macro.

You provide descriptive information to the declarative macros by specifying the keyword
parameters associated with each. From these, data management builds the appropriate
DTF file table for the type of file you have selected.
You perform I/O operations upon your file by issuing imperative macroinstructions in your
basic assembly language (BAL) program. These, providing the essehtial interface between
your program and OS/3 data management are what you use to access and generate data
within your file and to position it fOr more effective processing. Data management
communicates directly with the:resideht systems access technique (SAT) of the OS/3
supervisor for access to the physical input/output control system (PIOCS).

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-2

The transient routines invoked by the OPEN macro, for example, complete setting up your
DTF file definition tables and perform certain checks to ensure the integrity of your
definition. Once you have opened a file, you may then access it via the imperative
processing macros (GET, PUT, CNTRL, READ, WRITE, etc). You terminate your file
processing by issuing a CLOSE macro and can then do no further processing on the data
in the file until you reopen it by issuing another OPEN macro.
When you are processing files sequentially, the GET macro reads data blocks and delivers
individual records to you, one at a time. You output records to the disk file with the PUT
macro, which you may also use to update records. Data management provides buffering
via blocked records and automatically blocks and deblocks them for you. You may overlap
your I/O with your sequential processing by specifying a work area, or a second I/O area,
in addition to the one I/O area that is always required for each file. As is true throughout
OS/3 data management, your I/O areas must be half-word aligned.
For randomly processing files, data management offers you the capability to erase data
from an expired or newly allocated file, to create blocks in.a file, or to expand a file by
generating data blocks in space newly allocated to it You retrieve records via the READ
macro and output them via the WRITE macro; each of these maóros has several forms,
which you specify as required, to access a block by its relativedisk address, or by a key to
be matched via search and an address for starting the search.
You may subdivide each nonindexed file, defined by the DTFNI declarative macro, into as
many as seven file partitions, each having its own I/O area and characteristic block size,
record size, and key length. Each partition of a DTFNI file may be further subdivided into as
many as 71 serial subfiles. You may gain access to the specific partition and subfile
required by issuing special imperative macros (SETP, SETS, for example) provided for this
purpose.
For all three file types, OS/3 data management gives you the option of generating and
processing your own standard user header and trailer labels. You may accompish this by
coding a special user label processing routine; which receives control from the OPEN and
CLOSE transients. You should remember that user standard labels are associated with
your file and are not maintained atthe partition or subfile level. Your label processing
routine, furthermore, may not issue any of the file processing imperative macros, although
a special macro, LBRET, is available for use in this routine.
It is important for you to keep in mind, as you study this section, that differences exist
between 0S73 data management and the data management of SPERRY UNIVAC or other
systems you may be acquainted with. Another point to remember is that some macros are
used for other types of OS/3 data management files than those described in this section,
with slight differences in format or effect. For example, the imperative macro SETF (15.7.8)
is also used for magnetic tape files defined by the DTFMT declarative macro, but in its tape
application has no UPDATE positional parameter.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT.

UP-8068 Rev. 4

15-3

Following functional descriptions of each of the three file processing methods, this section
of the manual presents a discussion of the DTF declarative macros. A summary of the 37
keyword parameters (Table 1 5—7) and a description of their use follow these. The next
paragraphs present a summary of the 18 imperative macros used in processing your files,
and a detailed description of the use of each follows the summary. The final paragraphs of
this section discuss the error and exception handling features of the nonindexed file
processor system. You will find numerous. coding examples throughout.
15 2

FUNCTION DESCRIPTION OS/3 SAM

As you have just noted, you use the DTFSD declarative macro to define disk files that data
management is to process as sequential access files. During your processing of DTFSD
files, you should keep in. mind that multivolume DTFSD files are maintained in singlevolume-mounted mode, only the current volume being online at any one time.. Data
management takes care of communicating with the operator to request and validate the
mounting of subsequent DTFSD volumes automatically. Files defined as sequential access
by the DTFSD declarative macro may contain fixed- or variable-length records, blocked or
unblocked.
For input operations, you use the GET macro; data management reads the input data and,
deblocking it automatically if required delivers the records one at a time to you For
output, you deliver records to data management one .at a time via .the PUT macro; when a
full block of records is ready, data management writes it to disk. You may process input or
output records in a work area or directly in the I/O area.
If you use a work area data management moves an output record from the work area to
the .1/0 area; it moves an input record from the I/O area to the work area If your records
are blocked, or if you provide two I/O areas without a work area, you must supply an
index register (via the IOREG keyword parameter of your DTF), into which data
management places the starting address of the current record position in the I/O area.
.

You may overlap your I/O operations with your other processing if you provide one or
more work areas or a second I/O area in addition to the one I/O area you must always
provide.
.

When you are processing variable-length, blocked records in the .output.mode and do not
provide a work area, you must yourself test whether the next record will fit in the space
remaining in the current output area When it does not you issue a TRUNC Imperative
macro to output a. truncated block to disk. Data management provides you with the
number of bytes remaining in the I/O area in a register that you specify via the VARBLD
keyword parameter of your DTFSD declarative macro.
.

When you are processing input records from aDTFSD file, you may reach a point where
you, want .to omit processing the records remaining in the current block or volume and
begin with the first. record of the next. You m.ay accomplish either of these actions by
issuing the RELSE imperative macro for skipping the remaining records in the current
block, or the FEOV macro for skipping the remainder of the current volume.
,

+—

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 5-4

When necessary, you may use the PUT imperative macro to update records you have
retrieved, but you may not change their record length. You issue the PUT macro for the
record to be updated following the GET macro by which It IS retrieved
In addition, you may extend aDTFSD file beyond the current end-of-file (EOF) address of
the last volume of the file. There are two ways of doing this: in the update mode, you
provide for this extension by coding it in your EOF routine; :for output files, you speóify the
extend mode of processing in the LFD job control statement of the device assignment set
by which you allocate the file. (The details of these two methods are developed under the
discussion of the PUT macro; see 15.7.9.2 and 15.7.9.3.)
To use a DTFSD file as a disk work file creating and then processing it under the same
DTF file descriptor you initially specify TYPEFLE=INOUT in the DTF open the file for
output and create it and then close it Changing the file processing direction to input via
the SETF imperative macro, you then reopen the file, using the same DTF, to retrieve and,
optionally, update your records. The details of this method are developed under the
discussions of the SETF macro (15 78) and the PUT macro (15 79 1)
15.3.

—0..

FUNCTIONAL DESCRIPTION, OS/3 DAM

You define DAM files which you process at random with OS/3 data management, by
means of the DTFDA declarative macro.
Another way in which OS/3 DAM differs from OS/3 SAM and OS/3 nonindexed fIle
access method is that DAM supports fixed- and variable-length records in unblocked
format only whereas the other two also support blocked records Consequently you have
no need of a work a:rea or a second I/O area, as you do for processing sequential blocked
records or for overlapping I/O with processing and therefore the DTFDA declarative macro
does not have IOAREA2, IOREG, RECSIZE, nor WORKA keyword parameters associated
withit.
A third point of difference to remember between SAM and DAM is that all volumes of a
multivolume DAM file are kept online when you are processing; there is ho EOF concept
in the SAM sense and consequently no EOFADDR keyword parameter associable with the
DTFDA declarative macro, nor is there a combined input/output file type
(TYPEFLE=INOUT), or needfor an UPDATE keyword parameter.
OS/3 DAM provides you with a means for creating records in a file, erasing data from an
old or newly allocated file, and expanding a iile by generating records in space newly
allocated to it.
The input work horse for direct access files is the block-level READ imperative macro,
which has two forms (READ,KEY and READ,lD) for accessing a blOck through a search on
key (starting the search at an address you specify) and for accessing a block directly at a
relative disk address (ID) that you provide to data management. You indicate to data
management which of these forms of the READ macro you intend to use by specifying the
READKEY and READID keyword parametes in your DTFDA declarative, and you provide

UP-8068 Rev. 4

i 5.-5

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

data management with READ-related information in a number of other DTF keyword
parameters, discussedin 15.7.14. To give data management time to locate the block you
want and to move it to the I/O area, you must issue a WAITF imperative macro after every
READ macro issued to a DTFDA file, before you may issue another imperative to the file.
This assures you that the data. transfer has taken place as specified before you proceed
further(15.7.16).
Another imperative macro for DTFDA files. that mu be paired with a following WAITF
is the direct access output processing macro,
and for the same reasons
macro
WRITE, which, like READ, is also a block-level macro. The WRITEmacro hasfive forms
that may be used with each other and with the two READ macro forms to create, update,
and erase direct access disk files. Two of these forms (WRITE,RZERO and
AFTER,EOF)do not actuallyoutput a block:to disk. Youuse these to reposition the
1
*WRITE
disk: access arm to a flew track, or to record the ID returned after the last block was
written as the end of data in the file. These forms of the WRITE command, and the WRITErelated DTFDA keyword parameters are developed in detail in 1 5 7 11 and 15 6
—

15.4.

FUNCTIONS OF THE OS/3 NON INDEXED FILE ACCESS METHOD

The logical IOCS processor, which processesnonindexedfiles you define with the DTFNI
declarative macro, will also process sequential files defined by the DTFSD macro and
direct access files you define with the DTFDA macro. It supports all 05/3 random access
:file processing imperative macros and all the sequential processing macros; however, only
files you define by the DTFNI macro maybe processed by the combination of both direct
and sequential processing techniques. Similarly, it is impörtantto remember that only to
DTFNI files may you issue the following five imperative macros NOTE POINT POINTS
SETP, and SETS.
The DTFNI declarative macro has a number of unique keyword parameters: you will specify
to realize other extensions to file processing techniques which apply to nonindexed disc
files under OS/3 data management: the PCA and SUBFILE keyword parameters, for
example, by which you specify that your DTFNI file is subdivided into file partitions and
that these, in turn, are subdivided into partition subfiles. You will note also the SIZE and
UOS (unit of store) keyword parameters, which you use for dynamic allocation and
extension of DTFNI files to the partition level.
many as seven file partitions, each of which hasits
•You may subdivide a DTFNI file into
own I/O area or areas and its own characteristic record size,block size, and recordformat.
Each partition you may further subdivide into a maximum of 71 subfilés, having the same
characteristics as the partition of which it is a part. You define a DTFNI file as being
partitioned by specifying two or more PCA keyword parameters in the DTF and by coding a
• DPCA (define partition control appendage) declarative macro for the second through the
seventh partitions of the file. In the DPCA declaratives, you specify a keyword parameter
for each aspect in which the partition differs from the parent DTFNI file; for this reason,
it is already fully
you do not prepare a separate DPCA description for the first partition
described in the DTFNI macro.*
—

*lt is not mandatory, of course, that each partition of a DTFNI file have different record lengths or formats; however, even
though a partition may be the same as the parent DTFNI file in all other respects, if it is a partition ft has its own separate
name, blocksize, and I/O area and requires its own DPCA declarative macro for separate identfty and accessibility.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-6

When you open the DTFNI file for processing, only the first partition is set active and
available to you. for processing; to gain access to some other partition, you issue the SETP
imperative macro to the file and specify. the partition you want to process by name.
Subsequent processing is carried out on this partition until you select another by issuing
another SETP macro. When you have selected the partition you want. to process, you issue
a SETS imperative macro to specify whichever subfile it is you want to process, having
previously indicated that data management is to support subfiles for this file via the DTFNI
or DPCA keyword parameter SUBFILE These procedures are detailed further in the
descriptions of the DTFNI and DPCA declaratives (15.5.3 and 1 5.5.4) and the SETP and
*
SETS imperative macros (15.7.4 and 1 5.7.5).
OS/3 data management will allocate and extend DTFNI space automatically for you, as
you need it, using the disk space management routines of the OS/3 supervisor and taking
its cues from both your jobcontrol statements and your DTFNI/DPCA keyword parameters.
It satisfies the space requirement for the first partition from the first available area .of the
extents you specified in the device assignment set of job control statements by which you
initially allocate the file; to the first partition it allocates that percent of the total file
allocation you have specified in the SIZE keyword parameter of the DTFNI declarative
macro.
You use the UOS keyword parameter to indiate the percentage of additional space data
management will dynamically allocate to this partition, should you ever issue a WRITE or
PUT output imperative macro referencing a block or record that lies beyondthe current
maximum relative block address for the partition. The UOS keyword parameter specifies
the percentage. of the secondary allocation data management may assign. (You will .have
specified the total number of tracks or cylinders by which the file may be extended
dynamically in the third positional parameter of the EXT job control statement in your
device assignment set for the file.)
Further details on dynamic.extension are given in descriptions of the SIZE and UOS
keyword parameters (1 5.6.24 and 15.6.29); each DPCA declarative macro has its unique
SIZE and UOS keyword parameters. You should also remember that DTFNI files will not be
dynamically extended beyond the volumes on which they initially reside.
Should you ever want to expand a growing DTFNI file beyond the physical volumes you
originally allocated to it (assuming that these volumes are still full after your. efforts to
reorganize the file and scratch expired or unused portions of it), you will need to copy the
file sequentially off to tape or other disk devices, using one of the OS/3 data utility
programs, redefine the file with a new DTFNl macro, reallocate this to new devices, and,
copying it. back, effectively create a new file. (The OS/3 data utility programs are described
in the data utilities user guide, UP-8069 (current version).
Other enhancements that apply only to processing your DTFNI files are the NOTE and
POINT imperative macros. You use the NOTE macro to access the partition-relative
address of the current record or block, which data management places in the. DTFNI file
table for you to reference You may then use the current address for file positioning via
the POINT macro, which updates the current record address in the DTF as you direct; your
subsequent file processing proceeds from this updated address. (Further details are
developed on the NOTE and POINT macros in 15.7.17 and 15.7.18.)

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-7

The imperative macro POINTS is useful to you for initializing the relative block address of
the current partition; you select the current partition, as previously described, with the
SETP macro. (The POINTS macro is fully described in 15.7.6.)

15.5.

NONINDEXED DISK FILE DECLARATIVE MACROS

You will use the four DTF declarative macros described in the following paragraphs to
define disk files and partitions to OS/3 data management. Note that, although the DTF
keyword parameters listed in the following statement formats are presented in alphabetic
order, you may code these in any convenient order, just so you separate them with
commas
Following the statement formats are tables summarizing the required and optional
keyword parameters; the detailed descriptions of the keyword parameters are presented in
15.6 and a table recapitulating all of them follows the descriptions. Except for the LACE
keyword (15.6.8) and the LOCK keyword (15.6.36), the keywords are described in
alphabetic order.
Refer to the Preface of this manual to review OS/3 statement conventions, and to 1.6 for
a general discussion of DTF macros and BAL rules for coding their operands.
In the declarative macroinstruction format delineations that follow, a comma is shown
preceding each keyword parameter except the first, to remind you that all keywords coded
in a string must be separated by commas. However, a comma must not be coded in
column 16 of a continuation line, nor follow the last keyword in the string. Refer to the
coding examples that follow.

15-8
Update C

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

DTFSD

15.5.1.

Defining a Sequential Disk File (DTFSD)

Function:
You will use the DTFSD declarative maôro instruction to define input and output disk
files that you intend to process sequentially. The DTFSD macro establishes a 242-byte
file table. Table 15—1 summarizes the DTFSD keyword parameters. These are
described in detail in 15 6 A coding example follows Table 15—1
Format:
LABEL

tOPERATiON

filename

DTFSD

OPERAND

rAccEss=

I
I
L

EXC
EXCR
SRDO
SRD

BLKSIZE=n
,EOFADDR=symbol
r,ERROPT=

[

5 IGNORE
SKlP

[,ERRORsymbol]
,lOAREAlsymbol
[,IOAR EA2=symbol]
[,IOREG(r)]
[,LABADDRsymb0I]
[,LACE=n]
[,LOCK=NO]
[,OPTI ON=Y ES]
T,RECFORM

FIXBLK
FIXUNB
VARBLK
VARUNB

[,R ECSIZE=n]
[,SAVAREAsymboI]
[,TRLBL=YES]
(continued)

15-9
Update C

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

OPERAND

LOPERATION

LABEL

DTFSD (cont)

,TYPEFLE=

(INOUT
INPUT
(OUTPUT

[,UPDATE=YES]
[,VARB LD=(r)]
[,VERI FY=YES]
[,WO R KA=Y ES]

Table 15—1. Summary of Keyword Parameters for DTFSD Macro Instruction (Part 1 of 2)

Filia

specification

Keyword

Remarks

Input

Output

In/Out

EXC

Request exclusive use of file for
associated DTF

EXCR

Request exclusive use of file for
associated DTF while permitting read
use for other jobs

SRD

Request read function for file
associated with DTF while permitting
read/write for other jobs

SRDO

Request read function for both files
associated with DTF as well as other
jobs. No writing permitted.

BLKSIZE*

n=maximum block size

EOFADDR

symbolic label

ERROPT

IGNORE
SKIP

X
X

ERROR

symbolic label

IOAREA1

ACCESS*

The maximum block size, in bytes

Identifies EOF routine

X
X

Ignore parity error
Bypassparityerror

Address of user’s unrecoverable
error routine

symbolic label

Address of I/O area

IOAREA2

symbolic label

Address of alternate I/O area

IOREG

lrl=general register

Required if records are processed in the
I/O area and records are blocked

LABADDR

symbolic label of user’s
label routine

Required if user header or trailer labels
are to be created

Required if user header or trailer labels
are to be retrieved

LACE

n=lace factor

Specifies factor for record
interlace

LOCK

Specifies that file lock is not to be set
on a lockable file at OPEN, permitting
read-only access

OPTION

YES

Specifies file not always to be processed

15-10

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP8068 Rev. 4

Table 15—1. Summary of Keyword Parameters for DTFSD Macro Instruction (Part 2 of 2)

FIes
Keyword

Specification

Remarks

Input

Output

In/Out

For fixed-length, blocked records

F1XUN8

Fo f xed length unblocked records
assumed

VARBLK

For variable-length, blocked records

VARUNB

For variable-length, unblocked records

RECSIZE*

n=number of bytes in
record

For fixed-length, blocked records

SAVAREA

symbolic label

Specifies address of save area for
contents of general registers

TRLBL

YES

Read or write user trailer labels when
CLOSE issued to file, ISpecify LABADOR
also.)

TYPEFLE

INOUT

For I/O files

RECFORM*

FIXBLK

NPtJT

For nput f es assumed

OUTPUT

UPDATE

YES

VARBLD

(r)’general register

VERIFY

YES

WORKA

YES

For output files

Required if records are to be written
beck to the same location from which
they were read

Required for variable-length, blocked
records built in output area; register
contains number of bytes left in output area.

Check parity after records have been written,

Process records in work area,

LEGEND:
R
X
V

Required
Optional
One option required

Assumed parameter, if none specified
Parameter may be changed on DD job control statement.

Example:
LABEL

LOPERATIONt

1
—

1_±
I

I
I

—

OPERAND

I
I
I

EJ1ELJlcJQL I

Li,_L_1

tAE1 I

i
I

—

10101,1

—

c..3P
”
A
P
1
r

l_Ll

e”=

’I
1
l’’

I
I

IIIIII

I.. ,.
L

L
L
L

L....

I
I

1111

This example defines a file ACCNTS that is a SAM input file (by TYPEFLE default
option). The required I/O area is designated symbolically as READ. The block size is
800 bytes, record size is 100 bytes, and records are fixed and blocked. An end of file
routine FINIS has been specified to handle that occurrence. No special label handling
or error routines are provided; therefore, errors will return inline.

1 5—i 1
Update C

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

DTFDA

Defining a Direct Access Disk File (DTFDA)

15.5.2.
Function:

You will use the DTFDA declarative macroinstruction to define files that are to be
randomly processed. The DTFDA macro establishes a 242-byte file table. A summary
of DTFDA keyword parameters is presented in Table 15—2; these are described in
detail in 15.6. A coding example follows the table.
Format:
LABEL

LiOPERATIONL

filename

DTFDA

OPERAND

rAccEss= (EXC
)EXcR
I
SRD
I
(SRDO
L
[AFTER=YES]
,BLKSIZE=n
[,E R RO R=symboll
[,IDLOC=symboll
,IOAR EA1 =symbol
[,K EYARG=symbol]
[,KEYLEN=n]
[,LABADD Rsymbol]
[,LACEn]
[,LOCK=NO1
[READID=YES]
[,READKEY=YES]

[

,RECFORM= jFIXUNB
VARUNB

RELATIVE=
1
[

{}]

[,SAVAREA=symbol]
,SE EKADR=symbol
[,SRCHM=YES]
[TRLBL=YES]
(continued)

15-12
Update C

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

LABEL

LOPERATION

OPERAND

rL ,TYPEFLE= fIrHttT
OUTPUT

DTFDA (cont)

[,VERIFY=YES]
[WRITEID=YES]
[,WRITEKEY=YES]

Table 15—2 Summary of DTFDA Keyword Parameters (Part 1 of 2)

Files
Keyword

ACCESS*

Specification

EXC

R.marks
Read

Write

Request exclusive use of file for
associated DTF

Request exclusive use of file for
associated DTF while permitting read
use for other jobs

EXCR

SRD

Request read function for file
associated with DTF while permitting
read/write for other jobs

SRDO

Request read function for both files
associated with DTF as well as other
jobs. No writing permitted.

AFTER

YES

BLKSIZE*

n=maximum block size

ERROR

A capacity record on each track is assumed.

Length of IOAREA1, in bytes

symbolic label

Address of user error routine

IDLOC

symbolic label

Address of field containing the record ID

IOAREA1

symbolic label

Name of I/O area defined by user

KEYARG

symbolic label

Address of field for key used for key search

KEYLEN*

n=key length

Length of the key in bytes

LABADDR

symbolic label

Address of user label handling routine

LACE*

n=lace factor

Specifies factor for record interlace

LOCK

Specifies that file lock is not to be set
on a lockable file at OPEN, permitting
read-only access.

READID

YES

Record referenced by ID

READKEY

YES

Record referenced by KEY

RECFORM*

RELATIVE

For fixed-length records

VARUNB

Variable-length records

Relative addressing

—

record
track

15-13

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table 15—2. Summary of DTFDA Keyword Parameters (Part 2 of 2)

Files
Keyword

Specification

Remarks
Read

Write

SAVAREA

symbolic label

Specifies the address of a save area for
contents of general registers

SEE KADR

symbolic label

Address of track reference field

SRCHM

YES

Search multiple tracks. (If specified, file
must be allocated on a cylinder basis.)

TRLBL

YES

User standard trailer labels are to be read
or written when CLOSE issued so file. Specify
LABADDR also.

TYPEFLE

1NFJT:

Check standard labels

OUTPUT

Write standard labels

VERIFY

YES

Records are to be checkread

WRITEID

YES

Output record is located by means of its
relative disc address (ID).

WRITEKEY

YES

Output record is located by key.

LEGEND:
Required
Optional
One option required
Assumed parameter, if none specified
Parameter may be changed on DD job control statement.

R
X
Y
*

Example (DAM Input File):
LABEL

OPERATONi

ill

OPERAND

COMMENTS

L1?FIITHE F-RiATYF
1
1LE
iPE

ADI’RET AC.CS

rNPUr FILE

yjpp

Fig

KIE=

I I I I

iJJLL

YTE LbNC
INuTJUTPuT A’EA

JM
1

ii
j

AZO-3YTE

KEY

jR tLD BE ISSUED
1 A..L REc.YRps A’RE TfE SAME: tE
ECFRM=FIXUNB,
DIC ID
1
3ID
ArSA-SvTEFrELD

Example (DAM Output File):
LLJL__i_J_L_Ll

UTFILE.
I
-

IEAlJ
T
1
’PJ,,
EUTPu
VEIFYYE$,
ggN=

x
x
x

_I__1_i

1
I

L
I

1.
I

15-14
Update C

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

DTFNI

15.5.3.

Defining a Nonindexed Disk File (DTFNI)

Fu nctio n:
You will use the DTFNI declarative macro instruction to define disk files that are to be
processed sequentially, randomly, or by a combination of sequential and direct access
processing techniques. The DTFNI macro establishes a 242-byte file table. See 15.5.4
for a description of the DPCA declarative macro, which you use to define the second
and all subsequent partitions of a partitioned DTFNI file. Table 15—3 summarizes the
DTFNI and DPCA keyword parameters; coding examples follow the table. Keyword
parameters are detailed in 15.6.
Format:
LABEL

tOPERATION1

filename

DTFNI

OPERAND

F ACCESS=
I

EXC
EXCR
SRD
SRDO
L
[AFTER=YES]
,BLKSIZE=n
,ERROPT= f IGNORE
SKlP
L
[,EO FADDR=symbol]
[,ERROR=symbol]
[,lDLOCsymbol]
,IOAREA1=symbol
[,IOAR EA2=symbol]
[,IOREG(r)]
[,KEYARGsymbol]
[,KEYLENn]
[LABADDR=symbol]
[,LACEn]
[,LOCK=NO]
[,OPTION=YES]
[[,PCA1=symboll ,...,[PCA7=symbol]}
[,READI D=YES]
[,READKEY=YES]

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

LABEL

OPERATION

DTFNI (cont)

15-15

OPERAND

F,RECF0RM

I
I
L

[,R ECSI ZE=nJ
[RELIvrIvE=

FIXBLK
FIXUNB
VARBLK
VARUNB

{.}]

[,SAVAREAsymb0II
,SE EKADR=symbol
[SRCHM=YES]
[,SIZE=n]
[,SUBFI LE=YES]
[,TR LB L=YES]
,TYPEFLE= ( INOUT
INPUT
I
(OUTPUT
L
[,UOS=n]
[,UPDATE=YES]
[,VARBLD=(r)]
[,VERIFY=YES]
[,WOR KA=YES]
[,WRITElD=YES]
[WR1TEKEY=YES]

15-16

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

DPCA

15.5.4.
—0”-

Defining a Partition Control Appendage (DPCA)

When you have a DTFNI file that is to contain two or more partitions, you use a DPCA
declarative macro to define separately the second and each of the subsequent partitions
(that is partitions 2 through 7) Descriptive information for the first partition (and for the
parent file as a whole> is contained in the 242-byte DTFNI file table The DPCA declarative
macro sets up an auxiliary file table,called a partition control appendage, which defines
the aspects in which each partition differs from the first and occupies only 82 bytes of
main storage.
Notice that the label of each DPCA macro is partition-name this is the symbolic label of
the partition you have specified in the corresponding PCA keyword parameter of the parent
DTFNI macro.
You should also note the absence of all strictly fi/e-relative keyword parameters from the
DPCA macro ERROPT ERROR and LABADDR for example The reason for this is to
simplify matters for you OS/3 data management relies upon the DTFNI file table for all
file-relative keyword parameters and you do not specify these again in the DPCA macros
Following the format statement Table 15—3 summarizes the DTFNI and the DPCA
keyword parameters; these are, in turn,dëtailed in 15.6. Coding examples follow the table.
Function:
You use the DPCA macro to define the second and all subsequent partitions of a
multipartitioned DTFNI file. A maximum of seven partitions may be defined in all. The
DTFNI file table contains descriptive information for the first partition. Separate DPCA
macros establish partition control appendages defining each of the others (partitions 2
through 7).
Format:

—

LABEL

partition-name

LOPERATiON

DPCA

OPERAND

BLKSIZE=n
[,EO FADD R=symbol]
,IOAR EA1 =symbol
[,l OAR EA2=symbol]
[,lOR EG(r)]
[,KEYARG=symbol]

[,KEYLEN=n]
[,LACE=n]

UP—8068 Rev. 4

15-17
Update C

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

LABEL

OPERATtONt

OPERAND

DPCA (cont)

T,RECFORM=

I
I

FIXBLK
FIXUNB
VARBLK
VARUNB

[,R ECSIZE=n]
[,SIZE=n]
[,SUBH LE=YESJ
[,UOS=n]
[,VARBLD=(r)]
[,WOR KA=YES]
Table 15—3. Summary of DTFNI and DPCA Keyword Parameters (Part 1 of 3)

Keyword

Specification

Used
for
OPCA

Files
Remarks

Input

Output

In/Out

EXC

Request exclusive use of file for
associated DTF

EXCR

Request exclusive use of file for
associated DTF while permitting read
use for other jobs

SRD

Request read function for file
associated DTF while permitting,
read/write for other jobs

SRDO

Request read function for both files
associated with DTF as well as other
jobs. No writing permitted

AFTER

YES

BLKSIZE*

n=maximum block size

EOFADDR

symbolic label

ERROPT

ACCESS

A WRITE, AFTER macro will be issued.

Length of IOAREA1, in bytes

Address to which control is passed when end
of sequentially processed file is reached

IGNORE
SKIP

No
No

Y
Y

Y
V

Ignore parity error
Bypass parity error

ERROR

symbolic label

Address of user error routine

IDLOC

symbolic label

Address of field containing the record ID

IOAREA1

symbolic label

Name of I/O area defined by user: always
half-word aligned

IOAREA2

symbolic label

Name of alternate I/O area

IOREG

Irl general register

Required if records are processed in the
I/O area and records are blocked

KEYARG

symbolic label

Address of field for key used for key search

KEY LEN*

n=key length

Length of the key in bytes

LABADDR

symbolic label

Address of user label-handling routine

n=Iace factor

Specifies the factor for record interlace

LACE*

[

15-18

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table 15—3. Summary of DTFNI and DPCA Keyword Parameters (Part 2 of 3)

Specification

Keyword

Files

Used
for

DPCA

Remarks

Input

Output

IN/Out
X

Specifies that file lock is nol to be set
on a lockable file at OPEN, permitting
read-only access

LOCK

OPTION

YES

Specifies an optional file

PCAn

symbolic label

Specifies the address of partitions (1 to 7)
used to subdivide a file

READID

YES

A READ, ID macro will be issued.

READKEY

YES

A READ,KEY macro will be issued.

RECFORM*

FIXBLK

Fixed-length, blocked records

FXUN

Fixed length records unblocked

VARBLK

Variable-length, blocked records

VARUNB

Variable-length records, unblocked

n=number of bytes
in record

Specifies record size

Relative addressing

SAVAREA

symbolic label

Specifies save area for contents of general registers

SEEKADR

symbolic label

Address of track reference field

SIZE*

n=percent

Specifies percentage of total file allocation to
be initially assigned to partition

SRCHM

YES

Search multiple tracks. (If specified, file must be
allocated on a cylinder basis.)

SUBFILE

YES

Support division of file partitions into subfiles

TRLBL

YES

Read or write user trailer labels when CLOSE
issued to file. (Specify LABADDR also)

TYPEFLE

INOUT

This file may be used as either an input file or
an output file.

tNPIU1

OUTPUT

UOS*

n=percent

Specifies percentage of secondary allocation to
be used for extending partition

UPDATE

YES

Write records back into same location from which
they were read.

VARBLD

)r)=genera) register

Required for variable-length, blocked records that
are built in output area; register contains number of
bytes left in output area,

VERIFY

YES

RECSIZE

RELATIVE

record
track

Read and check standard labels for file. If file is
processed sequentially, the PUT macro may not be
issued for this file unless UPDATEYES has also
been specified in the DTF.

Write standard labels for ths file. If file is
processed sequentially, the GET macro instruction
may, not be issued.

Records are so be check-read.

15—19

SPERRY UNIVAC 05/3
BASIC DATA. MANAGEMENT

UP-8068 Rev. 4

Table 15—3. Summary of DTFNI and DPCA Keyword Parameters (Part 3 of 3)

Keyword

Used
for
DPCA

Specification

Files
Remarks
INPUT

OUTPUT

WORKA

YES

Yes

WRITEID

YES

WFIITEKEY

YES

IN/OUT

Process records in work area

AWRITE,lDmacrowillbeissued

A WRITE KEY macro will be issued

LEGEND:
R
X
Y

Required
Optional
One option required
Assumed parameter

if none specified

Parameter may be changed on DD job control statement.

Examples of DTFNI declarative macros used to define a nonpartitioned

nonindexed file and a

nonindexed file containing two partitions.
Example:

P
1RT
r
1
N
A

)ITNt

—

i i
I 1 I I
I

—

lZ,I

LREiAI L)IFF&,
L...Ariti’6

—

1111

—

I
I

H—I

I -I

iT
PAR
I
T
1
t

1__.

)iTNt
-

—

i I

I I

.....Ll

—

JJ_LJ_
____i__.

l.......L.. JJ...

I •I

.—

—

-I

3LiIE=Z5V,
L. I 71
1
Li
PM
&c
F
1
? Ec4 1 i& = I Z IB
‘C. A
i’..1l
1I
I

—

....j.........J

—

I
1

I Ii

ç.
—

,-,

___)<

—

.—

I
I

1_J±J_J_LL

—

I
I

iI 1
E= 5
L...)IIIl

liii

±-7BvIpezI
71
z
1
i.eIA
1
C’

IFF&1 i
=7
U
-II 1
tAR
E
4
EI

——

—

1L1

1
Ei1_EC

—

Jjj

Lt partition of a nonindexed file.
With the UOS keyword, you specify to data management what percentage of your
secondary allocation of disk space to the file it is to suballocate each time the partition
requires additional space. From your acquaintance with OS/3 job control, recall that you
specify the number of cylinders or blocks that is to constitute the secondary allocation of
disk space to. a file with the third positional parameter on the EXT job control statement of
your file’s device assignment set. (To.review this statement in detail, you should refer to
the job control, user guide, UP-8065 (current version).)
When you have specified the UOS keyword parameter for the partition (and have not
specified a zero increment in your EXT.job control statement), and the partition requires
more space, data managementwill. automatically suballocate to it the number of additional
tracks that is equivalent to the amountof storage.specifiedby the UOS keyword. This
amount is designated the unit of store; the same amount is used each time the partition
needs extension. Data management keeps a record of suballocation information developed
for all partitions in the format 2 label associated with the file (Appendix D).
Data management learns of the need to extend a file
imperative macros (PUT or WRITE) references a
maximum relative block address data management
partition. Data management acts automatically to
several points you should keep in mind.

partiton each time one of your output
block that lies beyond the current
maintains in the PCA table for the
extend the partition,. but there are

One point is that.you.must have specified.. the UOS keyword parameter in the first place; if
you omit it no extension can be made A second point is that file partitions will not be
extended beyond the volumes on which the file resides Furthermore if after extending
your partition by one unit of store data management finds that the requested block still
lies beyond the new maximum relative block address, it sets the invalid ID flag (byte 0, bit
1) in filenameC and transfers control to.your error routine (or to you inline if you have no
error routine). Data management takes the same action if there is no space available on
the disk to extend the partition or if you have not specified the UOS keyword. Finally, a
unit of store specification greater than 100% is not valid.
Keyword Parameter UOS:

UOSn
Specifies as the unit of store the percentage of secondary disk storage
allocation for the file that data management is to suballocate to the partition
being defined each time it requires more space. The value of n, which is the
specified percentage, may not exceed 100. Secondary storage allocation is
specified in the EXT job control statement in the device assignment set for the
file
..

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

15-54

Used with DPCA. declarative macro or with DTFNI macro defining first (or only)
partition of a nonindexed file. Not used with DTFDA or DTFSD macro.
If omitted, or if a zerosecondary storage allocation is specified in EXT job control
statement, no extension will be made.

15 6 31

Specifying Update Processing Mode for Sequential Files (UPDATE)

The UPDATE keyword parameters is used with the DTFSD and DTFNI macros.

—*

You will recall from the discussion of the TYPEFLE keyword parameter that when you have
specified TYPEFLE=INPUT, you define a read-Only file and may not issue an output
imperative macro to it unless you have also specified UPDATEYES (15.6.29).
When, therefore, you have an inputfile defined bya DTFSD macro, or an input file defined
by the DTFNI macro that is to be processed sequentially and you want to update your data
records, you specify UPDATE=YES to make this possible. Only then may you retrieve your
records with the GET imperative macro and, modifying them if you need to, rewrite them
to disc with the PUT macro. (The UPDATE=YES specification is also accepted in your DTF
for sequentially processed files you have defined as TYPEFLEINOUT, although you do not
need to use it for this 2-way type of file.) Another point worth remembering is that the
UPDATE keyword parameter, unlike the TYPEFLE keyword, has nothing to do with your
mode of label processing; its use affects only your mode of data record processing in
sequential input files.
Keyword Parameter UPDATE:
UPDATE=YES
Used only with DTFSD macro or DTFNI macro defining sequentially processed
files and only when you have specified TYPEFLE=lN PUT or TYPEFLEIN OUT for
these files When used specifies that sequential output function (PUT macro)
may be issued to update data records in file Unrelated to label processing
If omitted from DTF for a sequentially processed input file (TYPEFLE=INPUT); you may
not issue an outpUt function to the file.

15.6.32.

Specifying Register for Residual Space, Variable Records (VARBLD)

When you are outputting variable-length, blocked records to a sequentially processed disk
file, and you are building these in an I/O area without a work area, you must specify the
VARBLD keyword parameter.
Data management uses the general register you specify with this keyword to inform you of
the number of bytes of residual space remaining in the I/O area after the execution of
each PUT macroinstruction you issue. Before you issue your next PUT macro, you must
test whether there is enough space left to accommodate the next record. If there is not,
you must issue a TRUNC macro to write out the current block. (These procedures are
detailed in 15.7.9.4 and 15.7.10.)

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-55

The VARBLD keyword parameter is nOt supported by the DTFDA macro because the
blocked record formats may not be specified for DTFDA files; you may specify the keyword
for sequentially processed output files or partitions defined by the DTFSD, DTFNI, or DPCA
declarative macros.
Keyword Parameter VARBLD:
VARBLD=(r)
Specifies a general register into which data management loads the number of
bytes remaining in the I/O area after each execution of a PUT macroinstruction
to a sequentially processed output file containing blocked, variable-length
records, where r is the number of the register and must be enclosed in
parentheses. Supported for DTFSD, DTFNI, and DPCA macros; not supported for
DTFDA macro. Value of r may range from 2 through 12, but register 13 may also
be used if SAVAREA keyword has also been specified.
When you are building variable-length blocked records in an I/O area for output to a
sequentially processed file, without a work area, you must access the VARBLD register to
test whether enough space remains in the area for the next record before issuing your
next PUT macro. You issue a TRUNC macro when it does not. See 15.7.9.4 and 15.7.10.
1 56.33.

Specifying Parity Check Verification of Output (VERIFY)

When you want data management to make a parity check of your data records or blocks
after it has written each of them to disk, you must specify the optional VERIFY keyword
parameter. Verification necessarily increases execution time for the output commands
involved (PUT or WRITE macroinstruction). If. a parity check is conducted and reveals an
error, data management normally sets the output parity check error flag (byte 2, bit 2) in
filenameC and transfers control to your error routine, if you have specified one, or to you
inline (Appendix B).
You may specify the VERIFY keyword parameter with the DTFSD, DTFDA, and DTFNI
macros; it is not supported by the DPCA macro.
Keyword Parameter VERIFY:
VERIFY=YES
Specifies that data management is to conduct a parity check of output blocks or
records after writing them to disk. Parity check verification necessarily increases
execution time for PUT or WRITE macro. Optional for DTFSD, DTFDA, and DTFNI
files; not supported for DPCA macro.
If omitted, no verification is performed; however, data management may detect an
output parity check error by other means. You may direct data management to take
certain actions with the ERROPT keyword parameter (15.6.5).

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

15.6.34.

15-56

Specifying Sequential Processing in a Work Area (WORKA)

When you are going to process input or output records sequentially in a work area rather
than in the I/O area, you indicate this to data management by specifying the WORKA
keyword parameter in the DTF. This keyword is supported for the DTFSD declarative macro
and for sequentially processed files or partitions defined by the DTFSD declarative macro
and for sequentially processed files or partitions defined by the DTFNI or DPCA macro; it is
not specified for the DTFDA macro.

You specify the address of the work area in the second positional parameter of each PUT
or GET macro you issue to the file (15.7.9 and 15.7.12). When you use a work area and
therefore specify the WORKA keyword, you must not specify the LOREG keyword
parameter in your DTF (15.6.11).
Keyword Parameter WORKA:
WORKA=YES
Specifies to data management that you will be processing input or output records
sequentially in a work area and not in the I/O area. Supported for DTFSD macro
and sequentially processed files or partitions defined by DTFNI or DPCA macros;
not supported for DTFDA files,
Do not specify IOREG keyword parameter when you specify the WORKA keyword.
Address of work area is specified with each issue of GET and PUT macro.
15.6.35.

Specifying Issue of WRITE,ID Macro (WRITEID)

When you are processing a DTFDA file or randomly processing a DTFNI file and will issue
the WRITE,lD form of the WRITE imperative macro to locate an output block by means of
its relative disk address or ID, you must notify data management by specifying the
WRITEID keyword parameter in your DTF. (This use of the WRITE macro is detailed in
15.7,11.4.)
Keyword Parameter WRITEID:
WRITEI D=YES
Specifies that you will issue a WRITE,ID macro to the randomly processed file
defined by this DTFDA or DTFNI declarative macro to locate an output block by its
relative disk address (ID). Not supported for DTFSD files. See 15.7.11.4 for the
WRITE,lD macro.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

156.36.

15—57

Specifying Issue of WRITE,KEY Macro (WRITEKEY)

When you are processing a DTFDA file or randomly processing a DTFNI file and will issue
the WRITE,KEY form of the WRITE imperative macro to rewrite or update a block just read
by the READ,KEY macro, you must notifydata management by specifying the WRITEKEY
keyword parameter inyour DTF. (These uses of the WRITE and READ macros are detailed
in 15.7.11.5 and 15.7.14.2)
Keyword Parameter WRITEKEY:
WRITEKEY=YES
Specifies that you will issue a WRITE,KEY imperative macro to the randomly
processed file defined by this DTFDA or DTFNI declarative macro to rewrite a
block just retrieved by the READ,KEY macro. Not supported for DTFSD files. See
15 7 11 5 for the WRITE KEY macro 157 142 for the READ KEY macro
1 5.6.37 Nonstandard Forms of the Keyword Parameters
In order to minimize any recoding you may need to revise programs previously prepared to
run under other data management systems, OS/3 data management accepts certain
variant spellings for the keyword parameters described in this section. The nonstandard
forms of these keywords listed alphabetically are as follows

Nonstandard
Spelling

OS/3
Standard Form

Nonstandard
Spelling

OS/3
Standard Form

AFTR

AFTER

RDID

READID

BKSZ

BLKSIZE

RDKY

READKEY

EOFA

EOFADDR

REL

RELATIVE

ERRO

ER ROPT

SKAD

S EEKADR

lOAl

IOAREA1

SRCM

SRCHM

10A2

IOAREA2

TYPF

TYPEFLE

IORG

IOREG

UPDT

UPDATE

KARG

KEYARG

VBLD

VARBLD

KLEN

KEYLEN

VRFY

VERIFY

LBAD

LABADDR

WRI D

WRITEID

RCFM

RECFORM

WRKY

WRITEKEY

RCSZ

RECSIZE

WORK

WORKA

Table 15—7 summarizes nonindexed file declarative macro keyword parameters.

15—58

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table 15—7. Summary of Al! Declarative Macro Keyword Parameters Used With the Nonindexed File Processor System (Part 1 of 2)

Keyword
Parameter

Keyword
Specification

ACCESS

Used to Specify or define
DTFSD

DTFDA

D1FNI

DPCA

EXC

—

EXCR

SRD

SRDO

)(

—

Length of I/O buffer

Address of end-of-file/partition routine

—

This DTF: read/update/add use
Other jobs: no access
This DTF: read/update/add use
Other jobs: read use
This DTF: read use
Other jobs: read/update/add use

—

This DTF: read use
Other jobs: read use
IssueofWRITE,AFTERorWRITE,RZEROmacro

AFTER

YES

BLKSIZE

EOFADDR

symbol

ERROPT

IGNORE

Availability of record in I/O area despite parity error

SKIP

Bypass input record or ignore output record despite
parity error

—

ERROR

symbol

IDLOC

symbol

IOAREA1

symbol

IOAREA2

symbol

(r)

OREG

1’

Declarative Macros

X
—

Address of primary I/O buffer

Address of secondary I/O buffer

I/O buffer index register

Address of field containing key search argument

Length of key
Lace factor for record interlace operations

—

KEYARG

symbol

KEYLEN

LACE

LABADDR

symbol

—

LOCK

—

OPTION

YES

PCA(n)

symbol

READID

YES

READKEY

YES

RECFORM

FIXUNB

—

VARUNB
FIXBLK
VARBLK

X
X
X
X

RECSIZE

RELATIVE

R
T

—

Address of user error routine

—

X
X

—

Define field for next available record address

Address of user header/trailer label processing routine
Specifies that file lock is not to be set on a lockable file
at OPEN
Optional file for input
Partition address, where n
Issue of READ, ID macro

X
X

X
X
X
X

Format of data records

Record size

—

X
X

—

Issue of READ, KEY macro

Relative addressing method

15—59

SPERRY UNIVACOS/3
BASIC DATAMANAGEMENT

UP-8068 Rev. 4

Table 15—7. Summary of All Declarative Macro Keyword Parameters Used With the Nonindexed File Processor System (Part 2 of 2)

Keyword
Parameter

Keyword
Specification

Declarative Macros
Used to Specify or define

SAVAREA

symbol

SEEKADR

symbol

SIZE

SRCHM

YES

SUBFILE

YES

TRLBL
TYPEFLE

DTFSD

DTFDA

DTFNI

—

Address of register save area
—

Address of seek address field
Percent of total file allocation to be initially
assigned to partition
Multi-track search for key

Support of subfiles

—

Support trailer labels

X
X

X
X
X

—

YES

INPUT
OUTPUT
INOUT

X
X
X

—

UOS

UPDATE

YES

VARBLD

(r)

VERIFY

YES

WORKA

YES

WRITEID

YES

WRITEKEY

YES

—

DPCA

—

X
—

X
X
X
X

—

Define file type and mode of label processing

—

X
—

—

Secondary allocation
Update of sequential input file
Count of residual I/O buffer space for VARBLK file
Read/check of output recOrds to be performed
Sequential processing in work area
lssueofWRlTE,lDmacro
Issue of WRITE, KEY macro

LEGEND:
X
R
—

Optional
Required
Not supported
Assumed specification if keyword not specified

=
=
=
—

15.7.

IMPERATIVE MACROS FOR NONINDEXED DISK FILES

You inform the nonindexed file processor system of the distinct operations that data
management is to perform on your files and partitions by including the appropriate file
processing imperative macroinstructions in your program.
There are 18 of these Imperative macros available to you for processing your nonindexed
files and partitions Table 1 5—8 summarizes their functions
The paragraphs following the table describe the imperativemacros in detail; the macro
descriptions are arranged in four groups, according to the file processing functions
involved:
R

Initialization and Termination Macros:
OPEN
CLOSE

UP-8068 Rev. 4

SPERRY UNIVACOS/3
BASIC DATA MANAGEMENT

15-60

LBRET
S ETP
SETS
POINTS
FEOV
SETF
•

Creation Addition and Updating Macros
PUT
TRUNC
WRITE

•

Retrieval Macros:
GET
RELSE
READ

•

Validation and Positioning Macros:
CNTRL
WAITE
NOTE
POINT

Before. issuing an imperative macro to an OS/3 data management file, you must provide, a
72-byte save area full-word aligned into which data management expects to place the
contents of your registers. You may load general register 13 in your program, or use the
SAVAREA DTF keyword parameter to specify the address of the register save area. (See
15623)

SPERRY UNIVACOS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table 15—8.

15—6L

Summary of Imperative Macroinstructions for Processing Nonindexed Disk Files

4,
May be issued to
Secondary
Operands*

Macro

OPEN
C LOSE

—

LBRET

None

SETP

partition-name

SETS

subfile-number

POINTS
REOV

—

DTFSD
Files

File or partition termination

Creating, retrieving, andupdating standard
user header and trailer labels

—

Select partition for subsequent processing

—

INPUT
OUTPUT
UPDATE

PUT

workarea

TRUNC

—

RZERO

—

AFTER

—

AFTER, EOF
GET
RE LSE
READ

workarea

X
X

—

KEY
CNTRL
WAITF
NOTE
POINT

-SEEK

—

X
-

Select subfile or terminate current subfile creation

Initialize to first block of file or partition

Terminate processing of current volume

Set processing direction for type INOUT file

Record-level output, sequential mode

Terminate output processing of current block

Block level output by relative address

Block-level output by direct write

Track initialization

Write current block in next sequential position in file

Record end-of-dat ID in DTF and format 2 label

Record-level retrieval, sequential mode

Terminate input processing of current block

Block level retrieval by relative address

Block-level retrieval by key

—

X
X

—

address-field

—

KEY

File or partitioriinitializatioñ

—

X
ID

Remarks

DTFNI
Files

SETF

WRITE

DTFDA
Files

Seektocurrenttrackortotràck-indicatedbySEEKADR
X

Wait on I/O ornIetion;required after READ or WRITE

Access current relative block address

Position file to relative block address in address-field

*Except for the LBR ET macro, filename is assumed for operand-i; operands listed are secondary.

15-62

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

OPEN

157.1.

Opening a Disk File (OPEN)

You will use the OPEN imperative macro to open a disk file defined by the appropriate DTF
macro instruction ifl order to initialize it (and Its partitions If any) before It may be
accessed by the logical IOCS processor. The OPEN macro instruction calls the appropriate
transient routines to perform the following functions
•

validating and completing the file or partition tables

•

validating or creating system standard labels; and

•

reading or writing user standard header labels.

If yói define a DTFNI file to have more than one partition (by specifying two or more PCA
keyword parameters and by coding the necessary DPCA declarative macros), you initialize
all partitions by issuing an OPEN macro for the file.
This is the format of the OPEN macro
LABEL

[name]

L OPERATION t2

OPEN

OPERAND

filename 1
(1)
1

,filename n]

Positional Parameter 1:
filename
Is the label of one or more corresponding DTF declarative macroinstructions in
your program You may have as many as 1 6 files opened
(1) or 1
Indicates that you have preloaded register 1 with the address of the DTF filetable
(You use (1) or 1 as the operand only when you have a single DTF)

15-63

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

15.7.2.

Closing a Disk File (CLOSE)

After you have completed your processing of a disk file, you must issue the CLOSE macro
to check that all your I/O orders have actually been completed and to read or write the
system standard and optional standard trailer labels: in other words,to terminate the file.
Once you have terminated a file with the CLOSE macro (which calls a transient routine to
perform all of these functions), you cannot access it again unless you issue another OPEN
macro. An important point to note is that you do not terminate file partitions separately;
once you have done with all the partitions of a file you Intend to process you terminate
operations by issuing one CLOSE macro for the file that contains them (For this reason
the partition name never appears as an operand ofthe CLOSE macro.)
The format of the CLOSE macro is:
LABEL

[name]

LOPERATION1S

OPERAND

filename-i [,...,filename-ni
(1)
1
*AL L

The three basic ways to code the CLOSE macro involve the use of symbolic addresses in
the operand.
Positional Parameter 1:
filename
Is the label of the DTF declarative macro in your program; there may be 1 or as
many as 16 files named.
(1) or 1
Specifies that you have preloaded register 1 with the address of the DTF file
table. You may use (1) or 1 when you have only one file to terminate.
*ALL
Specifies that all files currently open in the job step are to be closed.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-64

LBRET

15.73.

Processing Optional User Labels (LBRET)

You will use the imperative macroLBRET in your label processing routine(whose symbolic
address is specified to data management via the LABADDR keyword parameter of your
DTF) to create,: retrieve, or retrieve and update optional user header or trailer labels. Note
that LBRET is the only data management rriacio your label processing routine may issue.
The maximum number of each type of label ybu may process is eight.
When your LABADDR routine receives contiol
1 data management wilIhave loaded general
register 1 with the ad.dress of the I/O buffer for use in processing input and outputUHLs
and UTLs. You must always use register 1, even though you may have specified only one
buffer with the IOAREA1 keyword; it is not possible to use a work area for processing user
labels.
Your LABADDR routine is accessed when the file is opened and again when it is closed;
register 0 contains the EBCDIC alphabetic character 0 in its least significant byte when the
file is opened and the character F when it is closed. Your LABADDR routine should be
coded to access register 0 and to process your header labels when the register contains 0
and your trailer labels when it contains F.
Another point to remember is that user header/trailer labels if you have them at all are
maintained at the file level only; data management does not maintain them at the partition
level. (For this reason, there is no LABADDR keyword parameter in the DPCA declarative
macro.)
The format of the LBRET macro is as follows:
LABEL

[name]

£OPERATIONi

LBRET

OPERAND

where:
1

Does not write or read a label; returns control to your program at the next
instruction after the OPEN or CLOSE macroinstruction.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

16-65

2
Writes a label to an output file or reads a label from an input file; then returns
control inline to your program at the next instruction after the LBRET 2
macroinstruction.
3
Writes back to diskthe label just read and returns contro[to your program inline
at the next instruction after the LBRET 3 macroinstruction.
TYPEFLE=INOUT must be specified in your DTF declarative mãcroinstrüction, or the file
processing direction reset for update processing with the SETF macroinstruction.

UP-8068 Rev. 4

15.7.3.1.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-66

Creating Optional User Labels

Your LABADDR label-creating routine delivers your standard user header or trailer labels
to data management one at a time, up to the maximum of eight. Data management will
write each label to the disk file. If you have specified LBRET 2, it will return control to your
label routine after each label has been written, until the eighth label has been written to
disk. Then data management will transfer control to you inline. If you are creating user
labels, control returns to you at the instruction next after the OPEN macro call by which
you initially opened the file for processing. If you are creating user trailer labels, of course,
data management returns control to you inline at the instruction next after the CLOSE
macro call by which you are terminating your processing of the file. (Remember that
reading or writing optional user trailer labels is one of the functions performed by the
CLOSE macro.) Remember also where labels are written:
s

User header labels are written by the LBRET macro on the first track of each volume
of a DTFSD file, and on the first track of the first volume of a DTFDA or DTFNI file.
They are 80 bytes long; their simple format is shown in 14.2.4.

‘

User trailer labels are written on the first track of each volume of a DTFSD file and on
the first track of the first volume of a DTFDA or DTFNI file, following your user header
labels. Their format and content are similar to those of the user header label and are
also shown in 14.2.4.

When you have fewer than eight user labels of either type to create, you issue LBRET 1
when you have created the last one. After it has written the last label to your disk file,
data management will return control to your program at the instruction next inline after
your OPEN macro call.

UP-8068 Rev. 4

15.73.2.

15-67

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Retrieving or Updating User Labeis

If YOU need to retrieve your user labels for updating or other label processing, you will
specify in the DTF the type of label processing you intend to perform (TYPEFLE=INPUT or
TYPEFLE=INOUT), specify. TRLBL=YES if you are going to process user trailer labels,
specify the address of your label processing routihé (LABADDR), and open the file with the
OPEN imperative macro. (You do not use the UPDATE keyword parameter of the DTF; this
is not related to label processing but affects data I/O)
When the file is opened data management will deliver your user header and trailer labels
one at a time to your LABADDR routine either until all existing user labels have been
passed to you, or Until you specify that you need no more, by issUing LBRET1.
Your label routine processes each label delivered by data management and then returns
control to data management by issuing the LBRET macro with 1 2 or 3 for the positional
para meter
If you want to terminate label processing short of the maximum (eight standérd user labels
of each type), you issue LBRET 1 when you need no more (this implies, of course, that you
keep track) Data management then transfers control to you inline to the instruction next
after your OPEN macro call
When you are processing all your labels (but not updating them), you issue LBRET 2. Data
management will retrieve the next label and pass itto your LABADDR routine. It will
continue to do so until there are no more to process then after you have processed the
last label, data management automatically transfers control to the next instructiOn after
your OPEN macro call.
When you are updating your user header and trailer labels, you issue LB
management will update the label just read writing the new label to disk
*
theold.

Here, data
the plaDe of

UP-8068 Rev. 4

SPERRYUNIVAC OS/3
BASIC DATA MANAGEMENT

15-68

SETP

15 7 4

Accessing a Selected File Partition (SETP)

When you open a multipartitioned DTFNI file for processing the only one of its partitions
that you may then access is PCA1, the partition defined in the DTF itself. All partitons of
the file are initialized when you issue an OPEN macro for the file, but only partition 1 set
active you cannot access any partition other than this first one with the OPEN macro
alone To select another partition of the opened file you need the SETP macro
The. SETP macro acts to select thern new partition, but it is important to remember that it
positions you for processing this partition at Its current position that is at the next
accessible block after the point at which you were last processing. If you want to begin at
some other point, you will need to issue additonal macros, for example, SETS (15.7.5),
POINTS (15.7.6), or POINT (15.7.18).
Once you have accessed a partition with the SETP macro all subsequent processing
continues on the selected partition until you issue another SETP macro All other
imperative macros with which you may process within a partition (POINT, POINTS, SETS,
and NOTE) depend on you to select the proper partition before calling them.
This is the format of the SETP macro notice that
have a partition name in the operand
LABEL

[name]

tOPERATiONIi

SETP

is the only imperative macro that may

OPERAND

(filename) (partition name
(1)
1

Positional Parameter 1:
filename
Is the label of the DTFNI declarative macro that describes the already-opened file
of which partition-name is part.
(1) or 1
Indicates that you have preloaded register 1 with the address of the DTFNI file
table.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-69

Positional Parameter 2:
partition-name
Is the label of the partition control appendage (PCA1—7) that denotes the
partition you want to access. (This is, of course, the same thing as the label of
the corresponding DPCA declarative macro for PCA2—7 and the label assigned
to the partition defined by PCA1 within the DTFNI macro.)
(0) or 0
Indicates that you have preloaded register 0 with the address of the partition
table defined by the DTFNI keyword (PCA1—7) that describes the partition you
want to access
Each DTFNI file table maintains the address of the partition that is currently active; when
you issue a SETP macro, data management modifies this current partition address to
indicate which partition you have selected to be active for subsequent file accesses (When
you close the file you have no further access to the file until you initialize it again with a
subsequent OPEN macro, which once more sets PCA1 active.)
If you have specified an index register (via the IOREG keyword parameter of your DTF),
each SETP macroyou issue will cause the index régistér té be loaded for the partition you
are accessing (During the opening of a multipartitioned file only the index register for
PCA1 will have been loaded)

15-70

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

SETS

15 7 5

Processing Subfiles within a Partition (SETS)

Within each partition of a DTFNI file, you may establish as many as 71 subfiles. Subfiles
must be created sequentially, but you may access them at random for data retrieval. If you
intend to use subfiles in the first partition (PCA1) of a DTFNI file you specs ihe SUBFILE
keyword parameter in the DTF data management reserves one track of the first volume of
the file for maintenance of a subfile table Similarly if you want subfiles supported for any
of the subsequent partitions, you specify the SUBFILE keyword parameter in the DPCA
declarative macros describing these partitions.
Once you have selected the partition to be subdivided the SETS imperative macro is the
one that provides you with the ability to create and subsequently retrieve the data in the
partition subfiles This is its format
LABEL

[name]

1OPERATiONL

SETS

OPERAND

(filename (subfile-no.
(0)
(1)
) (0
(1

Positional Parameter 1:
filename
Is the label of the DTFNI macroinstruction describing the file to which the
subdivided partition belongs.
(1) or 1
Indicates that register 1 has been preloaded with the address of the DTF file
table.
Positional Parameter 2:
subfile-no
Is the decimal integer number of the subfile (1 through 71) to be referenced.
(0) or 0
Indicates that register 0 has been preloaded with the subfile number.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15—71

The reason that the partition name does not appear in the operand is that the SETS macro
expects that you have already selected the partition you want, by issuing an appropriate
SETP macro before calling it. If you have not done so, or if the SETP macro you issue is for
the wrong file or partition, data management sets the invalid subflle bit (byte 3, bit 3) in
the error flag field of the DTFNI file table, referenced as filenameC (Appendix B). You
should check this bit whenever you issue a SETS macroinstruction.
What the SETS macro does is to maintain a partition-relative subfile table on the track of
the first volume of the file that you reserved by specifying SUBFILE keyword parameter in
the DTFNI or DPCA macro (This is either the first track on the volume or when optional
user labels are present, the first track after the user label track.) Data management uses
this table to keep track of the start of each subfile: the address of the record that starts it.
No record is kept by data management of the end of a subfile; unless you keep track
yourself of the record with which it ends it is possible to process through a subfile to the
end of the partition or logical EOF.
The subfile table is not available for you to access, but you may examine it in a disk print
taken with the system utility (SU) symbiont. To know its contents may help you visualize
what the SETS macro is doing for you when you create or retrieve subfile records There is
one 6byte entry in the table for each subfile, consisting of the relative block address of
the record at the start of the subfile and, if the records are in blocked format, its
displacement into the block. When you are creating a subfile, you issue a SETS macro to
insert the address of the next available block or record as an entry in the subfile table.
(Remember that you are creating subfiles sequentially, although you may retrieve the
subfiles at random.)
During retrieval, the SETS macro you issue moves the table entry for the subfile you have
selected to the current relative address field of the DTFNI or DPCA file table; the file may
then be processed between the limits of the current relative address of the start of the
subfile and the logical end of the file or partition. This séléctive positioning of a file for
subfile processing is a useful ability to keep in mind.
For creation of subfiles (output), the SETS macro must be issued following the output of
the last record to each subfile. SETS for output indicates termination of the subfile.
For retrieval of subfiles (input), the SETS macro should be issued prior to the first GET of a
subfile record SETS for input initializes processing to the start of a subfile

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-72

POINTS

15,7,6.

Initializing Position of a File or Partition (POINTS)

When you are processing within a file partition and want to get back to the start of it (that
is, to reset the current relative block address from its present value to the partition-relative
address of the first block of the same partition), you will use the POINTS macro that is
designed to do just this.
When you want to change partitions, you must first issue a SETP macro (15.7.4) to select
the new partition, and then issue the POINTS macro to get to the beginning of that:
POINTS initializes the relative block address of the current partition.
This is the format of the POINTS imperative macro:
LABEL

OPE RAND

L OPERATIONi

[name]

POINTS

(filename
(1)
(i

‘

Positional Parameter 1

filename
Is the label of the corresponding DTFNI macroinstruction in your program.
(1) or 1
Indicates that register 1 has been preloaded with the address of the DTFNI file
table.
LABEL

AOPERATION

I.
2.

IIi..1I

OPERAND

.
I
I
;
1
•T”
.J
t

fP
e
1
’’’cI.3
I
’r’Q
,1’1A
L
1_I
(‘I ) 1

15-73

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

FEOV

15.7.7.

Forcing End-of-Volume Procedures (FEOV)

When you are processing a DTFSD file for input or output, and want to discontinue short
of the actual end of this volume and to begin processing the next, you issue the FEOV
imperative macro.
This macro initiates end-of-volume (EOV) procedures on the current volume, which is
closed just as if the actual EOV had been reached. Volume swapping is performed, and
your next GET or PUT macroinstruction continues processing on the next sequential
volume. The FEOV macro may be used only for DTFSD files; these have only one volume
mounted at a time. It may not be used for sequentially processed files described by the
declarative macro because all volumes are always online, and there is no “current
volume” in the sense used here.
When you are processing sequential blocked input files and need to skip over the records
remaining in a block in order to resume with the next block of the same volume, a
different macro, RELSE, is available (15,7.13).
This is the format of the FEOV macro:
LABEL

/OPERATIONt\

FEOV

[name]

OPERAND

(filename
(1)
(i

Positional Parameter 1:
filename
Is the label of the corresponding DTFSD macroinstruction in the program.
(1) or 1
Indicates that you have preloaded register 1 with the address of the DTFSD file
table.
Example:

I[1

LABEL

LOPERATIONL
-

OPERAND

II1E(b’%ff, 1
F
IJI’
1
F
i._IE
..4

Treats the file described by the DTFSD macroinstruction, whose label is INFILE, as if
logical end-of-volume address had been accessed.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-74

SETF

15.7.8.

Setting File Processing Mode (SETF)

The SETF macroinstruction enables you to set the processing direction(change the type of
file) for DTFSD files, or sequentially processed DTFNI files, described by the keyword
parameter TYPEFLE=INOUT. You should not issue the SETF macro during your file
processing; it should, instead, be issued between your terminating file processing (with the
CLOSE macro) and your opening it again, or before the OPEN issued to the file at the start
of your program.
This is the format of the SETF macro:
LABEL

[name]

iOPERATIONIs

SETF

OPERAND

(filename) (INPUT
OUTPUT
(i
) (uPDATE
,

Positional Parameter 1:
filename
Is the label of the DTFSD or DTFNI macroinstruction that defines the INOUT file.
(1) or 1
Indicates that register 1 has been preloaded with the address of the DTFSD or
DTFNI file table describing the INOUT file.
Positional Parameter 2:
INPUT
Indicates that the INOUT file is to be set for input processing, without updating.
OUTPUT
Indicates that the INOUT file is to be set for output processing.
UP DATE
Indicates that the INOUT file is to be set for input processing, with updating.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

1 5--75

PUT

15.7.9.

Output of Sequential Disk Files (PUT)

You will use the PUT imperative macro to create, extend, or update disk files processed
sequentially. These are either files defined by the DTFSD declarative macroinstruction
(15.5.1) or those files and partitions defined by the DTFNI and DPCA declarative macros
(15.5.3 and 15.5.4).
Essentially, the PUT macro handles record-level output for sequential files in either of two
ways. It delivers an output record to data management in the current output area, if you
are processing in IOAREA1 or IOAREA2. But, if you are building your output records in a
work area (specifying WORKA=YES), the PUT macro delivers these to data management
for writing to disk directly from there. Either way, the record is no longer available to you,
once delivered.
If your output records are unblocked, they are delivered singly to disk; if your records are
to be blocked, data management handles blocking automatically for you from the work
area. You must take care of blocking for variable-length blocks constructed in an I/O area,
however, and you may optionally write out short blocks of fixed-length records. Both of
these actions are easily accomplished: see 15.7.9.4 and the TRUNC imperative macro
(15.7i0).
When your output records are blocked, or when you have specified a standby I/O area
(IOAREA2) but no work area, you must supply an index register via the IOREG keyword
parameter of your DTF or DPCA macro so that data management has a place to put the
starting address of the current record position in the output area (15.6.11). You do not do
this when building records in a work area, because you specify its address every time you
issue the PUT macro And if you are processing unblocked records in a single I/O area
(IOAREA1), you may reference these directly by means of the name you have assigned to
the area and do not need an index register.
An important point to remember is that, after data management writes the current output
data to disk from the output or work area, it does not clear these areas. You must be
careful either to clear the area yourself, or always to supply records
padded with blanks
if necessary
which completely fill out the work area or I/O area. Otherwise, spurious
characters left over from previous records may appear in your output data. When you are
processing in a work area, it is freed for subsequent processing (but not cleared) each time
data management moves an output record from there. into the I/O area for you.
—

—

Sequentially processed DTFNI files with keys may also be easily output with the PUT
macro see 15795

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

15-76

This is the format of the PUT macro:
LABEL

[name]

AOPERATiON1

PUT

OPERAND

fiIename
{1

}

workarea
[,{O

Positional Parameter 1:
filename
Is the label of the corresponding DTFSD or DTFNI macroinstruction that defines
the output file
(1)orl
Indicates that you have preloaded register 1 with the address of the DTF file
table.
Positional Parameter 2
workarea
Is the label of the work area from which the output record may be obtained
(O)orO
Indicates that register 0 has been preloaded with the address of the work area
If omitted indicates that you have chosen to reference the current record either by
means or a register (IOREG keyword parameter) or by directly accessing the data
relative to the name you have assigned to IOAREA1 You may use the latter method
only for unblocked records processed in a single I/O area

NO TE:
When the work area is used the keyword parameter WORKAYES must be present
in the DTF statement
15 7 9 1

Creating a Sequential Disk File

The PUT macro gives you the ability tà create a new disk file and then to process it
sequentially: this amounts to using the disk file as a work file. You use the same DTF file
table to describe the file when you create it and when you process it; sUch a file may be
defined by a DTFSD or DTFNI declarative macro (15.5.1 or 15.5.3). The procedure is as
follows:
1.

Define the file, specifying the DTF keyword parameter TYPEFLEINOUT among the
other parameters you need.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-77

Open the file for output, using the OPEN macroinstruction (15.7.1); then create the
file, using the PUT macro to write your records to disk.
-

Close the file, using the CLOSE macroinstruction (15.7.2).

Issuing the SETF macroinstruction (15.7.8),
INPUT or UPDATE.

Reopen the file.

Retrieve your records sequentially, via the GET macroinstruction (15.7.12), or
optionally, update them with pairs of GET and PUT macros (15.7.9). It is important to
remember that when you update with the PUT macro, you may never change the
record length.

Close the file.

reset the file processing direction to

The following coding example shows how you might do this for a file with the logical
name INVNTRY. Once created as a TYPEFLE=INOUT file, the file is closed; after you reset
the file processing direction to UPDATE, you reopen and update it by issuing paired GET
and PUT macros to retrieve records and write them to disk.
Example

LABEL

A0PERATI0NA
10
16

OPERAND

—

JLJLJL

—

lit

—

liii

Iii

—

lii

—

‘I

lilt

—

Ii’t

.[1%.JI’/I,bLrfI’1I

—

ill

—

1111111

—

I
iii

III
—

liii

aitilit
I

—

I
Iii

.!.iL.. i’’ 1
E

IE
F
T
1
rPEi.t

—

clL_L

IiI.1i.1t.1i1t’I

I
I

OPERAND

LOPERATlONt

LABEL

ecr
_1_

III

—

-r.

15-78

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

—

I’i

—

1’
1
IL.J

I-

Ii
I

—

I
ii

.1.1.....

I
I

Other DTF keyword parameters including required keywords not pertinent to the
example, are not shown.

Must be INOUT file

Other parameters are not shown.

Creating file, using disk as work file

Now reset file processing direction to update and reopen file

Issuing paired GET/PUT macros to retrieve records, update them, and rewrite to
disk.

Terminate file; cannot be accessed until reopened.

15.7.9.2.

Updating and Extending an Existing Disk File Processed Sequentially

plus 1 is
the relative block number of the last data block
The logical end of a disk file
its end
file
the
as
of
label
2
recorded by data management in the DTF and in the format
of-data (EOD) address. (See D.3.2.) In a DTFSD file, this address is also called the logical
end-of-file (EOF) address. No EOF sentinel or other flag is recorded in the data area of the
file to mark this point, and there is no data record in the block at the EOD address.
—

—

When you are sequentially processing a nonindexed disk file in an update mode (that is,
you have specified UPDATE=YES in the DTFSD or DTFNI declarative macro), you may
extend the file beyond its Current EOF record by the following procedure, which you will
include in your end-of-file routine. (When you issue a GET macro and an end-of-file
condition is detected, control returns to you at the address specified by your EOFADDR
parameter in the DTF. You may not extend a file beyond its current volume by this means,
but see 15.7.9.3.)
1.

Issuing a GET macro, you place the record to be added to the file in the I/O area
(IOAREA 1 or 2) or in the work area you have specified.

Issue a PUT macro, which causes the new record to be added.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-79

Issue another GET macro and follow it by a PUT macro; this will output the next
record to be added to the file.

Terminate the file by issuing a CLOSE macro when you have completed all your
additions to it (15.7.2).

An important point to remember is that you must have anticipated the eventual need to
extend this file and provided for extension by the appropriate job control statements issued
at the time you originally created it. Extension is done automatically for you by data
management through the disk space management routines of the OS/3 supervisor; you
never need to call the supervisor EXTEND macro in your program.
Another point to remember is that you must not issue two PUT macros in succession in
the update mode; this will be flagged as an invaild macro sequence (byte 0, bit 6 of
filenameC (Appendix B)).
15.7.9.3.

Extending an Existing DTFSD Output File

Extending a sequential file within your EOFADDR routine is discussed in 15.7.9.2. You
have another means available for extending an existing sequential file: processing it in the
output mode (that is, by specifying TYPEFLEOUTPUT in the DTFSD declarative macro, or
resetting the direction of file processing to OUTPUT with the SETF imperative macro
(15.7.8)). This procedure also requires that you issue appropriate job control statements,
which are discussed in what follows.
First, the current last volume of the file is mounted; for a disk file described by the DTFSD
declarative macro, this is always a specific volume because only one volume is mounted at
a time. (All volumes of a DTFNI file, processed sequentially or not, are always online.)
When you issue an OPEN macro for the file, if you have specified the appropriate job
control statements
1 data management will position the file to itscurrent logical end-of-file
(EOF) address.
You then issue the PUT macros necessary to add records beyond the current logical EOF.
If you need them, allocate additional disk volumes to the file, and you may continue to
extend it beyond its current last volume to subsequent volumes.
The OS/3 job control statements you need to specify to extend a sequential disk file by
this method are discussed in detail in the job control user guide, UP-8065 (current
version) Briefly what you need in your device assignment set is an LED statement that
contains the logical name of your file (the name by which your program references it)and
indicates by an EXTEND (third positional parameter) that the extend mode of processing is
to take place: the sequential file will be extended by appending the new records to the
present end of the file.
It is important for you to remember that all LED names within a job step must be unique; if
more than one file is given in the same name, only the last one to be specified is available
for any operation
including extension by this method.
—

UP8O68 Rev. 4

15.7.9.4.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 5-80

Output of. Blocked Records, Sequential Disk Files

As you are forming variable-length records for output to a sequentially processed disk file
via the PUT macro, you will be determining the length of each record and placing this
information in the first two bytes of the 4-byte record descriptor word (RDW), at the head
of each record (14.3.2>. This information is contained within the record and is always in
the I/O area whenever the record is.
When you are outputting variable-length blocked records from an I/O area to disk and are
not using a workarea, you must test whether the next record will fit into the remaining
space in the I/O area before you issue the PUT macroinstruction for it. Data management
informs you of the amount of space remaining in the I/O area after each variable-length
record is moved in by a PUT macro; it does so by placing the number of bytes of residual
space into the general register you have specified (via the VARBLD keyword parameter of
the DTFSD or DTFNI macro or the DPCA macro (11.6.34). If you find that the next record
will fit, add it to the current block with the PUT macro. If you find that it will not, you
instead issue a TRUNC macro to write out the current block to disk and free the entire I/O
area for building the next (15.7,10). Data management will calculate the block size and
will enter it into the first two bytes of the 4-byte block descriptor word (BDW), as explained
in 14.3.2, before writing the block to disc.
On the other hand, when you are forming your variable-length blocked records in a work
area, each PUT macro you issue causes data management to test whether the record it
moves will fit into the I/O area. If it will, it is added to the block currently being built; if it
will not fit, data management first writes out the current block and then starts a new block
with the current record.
15.7.9.5,

Output of Sequential DTFNI Files With Keys

Files defined by the DTFNI declarative macro and processed sequentially may have a key
associated with each block of data. Before you issue a PUT macro to output such a block
to disk, you must place this key at the head of the block (just as you would before issuing
a WRITE macro with an ID positional parameter for direct access method output of blocks
with keys). When you issue the PUT macro, data management will write the key and data
portion of the block to disc. Subsequent sequential retrieval of blocks having keys (via the
GET macro) will, similarly, cause transfer of both the key and data. Remember that data
management will perform the normal blocking and deblocking for DTFNI files processed
sequentially.
Another point to remember is that, when you are creating or updating nonindexed files
with keys using the PUT macro you must specify the key length via the KEYLEN keyword
parameter of the DTFNI or DPCA macroinstruction (1 5.6.13).

UP-8068 Rev: 4

15.7.9.6.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-81

Optional Sequential Output Files

When you have a program that you anticipate will not invariably be called on to process a
particular sequential output disk file each time it is executed, you should designate this file
as optional by specifying OPTIONYES in the DTFSD or DTFNI macro (15.6.1 6). On the
occasions when you do not require the file to be output from your program, you need
merely omit the device assignment set of job control statements that usually allocate the
file to a disk When your program executes the OPEN macro for the optional file the OPEN
transient marks the file as optional and it disables the PUT macro mechanism so that no
I/O is performed
You should not forget to specify the OPTION keyword parameter for an optional file if you
do forget and the file has not been allocated by job control when your program is
executed, it is impossible to process the file. Data management will transfer control to the
address of your error routine.

UP-8068 Rev.4.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-82

TRUNC

15 7 10

Output of Short Variable Blocks to Sequential Disk Files (TRUNC)

The TRUNC imperative macro is used with sequentially processed variable-length output
files defined by the DTFSD or DTFNI macros to enable you to write short blocks of output
data to disk. Its use is mandatory with variable-length, blocked records that you build in
the output I/O area. Its function is to notify data management that the block currently
being built is to terminate and, is to be written, out to disk. Data management calculates
the block size and inserts it in the first two bytes of the block descriptor word (BDW)
before it writes the block to disk
When you have formed a variable-length record to be added to the block building in the
I/O area, you must determine whether there is room for it in the remaining space in the
I/O area before you issue the PUT macro. You compare the current record length, which
you have placed in the first two bytes of its record descriptor word (RDW), with the
number of bytes remaining in the I/O area. (Data management informs you of the space
left in the I/O area by placing the number of bytes of residual space in the general
register that you designated by specifying the VARBLD keyword parameter in the DTFSD,
DTFNI, or DPCA macro (15.6.34); it updates this number each time a variable-length
record is added to the current block by a PUT macro.)
If the current record will fit in the space remaining, you will issue a PUT macro to add it to
the current block. But if it will not, you issue a TRUNC macro to write the current block to
disk and to free the I/O area for building the next block. A subsequent PUT macro will
then start off the next block with the current record; the TRUNC macro resets the IOREG
index register to point to the new current area address of the next available output I/O
area.
This is the format of the TRUNC macro:
LABEL

[namel

OPERAND

1OPERATIONL

TRUNC

(filename
(1)
(i

Positional Parameter 1:
filename
Is the label of the corresponding DTFSD or DTFNI macroinstruction in the
program.
(1) or 1
Indicates that register 1 has been preloaded with the address of the DTF file
table.

SPERRY UNIVACOS/3
BASIC DATA MANAGEMENT

UP8O68 Rev. 4

15-83

Example:
LABEL

LOPERATIONL

OPERAND

Sends to the output device the short block of records accumulated by PUT
macroinstructions since the last TRUNC iwas issued or since a full block of records was
sent automatically to the output device for the file described in the DTF macroinstruction
whose label is OUTPUT.

UP-8068 Rev. 4

SPERRYUNIVAC OS/3
BASIC DATA MANAGEMENT

15-84

WRITE

15 7 11

Random Output of Records to Disk (WRITE)

The WRITE imperative macro is a block-level output processing macro that, in its various
forms and uses provides you with the following capabilities with randomly processed disk
files defined as output files by the DTFDA or DTFNI declarative macros, or as input/output
files by the DTFNI macro
creating a newly allocated file;
•

updating a previously created file by rewriting blocks to their original locations;

•

extending a file by generating data blocks in space newly allocated to it;

•

overwriting unwanted data in an expired or newly allocated file;

•

recording the logical end of a file or partition; and

•

moving the disk access arm to a new track and ensuring that the new track is
initialized.

Three forms of the WRITE macro output a block from main storage to disk; the main
storage address from which your data is written is contained in the location specified by
the IOAREA1 keyword parameter of your DTF. Its input counterpart for disk files that may
be processed randomly is the READ imperative macro, which is also a block-level
processing macro (15.7.14).
Because these two operate a block-level, you must control any record blocking and
deblocking that may be necessary, as OS/3 data management handles this function
automatically for you only for sequentially processed DTFSD and DTFNI files.
For disk files you define with the DTFDA macro, of course, this is no problem, as only
unblocked record format (fixed- or variable-length) may be specified for these files. For
randomly processed DTFNI files, however, in which you may have blocked records, you will
need to control their blocking and deblocking with the PUT and GET macros, used in
conjunction with READ and the WRITE,KEY or WRITE,lD form of the WRITE command
(15,7.11.4 and 15.7.11.5).
In all uses, you must issue a WAITF imperative macro (1 5.7.1 6) after each READ or WRITE
macro you issue, to ensure that the intended data transfer has taken place, before issuing
another imperative macro. Remember also that none of your transferred records will be
check-read for parity unless you specify the VERIFY=YES keyword parameter in your DTF
macro; check reading necessarily increases the execution time for each WRITE operation
(15.6.33).

WU0

nOV.

crcnn P

•N

UMIV4’%b soi a

‘“••••••

BAsIC DATA MANAGEMENT

Another DTF keyword parameterinvolvedis IDLOC, which enables you wiSái?êt1ie*eIth,e
disk address (ID) of yourblock returned to a specified field. The form of the returned IDis
governed by your specification of another DTF keyword parameter, RELATIVE, which you
might also review (15.6.22). The uses of the IDLOC keyword parameter are explained in
15.6.7 and Jurther 4isc.usspd in what follows. . ..
.1.
.

...

e’t’

:..••;

...,

;_.e

)i,.)..;.1;..;::.st.::.’:i.r:.

;

j,.•

. 4•

_;3

‘:‘‘

.:‘..,:::

• ••

%%••

•

—.7
_

.7...’

L?11.,

•

;
7..

•

—.

i;.

...,;•;•

.
:)1

••

•

...
•

..,:.

‘:-.

:.j:

-.:—

•
.

,.,.

.._1’

BASIC DATA MANAGEMENT

WRITE, AFTER

15.7.11.1.

Creating a Random Disk File by Sequential Load (WRITE,AFTER)

This is one form of the WRITE command you may use to create a file:
LABEL

[name]

LOPERATIONt

WRITE

OPERAND

(filename ,AFTER
(1)
(i

The second positional parameter, AFTER, specifies that the current block in main storage
is to be written as the next sequential block on the current track and that the remainder of
the track is to be cleared. If this current block, when written, occupies the last position on
the track, data management sets the last block on track accessed bit (byteO, bit 0) in
filenameC after completion of the WAITF macro. (See Appendix B for the details on
filenameC.) You should check this bit after each issue of the WAITF macro, and be
prepared to move to another track if it is set, using, for example, the WRITE,RZERO form of
the WRITE command (15.11.2) or the CNTRL imperative macro (15.7.15).
You should review the AFTER keyword parameter of the DTFDA and DTFNI declarative
macros; this parameter must be specified when you use the WRITE,AFTER form of the
WRITE command and precludes your use of the WRITE,lD function (15.7.11.4). Data
management does not automatically preformat the file at OPEN when AFTER=YES is
specified.
In the first positional parameter, filename represents the label of the DTFDA or DTFNI
declarative macro; (1) or 1 indicates that you have preloaded general register 1 with the
address of the DTF file table. The first positional parameter is specified in the same way
for all forms of the WRITE command and will not be discpssed further.
If you want to store the relative disk address or ID of the next block in the file or partition
you are processing, you would specify the IDLOC keyword parameter in the DTF (1 5.6.7).
The form in which this ID is returned to you is governed by your specification of another
keyword parameter, RELATIVE, which you should review (1 5.6.22).

—-

You have two basic ways of using the WRITE,AFTER imperative macro to create a new
direct access disk file: a simple sequential load process that proceeds from the file start
through all the tracks in succession, and another use, in conjunction with the
WRITE,RZERQ macro (15.7.11.1 2), which enables you to select the tracks to be filled in
whatever order you choose. Because the WRITE,AFTER macro (having written a block to a
file on a variable-sector 8411, 8414, 8424, 8425, 8430, or 8433 disk> then overwrites the
remainder of the current track with binary 0’s, you may also use it (with or without the
WRITE,RZERO macro) to expunge unwanted data from an existng variable-sector disk file.
You cannot do this if the file resides on the fixed-sector 841 6 disk in OS/3.

BASIC DATA MANAGEMENT

When you open a newly allocated direct access file the first time for output,the OPEN
transient positions you automatically at the head of relative track 001. If you are going to
use the WRITE,AFTER macro, you have specified the AFTER keyword, and no
preformatting has been done (if the file is on a variable-sector disk). If you issue
successive WRITE,AFTER imperatives, each followed by a WAITF macro (15.7.16), you
effect a sequential loading of your file in the simple order in which you present your
blocks to data management. You do not use the SEEKADR field’s contents to control this
macro, for the WRITE,AFTER macro used this way automatically shifts from track to track
and cylinder to cylinder sequentially. However, you must arrange to move the contents of
the IDLOC field (to which the following WAITF macro returns the ID of the next block in
physical sequence in the file) into the SEEKADR field in order for this method to work.
(One easy way, for bringing this about is to define the IDLOC and the SEEKADR fields as
the same area in main storage, as described in 15.6.7.) The file-filling sequence continues
until you reach logical end of volume and an error condition in filenameC indicates that
you have exhausted your file space, unless you have terminated loading sooner (as, for
example, when reaching logical end of file (EOF) in your input file). You do not, in this
method, need to test for setting of the last block on track accessed flag in filenameC
because of the automatic movement to the head of the next track that data management
performs.
You do need to keep your finger on track fill, however, when you usethe WRITE,AFTER
macro in the second method mentioned, for this controls your issue of the WRITE,RZERO
macro to select the next track to be filled
You should note a few more points about this method. The first is the last block on track
accessed flag is set by OS/3 after you have issued the WRITE,AFTER macrd that writes
the block in the last position of the current track; in some other data management
systems, this flag is not set until you issue a macro to write the next block, which will not
fit on the track.
Another point is that the setting of this flag must be tested for in your program inline
because accessing the last block is not a condition that causes control to transfer to your
error routine: if you test filenameC for this flag only in your error routine, you will miss it.
A third point is, that, although the WRITE
AFTER macro does not require aseek address to
1
guide it, the WRITE,RZERO macro does; you must, therefore, arrange to increment your
SEEKADR fields’s contents to the new relative track address you want before you issue it.
You will probably have specified relative track addressing (RELATIVE=T) when you use this
method for creating a file with WRITE,RZERO and WRITE,AFTER, but you may also use
relative record addressing (RELATIVE=R), although this is harder to control.
One final point is most important if your file resides on an 8416 disk. Because of the
fixed-sector format of this disk in OS/3, the action of the WRITE,AFTER macro is
significantly different from the foregoing description in that the macro, having written a
block, does not set all fields to binary 0 in the remainder of the blocks on the track. On the
8416 disk, moreover, there is no record 0 at the head of the track from which data
management can be informed of the amount of unused space. For these reasons, you
must always fill each 8416 disk track completely when you use the WRITE,AFTER macro.
If you write only the one block at the head of the track, for example, and then pass on to
another track, the residual data in the 39 remaining blocks is still there and may produce
unpredictable results when your program encounters it in later retrieval operations.

U-Ub 11ev.

iitcY urivi.c uwi

BASIC DATA MANAGEMENT

WRITE,RZERO

15.7.112.

Selecting and Initializing a New Track (WRITE,RZERO)

The form of the WRITE command to use for moving the disk access arm to a new track,
and ensuring that the new track is initialized is:
LABEL

[name]

OPERAND

LOPERATION

WRITE

(filename
(1)
(i

‘

,RZERO

Here, the second positional parameter, RZERO, specifies that data management will
position the file for subsequent processing at the relative track address you have pre loaded
into the field specified by the SEEKADR keyword parameter of your DTF (1 5.6.24). This
means that you have selected a new track, or that the track specified is to be treated as a
new track, and that writing will begin at the first record on this track. Note that this form
of the WRITE command does not actually output a record: it merely repositions the file so
that you may write the subsequent records beginning with the first record of a new track.
For writing the next record, you must follow this form with the WRITE,AFTER form ofthe
WRITE command, (15.7.11.1).
Because the WRITE,AFTER macro clears the rest of the current track, this
WRITE,RZERO/WRITE,AFTER combination is one you may use to create a new file or to
overwrite (or erase data from) an expired or newly allocated file on a variable-sector disk.
If you want to store the relative disk address, or identifier (ID), of the next block in the file
or partition you are processing with the WR1TE,RZERO/WRITE,AFTER macros, you would
specify the IDLOC keyword parameter in the DTF (15.6.7). The form in whic-hthis ID is
returned to you is governed by your specification of another keyword parameter,
RELATIVE, which you should also review (1 5.6.22). No ID is returned by the WAITF macro
that follows the WRITE,RZERO macro; the contents of the IDLOC field are unchanged.
Use of the WRITE,RZERO macroinstruction requires that you specify AFTER=YES in your
DTF; because data management does not preformat the file on a variable-sector disk when
this keyword is specified, you may not issue the WRITE,lD macro to it..

UF-8O68 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 5-89

WR ITE,AFTER,EOF

1 5.7.1 1 .3.

Recording the Logical End-of-File (WRlTEAFTER,EOF)

This form of the WRITE macromaybe used torecord the logicalend of data or end-of-file
address in the DTF. Data management also records it in thedisk format 2 label:
LABEL

[name]

1OPERATIONLs

WRITE

( filename

‘

OPERAND

AFTER, EOF

(1).
(i
The logical end-of-file (EOF) or end of partition is the relative disk address of the block one
beyond the block (containing data) that is written the farthest or deepest into the file or
partition. It is the address one block beyond thehighestused relative disk address, and
there is no data that belongs to your file there Data management uses this address
which it also knows as the end-of-data ID (EODID) to prevent your reading extraneous
data outside of the limits of the current partition or file space on disk and it records the
EODID in the disk format 2 label (See D 3 2)
If you issue a READ,lD macro that references a block whose relative disk address exceeds
the EODlD,datamanagement setstheinvaIidID flag (byteO, biti) infiienameC, issues
error message DM24 and branches to your error routine (See Appendix B ) You may on
the other hand write at or beyond the current logical end of file if you have provided for
file extension
You should not need to issue the WRITE AFTER EOF macro in a new program written in
OS/3, because data management automatically keeps track of the progress your program
is making as it fills the file and automatically records the EODID on file close However if
you have a program coded for some other system where it was necessary for you to issue
the macro you need not remove your WRITE AFTER EOF macro call from it
The WRITE AFTER EOF macro does not output a block nor does it make an ID return to
the IDLOC field It is however necessary for you to place in the SEEKADR field the relative
disk address of the block that data management is to use in calculating and recording the
EODID. Usually, this is the address of the block just written.
Note however that the partition name is never used in the first positional parameter If
you need to know where the end of a subfde occurs within a partition you must maintain
your own end-of-subfile data record data management does not provide this service to
you On the contrary it is possible to process through the end of a subfile to the logical
EOF or end of partition
Remember to specify the keyword parameter AFTER in the DTF when you intend to issue
the WRITE AFTER EOF form of the WRITE macro (1562) otherwise it will be flagged as
an invalid macro (byte 0, bit 6 of fi/enameC).

1 5-90

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

•

WRITE, ID

15.7.11.4.

Creating or Updating Blocks by Relative Disk Address (WRITE,ID)

You may use the following form of the WRITE imperative macro for creating a direàt
access fileor forupdating an existing one on disk:
LABEL

[name]

OPERAND

1OPERATION1

WRITE

( filename ‘j

(1)
(i
The second positional parameter, ID, specifies that a search is to be made in the output
file for a block whose relative disk address (ID) matches the content of the SEEKADR field
in your program (1 5 6 1 3) The ID you present to data management in this field may not be
negative or zero it must be in the form you specify with the RELATIVE keyword parameter
(15 6 22) If you issue the WRITE ID macro to process a file you must specify the WRITEID
keVword parameter in the DTFDA or DTFNI declarative macro defining the file (1 5.6.35);
the AFTER keyword must not be specified (15.6.2). Ifthe blocks inyour file are keyed, you
must specify the length of these keys with the KEYLEN keyword parameter (1 5.6.13).
Before you issue the WRITE ID macro you must ensure that the correct relative disk
address is contained as a fixed-point binary number in the form you have specified with
the RELATIVE keyword in the 4-byte SEEKADR field in your program If you define the
IDLOC and the SEEKADR fields to be the same physical area in main storage, data
management is, in effect, providing a new relative disk address to your WRITE,ID macro
automatically (Refer to 1 5 6 7)
In addition to providing your WRITE,ID macro with the correct ID, you must have the new
block already formed in the I/O area before you issue the macro. If your file contains keys,
moreover, you must place the key of each block in the I/O area ahead of the record proper
(or ahead of a string of blocked records), allowing for the block descriptor and record
descriptor words (BDW and RDW) as appropriate In executing the WRITE ID macro data
management locates the relative disk address you have specified (if it can) and writes the
entire block at the location including its key if yours is a keyed file
you
or of any form of the WRITE macro
Following your issue of the WRITE,lD macro
ensure
to
necessary
is
This
file
the
other
to
any
issuing
before
macro
WAITE
a
issue
must
that the intended I/O is completed Among other things the WAITF macro returns the
relative disk address of the next block in physical sequence in the file to your IDLOC field
if you have specified this keyword, in the form you have specified with the RELATIVE
keyword. If the relative disk address specified is not located, data management set the
record not found flag (byte 1, bit 3) in filenameC, which you should test in your error
routine when you are updating a file If the block written by the WRITE ID macro occupies
the last possible position on the current track data management sets the last block on
—

—

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-91

track accessed flag (byte 0, bit 0) in filenameC, but, because this is not an error condition,
control does not pass to your error routine. If you are controlling movement through your
file by incrementing the relative track number when you reach the end of track, you must
test for the setting of this flag inline.
There are two ways to use the WRITE,ID macro to create a new direct access file: a simple
file-filling operation that uses this macro alone, and an operation writing on specific tracks
that you select and move to, via the CNTRL macro, followed by the WRITE,ID macro.
When you open a new DTFDA or DTFNI file for the first time for output on a variablesector disk,* unless you have specified AFTER=YES in the DTF (15.6.2), the OPEN
transients preformat every track in the file, writing the count fields throughout at intervals
corresponding to your specified block size, and then position you at the head of relative
track 001, ready to write the first block. By providing your WRITE,ID macro with the
relative disk address for the first block, and thereafter incrementing the contents of your
SEEKADR field, you may fill your file at will, in any sequence of relative track or relative
record addresses. If you simply increment the relative record number in the SEEKADR
field, for example (having specified RELATIVE=R), before each WRITE,lD macro issued, you
achieve a file load in the simple sequential order in which you present your blocks. In this
circumstance, you have no need to test for the last block on track accessed flag because
data management automatically shifts you to the head of the next relative track. When you
close the file, data management records the end-of-data ID in the DTF file table and in the
disk format 2 label; you do not need to issue the WRITE,AFTER,EOF imperative macro for
this.f On the other hand, if you need to structure the data in your direct access file in
such a way that you must skip relative track 001 or certain other tracks during its initial
loading, the first imperative macro to issue after opening the file might be the CNTRL
macro (1 5.7.15), guided by a relative track address you have placed in the SEEKADR field
to position you to the head of the first track you wanted to receive your data. After
execution of the CNTRL macro, simply issue successive WRITE,lD macros, incrementing
the record number in the SEEKADR field until end of track; then increment the relative
track number before issuing the next CNTRL macro. (You cannot pair the WRITE,lD macro
with the WRITE,RZERO macro for this mode of processing, because this macro also
requires you to specify AFTER=YES in your DTF, and this is incompatible with using the
WRITE,lD macro.)
Updating an existing direct access file with the WRITE,ID macro is conceptually different
from creating a new one, although the action of the macro is the same. One thing to keep
in mind, however, is that the new block is written in the place of the old one on disk, and
data management requires that it be the same length. New blocks written to an existing
file must have the same length as existing blocks. The BLKSIZE specification is checked at
file open time against the block size recorded in the disk format 1 label; if these are
unequal, data management issues error message DM17 (INVALID BLOCK SIZE SPECIFIED)
and branches to your error routine. (Refer to Appendix B.)

*The variable-sector disks used with OS/3 data management are the SPERRY UNIVAC 8411, 8414, 8424, 8425, 8430,
and 8433 Disk Subsystems. The SPERRY UNIVAC 8415, 8416, and 8418 Disk Subsystems are fixed-sector disks and
are already preformatted at OPEN time.
tin fact, because this macro requires that you specify the AFTER keywordin your DTF and you cannot issue the WR1TE,ID macro if you
do, you cannot use WRITE,AFTER,EOF.

UP-8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-92

If you know the relative disk addresses of all the blocks that require updating, and you
have the update information formatted to replace the entire block (including its key, if this
is a keyed file), then you need not read your existing blocks into main storage. You need
merely issue successive WRITE,lD macros to update the file, providing the relative disk
addresses in the order of the update information in your input file.
On the other hand, if you must read the old blocks to determine whether or where tà
update them, you either would issue the READ,lD macro, process each incoming block,
and then issue the WRITE,lD macro to update each block that requires it, or you would
issue the READ,KEY macro followed by the WRITE,KEY macro. Remember the difference
between the lDs returned after execution of the two different READ macros, and plan your
use of the IDLOC field contents accordingly (Table 15—5). To equate the IDLOC and
SEEKADR fields in update mode is not good practice.
Another point to keep in mind about updating a keyed file is that you must not only specify
the length of keys with the KEYLEN keyword parameter in your DTF, but you must also
provide a key for each updated block in your I/O area. Both the key and the data fields of
the block on disk are updated when you specify this keyword.
Data management does not provide you adirect means of changing only the key of a block
on disk. You may do so with the WRITE,ID macro only by presenting data management
with a block in main storage that contains a new key field and a data portion that is
identical to that already on disk. Of course, this can be done by reading in the whole block
in question and updating only the key field before copying it all back to disk with the
WRITE,ID macro. (You must not attempt this with the READ,KEY/WRITE,KEY macros,
because with this pair you should not change the key of a block before returning it to the
disk file.)
A massive update of a direct access file with the WRITE,lD macro may be made more
efficient if the update information is presented in the physical order of the blocks that it is
intended for on disk; this is especially true if the file has been created by using record
interlace and a LACE factor tailored to the updating program (15.6.8). Having a keyed file
precludes this possibility, because you cannot create a keyed file without specifying the
KEYLEN parameter, and you cannot use record interlace if you do. In deciding whether to
lace a direct access file that does not contain keys, you need, of course, to consider the
additional costs of sorting your input file before using it in your update program.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-93

WRITE,KEY

15.7.11.5.

Rewriting Randomly Retrieved Blocks to Disk (WRITEKEY)

When you want to effect a direct-access rewrite, or updating, of a block that you have just
retrieved with the READ KEY form of the READ command (157 142) you will use this
form of the. WRITE macro:
LABEL

OPERATiON

[name]

WRITE

OPERAND

filename
{il)

KEY

Here, the second positional parameter, KEY, specifies that the block just read by a
READ,KEY macro is to be rewritten to its original location on disk. Both the key and the
data field will be updated Remember to specify WRITEKEY=YES in your DTF (1 5 6 35)
You should also remember that if the new block is longer than the old the new block will
be truncated if the new block is shorter data management will pad out the original field
with binary zeros In either case the wrong length error flag (byte 1 bit 5) will be set in
filenameC (Appendix B). You should check this bit after issuing the WAITF macro that
must follow each WRITE,KEY macro.
Another point to remember is that, because each block to be rewritten by the WRITE,KEY
form must first be retrieved by the READ KEY macro consecutive issues of the WRITE KEY
formconstitute a sequence error and will be flagged as an invalid macro sequence (byte 0,
bit 6, of filenameC).
Because the WRITE,KEY macro does not conduct a search but relies on the search made
by the preceding READ,KEY macro, it is not possible to add new records to a file with the
WRITE,KEY macro alone. It is guided neither by the contents of the SEEKADR field nor by
the contents of the KEYARG field. The only way the WRITE,KEY macro could be used to
create a new file would be to originally create one whose keyed records contain blank or
zero-filled data portions and then use the READ,KEY/WRITE,KEY combination to overwrite
each null data portion with actual data. But this would be an inefficient and unnecessary
way to go about creating a file.
If you want to store the ID of the block updated by the WRITE,KEY macro, you should
specify the IDLOC keyword parameter in your DTF (1 5.6.7). The form in which this relative
disk address is returned to you is governed by your specification of another DTF keyword
parameter, RELATIVE, which is described in 15.6.22.

15-94

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

GET

15712.

Retrieving Records From Sequehtially Processed Disk Files (GET)

You use the record-level GET imperative macro to obtain records of all types, one at a
time, from DTFSD files or from sequentially processed DTFNI files, opened for input
processing. Data management reads the records, automatically deblocks them if they are
blocked, and delivers each unblocked or deblocked record to you. If you are processing in
an I/O area, it places the records there, one at a time; if you are processing. in a work
area, it delivers the records there from the I/O area.
When you use a work area, you must remember to specify WORKA=YES in the DTF
declarative macro (15.6.35). Because you specify the address or label of the work area to
be used each time you issue the GET macro, you may use more than one work area, and a
different one each time.
When your input records are blocked, and you have no work area, or if you provide two
I/O areas, you must also provide an index register (using the IOREG keyword parameter of
your DTF (15.6.11)), into which data management places the starting address (in the I/O
area) of the next available record An index register should not be used to keep track of the
current work area, because you specify this with each GET macro; if you elect to use two
or more work areas it is important to use them consistently
This is the format of the GET macro:
LABEL

[name]

OPERAND

t.OPERATiON

GET

filename

}

workarea

[{(o)

Positional Parameter 1:
filename
Specifies thern label of the DTFSD or sequentially processed DTFNIdeclarative
macroi nstruction.
(1)orl
Indicates that you have preloaded register 1 with the address of the DTF file
table.

UP-8068 Rev. 4

15-95

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

Positional Parameter 2:
workarea
Is the label of an area into which data management moves the current record for
you to process. (A different work area may be used for each GET macro.)
(O)orO
Indicates that you have preloaded register 0 with the address of a work area
Omit Positional Parameter 2 when you do not use a work area
If you specify only one I/O area in your DTF and your input records are not blocked you
may access the data directly in the I/O area (IOAREA1). Otherwise, you mUst specify an
index register with the IOREG keyword parameter or use a work area. Table 15—9 shows
the uses of an index register and work areas, and the actiohs taken by data management
under the various combinations possible;
Table 15—9. Use of IOREG Keyword Parameter for Processing Blocked or Unblocked Input Disk Files Sequentially with GET
Macro

Number of
I/O Areas
2

Number of
Work Areas
0

Record
Format
Blocked

Unblocked

OREG
Specification
Required

Data Management Action

YES

DMS uses IOREG to point to address of current record within the block contained
in IOAREA1.

OMS delivers each unblocked record directly to user in IOAREA1.

DMS deblocks in IOAREA1 and delivers each deblocked record to workarea specified
in positional parameter 2 of GET macro.

DMS delivers unblocked record from IOAREA1 to workarea specified in GET macro.

YES

DMS deblocks in one IOAREA and delivers deblocked records to other IOAREA for user
to process.

YES

DMS delivers unblocked record to IOAREA specified by IOREG, Alternate areas are
available for overlap processing.

YES

DMS deblocks in one IOAREA and delivers deblocked records to workarea specified by
GET macro. Other areas are available for overlap processing.

YES

DMS delivers unblocked record to workarea specified by GET macro, from IOAREA specified
by IOREG. Alternates are available for overlap processing.

When you are retrieving blocked input records with the GET macro, you may come to a
point in the current block where you want to skip over the remaining records to process
the first record of the succeeding block; the RELSE imperative macro is designed for this;
see 15.7.13.
You have a different imperative macro, FEOV, available if you want to discontinue
processing the current volume of an input DTFSD file in order to begin processing the
next. This macro may not be used with sequentially processed DTFNI files, however; see
15.7.7.

15-96

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

RELSE

15.713.

Skipping Records in Sequentially Processed Input Blocks (RELSE)

When you are processing blocked input records with the GET imperative macro from
DTFSD files or sequentially processed DTFNI files? you may reach a point at which you
want to skip over the remaining records in the current block andto commence processing
with the first record of the succeeding block. To effect the skip, you issue the RELSE
imperative macro; the next GET macro you issue makes the first record of the next block
available to you (15 7 12)
The format of the RELSE macro is simply
LABEL

[name]

tOPERATiONt

RELSE

OPERAND

filename
{(i)

}

Positional Parameter 1:
filename
Is the label in your program of the DTFSD or DTFNI declarative macro defining
the file you are processing sequentially.
(1)orl
Indicates that you have preloaded general register 1 with the address of the
DTFSD or DTFNI file table.
When you want to terminate processing the current volume of a sequentially processed
input file defined by the DTFSD declarative macro in order to begin with the next volume,
you will use the FEOV imperative macro (15.7.7).;

UP-8068 Rev. 4

SPERRY UNIVAC 0S/3
BASIODATA MANAGEMENT

15-97

READ

15 7 14

Random Retrieval from Direct Access Files (READ)

The READ imperative macro is a block-level input prQcessing macro that, in its two forms
and various ues, provides you with the following capabilities for randomly processing disk
files defined as input files by the DTFDA and DTFNI declarative macros, or as input/output
files by the DTFNI macro:
•

retrieving a block or record by means of its relative disk address (ID), which you
specify;

•

retrieving a block by searching for its key, to be matched with a key you specify (the
search begins at an address that you also specify); and

•

updating a previously created file.

The READ macro causes a block to be retrieved from disk and to be read into main storage
at an address specified by the IOAREA1 keyword parameter of your DTFDA or DTFNI
declarative macro, when you specify only a single I/O area (15.610). On the other hand,
when you are processing DTFNI files and have specified a second I/O area (IOAREA2; see
15.6.11), the main storage address is contained in the index register you mustspecify with
the IOREG keyword parameter (1 5.6.11). (The DTFDA declarative macro, as you know,
does not support either the IOAREA2 or the IOREG keyword parameter.)
Because the READ macro operates at block level, and OS/3 data management handles
blocking and deblocking automatically only for sequentially processed files, you must
control any deblocking necessary when you read blocked input files defined by the DTFNI
macro. This deblocking you will take care of via the GET imperative macro (1 5.7.1 2), after
the READ macro has placed a block into main storage from disk. As you know, you may
not specify either of the blocked record formats for a DTFDA file. If your “unblocked” block
in a DTFDA file actuallycontains more than one logical record, therefore, you must tend to
the deblocking yourself. The GET macro is not supported for DTFDA files, however, and is
flagged as invalid if issued to such a file. The best solution to this quandary is probably to
avoid it by defining such a file with the DTFNI declarative macro in the first place.
Another important point to remember is that, after each READ macro you issue, you must
issue a WAITF imperative macro before you issue any other imperative (1 5.7.16). This is
necessary, to ensure that the intended transfer of the block from disk to main storage has
indeed taken place.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 5-98

If you want data management to store the relative disk address (ID) of the block retrieved
the two forms of the macro make different
by the READ macro, or of the next block
parameter of the DTF declarative macro
keyword
the
IDLOC
specify
would
you
returns
you is governed by your specificaton of
to
returned
(15.6.7). The form in which the ID is
another DTF keyword parameter, RELATIVE, which you might also review (15.6.24). The
uses of the IDLOC keyword parameter are further developed in what follows.
—

—

OS/3 data management supports the READ macro only for DTFNI flies or for DTFDA f lies

15-99

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

READ,i D

15.7.14.1.

Random Retrieval of Records by Relative Disk Address (READ,ID)

In order to use the READ,ID form of the READ macro to retrieve a specific record by its
relative disk address, or ID, you have a number of keyword parameters in the DTFDA or
DTFNI declarative macro to consider. First of all, recall the uses of the IOAREA1 and
IOREG keyword parameters (the latter is used with the DTFNI macro only) to specify the
main storage address into which the block that contains the record will be read (15.6.10
and 15.6.1 1). You will also need to use the SEEKADR keyword parameter (1 5.6.26) to
specify the 4-byte field in your program into which you will place the relative disk address
of the record you want retrieved (which must always be greater than zero) and you must
give notice to data management that you will be using the READ ID form of the macro by
specifying the READ=YES keyword parameter in the DTF (15.6.18). Both the key of the
block (if a key exists) and all data the block contains will always be read in. The form in
which you provide the relative ID of the desired record must be the same as you specify
with the RELATIVE keyword parameter.
Further, if you need data management to return to you the ID of the next block in the file
or partition after you issue the READ,lD form of the macro, you would specify the location
to which the ID is to be returned by the IDLOC keyword parameter (15.6.7). Finally, recall
that the form in which the ID is returned has been specified by means of the RELATIVE
keyword parameter (1 5.6.22).
When the logical record you want retrieved by ID from a DTFNI file lies within a block of
records retrieved, data management reads the entire block into your I/O area. After your
execution of the mandatory WAITF macro, data management returns the displacement of
the desired record into the block (measured in hexadecimal bytes) to the DTF file table,
right-justified in a 2-byte field designated as filenameD. You may address this field by
concatenating the character “D” to your 7-character file name. To retrieve subsequent
records contained in the same block, you may issue successive GET macros in the 2parameter form to specify the work area into which data management is to move the
current record (15.7.12). An important point here is that you must know the structure of
your blocks: there is no end-of-block indication provided by data management to prevent
you from going past the last record in a block you are processing in this way. A GET macro
issued after you have processed the last record in a block causes the entire next block to
be read in from the DTFNI file, and the first record from it to be moved to the specified
work area.
The format of the READ,lD form of the READ macro is:
LABEL

[name]

OPERAND

OPERATIONt

READ

filename

}

snimy 1JWVAC OS/a:
BASIC .DALk.MANAGEMEt4T

UP-8065 ReQ. 4’

15-1Q

j. .;

.lc4tiorL8JYarameter 1:
filename
Is the label in your program of the DTFDA or DTFNI declarative macro that
td0IpQ5SQ !i!e from which you are retrieving regor....
...

j1)pr’L.

. .

..•

•.

.-•.•.

.‘:“

•

.•.•

-.9

....

ave reFoaded register 1 vith tpe iddres of the DtF file
4
Indicalas that you I
table.
c:
— :
:

.:.

Positioral pararjietet 2
•-

‘

Specif&s that a search is to be made for a frecord with an ID matchin9 the
relflve’ disk addrás you have presented to data management via the field
tpe SEKADR ke%cwdid parameter áf the DTF macrcCin the to?m you
have specifiEd with the RELATiVE keyword patkmeter

specified’.ui

.‘i

.‘t’

‘.r•

.t:
.4

‘I..

.t.

.9
-

“.
“.

‘

•-

•I

2;.

a:.
•

.—..‘•.

•:r

:‘‘

‘

—...•

is:.

••.•

.‘::

‘

‘;:‘

•

•.

•

•;:.€,

•,..•.

•.,

.:r.

•

—.

•I;.•./

i.
•

.:.

...gr

‘

;:‘‘•

..‘:

•.

‘.

•

::.ö

ç.•

•

•.•:

t’

•

•i...

•‘

:.—..

•

:3
9.;..

‘.9.

•;;..•:

••#

;.‘“:‘;i.’.•.’
,..:•

•

“..

•.

Ct’

•

‘._.,

—.
‘‘

c’

•:.c•.

.‘

•7

‘“••

‘!

•

•:,v ::?e

•.

‘h4f

•.

::.

•9.

.
‘..

iS;—
—

‘L

•‘

:€.

••

•‘

‘:.

.•;‘:.••:•2;.’

:.t.

.c.,

si!

•

.:•

•)
•:

•‘••

1’ i:

‘‘:

.‘

•

•.

c.:

..
‘

‘ri,. .

UP-8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-101

READ,KEY

15.7.14.2.

Direct Retrieval and Updating of Input Blocks by Key (READ,KEY)

You will use the READ,KEY form of the READ macro when you want to retrieve blocks by
a search on key from input files defined by the DTFDA macro (15.5.2) or randomly
processed files defined by the DTFNI macro (15.5.3). It is this form of the READ macro that
is also used, in combination with the WRITE,KEY form of the WRITE macro, for updating a
randomly processed disk file (15.7.11.5).
You have a number of points to consider when you are using the READ,KEY macro; these
involve several keyword parameters in the DTF. First of all, in order that data management
may set up the DTF file table properly for this macro, you must specify the READKEY
keyword parameter. To guide the search, you must provide both a search argument and a
starting point. With the KEYARG keyword, you specify the key that is to be matched by the
key of the block you want retrieved (1 5.6.12); with the relative disk address that you place
in the 4-byte field, whose label you specify with the SEEKADR keyword (1 5.6.24), you
supply the starting point of the search. As to its end point, if you want the search to
continue past the end of the current track to the end of the current cylinder, you specify
the SRCHM keyword parameter; otherwise, the search ends at the end of the track
(15.6.26).
Remember that the relative disk address you supply to data management must be in the
form (relative track or relative record) that you selected when you specified the RELATIVE
keyword parameter (15.6.22): the same form is used by data management when it makes
the return of the relative disk address of the retrieved block to the 4-byte field whose label
you specified with the IDLOC keyword (15.6.7).
If the search is successful, data management moves the entire block to your I/O buffer,
including the key. Thus, the length of IOAREA1 (and of IOAREA2, if this is a DTFNI file and
you have specified double-buffering) must accommodate the length of the key as well as
the length of your data record. If this is a DTFNI file containing variable-length blocked
records, you have not only the KEYLEN specification and the block descriptor word (BDW)
to keep in mind, but also the record descriptor words (RDWs) that precede each logical
record. In a DTFDA file, you may not specify either of the blocked record formats, but a
variable-length record in this type of file is also preceded by a BDW and an RDW, exactly
as the variable, unblocked record is in the DTFNI file. A glance back at Figure 14—4 in the
preceding section will help you visualize what is in your I/O area when the READ,KEY
macro completes a successful search. Note that both the BDW and each RDW are four
bytes long.

15-102

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

The data portion of a fixed, unblocked record from a DTFDA or DTFNI file begins at a
displacement into your I/O area that is equal to your KEYLEN specification; the same is
true of the first of your fixed-length logical records in the blocked format in DTFNI files; the
succeeding records begin at intervals equal to your RECSIZE specification (15.6.21). When
you have variable, unblocked records in either file, the first (or only) data portion is found
at a displacement that is eight bytes longer than your KEYLEN specification; the
displacement of each succeeding variable record in a blocked DTFNI file may be calculated
by adding in the contents of the first two bytes of the RDW for the record preceding it
Figure 14—4 shows these relationships which you must use in accessing your logical
records from a block retrieved by the READ KEY macro after a successful search
If the search is unsuccessful, data management first sets the record not found flag (byte 1,
bit 3) in filenameC and either the end of track (byte 1, bit 6) or both this flag and the end
of cyhnder flag (byte 1 bit 7) depending on whether or not you have specified
SRCHM=YES in the DTF Data Management then branches to your error routine (or
returns control to you inline if you have no error routine specified) (Refer to Appendix 8)
Your error routine should check for these bits and provide action that is appropriate for
your application otherwise if you accept error returns inline you should test for these
flags after each issue of the READ KEY macro
The format of the READ KEY form of the READ macro is
L..ABEL.

[namel

tOPERATIONi2

READ

OPERAND

(filename

‘

KEY

(i
Here, the second positional parameter, KEY, specifies that data management will search
for a block that has a key matching the one you have placed in the location in your
program specified by the KEYARG keyword parameter. The search begins at the relative
disk address yoU have placed in the location defined by the keyword paiameter SEEKADR
and continues to the end of the one track, unless you have specified the SRCHM keyword
parameter.
The I/O area into which data is read will contain both the key and the data portions of the
block read data management moves the key to the I/O buffer

UP 8068 Rev 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15-1 03

CNTRL

15.7.15.

Controlling Disk Head Movement

a Track (CNTRL)

The CNTRL imperative macro gives you a means by which you may overlap disk head
movement with the processing of your records. While it may be used when you are
processing files defined by the DTFDA, DTFSD, or DTFNJ. macros, the CNTRL macro is
perhaps most useful for achieving some increase in throughput when you are sequentially
processing files on a shareable disk volume (A shared volume is one that may be
accessed by more than one user program in a multiprogramming environment at your
installation It is described in the device assignment set by a VOL job control statement
which has S as its second positional parameter)
When you issue the CNTRL macro to a DTFSD file data management issues a seek
command that positions the disk head to the track you are currently processing. When you
are processing a DTFDA or DTFNI file, on the other hand, you may issue the CNTRL macro
to reposition the disk head to a new relative track address, which you place in the location
specified by the SEEKADR keyword parameter of your DTF (15.6.26).
When your program and another are sharing the same disk volume, issuing CNTRL may
increase your throughput by positioning the disk head to the specified track while you are
processing your records. Any CNTRL macro you issue to a blocked file is ignored, and data
management will wait until the block is finished. (Of course, this feature protects you from
interrupting your own block processing prematurely, as well.)
When there is no problem of seek contention among programs (as when you are
processing a nonshared volume), using the CNTRL macro may still increase your
throughput and save you overall processing time. If you move the new current track
address into the location specified by SEEKADR after successful completion of a READ or
WRITE operation, for example, and then issue the CNTRL macro before you execute your
other record processing instructions, the disk head is repositioned during the time you are
processing, and data management can more promptly execute the next input or output
imperative macro you issue.
It should be clear from the foregoing discussion what the position of the WAITF macro
must be that you will always issue after a READ or WRITE macro to randomly processed
files (15.7.16): it must follow this macro and precede the CNTRL macro. To prevent you
from repositioning the disk head before you learned of an incomplete input/output
operation, data management will set the WAITF required flag (byte 0, bit 7 of filenameC)
after determining that you have failed to issue the WAITF macro before executing the
CNTRL imperative macro after a READ or WRITE macro. (The WAITE macro is not required
after the CNTRL macro; the CNTRL macro makes no return to the IDLOC field of your
program.)

15-1 04

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP—8068 Rev. 4

This is the format of the CNTRL macro used for processing all nonindexed disk files:
LABEL

[name]

OPERAND

LOPERATION

CNTRL.

(filename
(1)

‘

SEEK

The second positional parameter, SEEK, is always required; it specifies that data
management will issue a seek command to the disk head, positioning it for DTFSD files to
the current track or, for DTFDA or DTFNI files, to the relative track address contained in
the 4-byte location whose label you have specified with the SEEKADR keyword parameter.
(The address at this location should begiven in the form Ott, where tt is the relative track
number and 0 is binary 0; it must be left-justified in the SEEKADR field, and you must
have specified RELATIVE=T in the DTF for the file.) In the first positional parameter,
filename is the label in your program for the DTFSD, DTFDA, or DTFNI deàlarative macro
defining the file; (1) or 1 indicates that you have pieloaded register 1 with the address of
this DTF file table.

151O5

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev,4

WAITF

15.7.16. Waiting on Completion of I/O to Random Disk Files (WAITF)
When you are randomly processing input or output disk files defined by the DTFDA or
DTFNI declarative macros, using the WAITE macro is a compulsory safety measure to
ensure that the data transfer initiated by a READ or WRITE macro is completed before you
issue another imperative You must issue the WAITE macro following each READ macro
(15.7.14) or WRITE macro (15.7.11) you execute, before you may issue a CNTRL macro or
another READ or WRITE macro for the same file or partition. The WAITF macro is not
required following the CNTRL macro.
When data management detects that you have omitted this mandatory macro, it sets the
WAITF required error flag (byte 0, bit 7 of filenameC), and transfers control to your error
routine, if you have specified one, or to you inline.
The WAITE macro itself acts to check the completion of the data transfer you intended,
and to set the appropriate status or error bits in the status code fields of filenameC. These
bits you must always check after the execution of the WAITE macro
it is pointless to
anticipate the execution of the WAITE macro by checking filenameC immediately after you
issue the READ or WRITE macro, although perfectly legitimate to check it when you are
processing sequentially with the PUT macro and GET macro. (You do not use the WAITE
macro with these sequential input/output processing imperatives.)
—

The WAITF macro is not involved in the parity checking of output records; this is
performed as a separate operation by data management only when you specify the
optional VERIEY keyword parameter in your DTE (1 5.6.32).
The format of the WAITE macro is simply:
LABEL

[name]

LOPERATiONL.

WAITF

OPERAND

filename

}

As elsewhere, filename is the label in your program of the DTEDA or randomly processed
DTENI declarative macro; (1) or 1 indicates that you have previously loaded general
register 1 with the address of the corresponding DTF file table.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

15-106

NOTE

Accessing the Current Relative Block Address (NOTE)

15.7.17.

The NOTE macro, which you may use only with DTFNI files, is one of the extended
capabilities OS/3 data management provides for processing nonindexed disk files You
may use it whether you are processing DTFNI files randomly or sequentially, to access the
relative address of the current block or record The NOTE macro is used in conjunction
with the POINT macro (157 18) where a coding example is given
When you are processing sequentially after issuing a GET or PUT macro you use the
NOTE macro to access the relative address of the current block and the displacement of
the current record within this block. Because the addresses it returns are partition-relative,
the NOTE macro relies upon your having selected the partition previously by issuing the
SETP macro (15 7 4) and if you are working within a subfile of this partition having
positioned yourself to this with the SETS macro (15.7.5).
For sequentially processed DTFNI files the NOTE macro returns the address to a 6-byte
field of the DTF file table in discontinuous binary in the form:

Obbbdd
where:

Obbb
*
Is the number of the current block relative to the first block in the file 0 being
binary 0.
dd
Is the displacement, measured in hexadecimal bytes, of the current record within
that block.
For randomly processed DTFNI files, you issue the NOTE macro following a READ or
WRITE macro. The 6-byte address is in discontinuous binary, and the form of the address
is governed by what you have specified for the RELATIVE keyword parameter in your DTF
(1 5.6.22). If you have specified RELATIVE=R, the form is:
rrrdd
where

rrr
Is the relative record address of the current block.
dd
Is binary 0.

15-107

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

If you have specified RELATIVET, on the other hand, the address returned is in the form:
Ottrdd
where:
Ottr
Is the relative track address of the current block; that is, r is the number of the
block on the relative track denoted by Ott, 0 being binary 0.
dd
Again, is binary 0.
You need to use the SETP and SETS macros for randomly processed files also, as
mentioned in the previous paragraph, to pre-position yourself to the correct subfile of the
correct partition.
The NOTE macro returns the address you have specified to a 6-byte field in the DTFNI or
DPCA file table that you address by concatenating the character “B” to your 7-character
filename or partition name. It is important to remember that you must address this field as
filenameB whether you are processing the first partition (PCA1) of a partitioned DTFNI file
or are processing a nonpartitioned file. It is only when you are working in the other
partitions (PCA2 through PCA7), that you address this field as partitionnameB.
This is the form of the NOTE macro:
OPERAND

OPERATIONA

LABEL

NOTE

[name]

filename

}

Positional Parameter 1:
filename
Is the label in your program of the corresponding DTFNI macroinstruction. The
partition name is never used.
(1) or I
Indicates that you have preloaded register 1 with the address of the DTFNI file
table.

you must issue the
appropriate SETP/SETS macros before issuing the NOTE macro (15.7.4 and 15.7.5).
Remember that

all

returned

addresses are partition-relative;

15-108

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

POINT

15718.

Positioning a File or Partition to a Relative Block Address (POINT)

The POINT imperative macro is your means of randomly positioning a sequentially
processed DTFNI file or partition to a relative blockaddress. This address may be obtained,
for example, via the NOTE macro just described (15.7.17). Like NOTE, the POINT macro is
a useful extension of capabilities (OS/3 data management provides for processing your
DTFNI files; it is not supported for files you define by the DTFDA or DTFSD macros.
Another similarity to the NOTE macro is that the POINT macro also relies on you to have
selected your partition via the SETP macro (15.7.4) before you issue it. A third similarity is
that the form of the relative block addrOss used by the POINT macro is the same form the
NOTE macro uses.
When you issue the POINT macro for a sequentially processed DTFNI file, data
management modifies the current partition-relative block address and block displacement
that it maintains in the DTF file table (or in the DPCA partition table if you are processing
in a partition) you are subsequently processing from the new address
An important point to remember is that the POINT macro is effective onlyso Ion9 as you
continue to use the GET and PUT macros in your subsequent processing Of the file or
partition. If you subsequently issue a READ or WRITE macro(which would be quite
legitimate, for these are DTFNI files), these macros cause the current partition-relative
block address to be modified by the relative track or record address you will have supplied
to data management in the area specified by the SEEKADR keyword parameter of your
DTF (1 5.6.24). There is no error indication returnedto you when this occurs;’you must rely
upon yourself to keep this point in mind.
This is the format of the POINT macro:

LABEL

[name]

OPERAND

L\OPERATIONt

(filename)
(1)
)
(i

POINT

‘

Positional Parameter 1:

(address-field
‘(O)
(0

filename
Is the label in your program. of the corresponding DTFNI macroinstruction.
V

V
V

(1) on
Indicates that you have preloaded register 1 with the address of the DTFNI file
table.

UP-8068 Rev: 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

15—109

Positonal Parameter 2:
address-field
Is the label of a 6-byte field (Obbbdd) in your program containing the relative
block address and displacement of the record within the block The relative block
address portion (Obbb) is right-justified in the first four bytes and the record
displacement (dd) is right-justified in the second two
(0) orO
Indicates that you have preloaded register 0 with the address of the 6-byte
address field
Remember that when you are processing within a partition or a subfile of a partition you
must have preselected these by issuihg the appropriate SETP and SETS macros (15:7.4
and 15 7 5) For this reason the partition name is never used as an operand of the POINT
macro
The coding example that follows shows the use of a NOTE macro to access the current
relative address of a sequentially processed output file, FILE1, whenever a record
containing a desired value VALU in its first four positions is encountered This address
is then used by a POINT macro in a selective input or updating of FILE1, in what amounts
to random processing in a sequential file FILE2 is used as an index to FILE1 for this
processing
Exa mple:

LABEL

A0PERATi0NA

1EPI I
I

1111111

—

11•11

PIc.Jj—r

a I

[till
‘‘I

I
I

I
i

—

1%iIEI

I(..1TI

—

i’

(..)iT1

I a

—

i’

1. I

LjJLlJ,,i

p:’

I
I

III
-

I
I

1111

I
I

—

tL...E2I,(O)

1111

—

L..EIt,
r
F
F
L
1
i
Z
...
.t

L—.E
F.t
1

—

I
I

.,_

‘

I_I

I
—

—

i
—

iiitl
I

I
I

—

l!1t

OPERAND
16

I
I

IlL!

iJJ

iLLLj

u_i
_

BASIC DATA MANAGEMENT

Example (cont):

.i
EI’
i
2
1
I
I

4,.

IItb.%

—

7’.

i’i

—

I
I

—

11
E
1
D
2 1i

—

I_II

—

r
1
PI(.3

—

.._El
iFr
1

—

I
I

liii

iii

I
I

L...’ \/‘IL—(_S’

I
iL..
E
1
I

III

11111

III%1-

Iii

1.1

—

iiil

—

I1’I.IIAi)
2
i

.tL._El

I
1111111

iii

—

T
1
IE
—

iiil

—

t.l_.Ei2.

—

OPERAND

LxOPERATiONL

LABEL

FILE1 and FILE2, both DTFNI files, are opened for sequential output processing.

Record output to FILE1 is tested for desired value

VALU

NOTE macro is issued when ‘VALU’ found; relative address is returned to

filenameB.
4.

Relative address found by NOTE is output to FILE2, which will serve as an index
in STEP2.
--

input

(assume file

FILE1 is reopened for updating FILE2 for
processing directions have been reset).

Record retrieved from FILE2 is the address of a record in FILE1 containing
‘VALU’.

processing

POINT macro is issued to position FILE1 to address obtained in 6.

Sequential processing continues in FILE1 from position set in 7

Definition of the desired value normally located outside of executable code

BASIC DATA MANAGEMENT

15.8.
15.8.1.

ERROR AND EXCEPTION HANDLING
FilenameC

When certain errors or exceptions to file processing performance are detected by OS/3
data management, it will make appropriate entries in specific fields of the DTF file table,
which your program may address in order to learn of these conditions and take the proper
course of action on regaining control. One such field is fllenamèC (in the nonindexed file

processor system a 4-byte field), which you may access by concatenating the character
“C” to your 7-character logical filename.
A point to remember when you are processing the partitions of a DTFNI file is that, just as
your ERROR routine is a file-relative specification and belongs in your DTFNI declarative
macro (not in the DPCA declarative macro defining the partition), you do not have a field
for error flags in the partition control appendage established in the DPCA macro. That is,
there is no “partition-na meC”; error and status flags set during processing of partitions
are set in the field of the DTFNI file table and are accessed, therefore, as filenameC.
Most of the error and status flags have already been discussed in preceding paragraphs;
refer to Table B—3 for the meanings of the bits in filenameC of the DTFSD, DTFDA, and
DTFNI filetables that are set to binary 1 by OS/3 data management for certain error and
exception conditions.
Not all of the status flags represent conditions causing transfer of control to your error
routine. Some of these must be tested for inline in your program if you want to act upon
them.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

16-1
Update B

16. System Resource Control

16.1.

DEVICE ALLOCATION AND FILE ASSIGNMENT

In OS/3, the supervisor and job control have the essential responsibility for reserving
main storage and allocating peripheral devices for jobs that appear in the control stream
and make their needs known through job control statements.following the JOB statement.
Of these statements, DVC, VOL, EXT. LBL, and LED are essential for providing information
relating to your files. With proper Use of these statements you may reserve peripheral
devices and identify and assign to your program the files you have on them or will place
on them.
16.1 .1. Use of Job Control Statements
Every file that you intend to reference in your program must be represented in the job
control stream by a set of control statements, called the device assignment set, which
contains at least a DVC statement followed by an LED statement; Between these basic two,
you will need to insert as many as six other statements for your magnetic tape and disk
files: the VOL. EXT, LBL, LCB, VEB, and DD statements. The device assignment set specifies
the relationships between your files or volumes andthe peripheral devices; there is one set
for each file. Eollowing is a short summary of the functions of these statements; all are
described in the job control user guide, UP-8065 (current version):
•

The DVC statement assigns peripheral devices to your job.

•

The VOL statement specifies the magnetic tape or disk file volumes to be accessed by
the job.

•

The EXT Statement establishes new disk files or extends existing files on disk.

•

The LCB statement specifies and loads to the printer a unique load code buffer that
overrides the LCB set at SYSGEN time.

•

The VEB statement specifies and loads a unique vertical format buffer that overrides
the VFB set at SYSGEN time.

•

The DD statement modifies fields within the DTE file table at run time and avoids
recompiling DTE s when changes in DTE specifications are required

16-2

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP 8068 Rev 4

The LBL statement supplies label information for magnetic tape or disk files.

•

The LFD statement identifies the file control block for each file used in your job.

Card and paper tape files use only the DVC and LED statements and optionally the DD
statement. The printer always uses the DVC and LFD statements and optionally the LCB,
VEB, and DD statements.
16.1.2.

Sample Device Assignment Set

Following is an example of a set of control statements that you would use for reserving
space for a sequential disk file that is to be created:
LABEL

AOPERAT1ONA

OPERAND

1016
VlC
// 1
l.VlLJ

,iC., ,5,

7L
i”

/‘

1_.FiD I i
1

•

This device assignment set will cause modification of the volume table of contents (VTOC)
of disk pack 124365 to show that a sequential file called ‘INVENTORY MASTER EILE’
exists, and that the space reserved for it occupies a specific position on the pack. OS/3 job
control will also note that your program will address this file as ‘INVNTRY’ (its logical
name), and that space for one extent entry in the prologue area will suffice. To start with,
the file will be assigned 10 cylinders of contiguous space. When this space is exhausted,
you desire automatic extension, five cylinders at a time.
When space for only one extent in the prologue area is specified, no dynamic extension
can take place.
For a program that will subsequently operate on this file, you would use the same set of
job control statements, except that you would omit the EXT statement If you want to
recreate a file (for example, if an error occurred during your first attempt to create it), you
may use the lNlT positional parameter of the LED statement. This parameter has the same
effect as scratching the file and reallocating it to the same area as it previously occupied
on disk.
16.1.3.

Job Control Deallocation Statement (SCR)

The OS/3 job control language also provides an SCR statement that you may use to
deallocate (scratch) a file from a disk pack. When you use this statement, you must use an
LED name that is the same as the one you have used for the file in a preceding valid
device assignment set (DVC-LFD) The SCR statement will deallocate the file and its
extents before the program named in the next EXEC statement in the control stream is
executed; therefore, you may use it to free disk space needed for a subsequent job or job

UP-8068 Rev. 4

SPERRY UNIVAC 0S/3
BASIC DATA MANAGEMENT

1 6-3
Update A

step. (The disk space management facilities of the OS/3 supervisor also include an
imperative macro, SCRTCH, that provides similar functions an& is used for dynamic
deallocation (16.3).)

16.1 .4,

Using the File Lock Feature

The OS/3 file lock feature allows you to control the sharability of a file while you are
using it. Sharability control only applies to lockable files. To use the file lock feature,
proceed as follows:
sStepl
At system generation you specify the FILELOCK parameter to indicate which files are
lockable.
•

Step2
In your file definition (within your BAL program) and in the device assignment set for
the file (regardless of the program type), you specify your read/write requirements
and indicate whether other jobs or tasks within a job can share the file.

In the following paragraphs we will describe how to indicate which files canbe locked and
how to set the various degrees of sharability.
16.1 .4.1.

Indicating Which Files are Lockable

You indicate which files are lockable by using the FILELOCK parameter in the SUPGEN
section of the parameter processor at system generation time
If you choose FILELOCK=NO or omit the parameter only the system files prefixed with
$Y$ are lockable. No user files can be locked.
If you choose FILELOCK=YES all system files (prefixed with $Y$) and all files prefixed
with $LOKO1-$L0K99 are lockable
If you choose FILELOCK=SHARE, all files are lockable.
16 1 4 2

Setting File Locks for Data Files in BAL Programs

After you specify which files are lockable you specify the degree of sharability for each of
these files
If you choose FILELOCK=YES at system generation time, you can lock any file whose
filename you prefixed with $LOKO1 -$L0K99 in the // LBL job control statement in the
device assignment set. If you do nothing more, any prefixed file will be exclusively locked
when it is opened during the execution of your program. You have exclusive use of the
file. You can read, update, and add to the file. No other user can open the file until you
close it.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

16-4
Update B

If YOU choose FILELOCKSHARE at system generation time, you can lock all of your files.
If you do nothing more, each file will be exclusively locked when it is opened during the
execution of your program. You have exclusive use of the file. You can read, update, and
add to the file. No other user can access the file until you close it.
In both cases (FILELOCKYES or FILELOCKSHARE specified at system generation), you
can override this lock by specifying one of the options of the ACCESS parameter or by
specifying the LOCKNO parameter in the DTF macroinstruction for a file. (See 11.4.1 and
11.4.11.)

—*-

You can also override this lock at program execution time in two ways. The first way is to
include a // DD job control statement that specifies one of the ACCESS parameter options
in your device assignment set. The second is to prefix the filename with an asterisk (*) in the
// LED job control statement in the device assignment set. This will cause a read-only lock
to be applied to the file; that is, you can only read from the file and all other users can only
read from the file.
NOTE:
To set file locks on SA T files, see the supervisor user guide, UP-8075 (current version).
16 1 4 3

Setting File Locks for Data Files in Non-BAL Programs

After you specify which files are lockable, you specify the degree of sharability for each of
these files.
If you choose FILELOCK=YES at system generation time, you can lock any file whose
filename IS prefixed with $LOKO1 -$L0K99 in the // LBL job control statement in the device
assignment set. If you do nothing more, any prefixed file will be exclusively locked when it is
opened in your program. You have exclusive use of the file. You can read, update, or add to
the file. No other user can access the file until you close it.
If you choose EILELOCK=SHARE at system generation time, you can lock all of your files.
If you do nothing more, each file will be exclusively locked when it is opened in your
program. You have exclusive use of the file. You can read, update, or add to the file. No
other user can access the file until you close it.

—*

In both cases (EILELOCK=YES or EILELOCK=SHARE specified at system generation) you
can override this lock at program execution time. There are two ways to do this. The first
way is to include a // DD job control statement that specifies one of the ACCESS parameter
options in the device assignment set. The second is to prefix the filename with an asterisk (*
in the // LED job control statement in the device assignment set. This will cause a read
only lock to be applied to the file; that is, you can only read from the file and all other users
can only read from the file.

UP-8068 Rev. 4

1 6.1 .4.4.

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

16-4a
Update C

File Lock Feature Summary

Table 16—1 summarizes the data management file lock feature. Remember, before using
this feature, you indicated which files are lockable at system generation time through the
FILELOCK keyword parameter. Once again, the available options are:
•

FILELOCK=NO indicates that only the system files prefixed with $Y$ are lockable. No
user files can be locked.

•

FILELOCK=YES indicates that all system files (prefixed with $Y$) and all files prefixed
with $LOKO1-$LOK99 are lockable.

•

FILELOCK=SHARE indicates that all files are lockable.
Table 16—i. File Lock Summary

LOCK Keyword

Action

ACCESS Keyword

LOCKNO®not
specified

This DTF: read use/
update use/add use
Other jobs: no
access

ACCESS=EXC

LOCK=NO®

This DTF: read use
Other jobs: read
use

ACCESS=EXCR

ACCESS=SRDO

ACCESSSRD

Action
This DTF: read use/
update use/add use
Other jobs: no
access
This DTF: read use/
update use/add use
Other jobs: read
use (ACCESS=SRD
specified for other jobs>

This DTF: read use
Other jobs: read
use (ACCESS=SRD
or SRDO specified for
other jobs>
This DTF: read use
Other jobs: read
use/update use/
add use (ACCESS=EXCR,
SRD, or SRDO specified
for other jobs>

NOTES:
LOCK=NO not specified and ACCESS=EXC are functionally equivalent.

LOCK=NO and ACCESS=SRDO are functionally equivalent.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

16-5
Update C

Remember, files are locked based upon the physical file name or $LOKnn prefix for the
name that you specified in the // LBL job control statement of the device assignment set.
The volume serial number is not used. Since this is the case, you should use a unique
physical file name or $LOKnn prefix to differentiate between unrelated files or file sets on
different volumes.

If you specify the same physical file name or $LOKnn prefix for unrelated files, you risk
having files locked out unnecessarily when the ACCESS options are not compatible. For
example, assume that files A and B are unrelated and are on different volumes. Also
assume that these files have the same physical file name on the // LBL job control
statement in their respective device assignment sets. If file A is lockable and has bèeh
opened for exclusive use with JOB1, no other job can open file B because its physical file
name has already been locked to JOB1 even though file A is an unrelated/different file.
Using unique file names prevents this from happening.

16-6

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

RENAME

16.2.

RENAMING A DISK FILE (RENAME)

Neither OS/3 job control nor data management provides a means for renaming an existing
disk file. If you need to change the name of one of your files (as recorded in the 44-byte
file ID field of the format 1 label on disk), you must do it dynamically within your program,
using the RENAME imperative macroinstruction provided by the disk space management
facilities of the OS/3 supervisor. Note that you should not issue the RENAME macro to a
file that is currrently open.
Function:
The disk space management macro RENAME allows you to rename any disk file but a
system file. By specifying the new 44-byte file identifier you want used, the 7-byte
logical file name, and the volume sequence number of the volume on which the file
resides, you cause the new file identifier to replace the old file ID in the format 1
label of the VTOC. (The 7-byte logical file name is the same as that appearing as the
first operand of an LED job control statement for the file and in the label field of the
corresponding data management DTF declarative macro.)
Format:

LABEL

[name]

LOPERATION

RENAME

OPERAND

Jparam-list
5 error-addr
[‘‘Ur)
(1)
f
‘

[,vol-seq-no]

Positional Parameter 1:
param-list
Specifies the address of a parameter list containing a 7-byte filename (as listed
on the LED job control statement and in the label field of the corresponding DTF
macro) and a 44-byte new file identifier. The parameter list is a 52-byte
character string, the first eight bytes of which contain the LFD-name of the file,
left-justified; the last 44 bytes contain the new file ID, also left-justified.
(1)
Indicates that register 1 has been preloaded with the address of the parameter
list.
Positional Parameter 2:
error-addr
Symbolic address to which control is transferred if an error is encountered.
(r)
Indicates that a register (2 through 12) has been preloaded with the error
address.

16—7

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Positional Parameter 3:
vol-seq-no
Specifies the volume of a multivolume file to be renamed.
If omitted, the value 1 is assumed.
Examples:

LABEL

LOPERATIONL

10
II

liii

111111
I

OPERAND

i
C
,
1
iCI2..)
’)
I

III

—

iii

Iii
I

SPERRY UNIVAC OS/3
BASIC. DATA MANAGEMENT

UP-8068 Rev; 4

16-8

SCRTCH

16.3.

DYNAMIC DEALLOCATION OF A DISK FILE (SCRTCH)

Function:
The disk space management macro SCRTCH enables you to deallocate any disk file
but a system file, making the space available for future use. After validating your
request, the SCRTCH macro removes the definition of the space or extents from the
format 1 or format 3 labels and updates the format 5 label in the VTOC. The extent of
the newly available freed space is inserted in the correct position in the format 5
record, where available extents are described in ascending sequence of relative track
addresses If you deallocate your file the SCRTCH macro deletes all format 1 2 and
3 labels from the VTOC and replaces them with format 0 labels. Note that yoU should
not issue the SCRTCH macro to a file that is currently open.
Three basic deallocation (scratch) functions are available to you:
•

deallocation of files by prefix;

•

deallocation of files by expiration date; and

•

complete deallocation of a file by file ID.

To deallocate files by prefix, you place a 4-byte prefix in bytes 76—--79 of the file
control block (FCB) of the file in main storage and specify the PREFIX parameter; the
SCRTCH macro searches the VTOC for files with file ID fields beginning with these
four characters and deallocates each one matched. The prefix may not include the
characters $Y$, so that it is not possible to you to scratch system files by mistake. But
by this macro you may deallocate all your temporary work files with one call on OS/3
disk space management.
To deallocate expired files, you specify the ALL parameter and include the expiration
date in the 3-byte expiration date field of the FCB; the SCRTCH macro compares this
with the expiration date in each format 1 label in the VTOC and deallocates all files
with earlier expiration dates.
To deallocate an entire file by the 44-byte file ID that is contained in the FCB, you
either omit the second positional parameter altogether, or specify (0) and preload bits
0 through 7 of general register 0 with the hexadecimal code 00.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP—8068 Rev. 4

16-9

Format:
LABEL

OPERAND

LOPERATIONA

SCRTCH

5 FCB-name
.1

(0)
ALL
PREFIX

(error-addr
[‘(r).

Positional Parameter 1:

FCB-name
Specifies the symbolic address of the FCB in main storage.
Bytes

I __.L_.

__]_

volume serial number

prefix, or expiration date, or file ID
(see table below)

————————— — ——————

Bytes

Contents

0—5

Volume serial number (VSN) of disk pack on which files to be
deallocated reside

6—n

One of the following:
4-byte prefix (may not contain $Y$); requires specification of
PREFIX in positional parameter 2
•

3-byte expiration date, in discontinuous binary in the form
YDD (year, day, day), where Y ranges from 0 to 99 and DD
ranges from 1 to 366; requires specification of ALL in
positional parameter 2

•

44-byte file identification
positional parameter 2

name;

requires

omission

(1)
Indicates that you have preloaded general register 1 with the symbolic address of
the FCB in main storage.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

16-10

Positional Parameter 2:
(0)

ALL

Indicates that you have preloaded register 0 with a hexadecimal function code
specifying the scratch operation desired, as follows:
Function Code

Interpretation

Scratch entire file.

Scratch all files of the volume whose expiration date is
exceeded by the content of the 3-byte expiration-date field of
the FCB.

Scratch all files that have the 4-byte prefix contained in bytes
76—79 of the FCB.

Specifies that all files of the specified volume with expired dates will be
deallocated.

PREFIX
Specifies that all files of the specified volume whose file IDs begin with the 4byte prefix placed in bytes 76—79 of the FCB are to be deallocated.
If positional parameter 2 is omitted, the file specified by the 44-byte file ID in the FCB
is scratched.
Positional Parameter 3:
error-addr
Specifies the symbolic address of your error routine, to which control will be
transferred if an error is encountered.
(r)
Indicates that you have preloaded the specified register with the address of your
error routine. Register 0 and 1 cannot be specified.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

16-11

Examples:

LABEL

LOPERATION1s

OPERAND

IIC.Rr.I..I
I
rC.1—i i1i.itiFII_.iEi..,i’ILiOi)
1
iC.i
I

I
I

This macro deallocates all files whose expiration dates are exceeded by the
contents of the 3-byte expiration date field of the FCB whose symbolic address is
MYFLE. Your error routines’ symbolic address is ERRXT.

This macro scratches the file whose 44-byte file ID is contained in the FCB
whose symbolic address is TRIFLE. You have preloaded general register 10 with
the address of your error routine.

16.4.

DISK SPACE MANAGEMENT AND THE VTOC

We have discussed two disk space management routines that update the VTOC of a disk
pack for you. All together, there are five OS/3 disk space management routines providing
vital services for maintaining a correct VTOC on every disk pack. Two of these transients
(ALLOC and EXTEND) you will not use directly because they are invoked automatically for
you, when you need them, by OS/3 data management or job control; they are therefore
not documented here but in the supervisor user guide, UP-8075 (current version).
Because the disk space management routines provide efficient, completely automatic
space accounting and maintenance they relieve you of the burden of keeping precise track
of the contents of your disk files An understanding of the structure of the VTOC and the
format of its label records is not essential to you as a data management user; however,
Appendix D describes the VTOC in full detail for your information, and the disk space
management macro OBTAIN is available for the rare occasions you will have to examine it
from a program.

16-12

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

OBTAIN

RetrievingVTOC Information (OBTAIN)

16.4.1.
Function:

The disk space management macro OBTAIN returns to you either the disk address or
the contents of a specified VTOC format label record for a specified disk volume. You
must specify a return buffer of a size appropriate for the information you want
retrieved.
Format:
LABEL

A OPERATION

OPERAND

{Paramhist

OBTAIN

}

[{erroraddr

}]

[,vol-seq-noj

Positional Parameter 1

param list
Is the address of a 12-byte parameter list containing the following:
Bytes 0—7

7-byte logical filename (as listed in the LFD Job control statement)

Byte 8

Hexadecimal code of the retrieval function to be performed on the
VTOC of the disk volume whose volume sequence number is
specified by positional parameter 3
Code

Function

Return VOL1 disk address

Return format 1 disk address

Return format 2 disk address

Return format 3 disk address

Return format 4 disk address

Return format 5 disk address

Return format 6 disk address

Return contents of VOL1 label

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Bytes 9—11

16—13

Code

Function

Return contents of format 1 label

Return contents of format 2 label

Return contents of format 3 label

Return contents of format 4 label

Return contents of format 5 label

Return contents of format 6 label

Return contents of the label recàrd that is located at the
disk address that has been preloaded into the first work
of the return buffer

Return buffer address. Specifies the address in main storage of a
return buffer The OBTAIN macro places the disk address or the
contents of the specified format label in the return buffer specified
by this field. All disk addresses returned by the OBTAIN macro are
stored in bytes 0 through 3 of this buffer, in the form 0 ccc hh rr,
in discontinuous binary If you specify function code 87 you must
store the disk address of the format label you want retrieved in the
same location in this buffer, in the same form and format.
The size of your return buffer must be four bytes when you request
the return of an address, 84 bytes when you request the contents
of the VOL1 label, and 140 bytes when you request thecontents of
a disk format label record

(1)
Indicates that you have preloaded register 1 with the address of the parameter
list.
Positional Parameter 2:
error-addr
Symbolic address of your error routine, to which control is transferred when an
error is encountered.
(r)
Indicates that you have preloaded the specified register with the address ofyour
error routine. Registers 0 and 1 may not be specified.

16-14

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Positional Parameter 3:
vol-seq-no
Specifies the volume sequence number of that volume of a multivolume file from
which you want to retrieve VTOC information.
If omitted, a value of 1 is assumed.
Examples:

111111

OPERAND

AOPERATIONA

LABEL

i;i2rI
iCili)iI(iL1
)
1
II

ill

i-I

BI1IIbIl

.1
ii

I
I

iii

You have preloaded register 1 with the address of your parameter list and
register 4 with the address of your error routine you are retrieving information
from the VTOC of the second volume of a multivolume file

This example is seeking information from the VTOC of the first volume of a
multivolume file; the error routine and parameter list are specified by their
symbolic addresses, ERRRTN and RECOVER 1, respectively.

16 4 1 1

Retrieving Specific Format Label Items

Once you have retrieved the desired format label with the OBTAIN macro, you may
address a specific field by its individual label; these labels are shown in Appendix D.

Cl)

-o
m

-I

-o
-o
m

-I

-Q

UP-8068 Rev. 4

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

171

17-1

Paper Tape: Data Management

GENERAL

This section describes OS/3 paper tape data management a system that provides the
basic assembly language (BAL) programmer with access at the logical-record level to the
SPERRY UNIVAC 0920 Paper Tape Subsystem. The operational characteristics of the latter
are outlined in Table A—6; for further information, however, refer to the 0920 paper tape
subsystem programmer reference, U P-7998 (current version).
After a brief discussion of the hardware and paper tape itself, this section describes the
effects of various character and record types on the modes of processing paper tape files
and gives an overview of programming with paper tape data management. Following this
overview, the four file processing imperative functions OPEN, CLOSE, GET, and PUT are
explained, with a description of the means available to you as a BAL programmer in OS/3
for including the paper tape data management processing modules with your own code.
The matter of defining a paper tape file to data management using the keyword
parameters of the DTFPT declarative macro to specify its characteristics and your
requirements for processing it, is then presented in full detail, with a number of simple
coding examples to clarify the use àfshift code scan tables and translation tables. The
discussion of file definition closes with a description of data management error processing
for paper tape files and the use of scan and translation tables when processing paper
tapes in ASCII(American National Standard Code for Information Interchange).
This section concludes witha few notes on the compatibility of OS/3with the paper tape
data management of other operating systems
17.2.

HARDWARE AND PAPER TAPE CONSIDERATIONS

The data management paper tape system in OS/3 is designed to be used with the 0920
paper tape subsystem, which can be configured as a paper tape reader, a paper tape
punch, or a combined reader and punch.
It is important to note that, when the subsystem is being used as a combined reader and
punch; there are two separate paper tape päths:Whereas reading and punching can take
place at the same time in such a subsystem, they cannot take place in one pass on: the
same tape. Two different passes are necessary to read and punch on the same piece of
paper tape, and in OS/3 the tape must be defined with a separate DTF for each such pass:
once as an input file, once for output, using different file names. In addition, you require
separate job control device assignment sets (of DVC-LFD statements).

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

17-2

As a reader, the 0920 paper tape subsystem can handle three different widths of tape:
11/16, 7/8, and 1 inch. The subsystem can punch two widths: 11/16 and 1 inch. As to
the number of tracks, or levels of tape characters, the subsystem can read or punch 5level tape on the 11/16-inch width and from 5 through 8 levels on the 1-inch width.
The subsystem runs in two reading and punching modes: binary and character. In the
binary mode, which is used only with 8-level (1-inch) tapes, there is a fixed, direct
correspondence between bits in main storage and holes punched on the tape, that cannot
be altered by rewiring the program connector board (17.2.1).
In the character mode (also called standard, or nonbinary, mode) from 5- to 7-level tapes
are read and punched; an even or odd parity signal may be punched on the tape and
checked during reading. It is not transferred to main storage, but, if a parity error is
detected (this is always done by the hardware), the most significant bit of the byte in main
storage representing the character is set to 1.
In addition, you may set up the program connector board to allow detection of a stop
character (often called the “wired stop character’ because of the clip-on wires used), as
well as a delete character
17.2.1.

The Program Connector Board

For control, the 0920 paper tape subsystem uses the program connector, a printed circuit
patch card which you set up with clip-on wires for the specific tape you are reading or
punching. You will have much need of the program connector for processing in character
mode, but it is bypassed completely for processing in binary mode A short summary to
highlight the procedure for wiring the program connector follows; for full details, consult
the 0920 paper tape subsystem programmer reference, UP-7998 (current version).
17.2.1.1.

Wiring the Program Connector for the Tape Punch

There are eight punch actuator circuits, each connected to a. pin on the program connector
board In addition there is a pin on the board for each of the seven least significant bits of
a byte in main storage, and two pins that generate odd or even parity signals, based on
the content of all eight bits of the byte in main storage. You connect the actuator pins to
the main storage bit pins by the clip-on wires; any actuator pin can be connected to any
bit pin. You can connect either parity signal pin (the odd or the even) to one of the actuator
pins, or you can ground the unused actuator pins together so that nothing is punched in
their tracks.
-

17.2.1.2.

Wiring the Program Connector for theTape Reader

A pin on the program connector is connected to each of the eight photodiodes in the read
station of the device; there are also pins for each of the seven least significant bits of a
byte in main storage, and two pins connected to reader circuits for checking odd or even
parity.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-3

You connect seven of the photodiode pins to any of the seven bit pins; any of the bit pins
can be grounded so that the associated bit in main storage is always zero. You may also
connect one of the two parity-check circuit pins to any one of the photodiode pins, or the
parity-check pins can be so connected that no parity checking is done.
The reader section of the program connector also allows you to specify one delete
character: and one stOp character for detection by the hardware when it is reading in
character mode; however, in the binary mode, it cannot detect these characters. Therefore,
if you need to delete characters from your input records in binary mode, or if your
application requires additional delete characters, remember that you must specify these as
software deletes in your program, using the- SCAN keyword parameter -of the DTFPT
declarative macro (17 5 3 1)
17.2.2.

Paper Tape Leader

If the optional tape spooler is. used with the 0920 paper tape subsystem, a tape leader at
least three feet long: must precede the first datacharacter to beread on the tape. In the
binary mode the leader must consist only of null characters; in the character mode, you
may use either null or delete characters If the reader spooler is not used, the paper tape
leader may be as short as two inches
17.2.3.

Paper Tape Trailer

When you are using the 0920 paper tape subsystem, you receive an indication of broken
tape if there are data characters under the read photodiodes when the end-of-tape switch
is activated. A false indication of broken tape, therefore, results when the end of an
unbroken tape goes by while the last of the data characters are still being read. To prevent
this false error indication from being given, you must follow the last data character on an
input tape with atape trailer at least12 inches (120: characters) long; there must be
nondata characters. In the binary mode, the trailer must consist only of null characters; in
the character mode, you may use- null or delete characters.
Figure 17—i is a schematic-diagram of a paper tape file with its leader and trailer.

—I

II’j

LEGEND:
L

Tape leader Immediately precedes the first data character on paper tape and comprises only null characters in binary
mode may comprise null or delete characters in character (standard) mode Must be at least three feet (360
characters) long if the optional tape spooler is used on 0920 paper tape subsystem; otherwise needs to be no more
than two inches (20 characters) long.

Tape trailer. Immediately follows the last data character on paper tape; must be at least 12 inches (120 characters)
long to prevent false error indication of broken tape. Comprises only null characters in binary mode; may comprise null
or delete characters in character mode.

Data file. In character mode, the format of data records may be either fixed, unblocked or undefined (that is, records
are of various lengths). The only record format used in binary is fixed, unblocked.
Figure 17—1.

Tape Leader, Paper Tape Data File, and Tape Trailer

17.3.

17-4

SPERRY UNIVAC OS/3
BASIC:DATA MANAGEMENT

UP-8068 Rev. 4

CHARACTER AND RECORDTYPES ONPAPER TAPE

Before looking into the way your data is organized on punched paper tape and appears to
data management and to your program, consider the uses of several character types
already mentioned, but not explainted so far: the null character, the delete character, and
the end-ofrecord stop. These are part of a class of characters selected byconvention or
arbitarily from among all the possible patterns that may be punched in one character’s
space on tape, different from the rest only in that they. are not used to represent data.
They are sometimes called control characters, but, on the other hand, they may represent
the absence of data or serve as information separators or delimiters to format your data
They may serve merely to fill space on tape as a tape leader as trailer. One of them may
be used to obliterate unwanted or erroneous data characters or other nondata characters.
Characters from this class may indeed be used to control communications or devices
(here, for example, the 0920 paper tape subsystem itself), and the term control characters
is then appropriate.
An important realization is thateach tape code you must assign to one of these characters
reduces by one the subset of possibilities you may use to represent your data. When you
are processing in character, or standard, mode, however, this limitation is not as serious
as it may seem: data management’s letter/figure shifting capability allows you to
represent more than one set of charcters in the same set of hole patterns punched on
tape.
17.3.1.
•

Null, Delete, and Stop Characters

Null Character.
The null character is represented on tape by the absence of any punches in the
information levels (tracks); only the feed (or’sprocket) hole is punched To punch the
a standard
tape code for the ‘null character, you place the hexadecimal ‘value 00
in your I/O area: You may use
convention in both ASCII and.EBCDIC processing
and trallerwhen yo’u are
leader
tape
paper
the
in
the null character (or the delete)
only the null for these
use
must
you
),
but
processing in character mode (MODESTD
use only the null
must
rly
you.
purposes’ in binary’ mode (17.2.2,. 17:2.3). Simila
character to represent the optional interrecord gap in binary processing, although the
delete character ma.y be. used.. instead, in character mode (17.3.4).
—

—

...

When you start to read paper tape the subsystem feeds tape until it comes to the
first character that is not a null (or a delete) it then beginning with this character
starts to transfer characters’ into main storage. For this reason,’you must never use
the null as the first cha.racter of,the first record on a tape; if you do, all ..subsequent
record lengths are off by one byte. In binary mode, once the transfer of data has
begun, all subsequent null characters are read into main storage, as binary 0’s
(hexadecimal 00), and, whatever these represent in your input file, you must program
to deal with them In character mode, on the other hand (MODE=STD) nulls are
never transferred into, main storage.
‘

.‘,

UP-8068 Rev. 4

SPERRYUNIVAC OS/3
BASIC DATA MANAGEMENT

1 7-5

Delete Characters
You may represent a delete character on tape by any of the hole patterns available for
you topunch, althoughthe standard ASCII deIetechãcter isäpunch in each of the
seven data tracks (17 5 10) The practice of punching a hole in each track or data
level to represent a delete character facilitates one of the main uses of the character
to cancel or obliterate unwanted data in a record There are however two types of
these the hardware delete and the software delete
In character mode only (MODE=STD), by wiring the program connectorboard, you
cancause thea hardware itself to recognize one of the incohiing tape ôodes as a
character to be deleted, which itdoes not transfer to main stbrage.ltskiis this
character, without leaving aspaàe in its place; and goes on to read in the next data
character This is called thE wired” or “hardware” delete; buts uch a character
cannot be used in binary mode
To prevent a character you want treated as a delete from being read into main
storage in binary mode, you niust so designate it inã söan table that you specify to
data management via the SCAN keyword parameter of the DTFPT declarative macro
that defines the file (17.5.31). You may specify more than one delete character this
way
these arecalled “softWar&’ deletes, because the data management software
takescare of them
in both binary and character modes.
—

—

A major use of the delete character, as suggested is to obliterate unwanted
characters from your paper tape file when these are identified in later processing,
once the file is created However (with one exception) you must take pains never to
include the delete character in your output data when you are creating a paper tape
file; it is punched into the tape by other means. Because of this use in cancelling out
any tape code, the delete is often called a “n.ib-oUt” charCctér.
The exception to the general rule of always excluding the delete character from
appearance among the data characters in your output is its use as the record gap
character when you are punching a tape (17.3.4).
The other uses of the delete, to constitute the paper tape leader and trailer, or the
interrecord gap (the record gap character) in standard mode have already been
referred to. In these uses, it is important to rernOmbér that the delete character must
be the hardware delete, to be wired for input files via the program connector board,
and not one of the software deletes designated in a SCAN table You may place the
hexadecimal code for the hardware delete in your I/O area as many times as you
want it punched in the, header or trailer, or you may form these. file-delimiting
character strings by splicing already punched strips of tape onto the ends of the file
after it is punched without them.

•

17-6

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Stop Character
Undefined records, used, only when you are, processing .,,in character mode
(MODESTD), require some means of delimitation as: they vary in length. For this,
you use an: end-of-record stop character at the low-order end of the record; it is
placed there automatically by data management when. you are punching an output
file. It is read into your ItO area. from an. input file, and marks the farthest point into
your I/O area you should attempt to reach in processing your data You specify to
data management what it is to use for this character on an output file by means of
the EORCHAR keyword parameter of the DTFPT declarative macro defining the file
(17.5.6); for an input file, you must specify the end-of-record stop to the 0920 paper
tape subsystem itself by wiring the program connector board (17.2.1.2). When the
subsystem encounters this character on reading an undefined record in character
mode, it automatically stops tape motion. Remember that in binary mode the
subsystem cannot be wired to recognize a stop character. The end-of-record stop
character may not be used in OS/3 as the record gap character.
The use of an end-of-record stop character affects the length of your I/O buffers and
work areas in character mode (MODE=STD); these effects are discussed in detail in
1751.3, 17.5.1.4, and 17.5.1.6. Figure 17—2 shows therelationship of record length
to the block size specification for an undefined record of the maximum size in a file.
Note the position of the stop character in some of the subsequent figures, also.
UNDEFINE.D RECORD (USED IN CHARACTER (STANDARD) MODE ONLY)
E

a
R

LEGEND:
E

End-of-record character, a ‘wired stop” character placed by data management as a delimiter at the end of each
undefined (variable-length) record. Specified by theEORCHAR keyword of a DTFPT declarative macro defining an
output paper tape file set for input files with clip on wires in the reader section of the program connector

Length of data record, which may not exceed 4094 bytes. For output files, you load this length into the register
specified with the RECSIZE keyword of the DTFPT macro. For input files, data management loads the RECSIZE register
with the length of each record it reads in.
Assuming thatD is the length of the longest data record inthe paper tapefile, then I as depicted here’ equals the
BLKSIZE specification, which may not exceed 4095 bytes. The BLKSIZE specification is the size of the largest logical
record to be processed and always includes 1 byte for the EORCHAR stop character that follows the data in an
undefined record.

Figure 17—2.

17.3.2.

Undefined Paper Tape Record of Maximum Size for the File:
Relationship of Record Length to BLKSIZE Specification

Letter and Figure Shift Characters

Only when you are processing in character mode (MODE=STD) may you use the
letter/figure shifting capability that data management offers to permit you to represent
more characters than you have unique hole patterns available in the number of data levels
or tracks in your tape.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-7

Setting aside a few of the hole patterns for the null character, one or more deletes, and (if
you have undefined records in your file), the end-of-record stop, you can nearly double the
number of characters that the remaining hole patterns represent if you select two more to
be shift codes and then assign two meanings to each of the patterns that this leaves you
one meaning when it follows the one shift code on tape one when it follows the other
The conventions in 05/3 data management are that one of these shift codes is the letter
shift character, all hole patterns following it on tape being translated as “letters”, and that
the other is the figure shift character, all tape codes that follow it being translated as
“figures” Another convention is that, on opening an input file, data management expects
that the first record of the file begins with a “figure” unless the first charaôter of the
record is the letter shift code. Data management inserts all shift codes automatically as it
punches your output records into paper tape files, and it deletes them automatically,
translating the intervening data as required, as it reads input records from tape.
To represent the letter shift and the figure shift codes, you may select any of the codes
that you can punch into the tape at your disposal
except for the null, deletes, and endof-record stop. Figure 17—3 shows the appearance of an undefined output record,
comprising both “figures” and “letters”, as it woUld appear in the I/O area after you had
formed it there for punching by data management, and as the record would look after it
was punched as the first record on tape. Notice that the letter shift code has been added
automatically by data management as the first character of the punched record
—

UNDEFINED OUTPUT RECORD, LESS THAN MAXIMUM SIZE FOR FILE, AS IT APPEARS IN i/O AREA
BLKS1ZE specification
Record size

Data moved by user to output area when he is
forming records to be punched on tape
LEGEND:
“Letters”: 8-bit configurations user has designated to be translated by the content of his LSCAN and TRANS tables
“Figures”: 8-bit patterns user has designated to be translated by the content of his FSCAN and TRANS tables

End of record stop character placed in I/O area by data management specified by EORCHAR keyword

Residual data in I/O area, not processed
Figure 1 7—3. Undefined Output Record for Standard Mode Paper File in I/O Area
and as Punched on Tape (Part 1 of 2)

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT.

UP-8068 Rev. 4

17-8

AND AS IT APPEARS PUNCHED AS THE FIRST RECORD ON A PAPER TAPE FiLE

LEGEND:
L
S
C

Letter shift code (LSC) punched by data management the OS/3 convention is that the first character in the first
record on tape is either a “figure” or the letter shift code

Tape codes to be translated on input as representing

letters

because they follow LSC and precede FSC

Tape codes to be translated on input as representing “figures”, because they follow FSC and precede LSC

S
C

Figure shift code (FSC), never the first character of the first record on tape

E
Q
4

End of record delimiter a character specified by the EORCHAR keyword of the DTFPT macro On input when this
character is encountered tape motion stops The 0920 paper tape subsystem can be wired to recognize this character
only in standard mode

Paper tape leader
Figure 1 7--3. Undefined Output Record for Standard Mode Paper File in I/O Area
and as Punched on Tape (Part 2 of 2)

FIgure 1 7—4 shows the relations of an undefined Input record s length and contents to
the I/O and work areas (and to the specified block size) notice that the bytes in the data
area beyond the end-of-record stop character aie not zeroed or otherwise processed by
data management you should avoid running into them in your processing
The means for designating the shift codes, for designating which characters are “figures”
and which “letters”, and for translating these are described in full elsewhere (17.5.3,
17.5.3.1, and 17.5.5, for example) under the DTFPT macro keyword parameters used for
the purpose. See also Figure 17—10, in 17.5.1.5.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

(for largest undefined
record, including
1 byte for EORCHAR)

BLKSIZE specification
(as read into I/O area originally)

[.4
IOAREA 1

I! I

letters

/ / 1
/
,,
I /
1/

, ,
1 I

I
I

/ / //

l/O0rWORK

lette:

figures

II II /,///

‘

1 79

Ii
‘

1/
//
1/
//
1/

/i
ii’

‘

I,’

figures

letters

// //
,‘

Bytes beyond
the EORCHAR (stop)
/ /
character are not
/ /
zeroed or otherwise
processed by data management.
/

/
/

letters

(As made available to user after GET instruction in I/O area or work area,) with shift and delete characters removed and data translated

Recordiength loaded into RECSIZE
register excludes
the EORCHAR (stop character)
that delimits each undefined record
on tape and in I/O and work area.

LEGEND:

EORCHAR (stop character)

Lettershift character

Figure shift character

Bytes beyond the EORCHAR (stop) character. These are not zeroed or otherwise processed by data management and
should not be accessed by the user.

Figure 1 7—4.

Relationships of Record Length, Work Area Length, and i/O Area Length to BLKSIZE Specification
and Content of RECSIZE Register for an undefined Record Input from Paper Tape with Shifted CodeE

UP-8068 Rev. 4

17.3.3

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

17-10

Record Formats in Paper Tape Files

In defining OS/3 paper tape files, one of two record formats may be specified, depending
on processing mode. When you are processing in binary mode, the only format you may
specify is the fixed, unblocked format, but when you are processing in character mode
(MODE=STD) you may specify either this or the undefined record format You use the
RECFORM keyword of the DTFPT declarative macro discussed in detail in 17 5 1 2 for
specifying the format of records in your file The two processing modes are described in
fully in 17.5.2.
The reason that the undefined format may not be specified in binary mode is that there is
no way the paper tape subsystem, when operating in binary, can be made to recognize the
end-of-record stop character that delimits the undefined record (17.3.1), yet this
recognition is essential for input processing.
The fixed unblocked record may vary in length from 1 to 4095 bytes If you are used to
processing records that are considerably smaller than 4095 bytes in your applications you
may wonder whether it is possible to block them in OS/3 Paper tape data management
does not offer facilities for blocking and unblocking records, and this is the reason you
may not specify a blocked format in your DTF; however, because a record is simply what
you tell data management it is, your file may indeed consist of blocked records. The only
point is that your program must deal with the blocking and deblocking that is necessary,
without the assist that data management offers in the magnetic tape and some of the disk
access methods.
In character processing mode (MODE=STD), fixed, unblocked records may contain shifted
characters and shift codes (they may not in binary mode), and when they do, moreover,
you should note that they will seldom be all of one size when punched on paper tape.
Figure 17—5, contained in a following paragraph (17.3.4), illustrates this point. Although
fixed, unblocked records may not be shifted in binary mode, they may be translated.
The undefined record is simply one that may be of any length up through 4094 bytes; its
maximum length is one byte less than the limit for the fixed-length record because of the
need for the end-of-record stop character just described (17.3.1). The actual length of
individual undefined records may vary from record to record; it is marked by the delimiting
stop character and referred to in the general register designated for record size (17.5.1.6).
It, too, may actually contain blocked records, but thereis no way to specify this fact todata
management, which has no facilities for blocking or deblocking. You must do this yourself.
Figures 17—5, 17—6, and 17—7, presented in the following paragraph, show the
appearance of records of each format.. on tape and in the data area. These records are
followed by an interrecord gap.
17.3.4.

Interrecord Gaps in paper Tape Files

Data management does not provide automatic facilities for punching a string of nondata
characters (null or delete characters, for example) after each output record to serve as an
interrecord gap. Yet a gap so constituted, especially if it contained a fixed number of these
characters, might facilitate error recovery and would serve to distinguish records on tape.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-11

If you want to create an interrecord gap for these reasons, you need only to place the
number of null or delete characters that you have decided to use at the end of each record
in the output of work area. There are a few considerations to keep in mind, however;
these affect both your block size specification and (for undefined records only) the value
placed in the general register used to refer to logical record length.
With output files in both binary and standard modes, a byte for every character to be
punched at the end of a record as part of an interrecord gap must be included in your
calculation of block size, which you specify with the BLKSIZE keyword parameter of the
DTFPT declarative macro (17.5.1.3). Furthermore, if your records are undefined, your block
size must still allow one byte more for the end-of-record stop character, which data
management inserts in the I/O buffer as a delimiter after the last record gap character
you place there. Therefore, the overall length of data-record-plus record-gap that youform
must be at least one byte shy of your BLKSIZE specification. You also count the bytes for
the record gap characters at the end of undefined records in the record length that you
load into the general register that you must use to refer to record size (the RECSIZE
register, 17.5.1.6). Refer to Figure 17—5.

..•.

data

[
•

data

IRG

Output File

Block size specification

I—

Undefined record, of maximum size for its file
(standard mode only).

P-I

IRG

Undefined record, of less than maximum size for
its file (standard mode only).

-P-I
Fixed, unblocked
mode.

data

record,

either

processing

IRG

I/O area contents
LEGEND:

End-of-record stop character, punched by data management

Bytes in I/O area beyond end-of-record stop, not processed by data management nor to be accessed by user

IRG

Length of interrecord gap, characters supplied by user

Figure 17—5.

Undefined and Fixed, Unblocked Records Followed by Interrecord Gaps
in Output Paper Tape File, Either Processing Mode

17-12

SPERRY UNIVAC OS/3
BASIC DATAMANAGEMENT

UP-8068 Rev. 4

With inputfilespräcessed in character rnode(MODE=STD),nUlls or deletes at the end of
each record are not included in your BLKSIZE specification because they are not
transferred ihtó mäihstorage. For the s me reason; data management does not inClude
the bytes for The record gap characters :in the record length it lOads for undefined records
into the RECSIZE register. A standard rnodë output file containing interreCord gaps would
therefore require a smaller BLKSIZE specification when it is read in than it needed when
punched Refer to Figure 17—6
Block size when created
1RG

‘

Input Files
E

data

Undefined record, of maximum size for its file, as
punched on tape with the interrecord gap

Content of I/O area when the same undefined
record is read in in character mode
(MODE=STD)

Fixed, unblocked record as punched on tape
with interrecord gap

Block size on input

Content of I/O area when the same fixed,
unblocked record is read in in character mode
(MODE=STD)

data

LEGEND:

End-of-record stop character, punched by data management
A.
IRG

Length of intérrecord gap, characters supplied by user when files were created, Punched ontapé, but not transferred to main
storage on input in character mode (MOf E= STD)

Figure 17—6.

Undefined and Fixed, Unblocked Records Followed by Interrecord Gaps
in Input Paper Tape Files, Standard Processing Mode

UP-8068 Rev; 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-13

For input files processed in binary mode, on the other hand, the situation is different.
Because the record gap characters are transferred into main storage (as nulls,
hexadecimal 00) at the end of each record, you must include the fixed number of bytes for
calculating block size, as well as programming appropriately to account for their presence.
A binary mode file containing interrecord gaps would have the same BLKSIZE specification
for input processing as it had when punched. Refer to Figure 17—7.
Block size when created
Input File

data

••.••••

r
data

Fixed, unblocked record as punched on tape in
binary mode with interrecord gap

IRG

•..•.•

Same record in I/O area when read in in binary
mode

ie block size on input

LEGEND:
IRG

Length of interrecord gap. Characters supplied by user when file was created. In binary mode, these characters are
read into main storage as input and must be included in BLKSIZE specification and in reserving main storage for I/O
area.

Figure 17—7. Fixed, Unblocked Record Followed by Interrecord Gap in Input Paper Tape File, Binary Processing Mode

It might occur to you that, when you are processing output files in character mode
(MODE=STD), you could punch a string of end-of-record stop characters, instead of nulls
or deletes, as an interrecord gap between undefined records. Although you could punch a
series of these characters, when your file is read in, the device would stop tape motion at
each of the end-of-record characters, and could not be made to skip over them. Other
paper tape systems you are familiar with may allow consecutive end-of-record characters,
without intervening data, to be punched in output tapes and skipped over on input
OS/3 does not provide the facility to skip these on input.
—

Figures 17—8 and 17—9 depict shifted undefined records and shifted fixed, unblocked
records as they exist on tape and appear in your work area when processed in character
mode (MODESTD).

17-14

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

IRG

j
1
i

figures

letters

figures

•

• •

—

•

letters

figures

record 2

record 1

Shifted, undefined records, each followed by a user-supplied interrecord gap as they appear on tape

BLKSIZE specification and length of work ares

‘4

figures

L 11
letters

figures

0
R

record 1

The first undefined record as made available to user in work area by GET macro.
LEGEND:
Bytes in work area beyond end-of-record stop character, not to be accessed by user

Figure shift character inserted and deleted by data management. Precedes each string of figures except those
beginning first record or tape

Letter shift character inserted and deleted by data management. Precedes each string of letters in every record on
tape

0
P1
IRG

End-of-record stop character, delimiter for each undefined record. Specified for input file by wiring program
connectors board

Interrecord gap, characters supplied by user. Not transferred to main storage in character mode (MODE=STD).

NOTE:
The record length placed by data management in the RECSIZE register does not include the end-of-record stop character
even though this character is read into I/O area and is moved with the record into the work area.
Figure 17—8.

Shifted, Undefined Records as They Appear on Paper Tape and in User Work Area:
Input File, Character Mode (MODE=STD)

—

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

IRG

frgs

letters

all letters

Record 1

figures

RGj

Ifigures

17—15

letters

Record 2

letter,

figs

all letters

Record 3

letters

and dze&ecch wo arco-sm&r than output
blocksize by the fixed number of record gap
characters punched between records

LEGEND:

Letter shift code, inserted and deleted by data management

Figure shift code, inserted and deleted by data management

IRG

Interrecord gap, a fixed number of characters supplied by user on output but not transferred on input in character
mode

NOTES:
1.

Record 1, including its interrecord gap, is two bytes larger than specified by the BLKSIZE keyword at output because of
the shift codes required after the first and second fields and inserted there by data management.

Record 2, likewise, is one byte larger than the output BLKSIZE specification (which must include the fixed number of
record gap characters you supply for each record), because of the letter shift code required. This record begins with a
letter, and the preceding record ended in a figure.

Record 3 is exactly the length specified by the BLKSIZE keyword at output. No shift code is required: the record
contains only letters, and the preceding record ended with a letter.
Figure 17—9.

17.4.

Shifted, Fixed, Unblocked Records on Paper Tape and in Work Areas:
Input File, Character Mode (MODE=STD)

PROCESSING PAPER TAPE FILES

The procedures in processing paper tape files are simply summarized. Before creating your
program, you obviously will know what form of tape you are going to read or punch,
whether it is to be in binary or character mode, whether it is to be translated into or from
the standard EBCDIC, and whether it is to contain shifted characters or rely on only one,
unique use of the codes available to you. Once these points have been determined by the
nature of your application, you will take the following steps to use the paper tape data
management system:
a

You define each of your paper tape files, using the keyword parameters of the DTFPT
declarative macro to specify your requirements.

Before reading or punching any data from or to any paper tape file, you issue an
OPEN imperative macro to initialize the file.

SPERRYrUNIVAC O$V3.:
BA5ICDATA MANAGEMENT

UP-8068 Rev..4

17-16.
.

At this point in your program, you may issue the GET imperative macro to read data
from the file, or the PUT macro to punch data into the tape. Note that you cannot
issue both macros to the same file in any one pass.

•

After all dâtá hai bóeiV Punched óriti a tipe, dr reid from. it, you isiUe I •O••SE
imperaiive macio to terminate yeiI jirôóOssing of it.
.

At program execution time, you must do the following:
•

Provide proper device assignement arid logical file definition for each file, through job
control DVC and LFD statementS.

•

Ensure that the program connector in the 0920 paper tape subsystem is properly set
up.

•

Ensure that the proper paper tape is mounted and that the device is online.

The following paragraphs describe the four imperative macros you may issue to a paper
tape file: OPEN, CLOSE, GET, and PUt
.

•.

•

C:
c.t.1

.c’n

‘

.‘

i
•

i•,

‘‘

7?.:

:‘;

..;f’1”:kt,

1.t

.•.

r;:;

UP-8068 Rev. 4

SPERRY UNIVAC OS/3

17-17

BASIC DATA MANAGEMENT

OPEN

17.4.1.

Initializing a Paper Tape File (OPEN)

Before issuing any of the other imperative macros to it, you must issue an OPEN
Imperative macro to the paper tape file to be processed The transients and overlays called
as a result link your file to the device you have assigned through job control and perform
otherfile initialization procedures.
For an input file, for example, that contains letter/figure shift äodes, the OPEN prOcessing
initializes the file so that the first record on tape is read in the figures mode. If the first
record on a paper tape actually begins with letters, therefore, a letter shift code must be
the first character punched on tape, or the record will be misread. This code is inserted
automatically for tapes punched by OS/3
Format
iOPE RATION

LABEL

[symbol]

OPERAND

OPEN

filename-i [,...,filename-n]
{1

IL
Positional Parameter 1
filename
Is the label in your program of the DTFPT declarative macro defining thepaper
tape file to be initialized You may initialize as many as 16 data management
files with one OPEN macro call they need not all be paper tape files
(1) or 1
Indicates that you have preloaded general register 1 with the address of the
DTFPT declarative macro You use this form only when you have a single file to
initialize.
Examples:
LABEL

LOPERATiONL

2
1
DMP1I ,DP1

I
1111111
_I

—

liii

—

I
—

OPERAND

—

I
(1)

Opens paper tape files DMPT1 and DMPT2

Opens the paper tape file DMPT7

1/-i

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

17.4.2. Terminating Paper Tape File Processing (CLOSE)
When you have completed processing your paper tape file, you must issue the CLOSE
imperative macro before taking any action to terminate the job (such as issuing supervisor
macros EOJ, CANCEL, DUMP, etc). Transients called by the CLOSE macro ascertain
whether all I/O operations have been completed, process errors on the final I/O
operations, and so forth. If you require further processing on the paper tape file, you must
reopen it. with the OPEN macro.
Format
tOPERATIONE

LABEL

[symbol]

OPERAND

filename-i [,...,filename-n]
(1)
1
*ALL

Positional Parameter 1:
filename
Is the label in your program of the DTFPT declarative macro defining the paper
tape file whose processing is to be terminated. You may close as many as 1 6
data management files with one CLOSE macro call; they need not all be paper
tape files.
(1) or 1
Indicates that you have preloaded general register 1 with the address of the
DTFPT declarative macro. YoU use this form only when you have a single file to
terminate.
*ALL
Specifies that all files currently open in the job step are to be closed.

17-19

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Examples:
LABEL

txOPERATIONz

M
P
1
l1 ,MP12

i
I

iili

a
I

OPERAND

—

i_ill

L,
A
1

ii_

—

III

—

I 121
1
X
I

I
I

Closes the files labeled DMPT1 and DMPT2

Closes the file labeled EX1

I
I

17-20

SPERRY UNIVAC 05/3
BASiC DATA MANAGEMENT

UP-8068 Rev. 4

GET

17 4 3

Reading a Logical Record from Paper Tape (GET)

You issue the GET imperative macro to an input file to make a logical record available to
you either in a work area or in an I/O area. In executing a GET macro, before data
management makes an input record available to you in an I/O area or moves it from there
to your work area, it has removed all shift or delete characters from the record and has
translated all data that requires translation.
If you want to use a work area for processing input records, you must specify the WORKA
keyword parameter in the DTFPT declarative macro defining the file and must also specify
the address of the work area with each issue of the GET macro. If you do not specify the
WORKA keyword, you must access each record in an I/O area. And, if you have specified
two I/O areas but no work area, you must use an I/O register to access the record
(17.5.1.4).
When your record is an undefined record (RECFORM=UNDEF), the end-of-record character
appears in the data area at the end of the record; furthermore, any unused bytes in the
area beyond this stop character are not zeroed or otherwise processed by data
management (refer back to Figures 17—3 and 17—4, for example). If you wish, you may
specify a record size register when you are reading undefined records. Data management
then loads this register with the length of the record, as it appears in the data area minus
shift and delete characters; this length does not include the end-of-record stop character.
Format:
LABEL

[symbol]

OPERAND

LOPERATIONZ2

GET

filename
{(i)

}[

workarea

{(o)

Positional Parameter 1:
filename
Is the label in your program of the DTFPT declarative macro defining the input
paper tape file from which you are reading a record.
(1) or 1
Indicates that you have preloaded register 1 with the address of the DTFPT file
table.
Positional Parameter 2:
workarea
Is the symbolic address (label) of your work area. You may change this label from
one GET macro to another.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATAMANAGEMENT

17—21

(0) or 0
Indicates that you have preloaded register 0 with the address of a work area.
Examples:
LABEL

tOPERATIONt

OPERAND

—
—

OIOI°II
—

—

P_I2, i( I
I

I-

DIMP
3
1
,”O)

Read a record from paper tape file labeled DMPT1 and leave the record in an I/O
area.

Read a record from paper tape file labeled DMPT2 and move the record to the
work area labeled WK1.

Read a record from paper tape file labeled DMPT3 and move the record to the
work area labeled WK5

1 1-22

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

PUT

17.4.4.

Punching a Logical Record into Paper Tape (PUT)

Having provided the data for an output record in an I/O area or work area, you issue the
PUT Imperative macro to punch it as a logical record into paper tape If you are using a
work area you must specify the WORKA keyword in the DTFPT declarative macro that
defines your output file, and you must specify the address of a work area with each PUT
macro you issue. The work area may differ from macro to macro.
Data management moves the output record from the work area to the output area and
before punching the record on tape; inserts letter and figure shift characters and
translates data as necessary. If this is the first record on the tape, and if it begins with a
letter, data management automatióally punches the letter shift character as the first
character of the record. If the record format is undefined, data management punches the
end-of-record stop character at the end of each record. You will have specified the shift
characters with the LSCAN and FSCAN keywords and the end-of-record character with
the EORCHAR keyword, when you defined the file with the DTFPF declarative macro.
To punch out undefined records you must also have specified a record size register using
the RECSIZE keyword in the DTF, and, determining the length of each record, you must
load this length into the register before you issue each PUT macro. The number you load
into the RECSIZE register is the number of bytes ofdata in the record; it does not include
bytes for the end-of-record stop character nor for the shift characters, which data
management inserts.
Format:
LABEL

[symbol]

OPERAND

LOPERATiON

PUT

filename
(1)

workarea

U
Positional Parameter 1:

filename
Is the label in your program of the DTFPT declarative macro that defines the
output paper tape file.
(1) or 1
Indicates that you have preloaded register 1 with the address of the DTFPT file
table.
Positional Parameter 2:
workarea
Is the label in your program of the work area from which you want the output
record moved.

17-23

SPERRY UNIVAC OS/3

UP-8068 Rev. 4

BASIC DATA MANAGEMENT

(0) or 0
Indicates that you have preloaded register 0 with the address of the work area
from which you want the record moved.
Examples:
IsOPERATiONLk

LABEL
1

1. 1
?5cO
E
2.

OPERAND

—

DI1 I8 WK, A
i

i
I

Punch a record which the user has placed in an I/O area, into the paper tape file
whose label is EX7.

Move the record that the user has placed in the work area labeled WKA to an
I/O area and punch it into the paper tape file whose label is DMPT8

Same as 2.

UP-8068 Rev; 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 7-24

DTFPT

17.5.

DEFINING PAPER TAPE FILES (DTFPT)

You define your paper tape files to data management by issuing a DTFPT declarative
macro for each file you will process in your BAL program using its keyword parameters to
describe the file The DTFPT macro does not generate executable code (and therefore
should not be issued in the midst of executable instructions or imperative macros) it does
generate a file table to contain data about the file and the results of processing.
When your program is assembled the assembler expands your DTFPT declarative macro
into a 215-byte file table, which it uses in a number of ways to control file processing and
to record certain results.
As you execute each imperative macro to process your file, for example, data management
places an informative reply, indicating normal completion of I/O or exäeptional conditions
(including unrecoverable error) in a program-addressable field of the DTF file table called
filenameC Your use of this field is explained under the ERROR keyword parameter
(17.5.9), as isthe use of another field, filenameD, to access a record containing a parity
error.
Following is a format delination of the DTFPT declarative macro, showing the required and
optional keyword parameters you will use to define your file and to indicate to data
management some of your file processing requirements. Notice that the keywords are
listed here in alphabetic order; however, you may issue them in any convenient order,
separating them with commas.

1 725

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Format:
LABEL

OPERATIONt

filename

DTFPT

OPERAND

BLKSIZE=n
[EOFADDR=symbol]
[,EORCHAR=expression]
[,ERROR=symbol]
[,FSCAN=symbolj
[,FTRANS=symboIJ
,lOAREAlsymbol
[,IOAREA2=symbol]
[,IOREG=(r)]
[LSCANsymbol]
[,LTRANS=symbol]
BlNARY
[MODE

[

[,OVBLKSZ=n]
[,OPTION=YES]
EREC FORM={JN’

[,RECSIZE=(r)]
[,SAVAR EAsymbol]
[,SCAN=symbol]
[,TRANS=symbol]

TYPE FLE={a
OUTPUT
[,WORKA=YES]

A comma is shown preceding every keyword but the first, to remind you that all keywords
coded in a string must be separated by commas. However, a comma must not be coded in
column 16 of a continuation line, nor follow the last of the string. Refer to the preface of
this manual for OS/3 format statement conventions and to 1 .6.3 for rules on continuation.
The symbolic label of the DTFPT declarative macro (filename), required for all DTFPT files,
is the logical name bywhich you address the file in your BAL program, it may contain no
more than seven alphanumeric characters, the first of’ which must be alphabetic.
Restricting filename to seven characters allows data management to generate symbols,
such as filenameC, which you may reference in each DTF file table by concatenating a
letter to the file name. You specify this file name to the imperative macroinstructions you
issue to process your file, and it is this name also that you use in the job control logical
file definition (LFD) statement with which you allocate the file,

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

17-26

Notice that there are two keyword parameters (BLKSIZE and IOAREA1) that you must
always specify in every DTFPT macro. Others are required under certain circumstances,
and some are entirely up to you
Notice also that the completion of many of the keyword parameters is symbol,
representing the fact that with symbol you specify the symbolic address of the subroutine,
translation table, scan table, or I/O buffer the keyword stands for. In expanding your
DTFPT declarative macro, the assembler generates an EXTRN pseudo-op for each symbolic
label the macro contains; this means that the corresponding subroutine or table need not
be assembled with the DTFPT macro, but, when it is more convenient or advantageous for
you to do so, may be assembled separately.
These are the keywords in point:

Keyword

Subsection

EOFADDR

17.5.4

ERROR

17.5.9

FSCAN

17.5.5

FTRANS

17.5.3

IOAREA1

17.5.1.4

IOAREA2

17514

LSCAN

1753

LTRANS

17.5.3

SAVARE

17.5.8

SCAN

17.5.3

TRANS

17.5.3.1

Table 17—1, followingthe DTFPT format delineation, summarizes the rules for specifying
the keywords. The keywords are discussed, in fuildetail, in the subsequent paragraphs.
Information on acceptable variations of some of:the keywords is given in 17.6, which
discusses the compatibility of OS/3 with certain other data management systems for
paper tape.

SPERRY. UNIVAC osa
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table 17—1.

17-27

Summary of DTFPT Keyword Parameters (Part 1 of 2)
lb. With
Fit. Typt

K.y.td

INPUT

SLi(SIZE

U.. With
Pttt.wttq
IWid.

EXTRN

OUTPUT

RINARY
—

STO

—

Lb.
Withk.t
Wtitt.d
C.d.t

lb. With
Shifttd
c.d.t

P.t.ph

Sp.tifV
With

0.ttils

13.5.1.3

—

Iy hytet, .1 I15,tt IV9VVl .c.d; ,t it . dyijyci
,Vytdl .,itthl -.tgy I thc.gh 4095
EOFADDR

tyicbcl

Sptyitiys tb.I .1
c.d.it.t.p. pVyyitg
,c.titt;
d Ic’ .11 itpt Ide..

EORCHAR

y.p’ytt ic

Reqiittd f, c.tpiit Iil.t iith uyd,fiytd ,yycdl;
tptifiet
ttop .5,
dtliy,ityll

Sptiifiyt ,bel of ase’t
.ptfied,

Vys

Reqifrtd. With LSCAN kayotd, to aWaitS ab&
af a.e’t figata ta.y tbIt tot piatahiag file. ai1h
thOt,d aadet

Ytt

V q
LTRANS
4 .
OSCAN
p
I,btl at at,t’. Ii 9l1tt,VtI.t lOt t,ble fa
PlOatttitgtthi ttedia pat lii,

Ypt

•

—

13,5.4

—

RECFORM
FIXUNB,

13.5,6

—

MODEBINARY

13,5.5

TRANS

1353

MODE=BINARV
ERROR

tyttbyl

FSCAN

tytabal

FTRANS

tab I

IOAREA1

t1ia tc.tiae.

If act

MOOEBINARV

Nyibal

Reqaiyd fa all iiltt; tp.aifia 1.5.1 at phtacy
I/O ball,,

Yat

tyaaI

sp..t.t i,btl at aptioV& s,aaadcy I/O ball,,.
R.qai,yt tpt,ifi.tiaa at IOREG if aa,k .,ta
p,a.t ttiy4itaattptaili4 IWORKA k,yiaa,dl

Y.t

(‘I

Sptaifd.,ia.adata,yp.,,atfl,tta,ihtaatyb,,
at 15, WaCN1 ttti ttt1 a bt ated ts I/O i,dc.
,taittt,. Rtqaicd htt IOAREA2 keyaab,d it
tptaified,battaak.e.p,aat.aiagit,at
IWORKA ktya.,dl

LSCAN

tyytbal

R,qai,,d,.titbFSCANk.ywad,ta,peaify
I,btl at att,’t I tttt taay NUt t pac.h tiltt
With thitted aad,t

V.a

LTRANS

tymbal

Reqai.td, .05 FTRANS tad SCAN heywada,
t 5
I
a I
Pt lv h I b
tic’, atbit Ia, ty i,pat file aaith thitted cad,,

Yet

MODE

BINARY

Reqai,,dta,peciiybi,a,yp,acttdagmode

Sru

Sp.aifiea CS tetata (eaebh,aeyI peacetsica
teed,

IOAREA2

IOREG

—

13.5.1.4

—

13,5.1.4

—

WORKA

13.5.1.4

MOUIEBINARY

13.5,3

TRANS.
MODE BINARY

13.5.3

RECFORMUNDEF

13.5.2,
13,5.2.1

‘_:

—

“.

Yet

—

13.5,2,
1 3,5.2.2

—

—,————,

OPTION

YES

Specifiesaptiacal filepiaceteica

OVBLKSZ

Specifit. at.,, d “a’h at acted,.4 1/0
batl,,t Ia, p,aa,ttiea fAted, ayblaek,d
eca,d teed. eiagthitt,daadea;a it,
dtcimal eae,bte aegieg team 2 thcaagh
4095 ted eeatt be at le,tt ace bytt l.egec
thee the BIKSIZE .peaitieetiaa.

FIXUNB

Sptcifie.tia,d,aeblaakedeeca,dfaee.t

UNDEF

Specifiet aedefieed ,aaa,d faeecat ‘aecyieg

Speaitiet,ie ee.edctacy peceethetea, the
eaecht, at the geaeetl mgitttata bt ated
Ia eat,, Ia Iteath at aadafieed .aaadc.
Reqaiced fee aatpat tile,; aptiaeal tee

RECFORM’

13,5.9

—

‘-

—

#ECFORMUNOEF,

13,5,7
13,5.1.5

MODEBINARY

—

Vet

Yet

V.a

Yet

Vet

13.5.1.2

—

MODEmaINARY

13.5,1.2

RECFORM=
FIXUNB,

13.5.1.6

leeathl. R,aa,dt mqaiee delimit,, leed’af’
ttapl. Oatpat filet ctqaice
RECSIZE mgatac.
,eaa,d

RECSIZE

—

tymbal

Speaefie, 1.5.1 at 72’byte tta.age ate,,
taliaaacd..l;eed, ice miach data maec5a.
,eeat.,ee,catteataafaaae’tgeaaeal
ceai.tees dadeg eaeaatiae at impecetlee
maceat. If eat apecefied, data meeageeeeet
eapaat, tee, ace, edd,as, a macalec 13.

Yea

SCAN

cymbal

Specitiec label at aae,’c iepat file chile
mede tEe,, teblt, Reqaiced tee iepat tica
iecith ahifted cad,, IMOOESTDI;
FTRANS aed LTRANS keyma,d, mate
alca be tpeaified. Optiaeel faa catta.aa,e
aheatate, deletiae I, biteacy made,
Optiaeel. eth TRANS keyeaacd, tea
ahaeaatt, delttiae ie eithaa made

Ye,

cymbal
‘

Sptaifiet labtl at ate,’t t,,tcletiae teble,
tee cay file bat, chifttd epat file

SAVAREA

TRANS

‘Vet
-

MODE=9INARV

—

13,5.9

-—

Yea

—

V.a

Yea

FTRANS,

V,,

WORKA

-‘

INPUT

Speaefeet a,, tpat file—cead eely

OUTPUT

Reqaieed ta eptacty cc teepee file—
paealeaely

YES

Specifies deable baft eeiaa ale macic tee,.,

aatciahaceemeat.peaitymitheeaflGET
‘

13.5.3,
13531

LTRANS

TVPEFLE

ec PUT mecca. Igeaced et lOVED leeymaed
it ,peaified

*parameter may be changed on DD job control statement.

—

‘-

—

Yea

Yes

Yea

Yet
-

Yea

Vet

—

‘

—

bRED

13.5.3.1,
13.5.3.2,
13.5.5
13,5,10
13.5.1.1
13.5.1.1

t3.5.1.4

UP-8068 Rev. 4

SPERRYUN1VAC OS/3
BASIC DATA MANAGEMENT

Table 1 7—1.

17-28

Summary of DTFPT Keyword Parameters j’Part 2 of 2)

LEGEND:
R

Required to be specified explicitly or by default

Specification is optional.
Default value assumed by data management if keyword is not specified

—

Not pertinent

NOTE:

A “yes” entry in the column headed “EXTRN” indicates that the assembler generates an EXTRN pseudo-op for the symbolic label
specified. This means that your coding that defines the subroutine, table, or main storage area in point may be assembled
separately from your DTFPT macro. You will need an ENTRY for each EXTRN.

17.5.1.

Basic DTFPT Keyword Parameters

The following subparagraphs explain several basic keyword parameters that you use to
indicate to data management how to set up the file table according to certain of the
fundamentals of your processing. With these keywords, youestablish whether your file is
an input or an output file, what the record format is, what the record and block sizes are,
whether you are using oversized buffers and which if either of the double-buffering
options you are using.
17 5 11

Specifying File Type (TYPEFLE)

Data management provides two types of paper tape file: input and output; the combined
file is not supported. The input file allows the use of the GET imperative macro to read
data from a paper tape (17 4 3) and requires you to code a routine for end-of-tape
processing (17 54) An output file allows the use of the PUT macro to punch data on a
paper tape (17 4 4) If your 0920 paper tape subsystem is configured with both a punch
and a reader simultaneous reading and punching are possible but on different pieces of
tape; each of these requires separate definition with a DTFPT declarative macro and
allocation with its own DVC
LED job control device assignment set. You should use a
different file name for each DTE.
—

Keyword Parameter TYPEELE:

TYPE FLE4NPUT
Indicates that this DTFPT macro defines an input paper tape file one that you
want to read. You must specify the label of an end-of-tape processing routine for
every input file, EOFADDR keyword parameter (17.5.4).
TYPE FLE=ÔUTPUT
Must be specified to define an output paper tape file
punched

one that you want

If you omit the TYPEFLE keyword, data management generates an input file table by
default; EOFADDR keyword must still be specified.

UP-8068 Rev. 4

17.51.2.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 7-29

Specifying Record Format (RECFORM)

In the OS/3 paper tape data management system, you have but two record formats:
undefined (that is records of various lengths) and fixed-length unblocked In the standard
(character> processing mode, you may use either format, but onlyfixed, unblocked records
may be processed in binary.
The reason for this is that, in the binary processing mode, the 0920 paper tape subsystem
cannot be made to recognize the end-of-record stop character used as a delimiter to mark
the ends of undefined records, which vary in length from record to record. Input paper
tape processing of records with varying lengths depends on the recognition of the
delimiter to stoptape motion automatically when a record has been read.
For processing output files with undefined records you must specify both an end-of-record
stop character with the EORCHAR keyword (17 5 6) and a general register to be used for
referring to record size (the RECSIZE register 17 5 1 6) Before you issue the PUT
imperative macro to punch an undefined record, you determine its length and place this
number in the two least significant bytes of the, RECSIZE register. The length is measured
in bytes and does not include the byte for the EORCHAR stop character. The number must
be positive and in the range 1 through 4094. When you issue the PUT macro, data
management places the stop character at the end of each undefinedrecord in the I/O
area before punching the whole contents into the tape
When you are processing an input file containing undefined records, your use of the
RECSIZE register is optional if you specify it data management loads it with the length of
each record read in again this length does not include the EORCHAR stop character You
must wire the program connector of the 0920 papertape subsystem to recognize the endof-record stop character that is punched in the tape (17.2.1.2).
Keyword Parameter RECFORM:
RECFORM=FIXUNB
Specifies that the record format is fixed and unblocked Only this format may be
used in binary mode You specify record length with the BLKSIZE keyword
RECFORM=UNDEF
Specifies that record length varies from record to record and that records are
delimited by.a wired stop character (EORCHAR keyword). Length of each record
is defined via the RECSIZE register. This record format is not valid for binary
mode if so specified a diagnostic appears in the DTFPT macro expansion in your
assembly listing, and RECFORM=FIXUNB is assumed.
If the RECFORM keyword is omitted, data management assumes that the record
format is fixed, unblocked.
17.5.1.3.

Specifying Block Size (BLKSIZE)

The maximum number of bytes that data managementcan transfer between paper tape
and main storage in one access is 4095 bytes. (If you are familiar with OS/4 data
management, you will recognize this figure as themaximumblock size in that system as
well)

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

17-30

The maximum block size limits the length of your logicalrecords. For the undefined record
(RECFORM=UNDEF, 17.5.1.2), because the EORCHAR stop character must be included in
the specified block size, the longest logical record is 4094 bytes. When you are processing
undefined records,: your I/O buffers and work areas must be at least as long as the
number of bytes specified as the block size.
When you are processing fixed, unblocked records, which do not end in a stop character,
your blocksize specification is the maximum length of a logical record and, because it is
the number of bytes moved to or from a work area, each work area must be at least as
long as the specified blocksize.
For neither record format does the specified block size need to account for the presence of
shift characters, which data management inserts and deletes. When you are processing
fixed, unblocked records, however,with shifted codes, you may specify that your [/0 areas
are larger than specified block size, using the OVBLKSZ keyword (17.51.5). When you do
this, you must also reserve at least as many bytes of storage for each I/O area as you
specified with the OVBLKSZ keyword but you need not reserve more for each work area
than you specified. with the BLKSIZE keyword. Do not specify the OVBLKSZ keyword
unless your fixed unblocked records contain shifted characters
With output tapes, additional bytes for any characters to be punched at the end of a record
to serve as an interrecord gap (17.3.4) must be included in your BLKSIZE specification.
With character mode input files (MODE=STD), however, nulls or delete characters at the
end of each record are not transferred into main storage and must not be included in the
BLKSIZE specification. The situation with binary mode input files is the same as for output
files: because record gap characters are transferred into main storage (nulls as
hexadecimal 00), you must include them in calculating block size, as well as programming
as necessary to deal with them.
When you issue the OPEN imperative macro for a paper tape file, the OPEN transients
check your BLKSIZE specification for validity. If there is no specification, or if the number
of bytes specified is other than 1 to 4095 bytes, the file is not marked open, and you may
not process it. Refer to 17.5.9 for the resulting data management error processing.
Keyword Parameter BLKSIZE:
BLKSIZE=n
Required for all input and output paper tape files. Specifies the length of the
largest logical record to be processed where n, a decimal number ranging from 1
through 4095, is the measure of this length in bytes.
If omitted, an error message appears in the DTFPT expansion in your assembly listing;
the file cannot be opened for processing.
17.5.1.4.

Specifying Buffers, Work Areas, and Double-Buttering (IOAREA1,
IOAREA2, IOREG, WORKA)

You must always specify at least one I/O buffer for each paper tape file, using the
IOAREA1 keyword parameter of the DTFPT declarative macro When you specify only one
however, and do not use a work area, you have no means of overlapping I/O operations
with your processing: each I/O operation must be completed before data management can
return control to your program. (The reason for this is to prevent your inadvertently
changing the data in your buffer before the I/O operation is completed.)

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

17—31

To increase your throughput over what this situation affords,data managementoffers two
methods of double-buffering: specifying a secondary I/O buffer and an index register to
point to the current one (with the IOAREA2 and IOREG keywords), or using one or more
work areas for processing while your I/O takes place from orto the IQAREA1 buffer. With
either of these mutually exclusive alternatives you benefit Double-buffering allows data
management to initiate an I/O operationand to return to you before it is completed. While
the I/O proceeds in one area (dont change the data in this one!), you may process in
another. This overlapping of I/O and processing obviously speeds up the execution of your
program.
:

No additional throughput isgained, however, if.you specify a secondary I/O buffer and use
work areas at the same time.. Although OS/3 allows this combination of areas, it does not
allow both double-buffering methods at once.
If you are going to use work area double-buffering, you must inform data management of
this by specifying the WORKA keyword in the DTFPT macro (the specification is
WORKA=YES), and you must then specify the address of a work area in the second
operand of each PUT or GET macro you issue (1 7.43, 17.4.4). You may use a different
work area each time For an output file, data management moves your data from the work
area to the I/O area before initiating an I/O. operation to the punch. For input files, data
management moves the data from.the I/O area to the work area before making it available
to you. Each work area you use (and there is no limit set by data management on their
number) must be of a length of least equal to the number of bytes you specified with the
BLKSIZE keyword (17.5.1.3). The reason for this is that data management always moves to
or from a work area exactly this number of bytes.
If, on the other hand, you choose the IOAREA1/IOAREA2 form of double-buffering, and
therefore do not want data management to move records to and from your workareas, you
must establish an I/O register to keep track of the current buffer, using the IOREG
keyword parameter. For an output file, data management’s OPEN processing sets up the
specified IOREG register to point to the address of one of the I/O areas; it changes this
address to that of the other buffer after each output operation. Before you issue a PUT
macro, therefore, you must move the data you want punched tothecurrent I/O buffer,
using the IOREG register to access the record.For input processing, after each GET macro
you issue, the IOREG register points to. the I/O buffer that contains the requested data
just read from paper tape. You must use the IOREG register to access it.
When your DTFPT declarative macro is expanded, the assembler generates EXTRN pseudo
ops for the, symbols you have equated to the IOAREA1 and IOAREA2 keyword parameters;
therefore the coding that defines these storage areas may be assembled separately from
the coding containing the.. macro. IOAREA2, if specified, must be of the same size as
IOAREAI.
.

The length of the I/O buffers defined by DS or DC statements somewhere in your BAL
program, should be at least the number of bytes you have specified with the BLKSIZE
keyword of this DTFPT declarative macro (17.5.1.3). It must be great enough to contain the
longest of your undefined records, including the end-of-reccrd stop character (EORCHAR
keyword, 17.5.6), but not including shift characters. Buffer length should also be no less
than the BLKSIZE specification for fixed, unblocked records without shifted codes. When,
however, your fixed, unblocked records do contain shifted codes, you may specify that your
I/O buffers are larger than your block size specification, via’ the OVBLKSZ keyword
(17.5.1.5); when you do this, the storage areas you define for IOAREA1 and IOAREA2
must not be less than your OVBLKSZ specification indicates.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

1 7-32

Keyword Parameter IQAREA1 :
;
IOAREA1symbol
Required for aI[paper tapefiles, to specify thesymbolic address of the main
storage area reserved foruse as the primary I/O buffer for the paper tape file
defined by thisDTFPT declarative macro. The length of the buffer is defined
elsewhere with a DS or DC statement. It must not be less than the OVBLKSZ
specification; if the OVBLKSZ keyword is not specified, buffer length must not be
less than the BLKSIZE specification.
.

If omitted, data management will not open the file defined by this DTFPT declarative
macro, and an error messageappears in your assembly listing. Refer to 17.5.9 for the
resulting data management error processing.
Keyword Parameter IOAREA2:
lOAREA2=symbol
Specifies the symbolic address of a secondary I/O buffer; optional forall paper
tape files. Length of IOAREA2 buffer must be the same as IOAREA1, and is
subject to the same considerations. When the IOAREA2 keyword is specified,
unless you specify work area processing via the WORKA keyword, you must also
specify a general register to reference the current I/O buffer, using the IOREG
keyword
Keyword Parameter IOREG:
IOREG(r)
Specifies the general register that is to be used to reference the current I/O area
when both the IOAREA1 and IOAREA2 keywords are specified for doublebuffering, and work area processing is not specified with the WORKA keyword.
The completion, r, must be enclosed ih parentheses; it represents the number of
the general registerused: Registers 2through 12 are always available for use; if
you specifythe SAVAREA keyword (17:5.8), register 13 is also available. If you
specify the IOREGkeyword, you shouldnot also specify the WORKA keyword; if
you specify both, an error flag appears in the:DTFPT expansion, and the WORKA
keyword is ignored.
Keyword Parameter WORKA:

WORKAYES
Specifies that data managementis to provide double-buffering via the IOAREA1
buffer and a user-specified work area. Data management moves an input record
from the I/O area to the work area you specify as the second operand of the GET
macro; It moves an output record from the work area you specify with the PUT
macro to the IOAREA1 buffer The length of each work area is defined with a DS
or DC statement elseWhere in your BAL program; each must have a length at
least equal to the number of bytes specified by your BLKSIZE keyword

SPERRY: UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

17-33

if YOU specify the WORKA keyword, you must not also specify the 1OREG
keyword. If you specify both, an error flag appears in the DTFPT expansion in
your assembly listing, and the WORKA keyword is ignored. The work area
processing described cannot take place in this event, nor when the WORKA
keyword is omitted.
17 5 1 5

Specifying Oversized Buffers (OVBLKSZ)

To obtain more efficient processing of input or output files containing fixed unblocked
records that are letter/figure shifted you may define I/O buffers in your program that are
larger than your BLKSIZE specification. Recall that your specified block size equals the
length of your logical record when you have specified RECFORMFIXUNB but that this
length does not allow for the insertion of the shift codes by data management (17.5.1.3).
When you are using oversized buffers you must notify data management that you are
doing so by specifying the OVBLKSZ keyword, whichindicates atthe same time how long
your oversized buffers are.
What this does for you in processing input files is to allow data management to read in
more characters than your fixed record length calls for. Data management removes shift
codes and delete characters from this larger block until the “compressed’ record thus
formed in the buffer does equal your specification (It has also translated the characters
between the shift codes with the specified FTRANS and LTRANS translation tables.) If data
management cannot create a record equal in length to your BLKSIZE specification from
the data in the buffer it reads in more When it has thus created a record of this size data
management either leaves this record in the I/O buffer and retuF s to you, or it moves the
record to your work area before returning to you. If you have defined I/O buffers large
enough, this mode of processing reduces the overall number of 1/0 operations requiredtO:
process your file. Figure 17—10 depicts the relations hip of the various specifications.
OVBLKSZ specification

IOAREA1

L.
figures

letters

IOAREA1

____

I
5

S
Cg

//
//

I
figures

/ / —
/7
/,

1’/’

letters

figures

—

7—
;.—.__

—----

[_____

WORK AREA

BLKSIZE p

feat

Figure 17—10. Relationships of Logical Record Length, Work Area Length, and I/O Buffer Lèhgth to
the BLKSIZE and OVBLKSZ Specifications for a Fixed, Unblocked Record Input
from Paper Tape with Shifted Codes (Part 1 of 2)

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068. Rev. 4

17-34

LEGEND:

Figure shift character

Letter shift character

Bytes in I/O area not tobe processed by user
NOTES:
1

The upper diagram depicts the record as originally read into the oversized I/O buffer it contains untranslated tape
codes and letter/figure shift codes. The hardware delete character has not beentransf erred to main storage, and data
management has removed all software deletes before tranSlation..

The center diagram shows the record as data management makes it available to you, left-justified, in the I/O buffer;
the letter and figure shift codes have been removed and intervening data translated into EBCDIC. Notice the bytes in
the oversized buffer extending beyond yoUr BLKSIZE specifiOation: these are Oxtraneous to your logical record, and you
should not access them.

The lower diagram shows the record moved into your work area, the length of which should be no less than your
‘BLKSIZE speOifiction. The record is left-justified in the wOrk area, also.
Figure 17—10.

Relationships of Logical Record Length, Work Area Length, and I/O Buffer Length to
the BLKSIZE and OVBLKSZ Specifications for a Fixed, Unblocked Record Input
from Paper Tape with Shifted Codes (Part 2 of 2)

For output flies the reverse takes place Specifying the OVBLKSZ keyword allows data
management more room to Insert the required shift codes Into the fixed-length record you
have supplied. It continues doing so until the oversized buffer is filled, when it writes out
the buffer contents to be punched on tape. If necessary, data management issues
additional I/O orders until the complete logical record you provided has been punched.
Your OVBLKSZ specification must not exceed 4095 bytes and must always be at least one
byte more than your BLKSIZE specification. When you use the OVBLKSZ keyword, you
must still reserve storage for your I/O buffers in your program; data management cannot
issue the necessary define storage (DS) or define constant (DC) instructions for you.
(Recall that you may assemble this part of your coding separately from your DTFPT
declaratIve macro if you want to) The I/O buffers must be defined to include as many
bytes as you have specified with the OVBLKSZ keyword; however, if you have specified
work area processing, you need not reserve storage for any work area that exceeds your
BLKSIZE specification; this is because the number of bytes that data management moves
to or from your work areas is always equal to the blocksize.
How do you calculate the extra space you need? If you know your data well, and your
logical records follow a definite pattern, there is no great difficulty in establishing the
number of additional characters to allow for the shift codes your records require.
Statistical sampling of your records, when you do not know their composition well, may
help you estimate the space you need.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

17-35

The worst case, of course, occurswhen there is an exact alternation: every letter being
followed by a figure every figure by a letter This situation doubles the length of your
logical record The best case occurs when only one shift code is required per record Do
not discount the possibility of timing several test runs with an adequate sampling of data
using successively larger OVBLKSZ specifications until you are reasonably certain that yoU
have the best trade-off of main storage space for increased processing speed in your
application Nor should you forget that your use of delete codes must also be taken into
account.
If you specify the OVBLKSZ keyword, but do not specify the WORKA keyword, do not
access data in the I/O buffers at a displacement greater than your BLKSIZE specification.
A glance back at Figure 17—b shows the possibility of accessing extraneous data if you
do.
If you do not specify the OVBLKSZ keyword with fixed, unblocked records that contain shift
codes, your records are processed in the I/O buffers within areas that are limited in their
length to the BLKSIZE specification. Reserving larger buffer space is then without useful
effect.
Keyword Parameter OVBLKSZ:
OVBLKSZ=n
Specifies processing input or output records in oversized I/O buffers, when
buffers greater than your BLKSIZE specification are defined to increase
processing efficiency of fixed; unblocked records containing shifteddata Here, n
is the decimal number of bytes used for buffer length; n must be at least one
byte greater than your BLKSIZE specification, but may not exceed 4095 bytes.
When you specify the OVBLKSZ keyword, you must define I/O buffers that have
a length at least equal to n; buffer length greater than n is unused. Work areas,
if specified need be no longer than your BLKSIZE specification
The OVBLKSZ keyword may not be used if RECFORMFIXUNB is hot specified,
explicitly or by default, or if records do not contain shifted data.
If omitted, records are processed in the I/O buffers within areas limited in length to
your BLKSIZE specification.

17 5 1 6

Specifying Register for Record Size (RECSIZE)

When you are processing an output file ontaining undefined records you must specify a
general register in which you will place the length of each record before you issue the
PUT imperative macro The use of a record size register is optional for input processing of
undefined records; if you specify such a register, data management places in it the length
of the logical record that is available to you in the I/O buffer or in your work area before
returning to you from its execution of your GET macro

UP-8068 Rev. 4

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

17-36

The record size placed by you or data management in this register is a fixed-point binary
number measuring the length of the record in bytes it may range from 1 to 4094 bytes
This length does not include extra bytes for the end-of-record stop character (17 5 6) nor
the shift codes if any that data management inserts However for output undefined
records you must include extra bytes for any characters you want punched at the end of
the record to serve as an interrecord gap (17 3 4) Data management does not include
record gap characters in the input record length it loads into the register.
The record size register is specified with the RECSIZE keyword and is used only in
character mode (MODE=STD) for undefined records Files processed in binary mode may
not contain undefined records.
Keyword Parameter RECSIZE:
RECSIZE=(r)
Specifies the number of the general register that is to be used to refer to the size
of undefined records where r is the register number and must be coded in
parentheses. General registers 2 through 12 are available for this use, as is
register 13 when you have also specified the SAVAREA keyword.
The RECSIZE keyword is specified only when processing is in character mode
(MODE=STD) and records are undefined (RECFORM=UNDEF). It is required for
output processing; before issuing each PUT macro, you must place the length of
the undefined record in the RECSIZE register. Use is optional for input
processing; data management loads the RECSIZE register before returning to you
from each GET macro.
17.5.2.

Specifying File Processing Mode (MODE)

The 0920 paper tape subsystem itself operates in either of two modes binary or
nonbinary. The nonbinary mode of the hardware (for which the term character mode, used
in this manual, is probably more descriptive) is the standard mode of operating the
hardware in OS/3 data management

17.5.2.1.

Highlights of Binary Mode Processing (MODEBINARY)

The binary mode is designed for use only with 1-inch, 8-level paper tape. In this mode,
each of the eight bits of a byte in main storage that represents a character corresponds to
a hole position on the tape. This correspondence is fixed within the hardware, and you
cannot use the program connector board to change it
as you can for character mode.
In binary mode, because you cannot wire the board so that the subsystem can recognize
the stop character that delimits undefined records (thus permitting an automatic stop of
tape motion when the hardware has read in a full record), you are limited to fixed,
unblocked record format. Another way in which the binary mode differs from character
mode is that figure and letter shifting is possible only for character mode; you have no
need of the keyword parameters used to specify shift codes in character mode, nor
concern for the effects of these extraneous characters on the sizes of your buffers and
work areas.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

1 7—37

Just as the subsystem cannot recognize the stop characterin binary mode, so also it
cannot recognize a delete (or rub-out ) character Data management however provides
you the means for specifying what characters you want to use as deletes this is the SCAN
keyword parameter of the DTFPT declarative macro When you have used this to specify
one or more delete characters for an input file, each recordis scanned as it is read in, and
any such characters are deleted As the characters are removed the record is
“compressed”,. and data management reads more characters from tape,if necessary, until
the record of the fixed length you have specified is in your buffer (For further detail see
the SCAN keyword (17.5.3)J
.

Although you cannot use shifted codes in binary mode, you may indeed specify that your
data is to be translated. Data management translates your inputor output data according
to the table you provide in your program (or assemble separately) specifying its symbolic
address via the TRANS keyboard parameter (1753.2).
As to null characters in binary mode, once your input file has been read past the tape
leader (which must contain only null characters: 172.2), anynull charactersencountered
after the first non-null aretransferred to main storage. If, for example, you areusing nulls
to denote an interrecord gap (17.34), these will appear in your I/O area or work area at
the end of each record (recall that you must include them incalculating your BLKSIZE
specification); your program must provide for any action that may be necessary. Similarly,
because the null characters you must use for your paper tape trailer in binary mode
(1723) are also transferred to main storage, you must do what is necessary in your
program to dealwith them.
Finally, binary mode differs from character mode in thatparity checking is not possible.You
can neither punch a parity channel on tape nor check parity on an input tape with the
hardware. On the contrary, the program connector board on the 0920 paper tape
subsystem is completely bypassed when you are processing in binary mode.
Keyword Parameter MODE:
MODE=BINARY
Specifies that the input or output file defined by this DTFPT declarative macro is
to be processed in binary mode. Record format must be fixed, unblocked. Data
may be translated on input or output, but not shifted. On input files, all null
characters occurring after the first non-null on the tape are transferred to main
storage.
If the MODE keyword is omitted data management assumes MObESTD has been
specified (17.52.2).
17.5.2.2.

Highlights of the Character Mode (MODESTD)

The character (nonbinary, or standard) mode of paper tape data management is intended
for use with 5- through 7-level tapes in 11/16, 7/8, and 1-inch widths. The 7/8-inch
width is limited to read-only processing.

UP-8068 Rev. 4

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

1 7-38

In the character mode of processing, you may specify either the fixed, unblocked record
format, or the variabIeength, undefined format (17.5.1.2). For input fileswith undefined
records, you must wire the program connector board to specify the endofrecord delimiter,
and you may specify a record size register,. into which data management loads the length
of each record it reads in (17.51.6). For output files containing undefined records the
RECSIZE register is not optional; you must specify it and load ityourself with record length
before you issue the PUT imperative macro to punch each record into the tape. You must
also specify the end-of-record delimiter (using the EORCHAR keyword), which data
management places at the end of each undefined record to cause tape motion to stop
when this character is encountered after reading the record (17.5.6).
To allow more characters to be encodedon paper tape than would otherwise be possible
with fewer than eight levels or tracks, data management provides a letter- and figureshifting capability, described in detail with the keyword parameters that implement it
(FSCAN, LSCAN, FTRANS, LTRANS, and SCAN in 17.5.3 and 17.5.5). Data management
handles insertion of shift characters on output and deletes shift codes on input, translating
intervening data. You specify the shift codes, which. may be any of the codes that you can
punch on tape with the number of levels (tracks) in use.
Through the TRANS keyword parameter (17.5.3.1 and 17.5.3.2), the character mode is
provided with a translation capability that you may use for any but an input file with
shifted codes. For the latter, a translation capability is provided through the SCAN,
FTRANS, and LTRANS keywords (17.5.3). For output files with shifted codes, translation is
performed after inserting shift codes; the shift characters themselves are not translated.
When you are processing in character mode, you may wire the program connector board
so that the hardware recognizes one delete character in input files.If you need more than
one delete character, you may specify the remainder of them with the SCAN keyword
(17.5.3.1), and data management takes care of deleting these. Or you may specify all your
deletes with the SCAN table and not have a hardware delete.
Parity signal generation and checking are both facilitated in the character mode of
processing. You may wire the program connector board in the 0920 paper tape subsystem
to punch an odd or even parity track on an output tape, or to check a paritytrack, again
odd or even, that has been punched into an input tape. You may connect any photocell or
punch actuator to any memory bit, except the most significant bit, of a byte in main
storage. The parity signals are generated within the subsystem; when you are punching,
the parity signal generated is based on all eight bits of the byte in main storage, even
though fewer than seven tracks are actually being punched in the paper tape.
When the hardware detects an odd or even parity error on a character of an input record,
the most significant bit of the byte in main storage that represents the character is set to
binary 1, and data management performs the error processing detailed in 17.5.9.

UP-8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-39

Keyword Parameter MODE:

MODE=STD
Specifies that the input or output file defined by this DTFPT declarative macro is
to be processed in the standard, nonbinary (óharacter) mode. You can read and
punch tapes with from five to seven data levels and may use either fixed,
unblocked or undefined record format. You may suppress parity, signal punching
or checking or use the hardware to punch an odd or even parity signal on output
tape or check parity on an input tape. In character mode,: you may wire the
program connector board so that the hardware recognizes one delete character
and the end-of-record stop character. Null or delete charactersin this mode are
never transferred to main storage. Data may be translated on input or output and
may contain shifted codes.
17.5.3.

Letter/Figure Shifting and Translation, Input Files in Character Mode (SCAN,
LTRANS, FTRANS)

The letter/figure shifting capability that data management provides you for use in
character mode processing (MODE=STD) allows more data and control characters to be
represented by the hole patterns you can punch in tape than would be possible without it.
Consider the 5-level paper tape which can offer only 2 distinct combinations of punches
in its five tracks. These 32 hole patterns are enough to cover one case of the alphabet, but
not the 10 numbers in addition
and this leaves out a null, a delete, and any other
characters you might need.
—

If you assign two of the 32 hole patterns to the null and delete characters however, and
two of the remaining 30 to shift codes (one the “letter shift”, the other the “figure shift”),
you have 28 patterns left for representing data. (Shift codes may be any of the .32.) But
these 28 hole patterns can now represent 56 characters, if. you establish that each pattern
represents one character when it follows the letter shift code on a tape, but a second
character when it follows the figure shift. This is exactly what you do with the SCAN,
FTRANS, and LTRANS keywords in your DTFPT macro, with which you specify scan and
translation tables for shifted input files. You can then handle one case of the alphabet, 10
numerals, and 20 other characters as well. You may placecodes representing any symbols
in efther table; it makes.nodifference.to data management.
One reason this is possible is that, although data is encoded on tape in a 5-hole system,
you are representing it in main storage in an 8-bit system. One convention in OS/3 is
data management’s assumption that the first record on every paper tape begins with a
“figure”: one of the 28 characters that you have decided may be represented by the hole
patterns that follow the figure shift code on paper tape. However, if your first record
actually begins with a “letter” (one of the other 28 characters that the same set of hole
patterns may stand for), the letter shift code must be the first non-null character on the
tape. Data management automatically punches this on output tapes for you.
Another circumstance making character shifting and translation easier in OS/3 is that
data management implements these with the BAL translate (TR) instruction and translate
and test (TRT) instruction. Both of these rely on the ordering of the 256 configurations
possible in an 8-bit system that is shown in the EBCDIC columns of Table C—i, and your
scan and translation tables should be based on the same order of character positions.

SPERRY UNIVACOS/3
BASIC DATA MANAGEMENT

UP-8068 Rev4

17-40

For paper tape input files with shifted codes, in character mode, datamanagement deletes
the shift codes it encounters in input records and translates the data between them. (For
output files, data management inserts the shift codes; this is described in 17.5.5.) The
shift codes you use are entirely up to you you may select any of the hole patterns that
may be contained in the number of levels in thetape youare using
When you have specified the fixed unblocked record format (RECFORM=FIXTUNB) for a
file containing shift codes, note that your records on paper tape are not actually fixed in
length. Usually, each has been made longer by the insertion of one or more shift codes
and thus exceeds the fixed length your record had when you provided it to data
management to be punched. (For an illustration of this, refer back to Figure 17—5.)
When you are processing fixed, unblocked records with shifted characters, however, you
can make for more efficient processing by reserving storage areas for I/O buffers that are
somewhat larger than the fixed length you provide to data management with your
specification of the BLKSIZE keyword parameter Whenyou do so for an input file, data
management is able to read in more characters at a time; the delete and shift characters
are removed, shifted characters are translated as required (and additional tape reads
performed if necessary) until the number of data characters in the buffer equals your
BLKSIZE specification Then the data is made available to you in the buffer or moved to
your work area. To specify thisprocedure, whichspeeds up processing by permitting fewer
I/O operations to be issued by data management, you specify the OVBLKSZ keyword in
your DTFPT macro (17.5.1.5).
Keyword Parameter SCAN:

SCANsymbol
Specifies the symbolic address of your input file shift codescan table. Required
in character mode (MODESTD) for input files with shift óódes; the FTRANS and
LTRANS keywords must also be specified whenever the SCAN table specifies
which are the shift codes.
An optional use of the SCAN table in character mode is to specify one or more
delete characters (instead of or in addition to the one delete character you may
specify by wiring theprogram connector board, which you then do not include in
the:SCAN table). Whenyou use theScAN table for deletion only, youdo not
specify the FTRANS or LTRANS keyword, but you may specify the TRANS
keyword (17.5.3.1).

UP—8068 Rev4

SPERRYUNIVAC 0S13
BASIC DATA MANAGEMENT

17-41
:

The SCAN table, whose address is specified by symbol, need be only as long as
the numberof paper tape codes in thesettobe read. It contains a 1-byte entry
for each of these all are hexadecimal 00 except those used to specify the figure
shift character the letter shift character and the software delete characters (if
there may be one none or many) The nonzero entries in the SCAN table
any
are:
—

Hexadecimal
Code

Use

Defines the figure shift character; is placed in the byte
position of the table that corresponds to the figure shift
code

Defines the letter shift character; is placed in the table in
the byte corresponding to the letter shift code

Indicates a character to be deleted bydata management.
(This “software” delete is in addition to or instead of the
“hardware” delete character that may be specified by
wiring on the program connector board);-There may be
many software delete characters specified in the SCAN
table; you may specify deletes with:or withoUt the use of
a hardware delete character

Refer to the coding example that follows the descriptions of the FTRANS and
LTRANS keywords for an explanation of the SCAN table. See also 17.5.3.1 for a
description of the use of the SCAN keyword to delete characters from records
processed in binary mode (MODEBINARY).
Keyword Parameter FTRANS:
FTRANS=symbol
:
Specifies the symbolic address of your input file figure translation table required
(with the SCAN and LTRANS keywords) to process input files in the character
mode (M0DE=STt) that contain shifted characters The label of the translation
tableissymbo/.
:

The translation table specifies the correspondence between a character that is
punched after the figure shift character on tape and the 8-bit code that data
management is to place in your data area. Each position in the table corresponds
to a different hole pattern on the tape beginning with hexadecimal 00 (null
which is never transferred into :main storage, but simply marks the first position
in the table) and extending through hexadecimal 1 F, 3F, or 7F, depending on the
level of tape you are using.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

17-42

The FTRANS table containsa 1-byte entry for each paper tape holepattern in the
set to be read; all entries are hexadecimal 00 except those in the positions for
the hole patterns that may follow the figure shift character on tape. The 1-byte
entries for thesehole-patterns may be the hexadecimal digits for the 10 EBCDIC
numeral graphics(F1, F2, and so on); on the other hand, they may also be any
codes of your choosing: alphabet, punctuation, ASCII numerals, or whatever you
have decided will be “figures”. (In the coding example that follows the
description of the LTRANS keyword, the codes are hexadecimal Fl, F2, etc, for
the EBCDIC numerics.)
The FTRANS keyword should be specified only for files processed in character
mode (MODE=STD);. it is ignored if you specify it for binary mode. You must not
specify it with the TRANS keyword; if you do, both FTRANS and TRANS are
ignored. In either case, a diagnostic message appears in the DTFPT macro
expansion in your assembly listing.
The assembler generates an EXTRN pseudo-op code for symbol, which allows
you to assemble your figure translation table separately from the DTF if you
want.
Keyword Parameter LTRANS:
LTRANS=symbol
Specifies the symbolic address of your input file letter translation table; required
(with the SCAN and FTRANS keywords) to process input files in the character
mode (MODE=STD) with shifted characters.
The translation table, whose label is symbol, contains a 1-byte entry for each
paper tape code in the set to be read; all are hexadecimal 00 except those used
to specify which tape codes follow the letter shift character on tape and therefore
are to be translated as “letters.” The 1-byte entries for these tape codes may be
the hexadecimal digits for the EBCDIC graphics desired (see Table C—i) or, as a
matter of convenience, their character representation. On the other hand, they
may be anything you want to designate as “letters.”
The LTRANS keyword should be specified only for files processed in character
mode (MODESTD); it is ignored if you specify it for binary mode. You must not
specify it with the TRANS keyword; if you do, both LTRANS and TRANS are
ignored (as wel[ as SCAN and FTRANS, if these are specified). In either case, an
error message appears in the DTFPT macro expansion in your assembly listing.
The assembler generates an EXTRN pseudo-op code for symbol; therefore, you
may assemble the letter translation table separately from the DTF if you have
reason to.
The following coding example illustrates how you might devise scan and letter/figure
translation tables for an input file contained on 5-track paper tape, which provides only 32
possible hole patterns. The entirely arbitrary example assumes that you have decided on
the following correspondences to the paper tape codes, represented by their hexadecimal
positions, 00 through 1 F:

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Hexadecimal Code

17-43

Character

null

01 through 1C

“letters” (A-Z)

letter shift code

figure shift code

delete

01 through 09

“figures” (1 through 9)

“figure” (0)

Having decided that you need only one delete character, you take care of it by wiring the
program connector board, and therefore do not specify it as a software delete in the SCAN
table.
Example:
LABEL

&PERATIONL

I k4PP
I

—

1’PFiL...E;rI1iPAJTr,

lit
I

—

III

—

)1S
1
)iC

—

—
—

L..

—

lilt

—

1
)lS

—

ill

C
)
I
1
2
...3
.i
.

101011

till

)IC
lilt

—

JIl5
._.
â
1
tR
i

—

I
I

—

)iC
I
)l1

—

1111111

—

111111111111111111111111

iii

lilt

Ill

1111
II

Iii

11111

1111111111111
II

lIllillIl

II__II.IIXI,IZ.l
lOi(II

‘

li_i_I

I
I

111111

Ill

I
‘I

11111

ll
I

00’ t i 1
(.... 10 iBCDEIFGI—lIJi

XI_..3

i
I

l
1
L...

l
8
,lL...I

CtL_.lOiII._AIt4biPQRSli

ii
—

-I

—

Fig
(II....IlI1lI iO0
i

)iC.

—

101011

t....l

III

till

,2CL..
1
32.i

(II....I7I

lilt

III

(I.....ilI
O
1
iO

11111

a....2’O&ctj..’
(1.... lII0IOI’I I
liii

1.1

—

I
I

—

till

(tL.r_t
i
2
t

3
I

—

COMMENTS

]EPLT

—

OPERANb

UP-8068 Rev; 4

SPERRY UNIVAC OS/3
BASIC DATAMANAGEMENT

1744

NOTES:
1.

This is part of the DTFPT declarative macro defining an input paper tape file,
PAPTAP1. Note that it is processed in character mode; letter/figure shifting is
possible only in this mode. Keywords not relevant to the example are not shown.

SCAN1 is the label of the shiftcode scanWble; you assign a 32byte length
attribute to this symbol because there are 32 possible codes on a 5-level paper
tape. You have equated this symbol :to thernS CAN keyword in the DTF.

You have placed the hexadecimal code 08 in the 30th byte position in the table;
this corresponds to the position of the letter shift code, 1 D. In the next byte of
the table corresponding to 1 E you place the hexadecimal code 04 to designate
1E as the figure shift code. All other positions in the SCAN table contain the
hexadecimal code 00; you have omitted the code OC because you have no need
for a software delete.

FTRANS1 is the label of the figure translation table like the SCAN table it is 32
bytes long. You have equated this symbol to the FTRANS keyword in the DTF

Having assigned the 1-byte hexadecimal entry 00 to the first byte of the table(to
take care of the null character assignment), you then assign the entries Fl, F2,
and so on to the next nine bytes This takes care of the EBCDIC numerial
graphics 1thrugh S.

Assigning hexadecimal 00 to the next seven bytes, you assign the entry FO to the
next byte. Thus the numeral zero is represented on tape by the punch pattern
corresponding to the hexadecimal position 11 when 11 follows the figure shift
code, 1 E. As indicated by theassignrnerit of hexadecimal OOto the 14 remaining
bytes of the table, there are no further characters to be represented by tape
codes that follow the figure shift code.

LTRANS1 equated to the LTRANS keyword in the DTF is the label of the letter
translation table for this input paper tape file it also has a length attribute of 32
bytes

Again the first byte of the table is assigned the entry 0016 because this position
is for the null character To the next 10 positions you assign the first 10 letters
of the alphabet declaring the string is a 10-byte character constant for
convenience of documentation

The next 10 being assigned in the same way you conclude your assignment of
the 28 available “letter” characters with eight more. The 7th is the period (.), and
the 8th is the blank to be represented on tape by the pattern in hexadecimal
position 1C. The translation table concludes with hexadecimal 00 being assigned
to the last three bytes these three bytes (1 D 1 E and 1 F) have been ciedicated to
the letter shift code the figure shift code and the hardware delete character

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-45

The foregoing example assumes that you have not wired the program connectorboard in
order to change the correspondencebetween hole patternson paper tape and those data
management encounters in main storage. As you know, you may connect any bit in main
storage to any hole position on tape; whatever you do has a definite effect on thelayout
and content of your FTRANS and LTRANS tables and how the characters on tape are
ultimately represented in your buffer.
Another point to be made is that the codes corresponding: to shift and delete characters
are not translated by either the FTRANS or the LTRANS table The entries in these tables
corresponding to the shift and delete codes may be hexadecimal 00 or any code: they are
simply used to fill out the table completely.

17.5.3.1.

Character Deletion, Input Files, in Binary or Character Mode
(SCAN, TRANS)

As previously noted (17 5 3) an optional use of the SCAN keyword parameter is to specify
a SCAN table that is dedicated to assigning one or more softwaredelete characters, to be
removed by data management from records read in from input paper tape files: in character
mode (MODE=STD). These software deletes are usually in addition to the hardware delete
that you specify with the wired program connector board; however, you may specify all of
your deletes in the SCAN table. When you: dedicate the SCAN table to character: d&etion
alone, you do not specify the FTRANS and LTRANS keywords, but you may specify: the
TRANS keyword: parameter
:,

In addition to this use you may specify the SCAN keyword parameter in the DTFPT
declarative macro, not only for a file processed in the character mode (MODESTD), but
also for one processed in binary (MODE=BINARY). Doing so is the only means data
management provides you for automatically deleting characters from records in binary
input files; as you will recall, you cannot use the program connector board for specifying a
wired or hardware delete when you are processing in binary mode (17 2.1.2).
When the SCAN table is used only to specify software delete characters there are only
two hexadecimal codes that may be used for entries one is OC which you place in each
byte position that represents a character to be deleted The other hexadecimal entry 00
you place in all the other bytes; these represent characters not to be deleted. The length of
the table must equal :the number of possible:hole patterns that can be: punched in the
number:of tracks or levels -in your paper tape: 32 bytes for a :5-level tape,64 for a 6-level
tape, 1 28 for a 7-level tape,: and 256 bytes for the 8-level tape that is used in binary modei

17-46

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP—8068 Rev. 4

In the following coding example, the programmer has specified a 256-byte SCAN table, the
last sixpositions of which are assigned to delete characters.
Example:
OPERAND

LOPERATiONL

LABEL

1
—

.__
.__...__
1
_
t
.DiS_

0 i
...
5Oi’O
.._XI..
2
1
’

—

tilt

—

liii

—

iiii

I
I

When your data in an input paper tape file requires translation before you process it (if, for
example, it is encoded in ASCII), but also contains characters to be deleted, you may have
data management delete them before translation by specifying both the SCAN and the
TRANS keywords in the DTF.You may do so for both binary and character mode
processing, but must not specify the FTRANS or LTRANS keyword.
In this Use, the SCAN table you provide may cOntain only the hexadecimal code OC,
entered for each character to be deleted before translation, and the hexadecimal code 00,
entered in the position for each code that is to be translated. In the TRANS table (an
example of coding a TRANS table is given in 17.5.3.2), you may enter arbitrary filler codes
in positions corresponding to the characters that the SCAN table causes to be deleted
because you will not see any translations for these in your I/O or work areas

17 5 3 2

Translation for Input Files without Shifted Codes (TRANS)

You may use the TRANS keyword parameter to specify a translation table for any type of
file except an input file with shifted characters. For the limited translation function
provided for files of every kind, via the FTRANS, LTRANS, and SCAN keywords, see17.5.3.
For the use of the TRANS keyword for output papOrtape files, see 17.5.5.
The TRANS table that you code for an input file without shifted óharacters is a simple
table, not exceeding 256 bytes in length, prepared in the form required for the BAL
translate (TR) instruction. Essentially, it is a string of 1 -byte (8-bit) codes that data
management is to substitute in your I/O or work area for the codes originally read in. The
number of codes in the string, then, equals the number of unique codes you expect to read
from paper tape, less the software and hardware delete characters, which of course are
never presented for translation.
When your input paper tape file is a binary file (MODE=BINARY), the 8-bit codes originally
read in are the directly corresponding images of the hole patterns punched in the tape. For
input files processed in character mode (MODE=STD), the 8-bit configuraitons originally
placed in the I/O area are those that result from your wiring of the program connector
board. In either case, data management uses these as indexes to your TRANS table,
adding their individual values to the address of the table, and the 8-bit code found at each
table location thus reached is transferred to the data area to replace the one originally
encountered.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

The following coding example shows how you
paper tape file (without shifting) processed on
that of the 64 original tape codes 26 represent
the numerals and 2 the null and the delete
letters with uppercase for your processing.

17-47

might devise a TRANS table for an input
6-level tape in character mode. Assume
uppercase alphabet 26 the lowercase 10
You now want to replace the lowercase

This is the original assignment of tape codes, which extend from hexadecimal 00 through
3F:
Hexadecimal Code

Character
null

00
1A

uppercase alphabet, A-Z

1B—34

lowercasealphabet, a-z

35—3E

numerals, 0-9

delete

Assume that the delete character IS taken care of by wiring the program connector board
(thus making it a hardware delete); this leaves 63 characters to. be translated.
Example:
LABEL

LOPERATIONA

1ANSlLC
1
(.T

2.
3
Li.
a;

I
I

—

I
I

1
IiC..

—

1
)IC

—

I 0 ABCt
iGI—lI
1

I
I

‘I

I....ili0’II<’[...Mt1iOIPQRS
1
T
I

‘

?‘

‘

—

I, JLL,.1JLLJJJL

I
I

‘

)iC
I

DLLI

—

DiC
1
1
)iC
a

OiO

X(.... I

—

&±
—

OPERAND

—

I
1

I
II

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

17-48

NOTES:
1.

Assigns a 63-byte length attribute to the symbol TRANSLC, which is equated to
the TRANS keyword parameter in the DTFPT declarative macro that defines the
input paper tape file to be translated.

The null character, hexadecimal 00, is unchanged, but an entry for it is
necessary in your TRANS table.

3-5. Likewise, the meanings originally assigned to the next 26 codes are unchanged;
you still want the tape codes 01 through 1A to be translated as uppercase
alphabet, A-Z. But note that you must confirm this by including the same
information in your TRANS table as applied when the paper tape file was
punched on tape.
6-8. Here is the only new information yourTRANS table contains: the next 26 tape
codes (hexadecimal 1 B through 34) are now to be translated into the EBCDIC
uppercase characters, from the lowercase characters that they represent in the
records on tape.
9.

The last 10 codes covered by this table are unchanged; they represent still the
numerals 0 through 9. There is no entry for the 64th tape code, as it is the
hardware delete character that your program will never see in the I/O area.

For further details on the preparation of translation tables to be used for the BAL translate
(TR) instruction, refer to the assembler user guide, UP-8061 (current version).
Keyword Parameter TRANS:
TRANS=symbol
Specifies the symbolic address of your translation table fOr input or output files,
where symbol is the label of your table. May be used for all paper tape files
except input files that contain shifted characters
The translation table you code is in the form required for the BAL translate (TR)
instruction. Data management generates an EXTRN pseudoop for. symbol, so
that you may assemble your table separately from the DTFPT declarative macro.
You must not specify the TRANS keyword when you specify the LTRANS or
FTRANS keywords (or both) If you do so an error message appears in the DTF
expansion in your assembly listing and data management ignores the following
keywords: TRANS, FTRANS, LTRANS, AND SCAN (if the latter is specified).
You may specify the TRANS keyword with the SCAN keyword for input files in
binary or character mode, using the SCAN keyword to delete characters that are
not to be translated (17.5.3.1).
When you use the TRANS keyword to translate output files with shifted codes,
the shift codes are not translated (17.5.5). For translating input files with shifted
codes, use the FTRANS and LTRANS keywords (17.5.3).

UP-8068 Rev. 4

17.5.4.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-49

Specifying the Endof-Tape Routine for Input Files (EOFADDR)

For every input paper tape file, you must code a routine to handle the end-of-tape
condition You must also use the EOFADDR keyword parameter in the DTFPT declarative
macro defining each input file to specify the label of this routine to data management,
which branches to it automatically whenever end-of-tape is sensed, and when you issue a
GET imperative macro to an. optional. input file, having specified the OPTION. keyword
under conditions described in 175.7. You need not assembIe.your end-of-tape routine
with the DTF, however.: in expanding your DTFcoding, the assembler generates an EXTRN
pseudo-op code for the label of this routine, and you may therefore assemble it separately.
If you have only onestrip of tape to read, your, end-of-tape. routine may simply terminate
file processing by issuing the CLOSE imperative m,acro,as you must.do.thiswhenever you
have completed all processing (1 7 4 2) On the other hand if you need to read a number of
strips of tape, you must anticipate that data management branches to your routine at the
end of each of them, andthat.the. paper tape subsystem itself goes into the,. stopstate. If
you want to return to a routine which has been reading and processing tapes, you have
onlyto branch to the address contained in register 14, asthisregister holds the address of
the next instruction after the last GET macro you issued. However, if.you want to issue
any imperative macros in your end-of-tape routine before you use this return address, you
must remember to store and restore the contents of register 1 4 to preserve the return
address it contained at the ertry.of your routine.
.

Remember that in order for you to read the next tape the operator must load it into the
reader. and press the RUN switch or. the device. But,. if a GET macro is issued to read the
first record on the newly inserted tape before the operator can press the RUN switch the
physical IOCS issues .him’an operator message at the system console (DEVICE. xxx STOP
STATE RU?) to which he must reply “R” to read. (The reply “U” results in data
management error processing, 17.5.9.) To avoid having the operator go from the; reader.to
the console to read every tape,.you could program into your end-of-tape routine.a time
delay long enough to allow him to mount a tape.
Recall that in order to prevent a false end-of-tape condition being signalled before the last
data character is read from paper tape you must provide a 12-inch paper tape trailer
(17.2.3)..
,‘

.....

,..

Keyword Parameter EOFADDR

EOFADDRsymbol
Required for all input files to specify the label of your routine for handling the
end-of-tape condition,. where symbol is this label. The assembler generates an
EXTRN for’ label, so that your end-of-tape routine may be assembled separately.
You must close the paper tape file when all processing is completed
If you omit the EOFADDR keyword from the DTFPT macro for an input file (or if a valid
EOFADDR routine is not present on fil.e OPEN),data management does not open the
file, but issues error message DM61, sets the DTF error flag (bit (0) and error detected
in OPEN flag (bit 4) in filenameC, and branches to your error routine. See 17.5.9.

UP-8068 Rev. 4

17.5.5.

17-50

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Translation and Letter/Figure Shifting, Output Files (FSCAN,
LSCAN, TRANS)

Three additional keyword parameters may come into play in your DTFwhen you have
output files with shifted codes to produce in character mode (MODESTD)
•

FSCAN (required), which specifies the label of your figure scan table for this output
file Data management uses the table to ascertain which code it is to punch on tape
as the letter shift code, and to select out of your output data the groups ofcharcters
for translation as “figUres”.

•

LSCAN (also required), which specifies the label of your letter scan table, used by
data management in the same way to identify the figure shift code and the groups of
letters in your output data

•

TRANS (optional), which specifies the label of the translation table you have coded.
This table assigns, to each ofthe characters that will appear in your output data, one
of the hexadecimal tape cOdes that can be punched in the number of character levels
existing in your tape.

The FSCAN and LSCAN tables are, in a way, reciprocals in that, with the FSCAN table, you
specify the letter shift code (which must be nonzero), by placing it in each position that
corresponds to a “letter”, and indicate, by placing hexadecimal 00 in all the other
positions of the table, which 8-bit configurations in your output data are to be treated as
“figures” by data management. With the LSCAN table, you specify the figure shift code
(also nonzero) in each position corresponding to a “figure” and indicate, by hexadecimal
00 in their positions, those configurations that are to be treated as “letters.” These two
scan tables, between them, must provide a 1 -byte entry for every 8-bit pattern that you
may place in an I/O or work area to be punched on tape. Both scan tables are prepared in
the format expected as operand 2 of the BAL translate and test (TRT) instruction.
If you specify the TRANS keyword, you code the TRANS table in the format expected by
the BAL translate (TR) instruction, assigning a hexadecimal tape code to each of the 256
possible 8-bit patterns that may appear in your output: To all remaining 8-bit
configurations, which are not to be presented in your output data (this includes the
EORCHAR stop character and the two shift codes which data management punches but
never translates), you could assign the same tape code. This cOde may be the one that you
will insert in your TRANS table to represent the nonprinting EBCDIC graphic character
(opposite hexadecimal 40 in Table C—i), but you could use some other code
The TRANS keyword isnot required to produce output files with letter/figure shifting, but
its use is a great convenience, especially with 5-level tape. If you do not use a TRANS
table, you must work entirely with the data characters that you can punch directly on tape.
This means that, with a 5-level tape code, you can have only the hexadecimal codes 01
through iF in your data buffers. On the other hand, using a TRANS table allows you to
and still use 5-level
EBCDIC is only one example
work in a more convenient code
tape.
—

—

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

17-51

For full details on the preparation of tables to be used as operandsof the BAL translate
(TR) and translate and test (TRT) instructions, refer to the. assembler User guide, UP-8061
(current version), but first consider the two following coding examples, which are based on
these assumptions:
•

Your output tape has five levels, offering 32 hole patterns; these patterns are to be
represented in your translation and scan tables, and on the program connector board,
by the hexadecimal codes 00 through 1 F.

•

You have 37 EBCDIC characters for which you will present 8-bit codes in your output
data. These are the 26 uppercase alphabet characters (A-Z), plus the nonprinting
space character (these will constitute your “letters”) and the 10 numerals (0-9) (these
will constitute your “figures”).

•

You will use the hexadecimal tape code 00 to represent the null character, 1 B for the
end-of-record stop character, 1 C for the nonprinting space character, 1 D for the letter
shift code, 1 E for the figure shift code, and 1 F for the delete character.

Although you may not expect to output any delete characters when you create your paper
tape file, you probably intend to use them in routine processing of the file, and therefore
must provide room for at least one delete character in your initial assignment of codes.
(Later for input processing, you may specify one delete with the program connector board
or one or more with the SCAN keyword parameter.)
You must specify the end-of-record stop character with the EORCHAR keyword of the DTF
for this output file; data management automatically punches this after the last data
character in each undefined record (17.5.6).
Thus, the following correspondences will be used:
•

Letters:
Graphic
Symbol

Hexadecimal
Representation
in I/O Area

Hexadecimal
Tape Code, After the
Letter Shift Code, 1 D

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Graphic
Symbol

Hexadecimal
Representation
in I/O Area

Hexadecimal
Tape Code, After the
Letter Shift Code, 1 D

17—52

17-53

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Figures:
Hexadecimal
Tape Code, After the
Figure Shift Code, 1E

Hexadecimal
Representation
in the I/O Area

Graphic
Symbol
0

:F7

In this example, any 8-bit configurations other than these that you present inthé I/O area
are to be punched as the nonpranting SP character that is following the letter shift code
as 1 C. Taking it cue from the result Of using the FSCAN table on your data, data
management inserts the letter shift code automatically.
The Ond-of-record stop character, 1 B, does not require either shift óode; you must always
be sure that neithér it, northe code 1C, nor either of the shift cOdes, ever appears in your
output data for translation
The first of the coding examples discusses your DTFPT dOclarative macro and your TRANS
table; the second is devoted to your FSCAN and LSCAN tables.
Example
LOPERATONA

LABEL

‘APIAiPZ
i
I

COMMENTS

OPERAND

TEPJ 1PFLEJitPLLT,i

LJ_LADEI:ISrD,,IIIIII,I

?CFR.U11iTF,

IiiIi
i

1111111
I

—

SCAI:FSCAiN2,
AN,:LSCN2,
AILsIrReLlIs.2,I
1
rR
I

111111

1111111

.._I......I_.._I_..._I___

III

i
I

I
II

lII

111111111

111
11
il
1
111
li
1
I

IIIIIIII

11111111111111

111111111

(cont)

11-54

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

Example (cont):
COMMENTS

OPERAND

tsOPERATION

LABEL

2TR.A).Lc2.

21CL,
4.

)iC___,____

‘
7

‘

.1,11,,

XL9QL4OB&QDOfJIPIOjIII 2’
XL I I I CL’ i

—

1
)iC

I’,...I

(LI

IC’
II 0,0.1 0203tTh4Q.5t)GOI7USOI

—

I
,,

J...I’
1
X

—

I
-

q3Xi__jItC
(L9 tO2O3O5OO7OR9

I
I

II.

—

I
I

)LC
_
1
...,_....._.._)(L...I,’lI,C.’ IIIIIIIIIIIIIIIIl

JLLL

II”

LLjLj

ILJLL

NOTES:
1.

This is part of your DTFPT declarative macro for the output paper tape file
PAPTAP2, which is to be processed in character mode (MODE=STD). As
PAPTAP2 contains records in undefined record format, you must specify the endof-record stop character, which data management punches automatically after
each record on tape, with the EORCHAR keyword parameter (17.5.6); this is the
hexadecimal code lB. The required BLKSIZE, IQAREA1, and RECSIZE
specifications, as well as other keyword parameters not relevant to this example,
are not shown.

You assign a length attribute of 256 bytes to the symbol TRANS2, thus
embracing the following define constant (DC) statements. You have equated
TRANS2 to the TRANS keyword parameter in your DTF; thus the DC statements
constitute your translation table for the paper tape file PAPTAP2. It covers the
256 positiOns of Table C—i.

To the first 193 positions of Table C—i (decimal 0 through 192), you assign the
tape hexadecimal code 1C. Note that the nonprinting EBCDIC space character
(hexadecimal 40) is embedded in this 193-byte string; becauseit is, theeffect of
your specification is that any of the first 1 93 EBCDIC characters (if they appear in
your output data) are to be represented on tape by the hole-pattern chosen to
represent the space.

To the next nine positions in the TRANS table (those corresponding in Table C—i
to the EBCDIC graphics for the alphabetic characters A through I), you assign the
tape codes 01, 02, and so forth, through 09.

The next seven positions are not used, and any 8-bit configurations from this
part of the table will be represented on tape by the space code, 1C.

To the next string of nine alphabetic characters (J through R) you assign the
tape codes OA, OB, and so forth, through 12.
-

Eight unused positions follow these.

17—55

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

8. The last eight alphabetic characters, S through Z, are assigned the tape codes 13
through 1A. Tape codes lB and 1C already have their assignments; codes 1D
and 1E will be assigned with the FSCAN and LSCAN tables; as described in the
next coding example. You have determined that the tape cOde 1 F is to represent
one delete character, but, because. you will not use it in this output file and
because (like 1D and 1E) it is not to be translated, you do not include a
translation for it in the TRANS table.
9. The next six table positions are also assigned the space code, 1C.
10. To represent the 10 EBCDIC numerics in your output data, you assign the 10
tape codes shown here. These are the second assignmentsfor thetape codes in
question, which have these meanings when they follow the figure shift code on
tape, andthe previously assigned ones when they follow the letter shift code.
11. The last six positions of Table C—i are provided for by assigning the space code,
1 C.
The second coding example discusses the figure and letter scan tables you prepare for the
same file. Remember that you need not assemble them, nor the translation table, with the
DTF because an EXTRN pseudo-op is generated for the label of each of them..
Example:
LABEL

zxOPERATiONt

SCu4lIIJl2
1

2.
-3

i
i
i

—

iii

—

1
)iC.

—

)iC

010

‘

Xii... I

—

I.l

—

——

iU1i

—

I
I

Iii

iii

i
I

li
I

—

‘

IffI

S.iL.i

—

‘

1__ t
X
0
I1
1 E.
1
—

iii

ii
I

L24
1
(
O
i OO’

i
111

q
I

‘(I.....

—

SCANiZ
1
L
7

C l....I2I5II
1
O

.IlI2IL....II
2

DiC
II

7XL.._.
2.
I
1
i’t1’ i

DiC

4
iC

OPERAND

I
I

—

I
I
I
I
I

NOTES:
You assign a length attribute of 256 bytes to the symbolic address FSCAN2 the
symbol you equated to the FSCAN keyword parameter in the DTF This attribute
embraces the four DC statements following it and these constitute your figure
scan table for the output file PAPTAP2.
2.

The first 27 bytes of the figure scan table, covered by this define constant (DC)
statement, contain the 1-byte hexadecimal entry 1D, which, solely because it is a
nonzero entry, specifies to data management that the code 1 D is the letter shift
code. It must appear in each byte position of the scan table that represents a
“letter”.

UP-8068 Rev. 4

17—56

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Because the first 27 positions of:TabIe C—i ‘do not ‘correspond to any EBCDIC
graphics, letters or otherwise, it may occur to you to question why the FSCAN
table shows these as letter positions. The reason is that they are all to be
represented on tape by the same code, 1 C, which you have also assigned to the
nonprint SP character in your TRANS table. Because you have included the SP
character among your ‘1etters” its code; 1 C, ‘must follow the letter shift code on
*
tape.

‘

;

‘

Other than the letter shift code, the only entry that yoU use in the figure scan
table is hexadecimal 00; this code must be entered in every byte position that
does not represent .a ‘letter”. Not allof these wil[ necessarily be “figures”, of
course but all of the figure ‘codes will be in this subset.

In the next byte, you insert the hexadecimal code 00 to indicate to data
management that the corresponding tape code, hexadecimal 1 B, is not a “letter”.
(It is also not a “figure”; recall that 1 B is specified to data management, via the
EORCHAR keyword in your DTF, as the end-of-record stop character. This has no
translation, requires no shift code, and should never occur in your output data for
translation)

The next 212 bytes also contain the letter shift code 1 D, specifying that the tape
codes in these positions represent “letters”. These include not only your 26
EBCDIC alphabetic symbols, but also 185 substitutions of this graphic for every”
other character in this set of 212, all of which must occur on tape after the letter
shift code.
‘

The hexadecimal code 00 in each of the last 16 bytes of the figure scan table
shows that these do not represent letters Recall that only the first 10 of these
are actually to be translated as “figures”.
“‘

When your output data is examined and tested by data management character
by character your data serves essentially as operand 1 and the FSCAN table as
operand 2 of the translate and test (TRT) instruction
So long as any of the 8-bit configurations in decimal positions 240 through 255
of Table C—i is encountered in your output data or the one in decimal position
27 (this one should never be there as it is equated to 1B) the result byte that
data management locates in the FSCAN table is hexadecimal 00 Scanning may
continue and these configurations are selected out for translation with your
TRANS table (shown in the preceding coding example) and the translate (TR)
instructiàn.
The first nonzero result byte that data management encounters in your FSCAN
table stops the scanning process; the letter shift code 1D (never translated) is
placed by data management in the I/O area after the last figure translation and
but this time data management’ uses your LSCAN
then scanning resumes’
way
to select the 8-bit configuration or group of
in
same
the
table
configurations, to submit for translation by your TRANS table.
—

UP.-8068 Rêv.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-57

You assign a 256-byte length attribute to the symboL LSCAN2, which you have
equated to the LSCAN keyword in the DTF. This length embraces the subsequent
DC statements, which constitute your letter scan table for the output file
PAPTAP2..
.

In each of thefirst 240 bytes cf the scan table, you enter the hexadecimal value
00. When these result bytes are tested by data management, using
the TRT
instruction the all-zero pattern each contains allows the scanning and the
translation processes to continue with your TRANS table and the TR instruction
These 240 bytes include bothshift codesthe delete, andthe ndofrecord stop;
except for these (which shouldnever appear in your output data for translation),
the 240 bytes represent “letters”, and therefore their translations should follow
thelëttër shift code data management has already punched into the tape. Recall,
hOwever; that most of these translations arethe “dead-end” substitutions of the
space charactercode, IC, foreverythingbut the 26 alphabetic characters and the
space itself.

You enter the figure shift code, 1E, into each of the next 10 bytes (decimal
positions 240 through 249 in Table C—i) to designate these positiofls as
‘‘figures”. Because lE is a nonzero entry in a letterscan table, data ménagement
immediately recognizes It as the figure shift code: When any of these: 10 bytes is
encountered in this LSCAN table by data management’s use of the TRT
instruction on a byte of your output data, the scanning proóess stops. Data
management first punches the figure shift code on tape, then punches the
correct translation, and, having shifted from this scan table back to the FSCAN
table, resumes scanning with it.

The last six bytes of. the LSCAN table contain hexadecimal 00; the “dead-end”
translation process continues if any of these bytes is reached by data
management.

Keyword Parameter FSCAN:
FSCANsymbol
Specifies the label of a figure scan table for an output paper tape file processed
in character mode (MODE=STO where symbol is the label The table which
may be assembled separately from the DTF, is prepared in the
required for
operand 2 of the BAL translate and test (TRT) instruction; it must contain a 1byte entry for each 8-bit configuration that you might place in an I/O or work
area to be punched ch tape. Entries in the FSCAN table corresponding to
“letters” must contain the nonzero hexadécimál code for the letter shift
character all others must contain hexadecimal 00
The FSCAN keyword must be specified with the LSCAN keyword to produce
output files with shifted codes in character mode (MODE$TD) If only one of
these two keywords is specified a diagnostic message appears in the DTF
assembly listing, and the specification isignored.lf specified when processing is
in binary mode (MODE=BINARY), a diagnostic appears in the DTF assembly
listing, and the specification is ignored.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

17-58

Keyword Parameter LSCAN:
LSCANsymbol
Specifies the label of a letter scan table for an output paper tape file processed in
character mode (MODESTD) where symbol is the label The table which may
be assembled separately from the DTF is prepared in the form required for
operand 2 of the BAL translate and test (TRT) instruction; it must contain a 1byte entry for each 8-bit configuration that you might place in an I/O or work
area to be punched on tape. Entries in the LSCAN table corresponding to
“figures” must contain the nonzero hexadecimal code for the figure shift
character; all other must contain hexadecimal 00.
To produce output files with shifted codes in character mode (MODE=STD) you
must specify both the LSCAN keyword and the FSCAN keyword. Refer to the
foregoing paragraph for the effect of misspecifying these keywords.
Keyword Parameter TRANS:
TRANS=symbol
Specifies the label of a translation table you have coded for any paper tape file
but an input file with shifted codes, where symbol is the label. The TRANS table
may be assembled separately from the DTF and is coded in the form required for
operand 2 of the BAL translate (TR) instruction.
When the TRANS table is used for output files with shifted characters, the shift
codes are not translated, but punched automatically by data management.
Refer to i7.53 fordetails on the Use ofthe TRANS keyword with input files.
17.5.5.1. Translation for Unshifted Output Files, Either Mode (TRANS)
When your output file does not contain shifted characters, but merely requires translation
from the EBCDIC character data in your I/O or work area to the hexadecimal tape codes
you can punch in the levels or tracks that exist in your tape, your task is simpler. You
specify the TRANS keyword in the DTF and prepare a translation table that is limited to the
EBCDIC codes you will use.
Consider the following example, which assumes a 5-level paper tape and records that
contain only the 26 EBCDIC uppercase alphabet, the space, and three punctuation marks:
the period and the left and right parentheses. You will not punch out a delete character in
1 hexadecimal iF, for punching into
creating this output file, but will reserveone tape code
the tape by other means as a rub-out character and possible specification later as a
hardware or software delete when you read thisfile in future input processing. For the
null character, you set aside the hexadecimal tape code 00, as before. Your 32 available
hexadecimal tape codes extend from 00 through I F; you need onlythe first 234 decimal
positions of Table C—i to cover the EBCDIC characters through Z.

17—59

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-’8068 Rev. 4

Example:
LABEL

1OPERATiÔNi
10
16

11?Ii%IISl1.J1DS,
,,
c
1
i
2.
I
3.
11
DC
I)iC
4. I I
1
Dl
S I I I I I
C.
1
)1C
I
I
7
8. I I I I
1
DiC
I
DiC
9, I

l.....23i’.1,
1
)C

—

I I.
12
13
(4

I
I

—

.1II.....i

—

I
I
III

—

1
DiC
II

i’
..1,’
_...
L
7
l
1
l
1
O
I... I 1012.1
1
k’

—

I
I

I O3
’ 1
....ili
X
5
1
1
t3
‘L_..i I Oi1l
I
I
I I lOll
...
I
1
Y
11
I..._iI
X
1
i
O’ I Oi I
1
.)E
1

—

(‘[.191 ‘

—

i....
x
3
1
I[.._I8I

—

lOll

I
I

i
6
Ifl1
I

I
I

I51I lI

‘i

I
I

D I Ei
I iC
1I 1

111111111

III

I
I

0
O
B
0
i
C
1
D
I”4’I

I
I

112.1131 I

I 171 IJ8I I 9i

11111

I
I

..‘Il...IIIIOIIII

‘ii’nn’,

111111

OPERAND

I
I

‘

I
I

III

NOTES:
1.

You assign a 234-byte length attribute to the symbol TRANSOUT, which is
equated to the TRANS keyword in your DTF (not shown). This length attribute
covers the 13 subsequent DC statements which constitute your translation table

You insert the hexadecimal tape code 00 in the first byte of your TRANS table.
This is unnecessary for an output file (because this code represents the null
character, which you do not expect to include in an output record), unless you
intend to place a certain (fixed) number of null characters at the end of each
record in your output to indicate an interrecord gap (17 34) If you are not using
the null character in this way you would include this byte with the next 74

To the next 74 bytes, you assign the hexadecimal code 01 Note that the EBCDIC
space character SP is included in the string this code then represents the
space and is also assigned to all EBCDIC characters not used

The device constant (DC) statement assigns your next tape code, hexadecimal 02,
to the EBCDIC period

The EBCDIC less-than character is assigned the
hexadecimal 01 as the other characters to be skipped

The left parenthesis is assigned the hexadecimal tape code 03

Fifteen more EBCDIC codes, unused, are assigned the nonprint code 01.

same

nonprint

code

UP-8068 Rev 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-60

8. Here, the right parenthesis is assigned hexadecimal 04.
9

Ninety-nine more EBCDIC codes through the left brace are skipped

To the next nine bytes representing the EBCDIC alphabetic characters A through
I are assigned the hexadecimal tape codes 05 06 and so on through OD

The seven subsequent EBCDIC characters through the right brace are assigned
hexadecimal 01

These nine tape codes cover the alphabet characters J through R

Eight more skips

14 The last of the EBCDIC uppercase alphabet S through Z are assigned your
remaining hexadecimal tape codes 17 through 1E
leaving only hexadecimal
1 F for future use when a delete character is needed

17 5 6

Specifying the End-of-Record Stop Character for Output Files (EORCHAR)

When you are processing in character mode (MODE$TD) and your file contains records
with varying lengths (RECFORMUNDEF) you have need of a character to delimit these
records With output files you must specify this character with the EORCHAR keyword for
data management to punch at the end of each undefined record when you issue the PUT
macro; recall that you must also designate one general register into which you load the
length of each undefined record before you issue the macro (the RECSIZE register,
17.5.1.6).
;

The end-of-record stop character causes tape motion to stop automatically when this
chaiactêr is èhôountered while an input file óohtaining undefined records1s being read.
Recall that, for inputprocessing, you must specifythis. character by wiring the program
connector board (17 2 1 2)
For output processing the character you specify with the EORCHAR keyword may be
represented by any of the tape codes you may punch in the number of tracks on your tape
however you should not use the null character nor in fact any of the codes to which you
have assigned a special meanihg’ (sUch as the delete, or one of the shift codes). The
EORCHAR stop character must be excluded, from, translation tables,.., as it has no
translation and it must be independent of shift status therefore it must also lie outside
the range of figures and letters designated by your scan tables In fact you must take
pains to exclude the EORCHAR stop from your own outpUt’’’
For an output file data management automatically inserts the EORCHAR stop character in
your I/O area before it writes the buffer contents out to the punch; your BLKSIZE
specification must always include one extra byte for it When an undefined record is
transferred to your I/O area from an input file the EORCHAR stop character comes with
it, and the buffer space you reserve must adcommodáte this byte; hàwever, the record
length that data management places in your optional RECSIZE register does not include
the EORCHAR byte. Figures 17—2, 17—3; ànd17—4, in 17.3, illustrate these points.

17—61

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Keyword Parameter EORCHAR:
EORCHAR=expression
Specifies the end-of-record stop character used to delimit each undefined record;
required for output files processed in character mode (MODESTD) when
RECFORM=UNDEF is specified. Here, expression is either an expression of selfdefining terms or a symbol that is, equated to an expression of self-defining
terms.
Data management places the character defined with the EORCHAR keyword at
the end of each undefined output record; it is the stop character punched on tape
to delimit each undefined record.
Examples:

LABEL

AoPERATIoNt2

OPERAND
16

.X .0
1
2 iLi_

—

l—iAR.
C
)
(.
I
1
E
1
—ItAR—
C. 1
I

—:

Iii

—

iiil

—

C[Al

—

lii

I
I

liii

I
liii

iii

NOTES:
1.

Specifies that the hexadecimal tape code 03 is to be punched by data
management as the end-of-record stop character to delimit each undefined
record on tape.

Specifies that the end-of-record stop character to be punched by data
management as a delimiter after each undefined record on tape is the logical
product (AND) of the EBCDIC character P and the hexadecimal value OF (this
Works out to be hexadecimal 07).

Specifies that the end-of-record stop character is the expression of self-defining
terms equated elsewhere in your program to the symbol CHAREX. The equate
(EQU) directive for the symbol CHAREX, represented by the last line of coding in
example 3, makes this example exactly the equivalent of example 1.
Notice two points about this way of specifying the EORCHAR keyword: the coding
that contains the equate (EQU) directive must be placed outside the DTFPT call
itself, but it must be assembled with the coding that contains the DTFPT call. The
assembler does not generate an EXTRN for expression.

17.5.7.

17-62

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Specifying Optional File Processing (OPTION)

Optional file processing for paper tape input or output files is much the same as for
punched card files described in Section 3 As with cards, an optional paper tape file IS
one that your program will not invariably punch or read every time it is executed; you

notify.data management that this is the case by specifying the OPTION keyword parameter
in the DTF defining the file. The specification is simply OPTlONYES.
If you have specified the keyword, there are two circumstances that result in optional file
processing by data management:

•

You have specified the OPT positional parameter in thejob control DVC statement in
the device assignment set for the file, and the device is not available at execution
time; or
You have not provided a device assignment set (job control DVC and LFD statements)
for the file.

For details on these job control statements, refer to the job control user guide UP-8065
(current version)
This is what optional file processing of a paper tape file involves:
•

If the file is an input file the first GET imperative macro you issue to it results in an
immediate branch to your mandatory end-of-tape routine, the label of which you must
specify with the EOFADDR keyword 17.5.4). No I/O is performed; you must close the
file, using the CLOSE macro (17.4.2).

•

If it is an output file, the first PUT macro you issue results in an immediate return to
your program, at the first instruction after the PUT macro. No I/O orders are issued
by data management. if you have specified the IOREG or RECSIZE registers, data
management sets these up so that you may process in exactly the same manner as if
you were actually punching a paper tape. Again, you must close the file.

If you have not specified the OPTION keyword parameter and one of the foregoing
circumstances occurs the paper tape file is not opened by data management and may not
be processed In the error processing that ensues data management takes the following
actions:
•

Sets the error in OPEN flag bit 4 of filenameC

•

Issues error message
ASSIGNMENT”.

•

Branches to your error routine or if none is specified returns to you inline at the
first instruction after the OPEN macro you issued to the file

DM21

the

log

INVALID

MISSING

DEVICE

17-63

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

If you do not code an error routine but take an inline return, then all GET or PUT
imperative macrOs that your program issues to the file result in further data management
error processing as follows
a

Data management sets the invaild imperative macro flag, bit 6 of filenameC; and

Issues error message DM13 to the log: “ATTEMPTED ACCESS TO AN UNOPENED
FILE”.

These actions result for every issue of GET or PUT to the file. Because the file has not
been opened, you need not issue the CLOSE imperative macro to the file. For fUrther
details on filenameC and other aspects of data management’s error processing, refer to
the ERROR keyword, 17.5.9.
Keyword Parameter OPTION:
OPTION=YES.
Specifies that the input or outpUt paper tape file defined by this DTFPT
declarative macro is an “optional” file and is not required to be processed every
time the program is executed. Data management performs optional file
processing if this keyword is specified and either no device is assigned to the file,
or you have specified the OPT positional parameter in the DVC job control
statement for the file and no device is available at execution time.
If you omit the OPTION keyword parameter and one of the foregoing conditions exists,
data management does not open the file, and you may not process it. Data
management error processing results.
17!5.8.

Providing a General Register Save Area (SAVAREA)

In common with the other OS/3 data management systems, paper tape data management
requires a 72-byte area in main storage, aligned on a fullword boundary, in which to store
your general registers while it is processing.
You must align and reserve storage for this area within your program but you have two
ways of providing its address to data management: loading its address into general
1 or specifying the label of the
register 13 before entering any data management imperative
area via the SAVAREA keyword in your DTF. You need only one general register savearea
per program, but if you specify the SAVAREA keyword in one DTF, you should specify it in
all.*
*lt is possible to write a vaild program in which you preload register 13 with the address of a save area before you issue any
imperative macros to a file whose DTF does not contain the SA VAREA keyword, and also, omitting the preload of register
13, issue imperatives to another file whose DTF does contain the SA VAREA keyword. The program could work; the trick
might be (in a large program processing numerous files) to be sure which file required which coding. You could not open all
and you might
files with the same OPEN macro, for example, in such a program, nor terminate them all with one CLOSE
be hampered in your use of register 13 for the IOREG or RECSIZE register.
—

17-64

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev:4

When you specify the label of the general register save area with this keyword, you free
register 13 for your own use and may, for example, use it for your IOREG or RECSIZE
register (17.5.1.4 or 17.5.1.6); otherwise, only registers 2 through 12 are yours. Refer to
1.4 for the content and layout of the save area, which is useful to examine in program
dumps or snaps. Note that register 13 is not included, however: if you want to. see its
contents in a snap, you must provide and load a specific storage area for them.
If the SAVAREA keyword is not present in the DTFPT declarative macro, data management
assumes that you have preloaded register 13 with the address of a fullword-aligned, 72byte general register save area before you issue any Imperatives If you have a BAL
program therefore written for some other data management system (such as the
9200/9300) in which you are using register 13 for your own purposes you may easily
convert it to run under OS/3. You need merely add a 72-byte register save area, fullword
aligned, to your program and specify its label to data management with the SAVAREA
keyword.
.

Because the assembler, in expanding your DTFPT declarative macro, generates an EXTRN
pseudo-op for each symbolic label specified via the keywords in the DTF, you may
assemble.the coding by which you define the register save area separately from the coding
in which you define the file.
.

Keyword Parameter SAVAREA:
SAVAR EA=symbol
Specifies the label of an area defined in main storage, füllword aligned and 72
bytes in length in which data management stores the contents of your user
general registers while it is processing,. where symbol is the label.
Only one such area is required per program, but if you specify the SAVAREA
keyword in one DTF, you.shóuld specify it in the DTF for. every, file your program
accesses.
.lf the SAVAREA keyword is omitted, data management expects that; before you issue
any imperative macro to a file, you have preloaded register .13 with the address of a
72-byte storage area, fullword aligned, in which it saves the contents of your general
registers
If you specify the SAVAREA keyword register 1 3 is available for your own uses
however, its cohtents:are not included in the general register save area for .ihspection
in a snap or dump of your program. Refer to 1.4 for the layout and’content of this
area.

UP-8068 Rev.4

17.5.9.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-65:

Data Management Error Processing, Paper Tape Files (ERROR)

When data management detects an error (hardware software or logical) it sets one or
more bits in the error flag byte of your DTF file table issues the appropriate numbered
data management error message to the log; and branches to your error routine. If you
have not coded a routine for error processing and specified its label to data management
with the ERROR keyword parameter control returns to you at the normal inline return
point the next instruction after the imperative macro just issued This is the point to
which data management would have transferred control if no error had occurred
When data management branches to your error routine register 14 contains the address
of the normal return point to which you may branch after you have completed error
processing to resume processing your file However if you intend to issue GET or PUT
imperative macros in your error routine you must first store the contents of register 14
and-then, having issued all your imperatives, restore register 14 to- its initial value before
you branch back to your program
The error flag byte is decimal byte 50 in the file table generated by the assembler in its
expansion of your DTFPT declarative macro the assembler also generates an EXTRN
pseudo-op for this byte, assigning it a label that is formed by concatenating the EBCDIC
character C to your 7-byte logical file name
which is why it is called filenameC If you
want to examine it to see what bits were set you can easily locate filenameC in a dump of
your program area because its address is contained in the allocation map and definitions
dictionary produced by the linkage editor or you can include filenameC in a snap taken by
your error routihé; however, it is more useful to access it dynamically. You may do so
inline or from your error routine, using the label of the error flag byte as the first operand
of a BAL test under mask (TM) instruction, for example, to determine which bits were set
so that you may take appropriate action.
—

Each of the eight bits in filenameC has a special significance when set to binary 1 as an
error flag Table 17—2 summarizes these meanings The subsequent paragraphs discuss
the errors represented in more detail, with actions you should consider taking in your error
routine or elsewhere.

Significance of Bits in FilenameC, Paper Tape Files

Table 1 7—2.

Hexadecimal
if Set Alone

Bit

0
.

Binary if
Set Alone

Significance for DTFPT File

10000000

DTF error

01000000

Wrong length error

0010 0000

Unique (parity) error

0001 0000

Unrecoverable error

0000 1000

Error detected in OPEN

0000 0100

Error detected in CLOSE

0000 0010

Invalid imperative macro

Other
Bits
Set
4

—

0000 0001

Invalid record size

Data Management Error Messages
Issued to Log
DM61:

INVALID DTFFIELD, PARAMETER,
OR PARAMETER COMBINATION

DM25:

WRONG LENGTH ERROR
DETECTED
(None)

—

DM23

(None)

—

UNRECOVERABLE I/O ERROR

(None)

—

17-66

SPERRY UNIVAC OS/3
BASICDATA MANAGEMENT

UP-8068 Rev. 4

DM13:

ATTEMPTED ACCESS TO AN
UNOPENED FILE, or:

DM14

INVALIDIMPERATIVEMACRO/
MACRO SEQUENCE

DM17

INVALID BLOCKSIZE SPECIFIED
or:

DM18:

RECORDSIZE INVALID

NOTES:
The “Other Bits Set” column shows only those bits invariably set by data management. Others may also be set, for example, to
indicate which errors are detected during OPEN or CLOSE processing.

Bit 4 is always set when bit 0 is set. The resulting binary configuration of filenameC is 1000 1000, and the byte then contains the
hexadecimal value 88

When bit 4 is set with bit 7, the resulting binary configuration is 0000 1001, and fi/enameC contains the hexadecimal value 09.
When an unrecoverable error is detected during OPEN processing, bit 4 is also set with bit 3, and fi/enameC contains the
hexadecimal value 18. When detected during CLOSE processing, bit 5 is also set with bit 3; fi/enameC contains hexadecimal 14.

•

DTF error (bit 0)

This bit is set by the OPEN transient overlay to indicate that a serious error has been
detected in your DTF. Data management also issues error message DM61. The error
detected in OPEN flag (bit 4) will also be set to binary 1. Your file is not marked open
and cannot be processed.
The DTF error bit is set when you have not properly specified the BLKSIZE keyword
parameter (17.5.1.3), have omitted the EOFADDR keyword for an input file (17.5.4),
have omitted the IOAREA1 keyword (17.5.1.4), or have specified an invalid address in
the DTF (that is, some label or symbolic address specified in your DTF is an invalid
in this case one that is not within your job region).
address
—

You should check your DTF assembly listing for error flag messages and your linkage
editor map for unresolved EXTRN symbols.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

•

17-67

Wrong length error (bit 1)
This bit is set for input files with undefined ;(variable length) records; it indicates that
data management has filled the I/O buffer with the number of :bytesspecified by your
BLKSIZE specification (shift codes having been removed), but that the hardware has
not detected the wired end-of-record stop character that delimits each undefined
record.
The wrong length error flag is also set for fixed, unblocked input files if the last record
on the tape is not a full-sized record (that is, the number of bytes of data yielded by
the final record, stripped of shift characters and deletes, must equal your BLKSIZE
specification, or you will receive a wrong length error indication).
Data management issues error message DM25 in either case. You may either stop
processing and close your file, or process the assumed partial record and. then,
issuing another GET macro branch to. the norma[ return point to continue processing
(remembering to store and restore register 14 as required).

•

Unique (parity) error (bit 2)
When a parity error is detected in reading an input, paper tape, the physical IOCS
issues a standard message to the operator, describing and locating the error. The
operator is able to move the paper tape back to the beginning of the record and to
retry the command; if the retry is successful, data management does not perform the
error processing set forth here. If the retry effort fails, however, you may have
recourse to further recovery attempts, as fOllows.
The unique (parity) error bit is set only for input files, processed in character mode
(MODESTD); the file must have been created with a parity track punchedon the
tape, and the paper tape subsystem must have been set up (using the program
connector board) to check the parity track for odd or even parity.
Set to binary 1, this bit indicates detection of a parity error in one or more characters
on tape. Furthermore, each character on which a parity error has been detected has
its most significant bit set to binary 1 in main storage. Your options depend on
whether your data contains shifted codes.
For files with unshifted data, you have three courses open to you in your error
routine:
—

—

You may stop processing records and close the file.
You may continue processing the record bybranching to the normal return point,
at the address contained in register 14.
You may store register 14 and isue another GET macro to skip the record
containing bad parity and read in the next. lfthe next record is free of parity
errors, you can restore register 14 and branch to the normal return point to
resume the processing that was interrupted by the initial detection of parity
error. On the other hand, of course, errors detected in the execution of your
second GET macro will result in another branch to your error routine.

UP-8068 Rev:4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-68

When parity errors are detected on files with shifted characters, however, your
recovery action is somewhat different. Data management does not perform shift
processing on the record, but leaves it in the I/O area. (Even though you may have
specified work area processing, the record is not moved to your work area.) Its shift
norare the intervening characters
codes are not remOved,:nor the software deletes
translated. Unless you want to stop processing and close the file, you must deal with
the erroneous record in your error routine; to skip this record is risky at best, because
the shift status is likely to be masked by the parity error, and your subsequent records
cannot be assured of being processed correctly
—

1f you have specified an l/O indexregister with the JOREG keyword (17.5.1.4), you
can locate the errorrecordbyreferring to this register On the other hand, if you have
specified more than one I/O buffer but do not have an IOREG register, you may refer
to: the address of. the error record that is contained in filenameD, a 4-byte field,
fullword aligned, and addressed by concatenating the EBCDIC character “D” to your
:7-byte file name. Do not modify the contents of filenameD.
After locating each character of the record that has a parity error and resetting its
most significant bit to binary 0, you may perform the character shifting in your error
routine, removing the shift codes and translating the characters between them as
required. You should compress the record and leave: it left-justified in the I/O area,
or; if you have specified work area processing, you must yourself move the record to
your work area(17.5.1:4)
You will use your SCAN table as operand 2 of the BAL translate and test (TRT)
instruction, and your FTRANS and LTRANS tables as operand 2 of the translate (TR)
instruction; refer to 17.5.3 for details on the use of these tables and instructions by
data management. Remember also to take care of removing any of the software
delete characters you may encounter in your error record.

Unrecoverable error (bit 3)
This bit, when set to binary 1, indicates that an unrecoverable hardware or software
error has been detected. In most instances, the physical IOCS issues a message to
:the operator, such :as “DEVICE XXX STOP STATE RU?’. This message indicates that
the paper tape subsystem is in the stop state. If the. operator replies “U” to this
message, data management branches to your error routine with the unrecoverable
error bit set and issues error rnessges DM23 to the log. Under certain conditions, the
error detected in OPEN or error detected in CLOSE bit (4 or 5) may also be set.
Error detected in OPEN (bit 4)
Thisbit issetwhenanyerrors are detected duringthe processing performed by the
OPEN transients (17.4.1). The file is not opened, and you may not issue any
imperative macros to process it. In your error routine, you should not attempt any
further processing of the file and should terminate your program. Itis not necessary
to issue a CLOSE macro to the file.

UP-8O68 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATAMANAGEMENT

1 7-69

Other bits may be set withthis bit to indicate which error was detected. For exaniple,
if you have an invalid DTF, this is detected during OPEN processing, and both bit 0
and bit 4 are set; data management issues errOr message. DM6’L Or, ifyour
specification of the BLKSIZE:orOYBLKSZ keyword is nota positivedécimal number in
the range 1 through 4095 (or the OVBLKSZ specification does not exceed block size)
the OPEN transient issues error message DM17, INVALID BLGCKSIZE SPECIFIED,
and sets both bit 7 and bit 4. Again, if the error detected by the OPEN transient is
unrecoverable, data management issues error message DM23 and sets both bit 3 and
bit 4. Finally, for the cirumstances under which the error in OPEN bitis setfor an
optional file, refer to the OPTION keyword, 17.5.7.
If you have not coded and specified the ERROR routine, but accept error returns
inline, data management expects that you will check for errors and deal with them
inline. When you do not do so, therefore, each imperative macro your program issues
to process an unopened file results in further data management error processing. Thi
includes setting the invalid imperative macro flag (bit 6)
.

Error detectedin CLOSE (bit 5)
This bit is set when errors are detected during the processing performed by the
CLOSE transients (17.4.2). Other bits may also be set to indicate which errOr was
dOtectOd: for example, bit :3 if the error is unrecoverable
CLOSE processing is completed, and you may reopen the file.

•

Invalid imperative macro (bit 6)
This bit is set to indicate that you have issued an inappropriate imperative macro to
process your file (for example, the GET macro to an output file, or a CNTRL macro,
whibh does not exist in OS/3 paper tapedata management). In this circumstance,
data management also issuesèrror message DM14, “INVAL[D MACRO/MACRO
SEQUENCE” to the log.
This bit is also set if you issue any imperative macro except OPEN to an unopened file
including One that could not be opened because of an invalid DTF or because of
some other error detected during your OPEN processing In this case, data
management issues error message DM13, “ATTEMPTED ACCESS TO AN UNOPENED
FILE”.

•

Invalid record size (bit 7)
This bit is set only when you are processing an output paper tapefile thatcontains
undefined records (RECFORMUNDEF); it indicates that the number you have placed
in the mandatory RECSIZE register(17.5.1.6) is negative,zero, or larger thanyour
BLKSIZE specification minus one byte (BLKSIZE-1) Data management does not punch
the record on tape. If this bit is set, data management also issues error message
DM18, “RECORD SIZE INVALID”. Your error routine should cease processing and
close the file.

UP-8068 Rev. 4

17.5.10.

17-70

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Processing ASCII Paper Tapes (SCAN, TRANS)

In OS/3, neither the physical IOCS nor paper tape data managementprovides automatic
translation facilities. How data comes in from paper tape and is. represented in main
storage (and vice versa) are determined solely by the way you set up your program
connector board and by the hole patterns on the tape. A hole on the paper tape always
corresponds to some bit in main storage.
On the other hard, translation of data, via translation tables that you supply, is always
possible for every type of file, be it input or output, binary ornonbinary, with or without
shifted characters. If you need to read a paper tape that has been punched in ASCII, or to
punch ASCII characters on tape, you must provide the proper translation tables in your
program.
The ASCII code is specified in American National Standard Code for Information
Interchange, X3.4—1968, and is a 128-character, 7-bit code. Another standard, American
National Standard Perforated Tape Code for Informat/on Interchange, X3. 30—1971,
specifies the representation of ASCII in perforated tape. The perforations are arranged in
eight longitudinal tracks, one for each of the seven information levels, and one for parity.
The bits of ASCII are assigned to specific tracks, and the ASCII character represented by
each 8-bit pattern is related to its corresponding column and row position in ASCII The
parity bit is always recorded on the number 8 track, and provides an even number of holes
for each character.
Figure 17—11, adapted from a figure in the standard, depicts a portion of an 8-track paper
no punches
tape on which have been punched a number of ASCII null characters (NUL
except the feed, or sprocket hole), the 10 ASCII numerical characters, and the ASCII delete
character (DEL). Therectangles above the diagram of the tape itself relate the standard
hole patterns punched in the tape to the ASCII character positions in the columns and
rows of the standard: the ASCII DEL character, for example, occupies column 7, row 15;
the ASCII numeral 9 occupies column 3, row 9. (There is not shown in these rectangles
the column/row position (0/0) that is occupied by the ASCII null character, NUL, because
there are seven of these punched in the tape in the figure.)
—

The following example, showing how you might code a translation table and a scan table
to read an ASCII paper tape in OS/3, using data management, assumes that:
R

Your ASCII input file is processed in binary mode, and the contents of its records are
limited to the ten ASCII numerical characters and the ASCII space character.

•

These eleven ASCII characters are to be translated into the corresponding EBCDIC
characters for your processing in OS/3.

•

The tape also contains the ASCII NUL character and the standard delete character,
DEL (Recall that in binary mode you must specify this as a software delete )

UP-8068 Rev. 4

•

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-71

The hexadecimal representations in main storage of the 13 codes punched on the
ASCII tape are the following:
Hexadecimal

ASCII Character

NUL

DEL
Column:

Row:
ASCII numerical
characteru

•

bi
b2
b3
FEED

•

b4
b5
b6

••••

•

.
••
••••

••

•

••

•

ASCII bit number

••

•

••

DEL

•

•
•
•

•

••
••••••••••
••••••••••

b7
CHECK

I
l

.+—ASCII delete
character

••••

•
•
•
•
•

2
3
FEED
4
5
6

Paper tape track number

Figure 17—11 Portion of ASCII Punched Paper Tape Showing Correspondence
Between Hole Patterns and the Bits of the ASCII Code

17-72

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev 4

ExampIe:
LABEL

COMMENTS

OPERAND

AOPERATIONt

=16

1. LLiiL

E’PFLE= :LNiP&,,

-_-

ER=Aè ANCLL,

CAN DEL7F,

Xi,,

..j.._..._J_._....
-

2. rlRANLJJJ
3

__I
-

)1CLJL

._.____.__.
.i_C
1
7

J---LLJ----L

LLLL4i
I...II5IOO

1E5EEZEBE$L±

JLLOLJQJELLFiZE3

)iLJ

(1L6LJQLLL

LLL
JLJ_L

1CL

LLLLLJ

LLLLLi_L

LL
L-_11111

111111

8 E,L7
EL
1

Li312LJQ

j_LJjijL
Lii

JLLJLJJL
JL

IIIIIIIIIIIIIIiiiIIIItII

2i
)i&

LLLIL
jLLj

CLLl

III

NOTES
1.

This is part of your DTFPT declarative macro, defining an input paper tape file,
INASCII, processed in binary mode. Required keyword parameters not relevant to
the example are not shown.

This is the define storage (DS) statement, coded elsewhere in your program, by
which you assign a 1 27-byte length attribute- to the symbol TRANSCII. Because
you have equated this symbol to the TRANS keyword parameter in your DTF,
data management recognizes the following define constant (DC) statements as
constituting your translation table for this file. The table need not be 128 bytes
long, even though this is the length of the ASCII code, because the 128th
character (hexadecimal 7F) is the standard ASCII delete, which you must specify
as a “software delete” to data management, via the SCAN table. Data
management will delete this character before translation.

In the the first 32 byte positions of your translation table, you insert the
hexadecimal value 00. This is the common code for both the EBCDIC and the
ASCII null characters, but note that this statement also substitutes the EBCDIC
null for each ASCII character in the remaining 31 of the first 32 positions in
Table C—i. None of these is expected in your input data, and you have no
translations for them. You might instead have substituted the EBCDIC space
but not the delete because deletion precedes translation

—

You substitute the hexadecimal value 40, which represents the EBCDIC space,
for the ASC1L space characters, occupying :decimaLposition 32 (hexadecimal 20)
in Table C—i.
-

The next 15 bytes of your TRANS table are also filled with the hexadecimal value
00 nullifying any unexpected ASCII maverick codes between the SP character
and the first of the ASCII humerals.

UP-8068 Rev[4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-73

Here you substitute ten EBCDIC hexadecimal values, FO, F1,F2, and so on, for
the hexadecimal values expected in your input data for the ten ASCII numeral
characters

Therernainder of the ASCIIcodes should not appear in your input dataand are
hence nullified
except 7F, the standard ASCII delete, which you provide for in
the following scan table.
—

This define storage (DS) statement assigns a 128-byte length attribute to the
symbol DEL7F, which you have equated to the SCAN keyword parameter in your
DTF. Data management recognizes the next two DC statements as your SCAN
table for the input file INASCII. This table must be 128 bytes long to inàludé all
128 characters of ASCII.

You insert the hexadecimal value 00 in the first 127:bytes of this table. Here,
this value has nothing to do with the ASCII NUL character it ensures that a zero
result-byte is encountered by data management when any of the hexadecimal
values in the first 127 positions of Table C—i is read in your input data, and the
data is submitted to the BAL translate and test (TRT) instruction. Any of these
127 characters occurring in your input data is eligible for translation, using your
table TRANSCII.

10 This statement inserts the hexadecimal value OC in the 128th byte of your scan
the standard ASCII delete character, hexadecimal 7F, is encountered
in your data, the result-byte data management accesses in the scan table
contains this nonzero value. The character 7F is therefore not translated; instead,
data management deletes it before testing your next byte of input data and thus
“compresses” your record:
: *
17 6

COMPARISON OF OS/3 WITH OTHER PAPER TAPE SYSTEMS

The OS/3 paper tape data management system is comparable with the paper tape
systems in SPERRY UNIVAC Operating System/4 (OS/4) data management, SPERRY
UNIVAC 9200/9300 Series Operating System IOCS; and the IBM System/360 Disk
Operating System (DOS). The following paragraphs discuss areas of compatibility.
17.6.1.

Compatibility with OS/4

OS/3 paper tape data management is compatible with the OS/4 paper tape system
documented in the OS/4 data management system programmer reference, UP-7629
(current version). The maximum block sizes of the two systems are the same: 4095 bytes.
The OS/4 ERRO keyword parameter is accepted by OS/3, but it is not implemented. All
OS/4 keyword spellings are accepted as alternates by the OS/3 DTFPT declarative macro.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

176.2.

17-74

Compatibility with the 9200/9300 SeriEs

All 9200/9300 Series DTFPT keywords, as documented in the operating system IOCS
programmer reference, UP-7526 (current version), are accepted by the OS/3 DTFPT
declarative macro. Of these, the following are accepted but nOt implemented; the
remainder are implemented:
AUN
CHNL
DEVA
FIGS
LTRS
Moreover, you should note that the 9200/9300 Series letter/figureshifting capability is
not supported for input files by OS/3. To run 9200/9300 Series paper tape programs that
process input files with shifted characters, you should remove the FIGS and LTRS
keywords from the DTFPT declarative macro call, substituting the FTRANS, LTRANS, and
SCAN keyword parameters and providing the necessary figure and letter translation tables
and scan table elsewhere in your program.
Another point of difference is maximum block size. OS/3 allows 4095 bytes; the
9200/9300 Series allows only 256. Paper tape files created under the 9200/9300 paper
tape data management system may be processed under OS/3; whether these should be
restructured, or existing programs modified to exploit OS/3’s 4095-byte maximum block
size, are matters of judging the trade-offs between increased throughput and the
programming effort involved.
A fourth point of difference is that OS/3 has no combined paper tape file capability. To
punch a paper tape and then read the tape for error checking in OS/3, you should code
two DTFPT declarative macros (one for input processing, one for output, using different file
names) and should specify two separate job céntrol DVC-LFD device assignment sets (one
for each DTF).
17.6.3.

Compatibility with IBM System/360 DOS

The OS/3 DTFPT declarative macro accepts all System/360 DTFPT keyword parameters
documented in IBM Systems Reference Library: DOS Supervisor and I/O Macros, Twelfth
Edition (February 1972), Order No. GC24-5037-1 1. Of these keywords, the following are
accepted but not implemented in OS/3:
DELCHAR
DEVADDR
DEVlCE
ERROPT
MODNAME
SEPASM
WLRERR

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

17-75

A second point of difference is maximum block size. IBM System/360 DOS provides
32,767 bytes; OS/3 allows 4095. Paper tape files containing fixed, unblocked records
larger than 4095 bytes, or undefined records larger than 4094 bytes, must be restructured
to be processed in OS/3, and existing programs exploiting the larger IBM maximum block
size must be modified.
A third point of difference is that, unlike IBM System/360 DOS, OS/3 paper tape data
management does not provide for skipping over strings of consecutive end-of-record stop
characters without intervening data when processing input files containing undefined
records.

(

Cl)

-v
-v
m

—I

-v

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Appendix A.

A-i

Functional Characteristics
of Peripheral Devices

The tables in this appendix summarize the functional characteristics of the peripheral
hardware available in the SPERRY UNIVAC Series 90 Data Processing Systems that are
relevant to OS/3 data management usage.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table A—i.

SPERRY UNIVAC Card Reader Subsystems Characteristics (Part 1 of 2)
0717 Card Reader Subsystem
Description

Characteristic
Card orientation
(80-, 66-, and 51-column cards)

Face in, with áolumn 1 leading, and row 9 down

Card rate

500 cpm (maximum)

Read technique

Dual redundant, solar cell technique using photo transistors,
COlumn 0 amplifier checking

Read modes

Image mode: 160 six-bit characters per card
Translate mode: 80 characters per card
Available code: 8-bit EBCDIC

Read station sensing

Column by column

Hopper capacity

2400 cards

Stacker capacity

2000 cards
0716 Card Reader Subsystem

Card orientation
(80-, 66-, and 51-column cards)

Face in, with column 1 leading and row 9 down

Card rate

1000 cpm

Read technique

Dual redundant, solar cell technique
using photo transistors.
Column 0 amplifier checking

Read modes

Image mode

—

Translate mode

160 six-bit characters per card
—

80 characters per card

Three available codes:
•
•
•

8-bit ASCII
8-bit EBCDIC (required)
Compressed code

Read station sensing

Column by column

Hopper capacity

2400 cards

Stacker capacity
Normal (stacker 2)
Reject (stacker 1)

2000 cards
2000 cards
0719 Card Reader Subsystem

Card orientation
(80-, 66-. and 51-column cards)

Face down, column 1 to left and row 9
facing away

Card rate

300 cpm

Read technique

Two columns of photosensitive sensors and
light-emitting diodes
Dual redundant.
Column amplifier checking

A-2

UP-8068 Rev.4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table A—1.

SPERRY UNIVAC Card Reader Subsystems Characteristics (‘Pàrt2 of 2,)
0719 Card Reader Subsystem

Characteristic

Description

Read modes

Image mode: 160 six-bit characters per card
Translat mode; 80 characters per card

Read station sensing

Column by column

Hopper capacity

1000 cards

Stacker capacity
Normal
Reject

1000 cards

Table A—Z SPERRY UNIVAC Card Punch Subsystems Characteristics (Part 1 of 2)
0605 Card Punch Subsystem
Characteristic

Description

Media

80-column cards

Punch mode

2-column serial

Check mode

Punch motion check

Feed mode

On demand

Punch rate

75 cpm (full card)
160 cpm (28 columns only)

Input capacity

700 cards

Output capacity

700 cards (primary stacker)
100 cards (reject stacker)

Reading

Optional

Read rate

160 cprñ

Punch translation
Image mode
Translate mode
Available code: EBCDIC

160 six-bit characters per card
80 characters per card
0604

Card Punch Subsystem

Media

80-column cards

Punch mode

Row

Check mode

Read of punched data

Feed mode

On demand

Punch rate

250 cpm

Input hopper capacity

1000 cards

A-3

A-4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table A—2. SPERRY UNIVAC Card Punch Subsystems Characteristics (Part 2 of 2)
0604 Card Punch Subsystem
Description

Characteristic
Output stacker capacity

1000 cards (normal and select stacker)

Reading

Optional

Read rate

250 cpm

Punch translation
Image mode
Compressed mode

160 six-bit characters per card
80 characters per card

Table A—3.

SPERRY UNIVAC Printer Subsystems Characteristics (Part 1 of 5)

0773 Printer Subsystem
Description

Characteristic

110 to 680 1pm, depending on character contingencies:

Print speed

Line advance
timing

Number of print
positions

Nominal print rate (1pm)

Available character sets

Characters sets per band

48-character business
63-characterprint
48/16-character print
85-character print
128-character special
961(16-16)-character
ASCII
256-character special

5
4
4
3 (plus 1 character)
2

500
400
400/670
310
217

2
1

217/500
114

875 ms for spacing
first line; for
skipping each
subsequent line:
3.33 ms at 6 Ipi
2.50 ms at 8 Ipi

8.75 ms for spacing
first line; for
skipping each
subsequent line:
2.22 ms at 6 Ipi
1.67 ms at 8 Ipi

8.75 ms for spacing
first line; for
skipping each
subsequent line:
1.67 ms at 6 lpi
1.25 ms at 8 lpi

120 print positions (columns) by standard printer; 132 or 144 columns
by feature

Form advance
control

Vertical format buffer

Line advance
rate

Single space only, 22 inches/second

Form dimensions

3 to 18.75 inches wide
1 to 24 inches long

Character set

Standard 48-character set. Any number of characters, up to 256, with
options.

Horizontal spacing

10 characters per inch

Vertical spacing

6 or 8 lines per inch, operator-selectable

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

A-5

Table A—3. SPERRY UNiVAC Printer Subsystems Characteristics (Part 2 of 51

0770 Printer Subsystem
Characteristic

Description

Print speed

0770—00

0770—02

112to14351prn,
depending on character
contingencies

213to2320lpm,
depending on character
contingencies

337to30001pm,
depending on character
contingencies

112 1pm 384 contiguous
characters

213 1pm 384 contiguous
characters

337 1pm 384 contiguous
characters

800 1pm 48 contiguous
characters

1400 1pm
characters

48 contiguous

2000 1pm
characters

1435 1pm
characters

2320 1pm
characters

24 contiguous

3000 1pm
characters

—

Line advance timing

—

24 contiguous

—

Advance and print
6lpi

1 line
2 lines
3lines
n+1 line
Number of print positions

0770—04

—

Time in ms
8lpi

120.0
127.6
135.2
120+7.6n

118.0
123.7
129.4
118+5.7n

Full print width of 132 print positions placed anywhere on a 16.5inch form. With 22-inch form, only central 13.2-inch portion can be
used (160 print positions with feature).

Form advance control

Vertical format buffer

Line advance rate

50 ips

Form dimensions

Continuous forms with standard edge sprocket-holes from 4 to 22 inches
in width. Carbons may be attached or unattached with multicopy forms to
a maximum of six parts. Recommended pack thickness not to exceed .0155
inch for high quality print.

Character set

Standard 48-character set. Any number of characters up to 384 with
options.

Horizontal spacing

10 characters per inch

Vertical spacing

6 or 8 lines per inch, as determined by program

75 ips

100 ips

—

48 contiguous

24 contiguous

A-6

SPERRY UNIVAC OS/3
BASIC DATAMANAGEMElT

UP—8068 Rev. 4

Table A—3. SPERRY UNIVAC Printer Subsystems Chàracteritlcs (Part 3 of 5)

0768 PrinterSubsystem
Description

Characteristic

900through 1100 1pm

0768—99

0768—02

0768—00

Print speed

84othrough 2000 1pm

i200through 1600 1pm

Line advance
timing

11.5 + 5.1 (n—i) ms —6 linesper inch
11.5+5.7 (n—i) ms—B lines per inch
where: n numberoflinesadvanced

Number of print positions

132 character print positions including spaces

Form advance control

Vertical format buffer and loopcontrol; up to 132 lines per command

Lineadvaricerate

25 ip

FOrmdirñènsions

4to22incheswide
1 to22 inches long

Character set

0768—00
0768—02
0768—99

63
94 characters
132 characters

Horizontal spacing

10 characters per inch

Vertical spacing

6 to 8 lines per inch

UP-8068 Rev. 4

SPERRY UNIVACOS/3.
BASIC DATA MANAGEMENT

Table A—3.

SPERRY UNIVAC Printer Subsystems Characteristics (Part 4 of 5)
0776 Printer Subsystem

---.

Characteristic

Description

Print speed

A-7

AvaiIable.
character
sets

384
192
128
96
64
48
32
24

Charactersets per
band
1
2
3
4
6
8
12
16

Nominal print rate (1pm)

0776—00; 01
115
225
325
420
600
760
1030
1090*

0776—02
150
290
420
540
750
940
1250*
1250*

0776—03
145
280
400
520
730
900
1220
1250*

*For duty cycle reasons, maximum speed
in 1pm is limited by a minimum time
between consecutive line feeds: 55 ms
for the 0776—00, 01. and 48 ms for the
0776—02, 03.
Time in ms
-

Advance and print

Line advance timing

6 Ipi

Number of print positions

1 line
2 lines
3lines
4 lines
5linês
n+1lies

Vertical format buffer

Line advance rate

22 inches/second

16
14.2
23.6
19.9
31.2
25.6
38.8
31.3
46.4
37T6+7.6h142+5.7n

i36 print positiohs including spaces

Form advance control

Form dimensions

8 lpi

4 to 18;75 inches wide
1 to 24 inches long

Character set

Standard 48-character set. Any number of characters up to
384 with options

Horizontal spacing

10 characters per inäh

Vertical spacing

6 or 8 lines per inch as determined by program

SPERRY UNIVAC O/
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table A—3.

M-O

SPERRY UNIVAC Printer Subsystems characteristics (Part 5 of 51
0778 Printer SUbstei
Description

Characteristic
Print speed

240 to 560 1pm, depending on character contingencies, at 6 lines per inch (Ipi)
(2 36 lines per cm) and single line spacing
Available character sets

Nominal print rate (1pm)
Basic
00/01

Speed Upgrade
02/03

48-character business

300

510

64-character print

240

415

48/16characterprint*

240/255

41 5/560

1 28-character print

120

240

335-character print*
Line advance t(ming
(in milliseconds)

Nuñ,ber
of lines

6 Ipi (2.36 lpcm)

8 lpi (3.15 lpcm)

single

35 ms

double

53 ms

51 ms

triple

61 ms

57 ms

Number of print positions

120 print positions (columns) per line; 136 columns by feature.

Number of characters

Standard. 48- or 64-character set, with five sets on a 240-character
band; or up to 256 characters with expanded character set control feature;
48-character set band repeats five times resulting in 240 characters;
64-character set band repeats fpur times resulting in 256 characters.

Forms advance control

Vertical format buffer

Line advance rate

Single space only, 22 inches (55.88 cm) per second (slew rate).

Ribbon feed

Bidirectional, self-reversing; ribbon removal without rewinding

Ribbon type

Fabric or plastic film

Codes

EBCDIC, ASCII, or any 8-bit code

Form dimensions

Continuous single part and multipart (up to six parts or up
to 0.018 inch (0.457 mm) thick) with standard edge sprocket holes. Printer
can also accept continuously spröcketed, 1 -part card stock forms àf
weights typically used for punch cards, postcards, or offset masters. Form
widths from 4.0 inches (101.60 mm) to 18.75 inches (476.2 mm) and lengths
up to 24 inches (609.6 mm) can be accommodated. Forms longer than 17 inches
(431.8 mm) can be run with casework door open, but noise level increases with
door open.

Horizontal spacing

10 charcters per inch (2.54 mm per print position)

Vertical spacing

6 Ipi (4.23 mm per line) or 8 Ipi (3.17 mm per line),
operator-selectable.

*The ‘16’ array is commonly a numeric subset. Extra 16 arrays are included in the 96/16—16 arrangement to
make up a total number of 256 characters in a band.

370 tracks per inch

10,240

192 tracks per inch

10,240
404 + 7 spare
usable tracks per
disc surface
Data 7
PsI

370 fixed
185 removable
i0,240
808+7 spare tracks
404+4 spare tracks

Data 3
gifed
P 1
Data 2 removable

200 tracks per inch

7294
200 + 3 spare
usable tracks per
disc surface
20

48 track per inch

3,328 bytes per track
77 total, 73 for data
use per disc surface

1 surface

100 tracks per inch
(free format)

3625

200 + 3 spare
usable tracks per
disc surface

Track density

Track capacity (byte)

Number of tracks

Number of surfaces per
I
dk

2200 ppi

4040 ppi

4040 pulses
per inch )ppi)

4040 fioed
4040 removable

2200 ppi

3268 ppi

1100 ppi

Bit density

sectors per track

1n fixed 256-byte

sectors,

156 kilobytes per
second

25 mx
75 ms
135 m

Transfer rate

Positioning time (seek time)
Minimum
Average
Ma m m

0 1

128 bytes in < 6ms

—‘

83.33 ms

—

25 MH

2 5 MR

50 MR

50 MH

50 MR

25 MR

250 MH

1 25 MR

Data 7
Post n gi

lOws
27 ms
45 ms
628 kilobytes per
second

lOws
30 ms
60 m
625 kilobytes per
second

10 ms
33 ms
60 mx
625 kilobytes per
second

312 kilobytes per
second

806 kilobytes per
second-

7,5 ms -----7 ms-27 ms
29 ms
50 ms
55 ms

806 kilobytes per
second

lOws
30 ms
55 mx

400 + 6 spare
usable tracks per
surface

404 or 808+7 spare
usable tracks per
disc surface

808 + 7 spare
tracks per disc
surface

404 + 7 spare
usable, tracks per
disc surface

--10 mx
30 ms
55 mx

13,030
13030
7294

7294

370 tracks per inch
192 tracks per inch
400 tracks per inch

400 tracks per inch

4040 ppi
4040 ppi
2200 ppi

3600 pm

1 t 8 (with opt
feature up to 16)

16.7

200 million

645 MH

3600 pm

1 tO 8 (WIth optlO
feature up to 16)

100 million

8433
Disk Subsystem

645 MR

8430
Disk Subsystem

16.7

25 ms
60 ms
130 m

2400 pm

2 1

2400 pm

21.5

1 1

2800 pm

21.5

2800 rpm

1 t

21.5

2800 pm

1 t

7.25 million

2400 rpm

Flotation period (ms/rotation)

speed

f d 5k U

0 s /d sk tt

Numb

Data capacity (8-bit bytes)

166.7

58.35 million

8425
Disk Subsystem

360 pm

2 1

2 t

58.35 million

8424
Disk Subsystem

28.9 million or
57.9 million

8418
Disk Subsystem

Description

28.95 million

8416
Disk Subsystem

2400 pm

33.1 million per track

8415
Disk Subsystem

2 1

8414
Disk Subsystem

2 to 4

8413
Diskette Subsystem
29.17 million

8411
Disk Subsystem

SPERRY UNIVAC Disk Subsystems Characteristics

242,944 bytes (using
tracks 1—73 for data)

Characteristic

Table A—4.

2mm
Optional

Optional

3mm

Simultaneous operation

Rewindtime

10 mx

25 mx
-

Optional

1mm

16 mx
--

Phase encoded

NRZ1

Phase
encoded

NRZI

Reversal time...

Phase
encoded

Recording mode

1600 ppi

800 ppi

1600 ppi
800 ppi

800ppi
556 ppi
200 P0!

1600 ppi
800 pp

Pulse density

3.0 mx..
5.0 mx

6.25
9.25

SO ms
80 ms

17:6 mx
23.6 mx

14.1 mx
20 1 ms

Optional

3mm

25 ins

NRZI

800 ppi

14.1 mx
20.1 mx

800 ppi
556 ppi
200 ppt

---

Interblock gap

I terbiock gap
Nonstop
Start-stop

9-track
06w

9-track
06 n

9-track
061n

Minimum
block size
Ibytesl

Optional

3mm
3m
Optional

10 ms

16 mx----

ged

1600 ppi
800 ppi

NRZI

556 ppi
200 ppi

800 ppi

14 mx
20 mx

Va able

1 5 m Is

2400 ft

1600 ppi
800 ppi

24 mx.. 30.mx
30 mx
38 mx

7-track
075in

9-track
O6in

Maximum block
size (bytesl

7-track
075

8191

65,535

Block length

0.6 in

8191

bIt

Va able

1 5 mdx

Va able

Tape th ckness

7-track
075

Variable

1 5 mlls

1 5 m lx

9-track
06

1 5 mils

2400 ft

2400.ft

2400 ft

Tape length (maximum)

7-track
075 n

2400 ft

Forward or backward
Forward

Tape direction
Reading
Writing

65,535

Forward or backward
Forward

42.7 inches per second

200 inches per second

120 inches per second

42 7 inches per second

Tape speed

60 inches per second

25 inches per second

NRZI

556 ppi
200 ppi

800 ppi

17 ms
23 mx

7-track
0751n

Forward or backward
Forward

96000 frames per second

40,000 frames per second

34,160 frames per second

320,000 frames per second

192,000 frames per second

UNISERVO 14

68320 frames per second

2 to 8

Data transfer rate maximum)

UNISERVO 10
2 to 8

2 to 8

UNISERVO VI-C

1 to 16

UNISERVO 20

1 to 16

UNISERVO 16

1 to 16

UNISERVO 12

Description

UN/SERVO Subsystems Characteristics

Tape units per subsystem

Characterist,c

Table A—5.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table A—6.

SPERRY UNIVAC 0920 Paper Tape Subsystem Characteristics

Characteristic

Description

Reader mounting

Mounted on a 7- by 9-inch panel having a pin spindle
for handling reels containing up to 50 feet of tape
(for tape reader without an optional spooler)

Tape read

Unidirectional (right to left)

Tape channel capacity

Capable of reading li/i 6-inch, 7/8-inch, or 1-inch
paper tape; 3-position tape guide available to adjust
to tape width used

Read speed

300 characters per second at 10 characters per inch

Type of tape

All conventional perforated tapes with a light
transmissivity of 40% or less

Stop and start capacities

Can stop on character or before next character; on start,
unit reaches full speed within two characters

Tape spooler

Up to 5-inch reels can be used with the spooler to allow
reeling of approximately 300 feet of paper tape

Tape leader

Approximately 3 feet of tape leader required when spooler
mechanism is used

Tape trailer

A 1 2-inch trailer must be provided to prevent false broken
tape indication

Punch mounting

Mounted within a 14-by 19-inch panel

Tape channel capacity

Handles paper tape width of 11/16 inch or 1 inch; five
levels of tape characters with 1 1/16-inch paper tape
being used; or 5, 6, 7, or 8 levels of tape characters
with 1-inch paper tape in use. Tape guide adjusts to
conform to paper tape width.

Punch speed

1 10 characters per second at 10 characters per inch

Type of tape

Oil base paper tape is provided. A compatible tape
utilizing a paper-plastic-paper sandwich is also
available.

Stop and start capabilities

Punching is performed one character at a time. Tape
punch is capable of stopping and starting between
characters.

Tape feeding

The tape punch handles a paper tape reel of 1000
feet with sensing signals to indicate low paper
tape supply.

A-il

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Appendix B.

B.1.

B-i

Error âñd Exception Handling

GENERAL

All programs using the services of OS/3 data management execute imperative
macroinstructions to obtain specific processing. OS/3 data management performs part of
the desired data manipulation itself but frequently calls on other OS/3 system programs
(such as the physical IOCS or disk space management) to perform other parts of the task
Most of the time the desired service is performed exactly as requested and control is
returned to you inline with no need to issue messages to the system console or to the log
Sometimes, however errors or exceptions to desired performance occur these may be
detected by data management or the other system programs at various points in
processing.
OS/3 data management is responsible for noting all errors and exceptions reported to it by
the other system programs, as well as for testing, within itself, for other types of erroror
exceptions. When any such condition is detected, OS/3 data management will always:.
•

make appropriate entries in certain fields of the DTF file table which your program
may address in order to learn of exceptions and errors and take the proper course of
action when control returns to you

•

log and display messages that call for operator intervention or are helpful in after-thefact tracing of your program s action

•

branch to an error/exception routine in your program.

B.2.

RETURN OF CONTROL

The design policy of OS/3 data management is never to terminate a user program. This
means that data management will always return control to you after detecting an error or
exception. If you provide the address of an error/exception routine in your DTF
macroinstruction, data management returns control to this address for all conditions of
error or exception. If you do not provide this address, data management returns control to
you inline, at the next sequential instruction after the macro call. Retries by PIOCS have
already been performed at this point in the processing.

B21.

B-2

SPERRY UNIVACOS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Error Handling with ISAM

When OS/3 ISAM detects certain logical errors, the processor sets a bit in the DTFIS table
that prohibits further reference to the file other than to close it These logical errors (also
lIsted in Table B—3) are:
.

Invalid macro sequence
•

Invalid ID

•

Invalid index search

•

File space exhausted

B3.

SYSTEMERROR. MESSAGES

In OS/3 system error messages are contained in a general file of canned messages
which are listed or displayed under the control of the OS/3 supervisor When OS/3 data
management detects a Ioggable error it acts through a logging transient routine to provide
the supervisor with the proper code for the specific message to be logged which the
transient translates from an error code field in the DTF file table This internal error code
may also be accessed by your program, it is placed in byte 56 of the DTF file table by data
management.
B 3 1

Data Management Error Messages

The error messages issued by OS/3 data management are shown in Table B—i, thefirst
column of which lists the internal error code placed in byte 56 of every DTF file table
(filenameE) When these messages are printed or displayed they will include between the
message number and the text the 7-byte logical filename (LFD name) and the channel and
device address which are maintained in the physical Unit bloók (PUB) on which the: file in
question is assigned. Table B—i also provides for each message an explanation of the
probable cause of the error a notation as to the data management module which issues it
and suggested actions by which you may recover from the error. Note, error messages
relating to unit record also apply to the 8413 diskette.

T, V
T, V, C
0 (See note.)
T, C, (See note.)
T,C (See note.)
T, M
T,C
H (See note.)

OPEN/CLOSE
OPEN
OPEN
OPEN
OPEN/EXTEND
OPEN
OPEN
All DMS
All DMS
OPEN/CLOSE
OPEN

FORMAT-i LABEL NOT FOUND
yOLUME SEQUENCE ERROR RIC
FILE SERIAL NUMBER ERROR R*C.
CREATION DATE ERROR RIC
PREFORMAT WRITE ERROR DETECTED
SPECIFIED NON-EXTENDABLE
FILE SECURITY CHECK RIC
ATTEMPTEDACCESS TO AN UNOPENED FILE
INVALID IMPERATIVE MACRO/MACRO SEQUENCE ISSUED
INVALID DTF, TYPE=nnø
PARTITION INVALID FOR SPECIFIED DTF,TYPE=nn®

DM06

DM07

DM 08

DM09

DM 10

DM11

DM 12

DM 13

DM 14

DM 15

DM16

T,S, L

T, S, L

T, L

C (See note.)

OPEN/CLOSE

SAM tape

I/O ERROR DETECTED WHILE ACCESSING VTOC

DM05

filename REQUIRES channel/device vsn WITH

DM 04

{

T, C

OPEN/CLOSE

FCB NOT FOUND/INVALID

DM 03

03
NOBKNO}

C (See note.)

SAM tape

filename REQUIRES channel/device vsn WITH RING R C

DM 02

T, L

OPEN

Suggested Action

OPEN ISSUED TO OPENED FILE

Issuing Module

DM 01

Message Number and Text

OS/3 Data Management Error Messages (Part 1 of 6)

Internal
Hexadecimal
Code

Table B—i.

WRONG LENGTH ERROR DETECTED
DATA CHECK DETECTED
READ ER9ORON RUNLIB DEVICE OR SPOOL FILE
PUNCH DOES NOT HAVE READ FEATURE
NOHARDWAREFORSTUBREAD
VALIDITY CHECK ERROR

DM 25

DM 26

DM27

DM28

DM29

DM 30

DM 31

T,M
T,M
T, S
LS
H
H

T, D

T, L, C
H

Disc DMS
OPEN
UNIT RECORD
UNIT RECORD
UNIT RECORD
Disc DMS

SAM/N I/ISAM/
IRAM/MIRAM
Disc DMS
Disc DMS

(No console message appears, but this code in the
DTF means: record not found for random function.)
RECORD NOT FOUND FOR SEQUENTIAL FUNCTION

INVALID FUNCTION ISSUED FOR OPTIONAL FILE

DM 32

DM 33

DM 34

(No console message appears, but this code
in the DTF means: end of data detected for
sequential operation.)

T,M

EXCEEDS FILE LIMITS GETCS ERROR:

Disk DMS, SAM tape

—

T, D

INVALID REQUEST(ID)

DM24

Disc DMS

UNRECOVERABLEI/O ERROR DETECTED

DM23

23
—

T, M

All DMS

HARDWARE ERROR

DM 22

T, M

T, C

UNIT RECORD

INVALID OR MISSING DEVICE ASSIGNMENT OR DEVICE NOT AVAILABLE

DM21

All DMS.

S,T

SAM tape

NO BKNO SUPPORT IN SUPERVISOR

DM 20,

CHECK ERROR STATUS/SENSE BYTES

T, C

OPEN

INVALID DEVICE CHARACTERISTICS SPECIFIED

DM 19

—

H,orT, D

ISAM/SAM/N I
UNIT RECORD

RECORD SIZE INVALID

DM18

T, S

OPEN/SAM/NI
UNIT RECORD

Suggested Action

INVALID BLOCK SIZE SPECIFIED

Issuing Module

DM 17

Message Number and Text

OS/3 Data Management Error Messages (Part 2 of 6)

Internal
Hexadecimal
Code

Table B— 1.

0
0)

-p
cc

T, 0
H, S

Printer
Printer

INVALID CONTROL CHARACTER
LINE TRUNCATED
EXTENT TABLE
filename channel/device vsn DATA BLKS: READ

DM43

DM44

DM45

DM46

DM47

DM48

T, D
Printer

CHARACTER MISMATCH

DM42

nnnnnn IC

T, R
ISAM, SAM tape

FILE SPACE EXHAUSTED

DM41

T, R

ISAM SETFL

INDEX SPACE WILL NOT SUPPORT PRIME DATA

DM40

T, C
C (See note.)
H
T, S. C
T, L
T, S
T, S
5, T
T, M

SAM tape
SAM/DAM/NI
OPEN disc
ISAM
SAM tape
NI
NI
All disc

SAM tape
UNIT RECORD

ERROR DURING LABEL PROCESSING
KEY LENGTH/LACE FACTOR INVALID
PROCESSING INHIBITED BY ERROR CONDITION
RECSIZE REGISTER NOT SPECIFIED FOR UNDEF FORMAT
INVALID SUBFILE NUMBER SPECIFIED
NO SPACE AVAILABLE FOR SUBFILE ENTRIES
HARDWARE ERROR DURING FILE CONTROL BLOCK
UPDATE
INVALID JCL SPECIFIED OR INVALID USE OR NAME IN VFB
OR LCB JOB CONTROL STATEMENT INVALID USE OR NAME
IN VCB OR LCB STATEMENT FOR printer file

DM49

DM50

DM 51

DM 52

DM53

DM54

INDEX INVALID

Suggested Action

Disc OPEN/EXTND
UNIT RECORD

VEX HAUSTED

—

nnnnnn .EOV

T, R

ISAM add and retrieve

INVALID FILE CONDITION

DM39

T, 0

ISAM

END OF DATA RETURNED BY SYSTEM—ILLOGICAL
CONDITION

DM38

ISAM load

SEQUENCE ERROR

DM37

RECORD REJECTED

ISAM add

DUPLICATE RECORD—REJECTED

DM36

36
—

ISAM add

ADD OF RECORDS RESTRICTED BY PREVIOUS OPERATION

Issuing Module

DM35

Message Number and Text

OS/3 Data Management Error Messages (Part 3 of 6)

Internal
Hexadecimal
Code

Table B—i.

cSi

a.J

m C*)

> P
0
m

w
>

CflCI)

W
C, T

C, T
B
0
0
0

C
0
0

All DMS

UNIT RECORD
UNIT RECORD

UNIT RECORD
MIRAM
Read/Punch
Read/Punch
Read/Punch
All paper tape
All paper tape
Printer

UNIT RECORD
Printer

INVALID DTF FIELD: PARAMETER, OR PARAMETER
COMBINATION, TYPE=nn CD
80 COLUMN CARDS READ WITH BLOCK SIZE 81-96
OPEN ERROR: BiNARY MODE CARD INPUT
FILE CANNOT BE SPOOLED IN
COMBINED CARD FILE CAN’T BE SPOOLED IN
ILLEGAL KEY CHANGE DURING UPDATE
BEGIN OUTPUT FILE PUNCH RECOVERY. R,U?
PERFORM PUNCH RECOVERY STEP 2A. R.U?
PERFORM PUNCH RECOVERY STEP 2B. R,U?
BEGIN OF FILE MARKER NOT COMPLETE.**I,C
IS IT END OF FILE OR END OF TAPE. **FT
INSUFFICIENT SPACE ALLOCATED FOR PRINTER SKIP CODES

SPOOL FILE FOR CARD READER FILE WAS NOT CREATED
UNRECOVERABLE ERRQR WHILE LOADING THE VERTICAL
FORMAT BUFFER OR LOAD CODE BUFFER.

DM 61

DM62
DM 63

DM 64
DM65
DM 80
DM 81
DM 82
DM 83
DM 84
DM 85

DM86
DM 87

C,T

SAMtape

TAPEMARKNOTFOUNDATFILEBOUNDARY

DM60

C, T

SAM tape

STD LABEL FIELDS DO NOT MATCH JCL SPECS

DM 59

C,T

SAM tape

FSNDOES NOT MATCH FIRST VOLUME VSN

DM58

w
Y

FILE LOCK
UNIT RECORD

jobname WAITING FOR LOCK IbI-file-name
DISKETTE DRIVE NOT AVAILABLE

DM88
DM89

C, T (See note.)

SAM tape, Disc DMS
UNIT RECORD

WRITE ATTEMPTED ON UNEXPIRED FILE RIC

DM 57

C, T

SAM tape

FILE NOT FOUND

DM 56

56
.

C, T

SAM tape
UNIT RECORD

Suggested Action

STD SYSTEM/USER LABEL NOT FOUND

Issuing Module

DM 55

Message Number and Text

OS/3 Data Management Error Messages (Part 4 of 6)

Internal
Hexadecimal
Code

Table B—i.

Tape extend
Tape extend
Tape extend
Tape extend
Tape extend
Tape extend

ILLEGAL EXTEND, HDR2 NOT FOUND
ILLEGAL EXTEND, EOF1 OR EOV2 NOT FOUND
ILLEGAL EXTEND, RECFORM INVALID
ILLEGAL EXTEND, RECSIZE INVALID
ILLEGAL EXTEND, BLKSIZE INVALID
ILLEGAL EXTEND, FILE FOLLOWS THE FILE TO BE EXTENDED

DM94
DM 95
DM 96
DM98
DM99
DM9A
DM9B
DM9C
DM9D
DM9E
DM9F

LOGICALENDOFFILEREACHEDRI*

PUNCH MISFEED. R,U?

PUNCH OFF-LINE.R,U?

PREPUNCHED CARD DETECTED DURING ERROR RECOVERY

R
I
C
U

Tapeextend

Read/Punch

Retry after mounting correct volume
Ignore the error condition.
:
Cancel job
Unrecoverable user error routine required
nn is a message type subcode that is used to provide additional information as to why the associated message was displayed or printed.
Refer to Table B—lA for the subcodes and their explanations.

Operators choose one of the following action messages to reply to data management error messages.

NOTE:

Tape extend

ILLEGAL EXTEND, STANDARD LABEL NOT SPECIFIED

DM93

93
PERFORM PUNCH RECOVERY STEP 3. R,U?

DO RECVRY STEP 2. REFILE LAST (2) CD(S)? R,U?

DM 92

Read/Punch

HAVE BLANK CDS BEEN PLACED IN HOPPER? R,U?

DM 91

Read/Punch

BEGIN ERROR RECOVERY ERROR CARD. R,U?

Issuing Module

DM 90

Message Number and Text

OS/3 Data Management Error Messages (Part 5 of 6)

Internal
Hexadecimal
Code

Table B—i.

Suggested Action

—I

m L3

w
>

cns
0 m

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table B—i.

B—B

OS/3 Data Management Error Messages (Part 6 of 6)

LEGEND:

Suggested actions

Check your data and rerun the job.

Control stream content should be checked.

Checking of program dump is recommended.

Program should handle this occurrence, proceeding or otherwise as programmed.

Program logic should be checked.

Maintenance check of disk pack check.

Operator intervention is needed. See system messages operator/programmer reference, UP-8076 (current version).

Reorganize file, getting more space or rebuilding index by new load.

Program specifications to data management should be checked.

Program termination is recommended.

VTOC should be printed out for check.

Warning message.

Rerun when device is available.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table B— 1,4.

Data Management Error Message Subcodes (Part 1 of 2)

Associated Data Message
Management
Type
Subcode*
Error Message
DM15

DM16

DM61

B-9

Explanation

Invalid DTF address

Invalid DTF type code

Invalid DTF partition control appendage (PCA)

Invalid DTF partition control appendage (PCA) address

File type code in DTF does not match type code in IOCS processor.

Wrong key location

Invalid DTF address in partition control appendage (PCA)

Missing extent table entry for partition control appendage (PCA)

Single mount specification does not match specification used to create file.
Single mount specifications do nat match between Format 2 label and DTF

Variable record specifications do not match between FOrmat 2 label and DTF

Two I/O areas are not contiguous.
Index buffer not contiguous with I/O area 1.
I/O area 2 address not contiguous with I/O area 1 address.
Index buffer not contiguous with I/O area 1 address.

Index operations intended, but no index buffer or key argument specification
Seek address not specified
Key argument not specified
Index buffer not specified

Key location does not match specification used to create file.
Key location values do not match- between Format 2 label and DTF
Key location value less than 4 with variable file
Key specifications not zero after last valid key entry
Key flag values do not match between Format 2 label and DTF.
Key size does not equaloriginaI keysize used to create file.

Nonindexed output intended to an indexed file
Indexed access intended to a nonindexed file

No work area or I/O register specification
I/O register specified incorrectly
Work area and I/O register specified together

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table B—lA.

Data Management Error Message Subcodes i’Part 2 of 2)

Associated Data Message
Type
Management
Subcode*
Error Message
DM6i (cont)

B-i 0

Explanation

Double buffering with update or randommode.
Double buffering with input and add
Double buffering with indexed input

Variable build register. specified incorrectly

Forward direction not. specified with output file

STD labels not specified with ASCII file
When specifying ASCII, BLKSIZE not greater than 9999

BKNO=YES not specified with block numbered tape

The reader does not have the 96-column read feature

.14

Block size and overflow percentage are too large for disk with low number of
tracks/cylinders (8415)

Format other than fixed unblocked or variable unblocked-

I/O area 2 not specified with combined file
Extend not allowed with combined file
Multisector I/O invalid with combined file

Block size or record size equals zero

An address in the DTF is not within the bounds of the user program

Invalid DTF, CR type not appropriate when Format 2 label active in multivolume

User specified seek address is not word aligned or I/O area’s are not half-word
aligned

With 7 track and convert-on; block size not multiple of 3

Error while performing recovery of IRAM/MIRAM file

Invalid specification in //DD job control statement

*When error condition occurs, the related subcode (in hexadecimal) is placed in byte 44 of the DTF file table.

B.3.2.

Disk Space Management Error Cods

The disk space management routines of the OS/3 supervisor do not generate error
messages, but instead load a hexadecimal error code into general register 0 for the error
or exception conditions listed in Table B—2. The first äolumn of this table contains the
hexadecimal error code, which is loaded by disk space management into register 0, byte 3.
This is followed by an interpretation of the-error or exception condition and suggestions for
recovery action.

UP-8068 Rev 4

SPERRY UNPAC OS/3D
BASIC DATA MANAGEMENT

Table B—2.
Internal
Hexadecimal
Code

B—il

OS/3 Disk Space Management ErrorCodes

Suggested
Recovery
Action

Interpretation

Unrecoverable hardware I/O error on WRITE command;
VTOC may be disturbed.

Unrecoverable hardware I/O error on READ command;
VTOC is disturbed.

Unrecoverable hardware I/O error on READ command;
VTOC not disturbed.

Same as error code 31

Indicated device (PUB) either not allocated or nonexistent.

Check the VOLjob control statement
aidthe volume sequence number
of the disc volume,

File ID error:
•

For EXTEND, SCRTCH, RENAME, OBTAIN: theformat 1 label
record cannot be found on specified volume.

•

For ALLOC: a file with the same file ID already exists
on this volUme.

List and examine VTOC,
using OBTAIN macro. Attempt
to copy all files to another disc;
then reprep the suspected defective
disc.

List VTOC and check all
format 1 labels. Check also
all parameters in the job
control device assignment set.

No empty label records in VTOC.

No space avaiIabIe•o this volume.

No file control block (FCB) found for t(iis internajiilenarne
(LFD name)

Check LFDjob control statement.

For OBTAIN, the disk address specified is iivalid.

Providecorrect disk address
arid rerun.

For track aligned files, SCRTCH is invalid.

Use release that recognizes
track aligned files.

‘$Y$’ is specified as first three characters of file ID to
SCRTCH macro (PREFIX function).

System files may not be
deallocated with SCRTCH macro.

$TOC is named as file to b scratched.

A $VTOC file cannot be
scratched.

Eliminate unused files or expand VTOC
area.
.

‘ForRENAME, the file tobe renamed is nat a
format label file.
3A

VTOC format error is detected..

Elminate unused files or change to a
nancontiguàus request.

Data set lábeldiskettes cannot
be scratched,
For diskette, check for duplicate
or overlapping space or a
duplicate name.
For disk, list VTOC and check
format 4 label.

Request for extension of file will exceed number of allowable
extents (16 for all but split files, which are allowed 13).

Create a new file with a single
extent large enough to
accommodate the contents
of the old file,

Error detected in your parameter table.

Review formats presented in
this manual and in
supervisor user guide, UP.8075
(current version).

B.3.3.

B-12

SPERRY UNIVAC OS/3
BAc DATA MANAGEMENT

UP-8068 Rev. 4

Disk File ExtensionError Handling

Three types of extend failures can occur, each associated ith
diagnostic:

data management error

DM45 EXTENT TABLE EXHAUSTED
No space exists in the logical extent table for additional space acquired by file
extension.
-

DM41 FILE SPACE EXHAUSTED
No physical space exists for file extension.
DM11 SPECIFIED NON-EXTENDABLE
DTF specifies the file as nonextendable by
—

—

maintaining a secondary allocation increment of zero (via the EXT card)
defining the secondary allocation përóent (UOS) as zero
setting the nonextendable flag in the partition table flag byte

Errors occuring during file extend operations are always associated with inability to
acquire output space for a buffer and consequent loss of output data. On extend failure
errors, file extend proOedures now minimize loss of öutputdatato one record.
B.4.

ERROR FLAGGING PROCEDURES

All OS/a data management pgorams set bits in a special field of the DTF file table tO serve
as error flags, providing you with particular information on the error. Disk and tape
programs set the bits in this field and then call the logging transient (B.3); card and printer
modules go directly to the logging transient When an error is detected during the
execution of a data management transient routine, the logging transient is called after the
setting of the error flag bits is completed or bypassed.

B.4.1.

B-i 3

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

FilenameC

The error flag field of the DTF file table is designated filenameC; it may be accessed by
your program through the test under mask instruction (TM), using for operand 1 your 7byte logical filename, to which you have concatenated the letter C. Note that the size of
filenameC varies with the type of file: for card and printer files, it is only one byte long; for
tape and disk files, it is four bytes long. Table 8—3 lists the significance of the bits that are
set to binary 1 in filenameC for certain error and exception conditions. For information on
paper tape error processing, refer to 17.5.9.
Table B—3.

Significance of Bits in filenameC (Part 1 of 4)

BYTE 0

Bit

DTFMI
DTFIR
DTFIS

Last block on
track accessed

Invalid ID

Invalid DTF

Hardware
error

Error found
in OPEN

Error found
in CLOSE

Invalid macro
sequence

Reserved

DTFSD
DTFDA
DTFNI

DTFMT

DTFPR

DTFCD

Reserved

Line truncated
(data too large)

Record size
invalid
(too large or
too small)

Reserved

Invalid control
character

Reserved

Invalid
PCA/DTF

Invalid
DTF

Character mismatch

Validity check
(unique unit error)

(DTFSD: reserved)
WAITF
required

Reserved

Record size
invalid
(too small)

Reserved

UP-8068 Rev. 4

SPERRY UNIVAC OS/3

B-14

BASIC DATA MANAGEMENT

Table B—3.

Significance of Bits in filenameC (Part 2 of 4)

BYTE1

I/O completed

Unrecoverable

Unique unit
error

DTFSD
DTFDA
DTFNI

DTFMI
DTFIR
DTFIS

Bit

DTFMT

Record not

Reserved

Unit exception

—-—-

Wrong length found

Reserved

End of track

Reserved

End of cylinder

Reserved

. 5

T&ile B—3.

Significance of Bits in filenameC (Part 3 of 4)

BYTE2

Bit

DTFMI
DTFIR
DTFIS

Command rejection

lntervertion required

Output pariiy check

Equipment check

Data check

Overrun

STOP state

Device check

DTFSD
DTFDA
DTFNI

DTFMT

Word count

—.———-—-—-—--—-—-———-——

Data converter
check
(7-track only)

B—15

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table B—3.

Significance of Bits in filenameC (Part 4 of 4)

BYTE 3
DTFMI
DTFIR
OTFIS

Bit

B.4.2.

DTFSD
DTFDA
DTFNI

DTFMT

Invalid record size

Logical end of file

File space exhausted
(DTFIS)
Logical end of volume
(DTFIR and DTFMI)

Logical end of volume

Processing inhibited

Invalid subfile

Wrong length error

Invalid index

Reserved

Sequence error
(DTFIS and DTFIR
only)

Reserved

Duplicate record

Reserved

ADD rejected
(DTFIS only)

Reserved

Other DTF Fields

Certain of the OS/3 data management modules place, in other fields of the DTF file
table than filenameC, additional information that is of value to you in monitoring the
processing of your files. The details are documented for each specific use in the
appropriate section of this manual; these fields are designated filenameA, filenameP,
filenameS, etc., and are addressed in the same manner as filenameC: by concatenating
the letter designation to your 7-byte logical filename.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

C-i

Appendix C. Code Correspondences

Cl.

GENERAL

This appendixpresents across-reference table and figures useful to you for visualizing the
correspondences among: the following codes commonly used in data processing and in
OS/3:
•

Hollerith punched card:codé

•

EBCDIC (Extended Binary Coded Decimal Interchange Code)

•

ASCII (American National Standard: Code for Information Interchange)

•

Binary bit-pattern (bit-configuration) representation for an 8-bit system.

•

Hexadecimai representation

•

Compressed code for punched cards

•

Binary (image) mode for punched cards

C.2.

EBCDIC/ASCII/HOLLERITH CORRESPONDENCE

Table C--I is a cross-reference table depicting thecorrespàndences among theHollerith
punched card code, ASCII, and EBCDIC. The table is arranged in the sorting (or collating)
sequence of the binary bit-patterns that have been assigned to the codes, with 0000 0000
being the lowest value in the sequence and 1111 11 lithe highest.
Note that the column headed Decimal uses decimal numbers to represent the positions of
the codes and bit patterns in this sequence, but counts the position of the lowest value as
the 0th (zeroth) position rather than the first. Thus, the position of the highest value bitpattern 1111 liii is represented in the decimal column by 255, whereas it is actually the
256th in the sequence. This scheme corresponds to the common convention for
numbering bytes, in which the first byte of a group is byte 0, and is convenient when you
are constructing a 256-byte translation table. (See the MODE keyword parameter of the
DTFCD declarative macroi nstruction (3.3).)

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

C-2

The column headed Decimal also represents the collating sequence for the EBCDIC
graphic characters shown in the fourth column of the table; the fifth column, Hollerfth
Punched Card Code, contains the hole patterns assigned to these EBCDIC graphics. Empty
space in the fourth column represents the positions of the EBCDIC control characters the
EBCDIC space charater is represented in the fourth column by the conventional notation
SP at decimal position 64, and the corresponding card code is “no punches.”
The ASCII graphic characters, listed in the sixth column of Table C—i, are also in their
collating sequence, and the hole patterns in the seventh column correspond to the ASCII
graphics. The ASCII space character is represented by the notation SP in the sixth column
at decimal position 32; the corresponding card code is, again, “no punches.” The empty
space in the sixth column represents the positions of the ASCII control characters. The
shading in the ASCII graphic character column indicates where the 1 28-character ASCII
code leaves off: there are no ASCII graphic or control characters that correspond to the bit
patterns higher in collating sequence than 0111 1111 (the 128th in Table C—i).
C.2.I.

Hollerith Punched Card Code

The standard Hollerith punched card code specifies 256 hole-patterns in 12-row punched
cards. Hole-patterns are assigned to the 128 characters of ASCII and to 128 additional
characters for use in 8-bit coded systems.. These include the EBCDIC set. Note that no
sorting sequence is implied by the Hollerith code itself.
C.2.2.

EBCDIC.

EBCDIC is an extension of Hollerith coding practices. It comprises 256 characters, each of
which is represented by an 8-bit pattern. Table C—i shows the EBCDIC graphic characters
only; the EBCDIC control characters are notindicated.
C.2.3,

ASCII

ASCII comprises 128 coded charapters,. each represented by an 8-bit pattern, and includes
both control characters and graphic characters. Only the latter are shown in Table C—i.
ASClI,is used for information interchange among data processing communication systems
and associated equipment.

osia

UP-8068 Rev. 4

SPERRY UNIVAC
BASIC DATA MANAGEMENT

Table C—i.

C-3

Cross-Reference Table: EBblC/ASil/Hollerith (Part 1 of 5,1

EBCDIC
Decimal

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54 --

Hexa
decimat
00
01
02
03
04
05
06
07
08
09
OA
08
OC
00
OE
OF
10
11
12
13
14
15
16
17
18
19
1A
18
1C
10
1E
iF.
20
21
22
23
24
25
26
27
28
29
2A
28
2C.
20
2E
2F
30
31
32
33
34
35
36

Binary

0000 0000
0000 0001
00000010
0000 0011
00000100
00000101
00000110
00000111
00001000
0000 1001
00001010
0000 1011
00001100
00001101
0000 1110
00001111
00010000
0001 0001
0001 0010
0001 0011
0001 0100
0001 0101
0001 0110
0001 0111
0001 1000
0001 1001
0001 1010
0001 1011
0001 1100
0001 1101
00011110
0001 1111
00100000
00100001
00100010
00100011
00100100
00100101
.00100110
0010 0111
00101000
0010 1001
00101010
0010 1011
00101100
00101101
00101110
00101111
0011 0000
0011 0001
0011 0010
0011 0011
0011 0100
0011 0101
00110110

ASCII
EBCDIC
Graphic
Character

..
-

--.

.-.

ASCII
Graphic
Character

Hollerith
Punched Card
Càde
1 2-0-9-8-1
12-9-1
12-9-2
1 2-9-3
12-9-4
1295
12-9-6
12-9-7
12-9-8
12-9-8-1
129-82
12-9-8-3
12-9-8-4
12-9-8-5
1 2-9-8-6
12987
1211981
11-9-1
11-9-2
119-3
11-9-4
11-9-5
11-9-6
11-9-7
11-9-8
11981
11-9-8-2
11 9-83
11-9-8-4
11-9-8-5
119-86
11-9-8-7
11-0-9-8-1
0-9-1
0-9-2
0-9-3
0-9-4
095
0-9-6
0-9-7
09-8
0-9-8-1
‘)982
0-9-8-3
0-9-8-4
09-85
0-9-8-6
09-87
12-11-0-9-8-1
9-1
9-2
9-3
9-4
9-5
9-6

Hollerith
Punched Card
Code

.::

. .
-.

...

;

..
.

I.
“

.#
,

$
%,
&

‘

(
1
.

...
.
.

-‘

—.

9-8 7
0-9-7
11-9-8-4
-. 11-9-8-5
11-9-8-6
11-9-8-7
No punches
12-8-7
8-7
8-3
11-8-3
0-8-4
12
8-5
12-8-5
11-8-5
11-8-4
-. 12-8-6
0-8-3
11
12-8-3
0-1
:o
1
2
3
4
.5
6
.

.
*..

12-0-9-8-1
12-9-1.
12-9-2
12-9-3
9-7
0-9-8-5
0-9-8-6
0-9-8-7
11-9-6
12-9-5
0-9-5
12-9-8-3
12-9-8-4
12-9-8-5.
1 2-9-8-6
12-9-8-7
12-11-9-8-1
11-9-1
11-9-2
i1.-93
9-8-4
9-8-5
9-2
0-9-6
11-9-8
11-9-8-1

..../.
•0
1.
2
3.
.4
5
6

C—4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table C—i.

Cross-Reference Table: EBCDIC/ASCII/HoUerith (Part 2 of 5)

ASCII

EBCDIC
Decimal

Hexadecimal

55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109

37
38
39
3A
3B
3C
3D
3E
3F
40
41
42
43
44
45
46
47
48
49
4A
4B
4C
4D
4E
4F
50
51
52
53
54
55
56
57
58
59
5A
58
SC
5D
SE
SF
60
61
62
63
64
65
66
67
68
69
6A
6B
6C
6D

Binary

0011 0111
0011 1000
0011 1001
0011 1010
0011 1011
0011 1100
0011 1101
0011 1110
0011 1111
0100 0000
0100 0001
0100 0010
0100 001 1
01000100
0100 0101
0100 01 10
01000111
0100 1000
0100 1001
0100 1010
O100 1011
01001100
01001101
01001110
01001111
0101 0000
0101 0001
0101 0010
0101 0011
0101 0100
0101 0101
0101 0110
0101 0111
0101 1000
0101 1001
0101 1010
0101 1011
0101 1100
0101 1101
0101 1110
0101 1111
01100000
01100001
01100010
01 10 001 1
01 10 0100
01100101
01 10 01 10
01100111
01 10 1000
01 10 1001
01101010
01 10 101 1
01101100
01101101

EBCDIC
Graphic
Character

Hollerith
Punched Card
Code

•SP

[
.

<
C
+

!
&

]
$
*

A
—

%
—

9-7
9-8
9-8-1
9-8-2
9-8-3
9-8-4
9-8-5
9-8-6
9-8-7
No punches
12-0-9-1
12-0-9-2
1 2-0-9-3
12-0-9-4
1 2-0-9-5
1 2-0-9-6
12-0-9-7
12-0-9-8
12-8-1
12-8-2
12-8-3
12-8-4
12-8-5
12-8-6
12-8-7
12
12-11-9-1
12-11-9-2
12-11-9-3
12-11-9-4
12-11-9-5
12-11-9-6
12-11-9-7
12-11-9-8
11-8-1
11-8-2
11-8-3
11-8-4
11-8-5
11-8-6
11-8-7
11
0-1
11-0-9-2
11 -0-9-3
1 1 -0-9-4
11-0-9-5
1 1-0-9-6
11-0-9-7
1 1 -0-9-8
0-8-1
12-11
0-8-3
0-8-4
0-8-5

ASCII
Graphic
Character
7
8
9
:
;

<
=

>
?
@
A
B
C
D
E
F
G
H
I
J
K
L
M
N
0
P
Q
R
S
T
U
V
W
X
Y
Z

[
\

]

A
a
b
C

d
e
f
g
h
1

j
k
I
m

Hollerith
Punched Card
Code
7
8
9
8-2
11-8-6
12-8-4
8-6
0-8-6
0-8-7
8-4
12-1
12-2
12-3
12-4
12-5
12-6
12-7
12-8
12-9
11-1
11-2
11-3
11-4
11-5
11-6
11-7
11-8
11-9
0-2
0-3
0-4
0-5
0-6
0-7
0-8
0-9
12-8-2
0-8-2
11-8-2
11-8-7
0-8-5
8-1
12-0-1
12-0-2
12-0-3
1 2-0-4
12-0-5
1 2-0-6
12-0-7
1 2-0-8
1 2-0-9
12-11-1
1 2-1 1-2
12-11-3
12-11-4

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table C—i.

C-5

Cross-Reference Table: EBCDIC/ASCII/Hollerith (Part 3 of 5)

EBCDIC
Decimal
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
14-4
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159

Hexadecimat
6E
6F
70
71
72
73
74
75
76
77
78
79
7A
7B
7C
7D
7E
7F
80
81
82
83
84
85
86
87
88
89
BA
8B
8C
8D
BE
8F
90
91
92
93
94
95
96
97
98
.99
9A
9’3
9C
9D
9E
9F

Binary

01101110
01101111
0111 0000
0111 0001
0111 0010
0111 0011
0111 0100
0111 0101
0111 0110
0111 0111
0111 1000
0111 1001
0111 1010
0111 1011
0111 1100
0111 1101
0111 1110
0111 1111
10000000
10000001
1000 0010
10000011
1000 0100
10000101
10000110
10000111
1000 1000
1000 1001
1000 1010
10001011
1000 1100
10001101
1000 1110
1000 1111
1001 0000
1001 0001
1001 0010
1001 0011
1001 0100
1001 0101
1001 0110
1001 0111
1001 1000
1001 1001
1001 1010
1001 1011
1001 1100
1001 1101
1001 1110
1001 1111

ASCII
EBCDIC
Graphic
Character

>
?

a
b
c
d
e
f
g
h
i

j
k
I
m
n
0

p
q

ASCII
Graphic
Character

Hollerith
Punched Card
Code
0-8-6
0-8-7
12-11-0
12-11-0-9-1
12-11-0-9-2
12-11-0-9-3
12-11-0-9-4
12-11-0-9-5
12-11-0-9-6
12-11-0-9-7
12-11-0-9-8
8-1
8-2
8-3
8-4
8-5
8-6
8-7
12-0-8-1
12-0-1
12-0-2
12-0-3
12-0-4
12-0-5
12-0-6
12-0-7
12-0-8
12-0-9
12-0-8-2
12-0-8-3
12-0-8-4
12-0-8-5
12-0-8-6
12-0-8-7
12-11-8-1
12-11-1
12-11-2
12-11-3
12-11-4
12-11-5
12-1 1-6
12-1 1-7
12-11-8
12-1 1-9
12-1 1-8-2
12-11-8-3
12-11-8-4
12-11-8-5
12-11-8-6
12-11-8-7

Hollerith
Punched Card
Code
12-11-5
12-11-6

r
s
t

u
v
w
x
V
z

{

S.
..

:
:

:..•

11-9-7
0-9-8
0-9-8-1
0-9-8-2

•.

•
.:
-

...

.
.

.:..

—

12-11-7
12-11-8
12-11-9
11-0-2
11-0-3
11-0-4
11-0-5
11-0-6
11-0-7
11-0-8
11-0-9
12-0
1211
11-0
11-0-1
12-9-7
11-0-98-1
0-9-1
0-9-2
0-9-3
0-9-4
11-9-5
12-9-6

0-9-8-3
0-9-8-4
1 29-8-1
12-9-8-2
11-9-8-3
12-11-0-9-8-1
9-1
11-9-8-2
9-3
94
9-5
9-6
12-9-8
9-8
9-8-1
9-8-2
9-8-3
12-9-4
11-9-4
9-8-6
11-0-9-1

SPERRY UNIVAC U/
BASIC DATA- MANAGEMENT

UP-8068 Rev. 4

Table C—i.

1..—0

Cross-Reference Table: EBCDIC/ASC11/Hollerith (Part 4 of 5)

Decimal

Hexadecimal

160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209

A0
Al
A2
A3
A4
•A5
A6
A7
A8
A9
AA
AB
AC
AD
AE.
AF
80
B1
B2
B3
B4
B5
B6
87
88
B9
BA
BB
BC
..BD
BE
SF
CO
Cl
C2
C3
C4
CS
C6
C7
C8
C9
CA
CB
CC
CD
CE
CF
DO
Dl

.EBCDIC
Graphic
Character

Binary

10100000
10100001
10100010
10100011
10100100
10100101
10100110
10100111
1010 1000
1010 1001
10101010
10101011
10101100
10101101
10101110
10101111
1011 0000
1011 0001
1011 0010
1011 0011
1011 0100
1011 0101
10110110
1011 0111
1011 1000
1011 1001
1011 1010
1011 1011
1011 1100
1011 1101
1011 1110
1011 1111
11000000
11000001
11000010
11000011
11000100
11000101
11000110
11000111
1100 1000
11001001
1100 1010
1100 101 1
1100 1100
1100 1101
1100 1110
11001111
1101 0000
1101 0001

ASCII

•

EBCDIC
Hollerith
Punched Card
Code

s
t

u
v
w
x
y
z

.
.
.
{

A
B
C
D
E
F
G
H
I

11:0-8-1
11-0-1
11-0-2
11-0-3
.11-0-4
11-0-5
11-0-6
11-0-7
11 -0-8
1 1-0-9
11-0-8-2
11-0-8-3
11-0-8-4
11-0-8-5
11-0-8-6
11-0-8-7
12-11-0-8-1
12-11-0-1
12-11-0-2
12-11-0-3
12-11-0-4
12-11-0-5
12-11-0-6
12-11-0-7
12-11-0-8
12-11-0-9
12-11-0-8-2
12-11-0-8-3
12-11-0-8-4
12-11-0-8-5
12-11-0-8-6
12-11-0-8-7
12-0
12-1
12-2
12-3
12-4
12-5
12-6
12-7
12-8
12-9
12-0-9-8-2
1 2-0-9-8-3
1 2-0-9-8-4
12-0-9-8-S
1 2-0-9-8-6
12-0-9-8-7

ASCII
Graphic
Character

.
.

1 2-0-9-7
1 2-0-9-8
12-8-1
12-11-9-1
121192
12-11-9-3

•
-

12-11-9-4
12-11-9-5
12-11-9-6
12-11-9-7
12-11-9-8
11-8-1
11-0-9-2
110-9-3
11-0-9-4
11-0-9-5
11-0-9-6
11 -0-9-7

-•

•

0-8-1
12-11-0
12-11-0-9-1
12-11-0-9-2
1 2-1 1 -0-9-3
12-11-0-9-5
12-11-0-9-6
12-11-0-9-7
12-11-0-9-8
2-0-8-1
12-0-8-2
1 2-0-8-3
12-0-84
1 2-0-8-5
1 2-0-8-6
12-0-8-7
12-11-8-1
12-1 1-8-2
12-11-8-3

.
.

•

ii-o
11-1

Hollerith
Punched Card
Code
12-0-9-1
12-0-9-2
12-0-9-3
12-0-9-4
1 2-0-9-5

12-11-8-5
1211-8-6
12-11-8-7
11-0-8-1

SPERR’? UNIVAC OS/S
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table C—1.

Cross-Reference Table: EBCDIC/ASCII/HoIferi(h (Part 5 of 5)
V

Héxa
dodmal

Decimal

Binary

1101
1101
1101
1101
1101
1101
1101
1101
1101

224

iiiooooc

225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255

El
E2
E3
E4
E5
E6

11100001
11100010
11100011
11100100
11100101
lllOOllQ
1110011!.
1110 1000
1110 1001
11101010
11101011
11 10 1 100
11101101
11101110
11101111
11110000
11110001
11110010
11110011
liji 0100.
1111 0101
1111 0110
11110111
1111 100011111001
1111 1010
1111 1011
1111 1100
1111 1101
1111 1110.
1111 1111

E8
E9
EA
EB
EC
ED
EE
EF
FO
Fl
F2
F3
F4
F5
F6
F7
F8
F9
FA
FB
FC
FD
FE
FF

EBCDIC
Graphic
Character

1101 0010
1101 0011
11010100
1101 0101

D2
D3
04
D5
06
07
D8
D9
DA
DB
DC
DD
DE
OF

—

EBCDIC

210
211
212
213
214
215
216
217
218
219
220
221
222
223

C-7

HöIIérith
Punched Card
Code
V

11-2
11-3
11-4
11-5
11-6
11-7
11-8
11-9
12-11-9-8-2

K
L
M
N

ASCII

Graphic

Character

‘

11i0110

0111
1000
1001
1010
1011
1100
1101
1110
1111

P
Q
R

12-11-9-8-4
12-11-9-8-5
12-11-9-8-6
12-11-9-8-7

V
V

VVVV

0-8-2

S
T
U
V
w
X
Y
Z

0
1
2
3
V

V
V

:
V

5
6
7
8
9,

11-0-9-8-2
11-0-9-8-3
11 -0-9-8-4
11-0-9-8-5
110986
11-0-9-8-7
0

VQ9

11-0-9-10-2
0-3
0-4
0-5
0-6
0-7
0-8

2
3
4•
5
6
7
8

V
VV
V

•

V
V

V...:

V
V

VVV

11 -0-8-2
11-0-8-3
1 1-0-8-4
11-0-8-5
11-b-8-6
l1-0-8-7
12-1 1-0-8-1
12-1 1-0-1
12-11-0-2
121 1-03
12-11-0-4
12-1 1-0-5
12-11-0-6
12-11-0-7
12-11-0-8
12-11-0-9
12-11-0-8-2
12-1 1-0-8-3
1 2-1 1 -0-8-4
1-0-8-5
12-1
12-11-0-8-6

VVV:

ASCII
Hollerith
Purlóhed Card
Code

12-1l-0-9-8-2
Vl2l1-O983
12110984
12-11-0-9-8-5
121l-0-9-8-6
12-11-0-9-8-7

12-11-0-8-7
1 2-0-9-8-2
12-0-9-8-3
12-0-9-8-4
12-0-9-8-5
1 2-0-9-8-6
12-0-9-8-7
12-11-9-8-2
12-11-9-8-3
12-11-9-8-4
12-1 1-9-8-5
12-1 1-9-8-6
1 2-1 1 -9-8-7
11-0-9-8-2
11-0-9-8-3
11 -0-9-8-4
11 -0-9-8-5
11 -0-9-8-6
-0-9-8-7
12-1 1-0-9-8-2
12-1 1-0-9-8-3
12-11 -0-9-8-4
12-1 1-0-9-8-5
12-11 -0-9-8-6
12-11-0-9-8-7

C3.

C—B

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

OTHER CARD CODES

Two other punched card coding systems can be handled with OS/3 data management and
all card reader and card punch subsystems in the SPERRY UNIVAC 90/30 System: the
compressed code and the column binary, or image, code.
C.3.1.

Compressed Card Code

Figure C—i indicates the construction of the compressed card code; each card column is
represented by an 8-bit pattern in one byte of main storage.

COLUMN PUNCH POSITIONS

/12
11
0

MAIN STORAGE
BYTE
BIT POSITIONS

NOTE:
PUNCH POSITIONS 1 THROUGH 7 ARE INDICATED IN
BITS 1 THROUGH 3, ACCOFDING TO THE FOLLOWING TABLE:

PUNCH
ROWS 1 THRU 7

BITS
123

NONE
1
2

000
011
101
001
010
100
111
110

3
4
5
6
7

Figure C—i.

Compressed Card Code

UP-8068 Rev. 4

C.3.2.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

C-9

Column Binary (Image) Code

Figure C—2 indicates the construction of this code Note that each card column requires
two bytes of main storage; an I/O area of 160 bytes is required for an 80-column card
COLUMN PUNCH POSITIONS

11
0

2
3

4
5
6
7
8
9
‘I

2131415161

DATA BYTE 0

j 213T4

DATA BYTE 1

NOTE:
BiTS 0 AND 1 ARE CLEARED TO ZEROS ON AN IMAGE READ.

Figure C—2.

C.4.

Column Binary (Image) Card Code

DATA CONVERSION

In OS/3 data management, there are five ways in which your data, held in main storage
in 8-bit bytes, may be converted into hole-patterns in punched cards, and vice versa:
•

Standard mode (EBCDIC)

•

Standard mode (ASCII)

•

Compressed code mode

•

Binary (image) mode

•

Translate mode for reading or punching

In EBCDIC standard mode (MODE=STD), data in main storage in EBCDIC code is punched
into cards in the Hollerith punched card code. Cards are read in Hollerith, and the data
stored in EBCDIC.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

C-1O

In ASCII standard mode (MODE=STD and ASCII=YES), data management translates data
stored in the 8-bit ASCII code in main storage to EBCDIC, and then the cards are punched
in Hollerith. The reverse process*is used when cards are read, unless a hardware ASCII
translate featUre: is available on the card reader, when data management omits the
EBCDIC-to-ASCII translation.
In the compressed code mode (MODE=CC), an 8-bit data byte is converted by data
management into asingle-column hole-pattern (Figure C—i).
In the binary or image mode (MOD E=BINARY), there is a one-to-one correspondence
between 12 data bytes in main storage (data is stored in the least significant six bits of
two 8-bit bytes) and the 12 possible row punches in a card column (Figure C—2).
In the translate mode (MODE=TRANS), you make your own assignment of 8-bit patterns to
the 256 hole-patterns listed under EBCDIC in Table C—i in the order these are shown in
the table.
The preceding considerations should be of little concern to you because, with OS/3 data
management, you can always use any mode with any peripheral equipment in your
installation’s configuration.
The 96-column card format (as shown in Figure C—3) hold 96 characters of data at six
bits per character. The characters are arranged on the card as three rows of 32 characters
each The fact that each character can be represented in six bits is the reason no binary
read mode is provided. Depending upon the translate features in the hardware, and MODE
keyword specification, each 6-hole character on a card is transferred into the user’s I/O
:
area as an EBCDIC or ASCII 8-bit byte.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

C-il

1 234567890
7

II II 2027 22232123 36272929 32 37 32

121394

1276II6?27t7273747576777I79a0Ii2l3941Sj6g7ne6o,,29399,sfl

67 96 99 0010

A
8
4
2

8
4

Digit
Punches

9192721 22 03 242026 77 24 26 30 32 32

••
....

••

•

••

4766

6* #70 #72 #74 #76 #76

lao P
62

#44 #86 $i

90
•t

#9290 94 69 16

003700

111213141516171819101

NUMERIC CHARACTERS
Zone
Punches

24727124

1
-#2136#39#10#4?434V4$4?474?49#5, ?
595
V
335
ft
BISIII•••••CIII
AISSIS..
•I•••II
8
•Ise••ss
•••.•••••.••
4
5•IS
•I•I
Ills
•l•I
2
•
•I•
IS
•
II
ISIS
1

{
(iJ

12010221224

....
•
•

02 02 104 IQS 0677776 109 70 1123114115’lZ’iT lii

B
A
• 8
4
2
t• 1

A
88

5
•

22
1

4444
22
1
1

ALPHABETIC CHARACTERS
Zone
Punches
Digit
Punches

.f•

B
A
(ê 8

‘

•

2
1

SPECIAL CHARACTERS
Zone
Punches
Digit
Punches

c .ii
•

5•

A
8
4
2
1

BBBBBBBBBBBBBBBBBB
AAAAAAAA
AAAAAAAAA
88
88
88
4444
4444
4444
22
22
22
22
22
22
1
1
1
1
ii
1
1
1
1
1
1
1
1

:ii: i: :ii: n i:: ii;iz

(blank)

BBBBBBBBBBBBBB
AAAAAAA
AAAAAAA
888888888888
888888888888
4444
4444
4444
4444
2222
22
22
22
2222
22
1
1
1
1
1
1
1
1
1
1
1
1
1

Figure C—3. 96-Column Card Punch Codes

A
8
4
2
1
B
A
8
4
2
B
A
8
4
2
1

•

-I,

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

D-1

Appendix D. Labels for Disk Files

Di.

GENERAL

This appendix describes the system standard labels for disk files in OS/3 as well as the
optional user standard labels that are supported by OS/3 data management for processing
disk files described by the DTFSD, DTFNI, and DTFDA macros. Note that OS/3 ISAMdoes
not support user labels for DTFIS files (The user standard labels are described in D 4)
Because your files within a disk volume may be stored in various locations a directory
listing the addresses of the fragments of the files is required. This directory, called the
volume table of contents (VTOC), and your files within a disk voIume require various
standard labels in predefined formats to describe the properties of the files and the
volumes on which they reside
The system standard disk labels include the volume label (VOL1 label) and seven types of
format labels. These labels may, according to their use, be separated into two distinct
groups:
•

Volume Information Group
—

—

•

VOL1 label
Format 4 label
Format 5 label
Format 6 label
Format 0 label

File Information Group
—

—

Format 1 label
Format 2 label
Format 3 label

The VOL1 label has a length of 84 bytes; all format labels are 140 bytes long.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

D-2

D.2. VOLUME INFORMATION GROUP
The volume information group, comprising the VOL1 label and the format 4, 5, 6, and 0
labels Identifies the volume and defines the VTOC, the status of the VTOC the available
space within the volume, and the device-dependent characteristics of the volume on which
the group resides.
Standard linkages maintained within the group are shown in Figure D—1. The VOL1 label,
normally the first label in the group to be referenced, is written at cylinder 0, track 0,
record 3 on each volume. The VOL1 label identifies the volume and contains a link to the
format 4 label. The format 4 label defines the extent occupied by the VTOC and the deviceindependent characteristics of the volume; it also supplies a link to the first format 0 label.
Each label in the VTOC that describes label records not in use is defined as a format 0
label and is linked to the next available format 0.
The format 4 label also supplies a link to the first format 6 label, which defines space
available within the extent areas of files sharing extents (split cylinder allocation) If more
format 6 labels are required, they are linked in the same manner as format 0 labels. The
format 6 label and its link from the format 4 label will be present only if split-cylinder
allocation has taken place
The first (or only) format 5 label immediately follows the format 4 label supplying an
implied linkage. The format s label defines unüsèd space on the volume in terms of full
cylinders. Successive format 5 labels, if required, are linked one to another. The VTOC
extent, as specified in the format 4 label, supplies an additional linkage because it is this
area that must be searched in order to access the file information groups

Figure D—/.

VTOC Volume Information Label Group

SPERRY UNIVAC OS/3

UP-8068 Rev. 4

D—3

BASIC DATA MANAGEMENT

D.2.1. VOL1 Label
As each disk volume enters the system, it is given a unique identification code or volume
serial number and the rudiments of a VTOC. The volume serial number and the address of
the VTOC are placed in the VOL1 label.

The VOL1 label, identified by a key field and label identification field containing “VOLl
written by the disk initialization routine at cylinder 0, head 0, record 3.

“,

The VOL1 label is the standard volume label in the OS/3. All reference to the VTOC of a
given volume is made by first obtaining the VOL1 label, verifying the volume serial
number, and, because the location of the VTOC may vary from volume to volume, using
the VTOC address contained in the VOL1 label to locate the VTOC itself.
The format of the VOL1 label is shown in Figure D—2; Table D—1 summarizes its
contents.
BYTES

0
V

4
label number

label identifier
8
volume serial number
12
volume security
16
volume table of contents address
24

reserved

44
owner name and
address code

reserved

Figure D—2.

VTOC VOL1 Label

Table D—1.

Label
DL$VL

Initialized

Disc prep

DL$VL1

DL$VSN

Contents of VOL1 Label

Bytes

Code

0—3

EBCDIC

DL$VSB

Disc prep

DL$VTC

Disc prep

Key

—

contains VOL1.

Label identifier

Label number

8—13

Volume serial number a unique code
assigned to a disc pack when it enters
the system. The same code should appear
visually on the disc pack for operator
identification.

—

VOL.

always 1.
—

Binary

Volume security

15—24

Discontinuous
binary*

VTOC address This field is used to point
to the format 4 label, which starts the
VTOC. The address is in the form cchhr in
bytes 15 through 19. Bytes 20 through 24 are 0.

25—44
DL$ONR

Description

4—6

;

45—54

55—83
*

D-4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

—

reserved for future use.

—

Reserved
EBCDIC

Optional owner name and address code
an installation-supplied user identifier.

—

Reserved

For discontinuous binary, each subfield is treated as a distinct binary entity. In the notation cchhr, each
different letter represents a subfield.

D.2.2.

Disk Format 4 Label

The format 4 label describes the VTOC itself and is the first record of the VTOC. An
indicator in the format 4 label states whether the format 5 label contains valid
information. In addition to describing the area occupied by the VTOC and its current

status, the format 4 label contains information on all device-dependent characteristics of
the volume on which it resides.
The format 4 label is written by the disk initialization routine at the disk address specified
in the VOL1 label. Only one format 4 label may exist on a given volume.
The address of the first available label record (i.e., a format 0 label) is placed in the format
4 label for use by OS/3 disk space management. An additional linkage is created and
maintained by disk space management that specifies the first active format 6 label and is
used only during split-cylinder allocation of data files. Figure D—3 shows the format 4
label; Table D—2 summarizes its contents.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

D-5

BYTES
2

-I

key field

format D

last active format 1

available file label records

highest alternate track
52

number of alternate tracks

reserved

number of extents

56
reserved

device size

track length

64
record overhead

flag

68
tolerance

labels

72
pointer to format 0 label

reserved

96
pointer to format 6 label

104

VTOC extent

112

reserved

136

Figure D—3.

Disk Format 4 Label

blocks

0-6

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP8O68 Rev. 4

Contents Of Disk Format 4 Label (Part 1 of 2)

Table D—2.

!zed
by

Label
DL$KY4

Disàprep

Bytes
0—43

Description

Code
Hexadecimal

Key field Each byte of this
field contains 0416.

DL$1D4

bisc

EBCDIC

Format ID always 4 for
format 4 label.

DL$LF4

Space mgmt

45—49

Discontinuous
binary

the address,
Last active format 1
in the form CCHHR, used for a search
on fiIename

DL$AF4

Disc prep

50—51

Binary

Available file label records
number of Onused records inthe VTOC.

DL$HA4

Disc prep

52—55

Discontinuous
binary

Highest alternate track address, in
the form CCHH, of alternate tracks
set aside in cae of bad tracks.

DL$AT4

Disc prep

56—57

Binary

Number of alternate tracks.

DL$V14

Space mgmt

—

Reserved for VTOC indicators
Bit

DL$XC4

DL$DS4

DL$TL4

Meaning

Contents

A format 5 label, if
present, contains
invalid information.

1—7

Unused

Number of extents contains 0116
indicate the one extent in the VTOC.

Disc prep

60—61

Reserved

Disc prep

62—65

Device size indicates the number of
cylinders and the number of heads per
cylinder on the device, in the form
CCHH:

Disc prep

66—67

Track length number of available
bytes on a tráàk exclusive of home
address and record 0.

Binary

—

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table D—2.

D-7

Contents of Disk Format 4 Label (Part 2 of 2)
V

Label

Initialized
by

Bytes

DL$R04

Disc prep

68—70

Code

Description

Record overhead— ILK describes
overhead
bVteô track, whée
I is for keyed record which is
not the last on track, L is for
keyed record which is the last
on traäk, and K is a decrement
applied to records which have
no key.
V

V
V

DL$FG4

Disc

prep

Binary

Flag

V
V

—

Bit

Meaning

0—5
6,7

Reserved
Device-dependent

characteristics

Disc prep

DL$T04

72—73

Tolerance a device-dependent
factor which is used to calculate
effective record lengths for that
device.
—

DL$LT4
V

Disc prep

Labels per track a devicedependent factor specifying the
number of 140-byte labels possible
in a VTOC track.

—

DL$BK4

Disc prep

DL$F04

Disc prep

76—80

DL$F64

Space mgmt

Blocks per track a devicedependent factor specifying the
number of directory blocks of a
partitioned file which can be
written on a track.
—

Discontinuous
binary

Format zero address in the form
CCHHR points to the first available
format zero record in the VTOC.
—

81—99

Reserved.

100-1 04

Format 6 addréssin the form
CCHHR points to the first
format 6 label created by
space management.

VV
V

—

DL$VX4

Disc prep

105—114

VTOC extent describes the extent
occupied by the VTOC itself. The
format of this field is identical
to the fields describing the extent
in the format 1 and 3 labels.

115—139

Reserved.

—

D.23.

D-8

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Disk Format 5 Label

The format 5 label is the second record in the VTOC and is used to maintain control of the
available extents in the volume at any time
The format 5 label is initialized by the disk initialization routine and maintained by the disk
space management routine. Each format 5 label may define up to 26 available extents.
Format 5 labels may be linked together should more than one become necessary. Figure
D—4 shows the format 5 label; Table D—3 summarizes its contents.

BYTES
0

key identification

relative track address

no. of cylinders in extent

no. of tracks in addition

available extent

available extents

format ID

available extents

r
136

format 5 pointer

Figure D—4.

Disk Format 5 Label

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table D—3.

Label

Initialized
by

Bytes

D-9

Contents of Disk Format 5 Label

Code

Description

DL$1D5

Disc prep

0—3

Hexadecimal

Key identification
Each byte of this
field contains 0516.

DL$XT5

Disc prep

4—5

Discontinuous
binary

Relative track address

DL$XC5

Disc prep

6—7

Binary

Number of cylinders in extent.

DL$XE5

Disc prep

Binary

Number of tracks in extent in addition to
the cylinders.

Space mgmt

9—13

Available extent describes another extent
in fields with the same format as bytes 4
through 8 above.

Space mgmt

14—43

Six more available extents.

DL$Fl5

Disc prep

DL$XS5

Space mgmt

45—134

DL$CP5

Space mgmt

135—139

D.2.4.

—

start of extent.

—

EBCDIC

Format ID

—

always 5, for format 5 label.

Eighteen more available extents.
Discontinuous
binary

Pointer indicates the address of another
format 5 label, in the form CCHHR. Binary 0
if no further label.
—

Disk Format 6 Label

The format 6 label is used to control split-cylinder allocation. Each format 6 label contains
a code that identifies all member files sharing the same extent area. Each member file is
allocated from 1 to n tracks within each cylinder allocated to the set, where n is the
number of tracks per cylinder, minus one. Additionally, a head pool is maintained that
specifies all tracks not currently allocated and available for use by new members of the
same split-cylinder set. A format 6 label will be created for each split-cylinder set defined.
The format 6 label is created and maintained by the disk space management routines.
Each label contains the disk address of the format 3 label that defines the extents
allocated to that split member set. The disk address of the first format 6 label is
maintained in the format 4 label. If more than one format 6 label is required, they are
linked together.
Note that no extent information is maintained in the format 1 label of a splitcylinder file
and that all members of a split-cylinder set share a common format 3 label. Figure D—5
shows the format 6 label; Table D—4 summarizes its contents.

D-1 0

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

higO 0.08

k.y dll

108
,:.‘,,,,,,,.

.......

FigUre D—5. Disk Format 6 Label
Table D—4

Initialized
by

Label

DL$H.H6
DL$SET

Hexadecimal

0—2
3

Description

Code

Bytes

Space mgmt

DL$1D6

Contents of Disk Format 6 Label

Key identification

always 06060616

Device high head.
Set identifier identifies each
member file of the split-cylinder set.
—

DL$1DF36

6—9

Discontinuous
binary

Disk address of the format 3 label
shared by all member files

DL$LHA6

Hexadecimal

Low head available in the specified
extent areas.

.
.

DL$HHA6
.

‘.

Hexadecimal

High head available in the
specified extent areas.

Hexadecimal

Nine additional entries for low and
high available head.

12—29

Space mgmt

DLeIDF16
:

30—33

Hexadecimal.

Format 1 disc address of primary
mehiber (CCRH)
1,9 additional split set format 1
disc address entries in the same
format as bytes 30-33.

34—109

Hexadecimal

Format 1 label disk addresses of up to 19
additional members of the split-cylinder
set in the same format as bytes 30—33

.‘

110—133

Reserved

DL$Fl6

134

Hexadecimal

Format identification .X’F6’.

DL$CP6

135—1 39

Discontinuous
binary

Pointer to next format 6 label
in the form CCHHR.

UP8O68 Rev. 4

D.2.5.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

D-1 I

Disk Format 0 Label

The format 0 label is used to identify label records in the VTOC not currently in use
Format 0 records are initialized by the disk initialization routine. The address of the first
format 0 is placed in the format 4 label, and each format 0 label is linked to the next. The
remainder of the label is filled with binary 0’s. Figure D—6 shows the format 0 label;
Table D—5 summarizes its contents.
BYTES
0

pointer to next available format 0 label

reserved

136

Figure D—6. Disk Format 0 Label

Table D—5.

Label

Initialized
by
Disc prep

Bytes

Contents of Disk Format 0 Label

Code

cescription

0—4

Discontinuous
binary

Disc address in the form CCHHR of
the next available format 0 label.

5—139

Binary zero

Reserved.

D.3.

D-12

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev.4

FILE INFORMATION GROUP

The file information group (Figure D—7) is composed of the format 1, format 2, and format
3 labels. The format 1 label is normally the first referenced label of the group. It is
obtained by executing a key search for the file ID in the VTOC extent defined in the format
4 label.
The format 1 label defines the characteristics of the file and may define up to three
extents occupied by the file. The format 1 label is linked to the format 2 label, which is
used to further define the file. These two labels are present for each file in the volume.
The format 3 label is used to define the extent area occupied by the file and is an optional
label, except that it will exist for all files created by using split-cylinder allocation. For all
other files, the format 3 label will exist only if the file occupies more than three separate
extent areas.
NONISPLIT FILES

OCCUPYING THREE
EXTENTS OR LESS

SPLIT-CYLINOER FILES

Figure D—Z

OCCUPYING MORE THAN
THREE SEPARATE EXTENTS

File Information Group Label Chain

D.3.1.

0-13

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT.

UP-8068 Rev. 4

Disk Format 1 Label

A format 1 label exists for each file in a volume. As many as three extents of a file may be
described in the format 1 label, provided that the file is not a member of a split-cylinder
set.
The format 1 label is initializedbythe disk space management routines. It is maintained by
both the space management and data management routines. The format 1 label contains a
pointer to the format 2 label. Figure D—8 shows the format 1 label; Table 0—6
summarizes its contents.
BYTES

fileD (key field 44 bytes(

fatmatiD

seeialfi(enumbee

euluteeeeqaeeceeo.

eap::too date

fOe

optitte todes

aaeat(ott date

e(uttte teqeettee Ca

PCAtblocksiee

PCAleeca,daae

PCA 2 tpeoifieatloot

PCA 1 ,eoatd focetat

PCA 3 tpeotf(oatiotte

PCA4spec(f(oatione

PCA 5 specifIcations

fications

PCA 7 specificatioos

key location fan (SAM

100

104

(lie higft hspd

a((ocatio:inceettoeot

ectent type

108

(octet litttif

112

cope’ tidal

eafeot eaqoence no.

second ectect (lObyteo(

136

file tet head

bone honit

tppet until

116

128

data eat ittdicetot

thitd eateot (l0byfeo(

fo,tttat 2 paints,

Figure D—8. Disk Format 1 Label

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table D—6.

Label
DL$KEY1

Initialized
by
Space mgmt

D—14

Contents of Disk Format 1 Label (Part 1 of 5)

Bytes

Code

Description

0—43

EBCDIC

File identifier Each file must
have a unique 1- to 44-byte name
in this key field, the first six bytes
of which may be a lock ID. A
search of the VTOC is made on
this name.

EBCDIC

Format identifier
format 1 label.

45—50

EBCDIC

File serial number—identifies the
volume on which the file starts, is
a 6-digit alphanumeric number, and
is the same as the volume serial num
ber of the volume on which the file
starts. The first volume of a file
is defined by the first job control
DVC statement in the device assign
ment set for the file.

51—52

Binary

Volume sequence number indicates the
number of this volume relative to the
first volume in the file. The first volume
of a file is defined by the first job control
DVC statement in the device assignment
set for the file.

53—55

Discontinuous
binary

Creation date format is YDD (year
day-day), where V is 0 to 99, and DD
is1to366.

DL$ED1

56—58

Discontinuous
binary

Expiration date the date when the
file may be deleted. Format is the
same as the creation date.

DL$XC1

Binary

Extent count specifies the number
of extents currently constituting
the file, or portions of it, on this
volume.

Binary

Option codes

DL$lDl

DL$FS1

Data mgmt

DL$VS1

DL$CD1

DL$OC1

Space mgmt

—

always 1, for

—

Bit

Content

Meaning

Preformatted by VTOC

Allocation by cylinder

New file

Partitions cylinder aligned

4—7

Unused

D-1 5

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table D—6.

Label

initialized

Contents of Disk Format 1 Label (Part 2 of 51

Bytes

bescrption

Code

DL$PC1

Data mgmt

Binary

PCA count number of partitions
which constitute the file.

DL$FT1

Data mgmt

Hexadecimal

File type

—

Hexadecimal
Code

Meaning

Sequential (DTFSD)

Direct access (DTFDA)

Nonindexed (DTFNI)

Indexed sequential (DTFIS)

IRAM(DTFIR)or
MIRAM(DTFMI)

SAT (DTFPF)

Undefined

00
63

Hexadecimal

File type
Hexadecimal
Meaning

Code

00:

lRAMfilenonindexed

1RAM file, indexed

M1RAM file, IRAM
characteristics

MIRAM file, MIRAM
characteristics

NOTE:
Thisbyte is meaningless unless byte 62
equals X’90’.
DL$BL1 Datamgmt

64—65

Binary

Reservedfor PCA1 block length
size of fixed-length blocks or
maximum size of variable-length
blocks.

—

DL$RL1

Data mgmt

66,67

Binary

Reserved for PCA1 record length
size of fixed-length records or
maximum size of variable-length re
cords.

DL$RF1

Data mgmt

Binary

Reserved for PCA1 record format

—

Bit

Content

Reserved

0,1
2

Meaning

0
1

Records have no keys.
Records have keys.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table D—6.

Label

Initialized
by

D-16

Contents of Disk Format 1 Label (Part 3 of 5)

Bytes

Code

Description
(Record format, àont)

DL$DS1

DL$KL1

Bit

Content

Meaning

Fixed-length blocked
records

Variable-length
blocked records

Fixed-length un
blocked records

Variable-length
unblocked records

Records are inter
laced.

Data mgmt

69—73

Discontinuous
binary

Partition descriptor 2; block size,
record size, and record format for partition 2.

Data mgmt

74—78

Discontinuous
binary

Partition descriptor 3.

Data mgmt

79—83

Discontinuous
binary

Partition descriptor 4.

Data mgmt

84—88

Discontinuous
binary

Partition descriptor 5.

Data mgmt

89—93

Discontinuous
binary

Partition descriptor 6.

Data mgmt

94—98

Discontinuous
binary

Partition descriptor 7.

Space mgmt

Binary

Data set indicators
future use.

Data mgmt

100-1 01

Binary

Key location high order position
of key field within each data record
of an
indexed-seqUential file.
—

—

reserved for

Table D—6.

Label

0-17

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP8O68 Rev. 4

Initialized
by

Contents of Disk Format 1 Label (Part 4 of 5)

Bytes

Description

Code

DL$SA1

102

Binary

Secondary allocation increment
the number of cylinders of disc
storage to be requested for each
dynamic extension of the file.

DL$LH1

103

Hexadecimal

File low head
allocation.

DL$HH1

104

Hexadecimal

File high head
allocation.

DL$XT1

105

Hexadecimal

Extent type indicator

—

split cylinder

—

Code

Meaning

No valid extent described

Sequential file (DTFSD)

Direct access file (DTFDA)

Nonindexed file (DTFNI)

Indexed sequentialfile (DTFIS)

IRAM (DTFIR) or MIRAM (DTFMC)

SAT (DTFPF)

Job Control

DL$XS1

106

Binary

Extent sequence number relative number
of extents in multiple-extent volume.

DL$XL1

107-1 10

Discäntinuous
binary

Lower limit the address specifying
the start of the extent, in the

—

form CCHH.

Table D—6.

Label

Initialized
by

DL$CP1

Contents of Disk Format 1 Label (Part 5 of 5)

Bytes
111—114

DL$XU1

D.3.2.

D-18

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Space mgmt

Description

Code
Discontinuous
binary

Upper limit the address specifying
the end of the extent, in the form CCHH.
—

115—124

Second extent same format as described
for bytes 105 through 114.

125—134

Third extent

135—139

—

Discontinuous
binary

—

same format as second extent.

Continuation pointer the address of a format
2 label. The address is in the form CCHHR.
—

Disk Format 2 Label

The format 2 label is used as an extension to the format 1 label to further describe the
file.
For nonindexed files (DTFSD, DTFDA, DTFNI), bytes 1 through 43 are used to carry
partition information in a maximum of seven 6-byte entries. For indexed ISAM files, bytes
13 through 43 are used to carry index control information. For IRAM and MIRAM files,
bytes 1 3 through 43 are used to carry index control and file characteristic information. For
library files, bytes 32 through 47 are used to carry information on the library text and
directory; bytes 13 through 31 contain binary zeros.
The format 2 label is initialized by space management and maintained by data
management. The label is always present and is linked from the format 1 label. The link
field in the format 2 label will point to a format 3 label, if used. This pointer will be
present for all split-cylinder files and for nonsplit-cylinder files requiring more than three
extents If it is not present the field is filled with binary zeros Figure D—9 shows the
format 2 label; Table D—7 summarizes its contents. The format of the ISAM file
information area is shown in Figure D—1O, and the contents of this area are listed in
Table D—8. The format of the IRAM/MIRAM file information area is shown in Figure
D—1 1, and the contents of this area are listed in Table D—9. The format of the library file
information area is shown in Figure D—12, and the contents of this area are listed in
Table D—1 0.

0-19

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

nonindexed LBC

key length or lace factor

reserved

BYTES

key ID

nonindexed LBC

EOD ID

reserved

key lenth or lath factor

EODID

(up to five additional partition descriptors)

40
blocks/track, PCA1

reserved

1516
relative track addr,2*

PCA2ID

tracks

relative track addr-1 *

PCA1 ID

tracks
15

/ \,/

128

tracks per cylinder

132

relative extent count

136

file low head no.

flags

format 3 pointer

*Thirtn bits can represent a maximum relativetrack address (RTA) of
). To support the larger 8433
16
(1 FFF
disc, the high-order bit of the tracks field (bit 16) of the logical extent is used to indicate that the RTA must be increased
(See Table 0—7.)
by aconstaht value of

io
8192

Figure D—9.

Disk Format 2 Label, Nonindexed Files (DTFSD, DTFDA, DTFNI)

u—Lu

SPERRY UNIVAC OS/
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

BYTES

disc address of last prime

current independent overflow address

disc address of last block level

reserved

overflow record count

prime data load count

number of cylinders having
overflow space full

data record, plus 1

overflow retrieval count, except
first of chain

index record, plus 1

total count of prime data records

reserved

bytes of main storage required
for top index

number of blocks per
cylinder

Figure D— 10.

number of records tagged
for deletion

ISAM (DTFIS) File Information Area, Disk Format 2 Label

13
BYTES

key length for key 1

key location for key 1

used for IRAM processing
key characteristic

descriptor for...

flag_byte_(MIRAM)

key 2

descriptor for...

...key 3

descriptor for...

...key 4

descriptor for...

...key 5

...in file, plus 1

number of index levels

sector
offset

number of records...

record size

last fine-level index block

NOTE:
Descriptions that pertain to IRAM files also apply to MIRAM files with IRAM characteristics.

Figure D—1 1.

IRAM/MIRAM File Information Area, Disk Format 2 Label

fine-level index
block size in
sectors

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

0-21

BYTES
28

directory partition lace factor

directory partition lace adjustment factor

text partition face factor

text partition lace adjustment factor

number of library blocks per track

NOTE:
In the format 2 label for library files, byte 3 and bytes 13—27 are reserved and contain binary zero.

Figure D—12.

Library File Information Area, Disk Format 2 Label

Table D—7.

Label

Initialized
by

Contents of Disk Format 2 Label (Part 1 of 3)

Bytes

Description

Code

DL$S102

Space mgmt

DL$SPC2

Data mgmt

Nonindexed last block control the number
of logical records in the last block of the
partition for fixed-length blocked files.

DL$SLF2

Key length or lace factor.

DL$SLA2

Reserved

DL$SEP2

Data mgmt

4—6

Hexadecimal

—

Binary

7—12

Data mgmt

13—43

Key identification X02’

End of data ID relative block address plus
1 of the last block written into the partition.
—

A 6-byte partition descriptor entry
in the same form as bytes 1—6.
Hexadecimal

For nonindexed files, up to 5
additional partition descriptors.
For ISAM files, see index information
area (Table 0—8 and Figure 0—10).
For IRAM and MIRAM files, see
IRAM/MIRAM information area
(Table D—9 and Figure D—1 1).
For library files, see library information
area (Table 0—10 and Figure D—12).

44—45

Unused (binary zero) for all but indexed files;
reserved for indexed files.

D-22

SPERRY UNIVAC .OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table D—7.

Initialized
b

Label

Bytes

Datamgmt

48—127

Description

Code

Blocks pertrack the number of blocks per
track in the first or only partition of the file.

46—47

DL$SBPT2

DL$SXAR2

Contents of Disk Format 2 Label (Part 2 of 3)

—

Discontinuous
binary

Logical extent table area— These entries are
4 bytes in length and specify PCA ID in 3
bits, starting relative track address in 13 bits,
and number of tracks in that address.
From one to twenty 4-byte logical extent
entries may be placed in this 80-byte area.
Each 4-byte entry has the following format:

DL$TPC2

128—129

DL$FLH2

130—131

132—133

DL$SXCT2
.

134

DL$SFL2

Hexadecimal

Bit

Meaning

0—2

The high-order three bits of the
logical extent identify the parti
tion to which it is assigned. (This
value may be from 1. to 7.)

3—15

The next 13 bits indicate the relative
track address of the logical extent.

16—31

If the first bit (bit 16) of the track
field is set on, a value of 8192 must
be added to the relative track
address to indicate the relative
track address of the logical extent
on the 8433 disc. The remaining 15
bits indicate the number oftracks
contained ir the extent.

Tracks per cylinder for this file.
File low head the lowest head
number intheassigned cylinders
accessible for this file.
—

Number of relative extents contained
In this label.
Flags
Bit

Content

Meaning

Reserved

3
4
5

Library lace adjustment,
type2

Library lace adjustment,
type3

1..

9400SAT compatible

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table D—7.

Label

Initialized
by

DL$SCID2

Space mgmt

Contents of Disk Format 2 Label (Part 3

Bytes

Code

135—139

Discontinuous
binary

Table D—8.

Label

D-23

of 3)

Description
The disc address, in the form CCHHR,
of the format 3 label (if required)
associated with this file.

Contents of Indexed File Information Area, Disk Format 2 Label

Initialized
by

Bytes

Code

Description

13—17

Discontinuous
binary

Discaddress of last prime data record (plus 1),
in the form rrrbb, where rrr relative block
address and bb = displacement within the
block

DL$NMA2

18—19

Hexadecimal

Count of cylinders having overflow space
filled

DL$10F2

20—23

DL$PDLC2

24—25

Discontinous
binary

Prime data load count

26—27

Hexadecimal

Count of the number of overflow records in
the file

DL$PID2

DL$NMO2

Data
management

Current address of independent overflow (rrr)

Reserved

—

DL$BID2

29—33

DL$NMR2

34—35

Discontinuous
binary

Overflow chain retrieval count, not first
otchain

DL$NMT2

—

Total count of number of prime data records

37—39

DL$NMP2
DL$NMS2

Reserved

—

Data
management

40—41

Disc address of last block level index record
(plus 1), in the same form as bytes 13—17

Hexadecimal

Number of bytes required to hold top index
in main storage

42—43

Number of records user has tagged for
deletion

44—45

Number of blocks per cylinder

UP-Ob

Hey.

rtrtrT

uIIvMi. JO/3

BASIC DATA MANAGEMENT

Table 13—9.

Label
DL$XILOC

Initialized
by
Data mgmt

Contents of /RAM/M/RAM File Information Area, Disk Format 2 Label

Bytes
1 3—1 4

Hexadecimal

Key location for key 1
Key length for key 1

15
16

Description

Code

Hexadecimal
(IRAM)

Used for IRAM file index processing

Binary
(MIRAM)

For MIRAM files, byte 16 contains key 1
characteristics:
Bit
0

Content
1

Meaning
Duplicates allowed
for this key

Key change allowed
for this key during
during update
Unused

2—4

17—20

Discontinuous
binary

Index-only records
permitted in this file

Variable-length
record format

Record control byte
(rcb) present

Descriptor for key 2 (binary zeros for IRAM)

21—24

Descriptor for key 3 (binary zeros for IRAM)

25—28

Descriptor for key 4 (binary zeros for IRAM)

29—32

Descriptor for key 5 (binary zeros for IRAM)
Hexadecimal

Sector offset for files created with recovery

DL$MARSO

DL$COUTR

34—36

Number of records in file (plus 1)

DL$REC

37—38

Record size

DL$CSIZ

Fine-level index block size in sectors

DLSCLEV

Number of index levels

DL$FAB

41—43

Relative block number of last block of the
fine-level index

*These bit positions areunused in the descriptors for keys 2 through 5.
NOTE:
Descriptions pertaining to IRAM files also apply to MIRAM files with IRAM characteristics.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table D— 10.

Label

Contents of Library Information Area, Disk Format 2 Label

Bytes

Code

Description

DL$DIRL2

Data
management

28—31

Hardware-adjusted lace factor for the directory
partition

DL$DIRF2

Data
management

32—35

Rotational adjustment for directory lace factor

DL$TXTL2

Data
management

36—39

Hardware-adjusted lace factor for the library
text partition

DL$TXTF2

Data
management

40—43

Rotational adjustment factor for the library’s
text

Data
management

44—47

Number of library blocks per track

—

D.3.3.

itzed

D-25

Disk Format 3 Label

The format 3 label is used to maintain extent information for the file. For split-cylinder
files, a format 3 label is always present. For files not using split-cylinder allocation, a
format 3 label for the file will exist only when more than three extents are required.
The format 3 label is initialized and maintained by the disk space management routines.
The format 3 label, when required, will always be linked from a format 2 label. Figure
D—1 3 shows the format 3 label; Table D—1 1 summarizes its contents.

D-26

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

8YTES...

0
-

extent type indicator

key identification

lower limit

extent sequence no.

upper in it

lower limit

upper limit
12

extent 5
24

extent 6

extent 7

44
format ID

extent 8

E
r

—,

128
extent 16

J
136

pointer

Figure D—13. Disk Format 3 Label

SPERRY UNIVAC osia
BASICDATA MANAGEMENT

UP-8068 Rev. 4

Table D—1 1.

Label
DL$I D3

Initialized
by
Space mgmt

Bytes
0—3

Contents of Disk Format 3 Label

Code

Description

Hexadecimal
.,

DL$XT3

D—27

Hexadecimal

Key identification
contains 0316.

—

each byte

Extent type indicator

—

Code

Meaning

00
01

No valid extent described,
Prime data area

DL$SN3

Binary

Extent sequence number relative
number of extents in this volume of
the file.

DL$XL3

6—9

Discontinuous
binary

Lower limit starting track address
of the extent, in the form CCHH.

DL$XU3

10—13

Discontinuous
binary

Upper limit terminating track
address of the extent, in the form CCHH.

—

14—23

Extent 5 same format as described
for bytes 4 through 13 for this
extent.

24—43

Extents 6 and 7.

DL$Fl3

—

EBCDIC

DL$XS3

45—134

DL$CP3

135—1 39

Format identifier
format 3 label.

—

always 3, for

Extents 8 through 16.
Discontinuous
binary

Pointer.— address of next format 3
label, in the form CCHHR. Binary 0
if nofurther label.

D—28

SPERRY UNIVAC OS/3

UP-8068 Rev. 4

BASIC DATA MANAGEMENT

OPTIONAL USER STANDARD LABELS

D.4.

Optional user standard labels are records made available to you via your label processing
routine (LABADDR) at the opening or closing of a disk volume. OS/3 data management
supports user standard: labels for your SAM and DAM disk files described by the: DTFSD,
DTFNI, and DTFDA declarative macroinstructions; it does not support them for your ISAM
files, which are described by the :DTFIS macro.
D.4.1.

User Header Labels

If you require user header labels, these will be written on the first track of each volume of
a DTFSD file and on the first track of the first volume of a DTFDA or DTFNI file. You may
write a maximum of eight labels. Figure D—14 shows the format of the 80-byte user
header label; its contents are explained in the table below Figure D—14.
0

label ID

label data

76
[________________________________________________________________

Field

Bytes

Code

DescriptiOn

Label ID

0—3

EBCDIC

Contains 4-byte label
identifier: UHL, followed
byalabel number which
ranges from 1 through 8.

Label data

4—79

User option

Contains 76 bytes of user
specified header label data.

Figure D—14.

Optional User Standard Header Label

UP-8068 Rev. 4

0.4.2.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

D-29

User Trailer Labels

If you need user trailer labels, these will be written on the first track of each volume of a
DTFSD file and on the first track of the first volume of DTFDA or DTFNI. files, following
your user header labels. You may write a maximum of eight labels on DTFDA and DTFNI
files, and eight labels per volume on DTFSD files. Figure D—15 shows the format of the
80-byte user trailer label; its contents are explained in the table below Figure D—1 5.
0

label ID

4
F

label data

F
Field

Bytes

Code

Description

Label ID

0—3

EBCDIC

Contains 4-byte label
identifier: UTL,
followed by a label
number which ranges
from 1 through 8.

Label data

4—79

User option

Contains 76 bytes
of User-speöified
trailer label data

Figure D—15.

Optional User Standard Trailer Label

D.5.

D—30

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

8413 DISKETTE FILE LABEL

Figurè D—16 illustrates the 8413 diskette file label form at. Table D—--12 Explains the
contents of eaóh field ih the diskette file Iàbèl.
3

label ID
0
reserved

file identifier

notused

20
record attribute

block length

24
beginning of extent (BOE)

28
physical record

length
record/block format

end of extent (EOE)
36
bypass

exchange type md

write protect

file security

40
volume séqüence ho.

multi-volume md.
44

file creation date
48

record length

reserved
60
reserved

64
file expiration date
68
verify/copy

md.

file org.

72
end of data

(EOD)

reserved

76
80

124
Figure D—1 6.

8413 Diskette File Label Format

—

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table D—12.

Field

D-31

Diskette File Label Description (Part 1 of 2)

Description

Byte Position

label ID

0—3

Contains 4-byte label identifier HDR followed by the number 1

Reserved

File identifier

5—12

Names user file and is from 1 to 8 characters. First character must
be alphabetic and no blanks are allowed. Duplicate names on the
same diskette are not allowed.

13—21

Not used

22—26

Indicates the record size as follows:

—

Block length

Character

Meaning

Record size will be obtained from the DTF

1—128

Actual record size; for example, 80.

Record attribute

Blank; indicates unblocked records

Beginning of extent (BOE)

28—32

Identifies the address of the first sector of the file by cylinder
number (pos. 28—29), head (pos. 30), and sector number (pos.
31—32).

Physical record length

Indicates physical record length and is blank meaning 128 bytes per
record.

End of extent (EOE)

34—38

Indicates address of last sector reserved for this file and uses the
same format as BOE.

Record/block format

This field must be blank.

Bypass indicator

Indicates a file to be skipped during exchange or copy operations
when transmitting or transferring files on the volume. If position 40
is blank, the file is transferred; if B, the file is not transferred.

File security

Blank indicates the file can be accessed. Nonblank indicates
restricted access. When nonblank, the volume accessibility indicator
in the volume label (track 00, sector 07) must also be nonblank.

Write protect

Blank indicates both reading and writing allowed. P indicates only
read activities allowed.

Exchange type indicator

Blank indicates file can be used for basic exchange. Nonblank
indicates additional label checking is ne?ded to exchange the file

Multivolume indicator

Character

Meaning

blank

File on 1 diskette

File continued on next diskette

Last diskette on which file resides

Volume sequence number

45—46

Indicates volume sequence number in multivolume set (01—99).
Blanks indicate no volume sequence checking performed on this
device.

File creation date

47—52

Indicates the creation date of the file by year (YY), month (MM), and
day (DD). Blanks indicate nonsignificance of creation date.

Table D— 12.

Field

Record length

D-32

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Diskette File Label Description (Part 2 of 2)

Description

Byte Position

53—56

Defines record length.
fifb

record length equals block lehgth (position 22)

(This field is ignored because blank in position 43 means the same.)
Offset to next record space

57—61

Not used

Reserved

62—65

Reserved

File expiration date

66—71

Contains date of deletion for a file. (Format is the same as creation
date in position 47—52.)
file date expired
999999

Verify/copy indicator

file date never expires

Character

Meaning

blank

File is created

File is verified

File datasuccssfully transferred to another medium

File organization

If position 43 contains blank, this field must also contain blanks.

Endóf data (EOD)

74—78

Identifies address of next unused sector within the file extent using
BOE format.
—

—

Reserved

80—1 27
NOTE:
ISAM does not support-the 8413 diskette.

If EOD equals BOE, the extent contains a null file.
If EOD equals address of next block beyond-file extent
(unblocked records), entire extent was used.
If blocked records areused, EOD must be used with offset to
next record space (position 57—61) to find the actual EOD.

Reserved
Padded with binary zeros

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATAMANAGEMENT

Appendix E.

E-1

Magnetic Tape Labels

OS/3 SYSTEM STANDARD LABELS FOR MAGNETIC TAPE

This appendix describes the system standard labels for magnetic tape files and reels (or
volumes) in OS/3. Section 8 describes magnetic tape SAM. record formats, volume
organization, andfile conventions. Section 9 describes the functions and operations of
magnetic tape SAM, including certain of the label-processing functions of transients
entered by the OPEN and CLOSE imperative macros and the user’s own special label
processing routine (the address of which he provides to tape SAM by specifying the
LABADDR keyword parameter in the DTFMT declarative macro defining any standard
labeled magnetic tape file for which optional standard user header or trailer labels (UHL or
UTL) are to be processed). The LBRET imperative macro (9.4.9) is issued in the users label
routine to control returns to and from tape SAM
In OS/3 tape SAM, magnetic tapes may be labeled or unlabeled, and a labeled tape may
contain eithernonstandard or OS/3 system standard labels Tape volumes have formats
that may be specified as standard, nonstandard, or unlabeled, using theFILABL keyword of
the DTFMT declarative macro (9.2.6.1); unlabeled format is assumed if this keyword is npt
specified.
E.2.

SYSTEM STANDARDTAPE LABELS

All standard tape labels, including optional UHL and UTL are in blocks of 80 bytes There
are five tape. label groups: three required, two optional:
•

Volume label group

•

File header label group

•

User header label group (optional)
File trailer label group

•

User trailer label group (optional)

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASICDATA MANAGEMENT

E-2

E2.1. Volume Label Group
The volume label group comprises a single volume label, VOL1. The VOL1 label identifies
the tape reel and its owner and it is used to checkthat the proper reel is mounted (Refer
to Table 9—3). When a tape is first used at an installation, its volume serial number (VSN)
and other volume information, as shown in Figure E—1, are usually recorded on it
magnetically with the TPREP utility routine, being specified to the routine with parameter
cards. The volume serial number is also written on the exterior of the reel for visual
identification to the operator. For a detailed description of TPREP, refer to the system
service programs (SSP) user guide, UP-8062 (current version); note that you cannot use
this routine to prep a magnetic tape volume dynamically, although you may prep as many
as 36 volumes with it.
As an alternative to using TPREP, if you want tãpeSAMto prep the volurnesof astandard
labeled file dynamically, as a preliminary, part of the job step in which you create the file,
you specify the’ parameter (PREP) in the VOL job control statement of the file’s device
assignmentiet, also ‘specifying a unique VSN Data management then préps the volumes
from informatiOn you supply on the associated VOL and’:LBL’statements. This procedure is
described in 9 3 3 3
When you issue an OPEN macro to an output tape file, its open-and-rewind options are
executed first (9 2 5 2 and 9 2 5 3) and then the tape is checked to see if it is at the load
point If it: 5 atthe load point, data management reads”the VOL1 label (if’ it isnotinthO
prep mode) and, checking the VSN, saves this fo’r use in writing or reading the file header
labels (HDR1 and HDR2). It then positions your tape so ‘that the.volume:Iabels’ are not
destroyed, and no further volume label processing is performed.
If the outpUt tãe is not at “the’ load point after the openandrewind:options are executed,
tape SAM assUrnes ‘that it is positiOned between the two ending tape marks of the
previous file; orjust prior to the HDR1 label of an existing file. In either case, no volume
label checking or creation is performed.
For an input tape, the OPEN transient first executes the open-and-rewind options and then
checks to see whether the tape is at the load point. If it is, the VOLl labe[ is read and the
VSN is used to check the file serial number in the appropriate file header or trailer label.
The tape is then positioned to the’ proper file header or trailer label, as specified in”the file
sequence number field of the associated LB’L’jobcontrol statement (9.3.4),and nofurther
volume label processing is performed. If the input tape is not at the load point after your
open-and-rewind options are executed, tape SAM assumes that the tape is positioned
between the two ending tape marks of a previously created file, or just prior to the HDR1
label of an existing file. In either case, no further volume label processing is performed.
When any volume label is encountered during the processing of a CLOSE macroinstruction
for an input tape (9.2.5.4, 9.4.2), if you have specified READ=BACK (9.2.5.1), the label is
bypassed without processing. Figure E—1 shows the format of the VOL1 label; its fields
are described in Table E—1.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

BYTES

0
4
8
12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76

LEGEND:
Generated by data management or reserved for system expansion.

E:i Written by data management from user-supplied data.
Figure E—1.

Tape Volume 1 (VOL1) Label Format for an EBCDIC Volume

E—3

Table E—1.

Field

Tape Volume 1 (VOL 1) Label Format, Field Description for an EBCDIC Volume

Initialized By

Bytes

Code

Description

Label
identifier

Tape prep

0—2

EBCDIC

Contains “VOL” to indicate
that this is a volume label

Label number

Tapeprep

EBCDIC

Always’i”, for the initial
volume label

Volume serial
number

Tape prep

4—9

EBCDIC

Unique identification number
assigned to this volume by
your installation. Tape SAM
expects 1 to 6 alphanumeric
characters, the first of which
is alphabetic

Volume
security

Data Mgt

EBCDIC

Reserved for future use by
installations requiring
security at the reel level.
Currently blank

Reserved

11—20

EBCDIC

Contains blanks (4016)

Reserved

21—30

EBCDIC

Contains blanks (4016)

Reserved

31—40

EBCDIC

Contains blanks (4016)

41—50

EBCDIC

Unique identification of the
owner of the reel: any
combination of alphanumerics

51—79

EBCDIC

Contains blanks (4016)

Owner
identification

Tape prep

Reserved

E.2.2.

E-4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

File Header Label Group

The file header label group comprises two labels, HDR1 and HDR2, described in the
following subparagraphs.
E.2.2.1

First File Header Label (HDR1)

The first file header label (HDR1), which identifies the file, is written at the beginning of
each file. The HDR1 label is required and has the fixed format shown in Figure E—2; its
fields are described in Table E—2. All fields in the HDR1 label may be specified in the job
control stream.

UP-8068 Rev. 4

SPERRY UNIVAC OSt3
BASIC DATA MANAGEMENT

E-5

BYTES

%‘

4
8
file identifier
12
16
20
file serial number
24

volume...

sequence number

file...

sequence number

generation..

number

version..

number
creation date

44
48

expiration date

file security

unused

system code

68
72
reserved

LEGEND:
Generated by data management or reserved for system expansion.

fjj

Written by data management from user-supplied data.

Figure E—2.

First File Header Label (HDR1) Format for an EBCDIC Tape Volume

SPERRY UNIVAC OS/3
BASIC DATAMANAGEMENT

UP-8068 Rev.,4

Table E—2.

Field

First File Header Label (HDR1), Field Description

Description

Bytes

Label identifier

O—2

Contains “HDR” to indicate a file header label

Label number

Always”l”

File identifier

4—20

A 17-byte configuration that uniquely identifies
the file.-It may contain embedded blanks and is
left-justified in the field if fewer than 17 bytes
are specified.

File serial number

21—26

The same as the VSN of the VOL1 label for the
first reel of a file or a group of multifile reels

Volume sequence
number

27—30

The position of the current reel with respect
to the first reel on which the file begins.

File sequence number

31—34

The position of this file with respect to the
first file in the group

Generation number

35—38

The generation number of the file (0000—9999)

Version number of
generation

39—40

The version number of a particular generation
of a file

Creation date

41—46

The date on which the file was created,expressed
in the form YYDDD and right-justified. The
leftmost position is blank.

Expiration date

47—52

The date the file may be written over or used
as scratch, in the same form as the creation
date

File security indicator

Reserved for file secUrity indicator. Indicates
whether additional qualifications must be met
before a user program may have access to the file.
0 = No additional qualifications are required.
1

Additional qualifications are required.

Unused

5459

Unused field, containing EBCDIC 0’s

System code

60—72

Reserved for system code, the unique identification
of the operating system that produced the file

Reserved

73—79

ReServed field, containing blanks (4016).

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

E-7

For input tapes, all fields up to and including the system code field in the HDR1 label are
checked at file open against the values you specify in the LBL job control statement
(9.3.4), unless you have specified read-backward processing (9.2.5.1). If you have specified
READ=BACK, tape SAM bypasses the HDR1 label without processing it. For multifile input
volumes, you should specify the file sequence number in the LBL job control statement to
ensure proper tape positioning.
For output files, the tape must be positioned properly before you may open the files. On
file open, the expiration date in the HDR1 label is checked against the current or actual
calendar date to determine whether the associated file has expired. If it has not, data
management issues error message DM57, and it is not possible to write to the file. You
should mount the correct volume and rerun.

If the file has expired, the tape is positioned so that the old HDR1 label is overwritten. The
HDR1 label for the new file, set up from the values you specify in the LBL job control
statement, is written on the tape.
E.2.2.2.

Second File Header Label (HDR2)

The second file header label (HDR2) acts as an extension of the HDR1 label and is
required in standard labeled files. Unless the HDR2 label was created by OS/3, however,
as indicated in the system code field of the HDR1 label, tape SAM ignores the HDR2 label
on input tapes. Figure E—3 shows the format of the HDR2 label; Table E—3 describes its
fields.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

BYTES

LEGEND:
Generated by data management or reserved for system expansion.
Written by data management from user.supplied data.
Figure E—3. Second File Header Label (HDR2) Format for an EBCDIC Tape Volume

B-B

UP-8068 Rev. 4

SPERRY UNIVAC 0S/
BASIC DATA MANAGEMENT

E-9:

Table E—3, Second File Header Label (HDR2), Field Description

Field

Bytes

Description

Label identifier

0—2

Contains HDR to indicate a file header label

Label number

Always “2”

Record format character

Character
D
F
U
V

Block length

5—9

Record length

Variable-length, with length
fields specified in decimal
Fixed-length
Undefined
Variable-length, with length
fields specified in binary

Five EBCD1C characters specifying the maximum
number of characters per block

10—14

Five EBCDIC characters specifying the record length forrn
fixed-length records. For any other record format, this
field contains 0’s.

Reserved

15—35

Reserved for future system use

Reserved

36—79

Reserved for future system use

•,

E.2.3.

Meaning

File Trailer Label Group

The file trailer label group comprises either of two pairs of labels, depending on whether
the reel contains an end-of-file or an end-of-volume condition In the first condition the
first label of the pair is the EOF1 label, in a format identical to the HDR1 label; the second
label is the EOF2 label. Its format is identical to the HDR2 label. In the end-of-volume
condition, these labels are the EOV1 and EOV2 labels; again, the formats of these labels
are identical to their counterparts in the file header label group, HDR1 and HDR2.
When you issue an OPEN macroinstruction to an input tape file, with READ=BACK
specified in the DTFMT macroinstruction, the OPEN transient checks the fields in an EOF1
and EOV1 label against the values you have specified in the LBL job control statement.
This processing is similar to that of the HDR1 label.
Figure E—4 illustrates the format of the EOF1 or EOV1 label; Table E—4 summarizes the
contents of its fields. Similarly, Figure E—5 and Table E—5 describe the EOF2 or EOV2
label.

E—1 0

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

BYTES

label identifier

ner

4
8
file identifier

12
16
20
file serial number
volume...

24
28

sequence number

generation...

number

version...

file.

.sequence number

number
creation date

44
expiration date

file security

block count

\
60

system code

68
72
reserved

LEGEND:
Generated by data management or reserved for system expansion
Written by data management from user-supplied data

Figure E—4.

Tape File EOF1 and EOV1 Label Formats

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table E—4.

Field

E-1 1

Tape File EOF1 and EOV1 Labels, Field Description

Bytes

Description

Label identifier

0—2

Indicates that this is a file trailer label;
contains “EOF” for an end-of-file label,
or “EOV” for an end-of-volume label

Label number

Always “1”

File identifier

4—20

A 1 7-byte configuration that uniquely identifies
the file. It may contain embedded blanks and is
left-justified in the field if fewer than 17
bytes are specified.

File serial number

21—26

The same as the VSN of the VOL1 label
for the first reel of a file or a group of
multifile reels

Volume sequence number

27—30

The position of the current reel with respect
to the first reel on which the file begins.

File sequence number

31—34

The position of this file with respect to the
first file in the group

Generation number

35—38

The generation number of the file (0000—9999)

Version number of
generation

39—40

The version number of a particular generation
of a file

Creation date

41—46

The date on which the file was created, expressed
in the form YYDDD and right-justified, The left
most position is blank.

Expiration date

47—52

The date the file may be written over or used as
scratch, in the same form as the creation date

File security indicator

Reserved for file security indicator. Indicates
whether additional qualifications must be met before
a user program may have access to the file.
0

No additional qualifications are required.

Additional qualifications are required.

Block count

54—59

In the first file trailer label, indicates the
number of data blocks: either in this file of
a multifile reel, or on the current reel of a
multivolume file. Tape SAM checks the block
count for input files or writes the count for,
output files.

System code

60—72

Reserved for system code, the unique identification
of the operating system that produced the file

Reserved

73—79

Reserved field, containing blanks (4016)

E-12

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

IJP-8068 Rev. 4

BYTES
2

label identifier

0
4

:>:Z/:

record format
character

nrir

block length

record length

20
24
reserved
28

32
36
40
44
48
52

reserved
56

60
64
68
72
76

LEGEND:
Generated by data management or reserved for system expansion.
Written by data management from user supplied data

Figure E—5.

Tape Ale EOF2 and EOV2 Label Formats

UP-8068 Rev. 4

E-13

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Table E—5.

Tape File EOF2 and EOV2 Labels, Field Description

Field

Bytes

Label identifier

0—2

Indicates that this is a file trailer label; contains
“EOF” for an end-of-file label, or “EOV” for
an end-of-volume label

Label number

Always “2”

Record format character

Character

Description

D
F
U
V

Block length

5—9

Meaning
Variable-length, with length
fields specified in decimal
Fixed-length
Undefined
Variable-length, with
length fields specified in binary

Five EBCDIC characters specifying the maximum
number of characters per block

Record length

10—14

Five EBCDIC characters specifying the record length
for fixed-length records. For any other record
format, this field contains 0’s.

Reserved

15—35

Reserved for future system use

Reserved

36—79

Reserved for future system use

E.2.4.

E-14

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Standard User Header and Trailer Labels

In a standard labeled file, you may use only the standard UHL and UTL; within the OS/3
tape SAME conventions, their use is entirely optional. You may have one or as many as
eight UHL or none at all the same applies to optional UTL If you use them they must be
in the OS/3 standard 80-byte format and content as described in Figure E—6 and Table
E—6. Their position in a standard labeled tape volume is as prescribed in Section 8.
When you have specified the block numbering option with the BKNO keyword parameter
of your DTFMT declarative macro (9 2 3 5), the system labels and your optional user labels
may not be the standard length. Optional user labels in an EBCDIC input file must then be
83 bytes long, and user labels in an ASCII input file 81 bytes long, to ensure correct
processing.
BYTES

label identifier

number

‘p

label data

-I

LEGEND:
Written by user’s LABADDR routine.
Written by data management. (See note to Table E—6.)
Figure E—6.

Optional User Header and Trailer Label Format, ASCII and Standard Labeled EBCDIC Tape Files

Table E—6. Optional User Header and Trailer Labels, Field Description for Standard Labeled Tape Files

Bytes

Description

Label identifier

0—2

Contains “UHL” for user header label; “UTL” for
user trailer label

Label number

Ranges from 1 through 8 (See note.)

Label data

4—79

Contains 76 bytes of user-specified information

Field

NOTE:
For ASCII files, the label number is not written by data management; it is the user’s responsibility. Also there is
no limit on the range; the user may have any number of user labels he wants.

E.3.

E—15

SPERRYUNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

ASCII STANDARD MAGNETIC TAPE LABELS

The figures and tables that follow describe the labels written (and expected to be read) by
OS/3 magnetic tape SAM for ASCII files Note the very small differences for foregoing
EBCDIC labels and these ASCII labels which conform to American National Standard
1969
Magnetic Tape Labels for Information Interchange X3 27
—

OS/3 magnetic tape SAM writes and procees the following ASCII standard labels:
VOL1, HDR1, HDR2, EOV1, EOV2, EOF1, and EOF2. Although data management also
provides for input and output processing of optional UHLs and UTLs (their forms are
identical in ASCII to those described in E 2 4) it does not provide for processing optional
user volume labels (UVLs) ohoitpüt. lfpresènt on ASCII input tapes, UVLs are àccëpted,
but bypassed and ignored.
For ASCII record formats and reel organizations, refer to Section 8.
E 3 1

ASCII Character Code and Processing

During input and output processing of ASCII magnetic tape files 05/3 data management
uses the character code specified by American National Standard Code for Information
Interchange, X3.4 —1968, peforming appropriàtO translations (EBCDIC to ASCII, or vice
versa) so that your program always processes in EBCDIC. Refer to 9.2.7.1 for details on
specific or automatic inclusion of the OS/3 ASCII translation table module during link
time. Appendix C provides a useful cross-reference table depicting the correspondence
between ASCII and EBCDIC.
E 3 11

Output Processing of Labels in ASCII Magnetic Tape Files

When you specify ASCII = YES in the DTFMT declarative macro defining an output
magnetic tape file, OS/3 data management writes out all system labels in ASCII. Just as
you must present your data to data management in EBCDIC (9 2 7 1) so also must you
present your optional UHL and UTL label data in EBCDIC Data management translates
these into ASCII before writing them out to tape It is your responsibility to write out the
labelnumber.
E.3.1.2.

Input Processing of Labels in ASCII Magnetic Tape Files

When reading input magnetic tape files coded in ASCII OS/3 data management assumes
1969, and that there is
that these comply fully with American National Standard X3.27
processing. Before
incorrect
in
no mixture of character codes. Any exception may result
passing your data and your optional UHLs or UTLs to you, data management translates
these into the form it expects to receive before ouptut: your program receives data and
labels in EBCDIC.
—

E 3 2

OS/3 Processing of Certain Fields in ASCII Tape Labels

The format and content of ASCII magnetic tape labels in OS/3 are depicted in Figures
E—7 thràugh E—11 and Table E—7 through E—1 1. These subparagraphs describe the
way OS/3 processes certain of the label fields; further notes appear in thetables.

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

E.3.2.1.

E-1 6

Accessibility Field

The accessibility field occurs in the VOL1, HDR1, EOF1, and EOV1 labels. During readforward input, a “space” (2/0) encountered in this field of both the VOL1 and HDR1 labels
allows processing to continue, whereas a nonspace in either field causes the issuance of
error message DM12 to the operator’s console; processing may not continue unless the
operator responds with the override option in effect at your installation. (For backwardread input, the procedure is identical, the fields interrogated being those in the EOV1 and
EOF1 labels.)
In OS/3 there is no option to write a nonspace character in the accessibility field of any
system label on output ASCII tapes; data management always creates this field as
“space”.
E.3.2.2.

Label Standard Level Field

The label standard level field occurs only in the VOL1 label. When writing output ASCII
tapes, data management writes “1” in this field to indicate that the tape is in full
1969. On input tapes, a “1:”. in this
compliance with American National Standard X3.27
field ensures correct processing; tapes created under later versions of the standard may
also be accepted, but you cannot be assured of correct processing.
—

E.3.2.3.

Expiration Date Field

The expiration date field occurs in the HDR1, EOF1, and EOV1 labels. If you attempt to
write over an unexpired file in an ASCII tape (one whose expiration date is later than
today’s date), data management issues error message DM57 to the operator console. You
will not be able to continue processing unless the operator responds with the override
option in effect at your installation.
You should note that, in a multifile ASCII volume, if you give a file a later expiration date
than you have given to the files that you have already recorded on the tape, this additional
protection you intend is not effective. The expiration date of the first file on a volume is
the latest date on which any part of the volume is protected from being overwritten.
E.3.2.4.

System Code

In writing output tapes, data management writes “0S3”, left-justified in the 13-byte
system code field The remainder of the field is filled with spaces The field is ignored on
input.
E.4.

PADDING

In other systems, provision has sometimes been made to allow label blocks to be extended
in length to the nearest multiple of the computer’s word length, any desired characters
being used for padding. OS/3 does not provide for padding of labels (nor of data blocks:
see Section 8). If the labels in your ASCII input files are not exactly 80 bytes in length,
they cannot be processed properly by OS/3. (If BKNO=YES is specified, however, label
length should be exactly 83 bytes.)

SPERRY UNIVAC 0573
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

E-17

BYTE

\
0

volume serial
ni.imber

accessibility

12
reserved for future
standardization

28
reservedfor future standardization
32

40
owner identification
44

60
reserved for future
standardization

72
label standard
level
76

Figure E—7.

Volume Header Label (VOL 1) for an ASCII Magnetic Tape Volume

E-18

SPERRY UNIVAC 05/3
BASIC DATAMANAGEMENT

UP-8068 Rev. 4

Table E—7.

Field

Volume Header Label (VOL 1),

Field Description for an ASCII Volume

Description

Bytes

Label identifier

0—2

Must be “VOL”

Label number

Must be “1”

Volume serial number

4—9

Six “a” characters permanently assigned by the owner to
identify thisphysical volume(thatis,thisreel ofmagnetic
tape). (See Note 1.)

Accessibility

An “a” character that indicates any restrictions on who
may have access to the information in this volume. A
“space” means unlimited access; any other character
means special handling, in the manner agreed upon
between the interchange parties. (See Notes 1 and 2.)

Reserved

11—30

Reserved for future standardization. Must be “spaces”.
(See_Note_2.)

Reserved

31—36

Reserved for future standardization. Must be “spaces”.
(See Note 2.)

Owner identification

37—50

Any “a” characters, identifying the owner of the physical
volume (See Note 1.)

Reserved

51—78

Reserved for future standardization. Must be “spaces”
(See Note 2.)

Label standard level

“1” means that the labels and data formats on this volume
conform to the requirements of American National
Standard X3.27—1969. “Space” means that the labels
and data formats on this volume require the agreement
of the interchange parties. (See Note 2.)

NOTES:
1.

An “a” character is any of the characters occupying the center four Columns of ASCII (American National Standard Code for
Information Interchange) except position 5/15 and those positions where there is a provision for alternative graphic
representation.

“Space” is the normally nonprinting graphic character occupying position 2/0 of ASCII.

UP-8068 Rev. 4

BYTE

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

E—19

sequence number

ation number

60
64

system code

reserved for future
standardization

Figure E—8. First File Header Label (HDR1) for an ASCII Magnetic Tape Volume

E-20

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table E—8. First File Header Label (HDR1), Field Description for an ASCII Volume (Part 1 of 2)

Field

Description

Bytes

Label identifier

0—2

Must be “HDR”

Label number

Must be “1”

File identifier

4—20

Any “a” characters agreed on between originator and
recipient (See Note 1.)
.

Set identification

21—26

Any “a” characters to identify the set of files of which
this is one. This identification must be the same for all
files of a multifile set. (See Note 1.)

File section number

27—30

The file section number of the first header label of each
file is “0001 This applies both to the first or only file
on a volume and to subsequent files on a multifile
volume. This field is incremented by one on each
subsequent volume of the file.
“.

File sequence number

31—34

Four ‘n” characters denoting the sequence (that is,
0001, 0002, etc) of files within the volume or set of
volumes. In all the labels for a given file, this field will
contain the same number. (See Note 3.)

Generation number (optional)

35—38

Four “n” characters denoting the current stage in the
succession of one file generation by the next. When a
file is first created, its generation number is 0001. (See
Notes 3 and 4.)

Generation version number (optional)

39—40

Two “n” characters distinguishing successive iterations
of the same generation. The generation version number
of the first attempt to produce a file is 00. (See Notes
3and4.)

Creation date

41—46

A “space” followed by two “n” characters for the year,
followed by three “n” characters for the day (001 to
366) within the year (See Notes 2 and 3.)

Expiration date

47—52

Same format as creation date field. This file is regarded
as “expired” when today’s date is equal to, or later than,
the date given in this field. When this condition is
satisfied, the remainder of this volume may be overwritten.
To be effective on multifile volumes, therefore, the
expiration date of a file must be less than, or equal to, the
expiration date of all previous files on the volume.

Accessibility

An “a” character that indicates any restrictions on who
may have access to the information in this file. A “space”
means unlimited access; any other character means special
handling, in a manner agreed upon between the interchange
parties.

Block count

54—59

Must be “zeros”

System code (optional)

60—72

Thirteen “a” characters identifying the operating system
that recorded this file. Output tapes written by OS/3
tape SAM contain “0S3”.

73—79

Reserved for future standardization; must contain “spaces”

Reserved
NOTES:
1.

An “a” character is any of the characters occupying the center four columns of ASCII (depicted in American National Standard
X3.4— 1968), except for position 5/15 and those positions where there is provision for alternative graphic representation.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table E—8.

E—21

First File Header Label ‘HDRT), Field Description for an ASCII Volume Part 2 of 2)

A “space” is the normally nonprinting graphic character occupying position 2/0 in ASCII.

An “n” character is any ASCII numeric digit, from 0 through 9.

“Optional,” when used to describe a field in these ASCII labels, means that the field may, but need not, contain the information
described. If an optional field does not contain the designated information, it must contain “spaces”.
BYTE

Figure E—9.

Second File Header Label (HDR2) for an ASCII Volume

E-22

SPERRY UNIVAC OS/3
BASICOATA MANAGEMENT

UP-8068 Rev. 4

Table E—9.

Field

Second File Header Label j’HDR2), Field Description for an ASCII Volume

Description

Bytes
Must be “HDR”

Label identifier

0—2

Label number

Must be 2

Record format

Character

Meaning

Fixed length

Variable, with the number of characters
in the record specified in decimal

Variable with the number of characters
specified in binary. (See Note.)

Undefined

Block length

5—9

Five “n” characters specifying the maximum number of
characters per block. (See Note 3, Table E—8.)

Record length

10—14

Five “n” charactersspecifying: if “record format” is F,
record length; if 0 or V. maximum record length including
any count fields; if U, then undefined. (See Note.)

Reserved

15—49

Reserved for OS/3 use; currently “spaces”

Buffer offset (optional)

50—51

Two “n” characters specifying the length in characters of
any additional field inserted before a data block—for
example, block length. This length is included in the block
length. (See Notes 3 and 4, Table E—8.)

Reserved

52—79

Reserved for future standardization; must contain “spaces”.
(See_Note_2,_Table_E—8.)

NOTE:
OS/3 magnetic tape SAM does not support the ASCII “V4ormat” record,

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

BYTE

E—23

label identifier

4
8

file identifier

12
16

20
set identification
24

file.

section number
.

.
.

file...

sequence number

gener

ation number

40
,

generation

version number
creation date

expiration date

accessibility
block count

64
system code
68

72
reserved for future
standardization
76

Figure E—1O. First End-of-File or End-of-Volume Label (EOF1/EQV1) for an ASCII Volume

E-24

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Table E—1O.

First End-of-File or End-of-Volume Label (EOF1/EOV1), Field Description for an ASCII Volume

Description

Bytes

Field
Label identifier

0—2

Contains “EOF” if an end-of-file label; “EOV” for end-ofvolume label

Label number

Must be “1”

File identifier

4—20

Any “a” characters agreed on between originator and
recipient (See Note 1, Table E—8.)

Set identification

21—26

Any “a” characters to identify the set of files of which
this is one. This identification must be the same for all
files of a multifile set. (See Note 1, Table E—8.)

File section number

27—30

The file section number of the first header label of each
file is “0001”. This applies both to the first or only file
on a volume and to subsequent files on a multifile
volume. This field is incremented by one on each
subsequent volume of the file.

File sequence number

31—34

Four “n” characters denoting the sequence (that is,
0001, 0002, etc) of files within the volume or set of
volumes. In all the labels for a given file, this field will
contain the same number. (See Note 3, Table E—8.)

Generation number (optional)

35—38

Four “n” characters denoting the current stage in the
succession of one file generation by the next. When a
file is first created, its generation number is 0001.
(See Notes 3 and 4, Table E—8.)

Generation version number (optional)

39—40

Two “n” characters distinguishing successive iterations
of the same generation. The generation version number
of the first attempt to produce a file is 00. (See Notes
3 and 4, TableE—8.)

Creation date

41—46

A “space” followed by two “n” characters for the year,
followed by three “n” characters for the day (001 to 366)
within the year. (See Notes 2 and 3, Table E—8.)

Expiration date

47—52

Same format as creation date field. This file is regarded
as “expired” when today’s date is equal to, or later than,
the date given in this field. When this condition is
satisfied, the remainder of this volume may be
overwritten. To be effective on multifile volumes,
therefore, the expiration date of a file must be less than,
or equal to, the expiration date of all previous files on
the volume.

Accessibility

Block count

54—59

Number of data blocks in the file or volume

System code (optional)

60—72

Thirteen “a” characters identifying the operating
system that recorded this file. Output tapes written by
OS/3 tape SAM contain. “0S3”. (See Note 1, Table E—8.)

73—79

Reserved for future standardization; must be “spaces”.
(See Note 3, Table E—8.)

Reserved

UP-8068 Rev. 4

BYTE

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

E-25

label identifier

record format

block length

28
reserved for operating
systems

buffer offset

60
reserved for future
standardization

Figure E—1 1.

Second End-of-File or End-of-Volume Label (EOF2/EOV2) for an ASCII Volume

Table E—1 1.

E-26

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Second End-of-File or End-of-Volume Label (EOF2/EOV2), Field Description for an ASCII Volume

Bytes

Description

Label identifier

0—2

Contains “EOF” if an end-of-file label; “EOV” for endof-vol u me

Label number

Must be “2”

Record format

Character

Field

Meaning

Fixed length

Variable, with the number of characters
in the record specified in decimal

Variable, with the number of characters
specified in binary. (See Note 1, Table E—9.)

Undefined

Block length

5—9

Five “n” characters specifying the maximum number of
characters per block. (See Note 3, Table E—8.)

Record length

10—14

Five “n” characters specifying: if “record format” is F,
record length; if D or V, maximum record length
including any count fields; if U, then undefined. (See
Note 1, Table E—9.)

Reserved

15—49

Reserved for 0S13 use; currently “spaces”. (See Note 2,
Table E—8.)

Buffer offset (optional)

50—51

Two “n” characters specifying the length in characters
of any additional field inserted before a data block—for
example, block length. This length is included in the
block length. (See Notes 3 and 4, Table E—8.)

Reserved

52—79

Reserved for future standardization; must be “spaces”.
(See Note 2, Table E—8.)

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

F-i
Update A

Appendix F. Consolidated Data Management
Migration Considerations

Fl. WHAT DO I HAVE TO DO TO MIGRATE TO CONSOLIDATED
DATA MANAGEMENT?
The answer is that the amount of effort varies with language of the program you want to
migrate: that is, BAL, RPG Il, 1968 American National Standard COBOL, 1974 American
National Standard COBOL, or FORTRAN.
F.2.

MIGRATION REQUIREMENTS

The migration requirements for programs written in the various programming languages
are discussed in the paragraphs that follow.
F.2.1.

BAL Programs

If your program is written in BAL, you must redefine your files. This means that you must
replace all basic data management DTF declarative macroinstructions with the
consolidated data management CDIB and RIB declarative macroinstructions.
If you use disk files with your program, these must be converted (using data utilities) to
MIRAM files before they can be used.
You must replace all basic data management imperative macroinstructions with the
appropriate consolidated data management imperative macroinstructions. These new
imperative macroinstructions must be immediately followed by inline coding that checks
the status of the operation being performed. This is necessary because consolidated data
management always returns control inline. There is no provision made for contingency
routine addresses such as EOFADDR and ERROR in the RIB macroinstruction.
After you have modified your program, it must be reassembled and relinked before it can
be executed.
Note that if your program creates disk files, these files must be specified as MIRAM files
in the job control stream used to execute the program.

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

F-2
Update B

F.2.1.1. OS/3 Sequential DTF Mode To CDI Macro Converter (DTFCDI3O1)
You can reduce the amount of effort required to migrate a basic data management BAL
program that processes sequential files (card, tape, printer, or SAM disk) to consolidated
data management by using DTFCD 1301. This converter processes basic data management
BAL source program modules that you have previously written to a library file. It produces
a consolidated data management source program module and a listing that shows the
actions taken by the converter. The consolidated data management source program
module is automatically written to the original library file unless you specify otherwise.
Those statements that cannot be converted or that require your attention are indicated by
diagnostic messages on the listing. As you can see, the converter can save you
considerable time because you only have to change your program where indicated.
After you have modified your program, it must be reassembled and relinked before it can
be executed.
The DTFCDI3O1 user guide, UA-0455 (current version) contains the detailed information
you need to successfully use the converter.

F.2.2.

RPG II Programs

An RPG II program does not require any modifications unless you want to want to use
workstations. It must, however, be recompiled and relinked before you can execute it even
if you did not modify it.
If your program uses disk files, these must be converted (using data utilities) to MIRAM
files.
Note that if your program creates disk files, they must be specified as MIRAM files in the
job control stream used to execute the program

F.2.3.

1968 American National Standard COBOL Programs

Programs that are written in this language cannot be migrated to consolidated data
management. They must first be converted to 1 974 American National Standard COBOL.

F.2.4.

1974 American National Standard COBOL Programs

A program written in this language does not require any modification unless it uses disk
files. It must, however, be recompiled and relinked before you execute it even if you did
not modify it.
If your program uses disk files, these must be converted (using data utilities) to MIRAM
files before you can use them.
Note that if your program creates disk files, they must be specified as MIRAM files in the
job control stream used to execute the program.

UP-8068 Rev. 4

F.2.5.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

F-3
Update 8

FORTRAN Programs

Your FORTRAN program does not have to be recompiled; however, you must update your
unit definitions, reassemble them, and relink them with your program before you can
execute it.
If you want to use workstations, you must modify your FORTRAN source program and
recompile it. You must also update your unit definitions and include unit definitions for the
workstations. These unit definitions must be reassembled and relinked with your program
before you can execute it.
If your program uses disk files, these must be converted (using data utilities) to MIRAM
files.
Note that if your program creates disk files, they must be specified as MIRAM files in the
job control stream used to execute the program.

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Reference

Term

Page

C
Card codes
column binary
compressed
data conversion
Hollerith
96-column punch
Card files
Card punch
card flow
characteristics
codes, 96-column
using CNTRL macro

C.3.2
Fig. C—2
C.3.L
Fig. C—i
CA
C.2.l
Fig. C—3

C—9
C—9
C—8
C—8
C—9
C—2
C—il

Term

Reference

Page

CNTRL macro
device skip code table
DTFCD macro
magnetic tape
nonindexed disk
printer
punched card SAM
using

Table 7—4
3.3
9.4.10
15.7.15
7.4.3
3.4.4
3.4.4.1

7—22
3—3
9—62
15—103
7—21
3—19
3—20

C.3.2
Fig. C—2
C.3.1
Fig. C—i
C.4
C.i
C.2
Table C—i

C—9
C—9
C—8
C—8
C—9
C—i
C—i
C—3

Code correspondences
column binary

See punched
card files,
Fig. 3—1
Table A—2
Fig. C—3
3.4.4.1

Index 3
Update A

compressed card code
data conversion
description
EBCDIC/ASCII/Hollerith

3—20
A—3
C—il
3—20
Codes

Card reader
characteristics
See also punched card,

Table A—i A—2

Character deletion

17.5.3.1

17—45

Character mismatches

7.3

7—13

Character mode, paper tape files
character deletion,
input files
description
letter/figure shifting
and translation
specifying
See also paper tape files,

ASCII
device-independent control
character
device skip
EBCDIC
shift
Combined files, diskette
description
record processing

17.5.3.1
17.2
17.3.3

17—45
17—1
17—10

17.5.3
17.5.5
17.5.2.2

17—39
17—50
17—37

Compressed card code
description
mode

See ASCII.
Table 7—1 7—6
Table 7—4 7—22
See EBCDIC.
See shift codes.
4.2.3
5.2.3

4—4
5—2

C.3.i
Fig. C—i
C.4

C—8
C—8
C—9

Consolidated data management
description
migration considerations

i—i
1.2
Appendix F

Characters, paper tape
delete
letter and figure shift
null
stop
types

17.3.1
17.3.2
17.3.i
17.3.1
17.3

17—S
17—6
17—4
17—6
17—4

Control characters
device-independent
overflow and home paper
paper tape
printer (DTFPR macro)

Table 7—i 7—6
Table 7—2 7—8
17.3
17—4
7—5
7.3

Checkpoint dumps, bypassing

9.2.8.2

9—29

Current data pointer

15.6.11

15—34

Current I/O area
5.4.4
11.5.1.2
942
157.2
17.4.2
17.5.9
7.4.5
3.4.5

5—12
11—25
9—48
15—63
17—18
17—65
7—27
3—24

13.4.11
13B.S.9

13—21
13B—1S

Current record pointer

ii 4 7

11—13

Current relative block address

15.7.17

15—106

CLOSE macro
diskette
ISAM
magnetic tape
nonindexed disk
paper tape
printer
punched card

SPERRY UNIVAC OS/3
BASIC bATA MANAGEMENT

UP-8068 Rev. 4

Term

Cylinder overflow
area, providing
control record
Cylinders
calculating space requirements
formats, ISAM files

Reference

Page

11.4.12
10.2
Fig 10—1

11—17
10—3
10—4

10.2.2.1
Fig. 10—1

10—11
10—4

D
DAM files
description
disk

Index 4
Update B

Reference

Term

with DTFPT macro keyword
parameters
with DTFSD macro keyword
parameters

Page

Table 17—1 17—27
Table 15—1 15—9

Deallocation, dynamic

16.3

16—8

Deallocation statement (SCR)

16.1.3

16—2

Declarative macroinstructions
description
RAM
ISAM
magnetic tape
MIRAM
nonindexed disk file
paper tape
printer
punched card

1—12
1.6.1
See DTFIR macro.
See DTFIS macro.
See DTFMT macro.
See DTFMI macro.
15—7
15 5
See DTFPT macro
See DTFPR macro.
See DTFCD macro.

152
15 3

1—10
15—4

C.4

C—9

Delete character

Fig. 1—1
12.2.1
1.3
1.7.5

1—4
12—3
1—4
1—18

17.2.L2
17.3.1

Deleting records

See record deletion.

Device allocation

16.1

16—1

102.2
Fig 10—4

10—8
10—9

Device assignment set
sample
use of job control statements

16 1 2
16.1.1

16—2
16—1

Data management error messages
description
subcodes

B.3.1
Table B—i
Table B—lA

B—2
B—.3
B—9

Device-independent control
character codes

Table 7—i

Device skip code table

Table 7—4 7—22

Data records, RAM
spanning disk sectors on
a fixed sector disk
with and without

Fig. i2—2
Fig. 12—1

12—5
12—4

Direct access files
random retrieval
See also DAM files.

15.7.14

Direct access method

See DAM.

Data
conversion
organization on typical
peripheral devices
partition, RAM
structure
utilities
Data blocks
format, ISAM
See also blocks,

DO job control statement
use
with DTFCD macro keyword
parameters
with DTFDA macro keyword
parameters
with OTFIR macro keyword
parameters
with OTFIS macro keyword
parameters
with OTFMI macro keyword
parameters
with OTFMT macro keyword
parameters
with OTFNI and DPCA macro
keyword parameters
with OTFPR macro keyword
parameters

16.1.1

16—1

Table 3—1

3—13

Table 15—2

15—12

Table 13—1

13—16

Table 11—3

11—21

17—3
17—5

15—97

Table 13B—i l3B—i0

Direct RAM files
adding records
creating
deleting records
description
extending
processing
reorganizing
retrieving and updating
records

Table 9—1

9_4

Direct retrieval

See READ,KEY
macro.

Table 15—3

15—17

Disk address, relative

Table 7—3

7—14

See relative
disk address.

13.1.2.3.
13.1.2.1
13.1.2.5
13.1
13.1.2.2
131 2
131 26

13—7
13—5
13—8
13—1
13—6
13—5
13—8

13.1.2.4

13—7

UP-8068 Rev. 4

Term

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Page

Reference

Disk file labels
description
diskette
file information group
optional user standard
volume information group
Disk files
access methods
assigning space to file
partition
creating by sequential load
description
dynamic deallocation
(SCRTCH)
extension error handling
IRAM
ISAM
labels

D—1
D.1
D30
D.5
Fig. D—-16 D30
Table D—12 D—31
See file information
group labels,
See standard
labels, disk.
See volume information group labels.

Term

Reference

Diskette
characteristics
combined files
file label format

input files
limitations
output files
record, formats

Section 15
SAM
15—49
15—86
1—8

15.6.25
15.7.11.1
1.3.6

using

17.5.1.4

17—30

15.4
15.5.4
15.5.4
Table 15—3
Table 15—7
15.6

15—5
15—16
15—16
15—17
15—58
15—20

15.6.37

15—57

DTF error

17.5.9

17—65

DTF fields
filenameC
other

See filenameC.
B—iS
B.4.2

DTF forms

1.6.1

1—12

DTFCD macro
diskette
punched card SAM files

5.3
3.3

5—5
3—3

15 2
15.3
15.5.2
15 52
Table 15—2
Table 15—7
15.6

15—3
15—4
15—11
15—11
15—12
15—58
15—20

15.6.37

15—57

13.3
13.3
13.4

13—15
13—15
13—18

Double-buffering
16—8
16.3
B.3.3
B—12
See RAM.
See SAM.
See disk file
labels.
See nonindexed
disk files.
16.2
16—6
15—78
15.7.9.2

renaming (RENAME)
updating and extending
See also sequential disk files.

15—103

Disk head movement

15.7.15

Disk prep routine

1.7.1

1—15

Disk sectors

12.2.2

12—3

Disk space management
description
error codes
OBTAIN macro
VTOC
Disk space requirements, estimating
indexed IRAM file
indexed MIRAM file
ISAMfile
SAM index area
nonindexed IRAM file
nonindexed MIRAM file
Disk subsystem’
characteristics
files,
flexibility

‘

1.7:3
B.3.2
Table’ B—2’
16.4.1
16.4

‘

1—17
B—10
B—li
16—12
16—11

DPCA macro
description
format
keyword parameter summaries
,

keyword parameters
nonstandard forms of keyword
parameters

‘

DTFDA macro
description

12.2.4
13A 25
10.2.2.1
10.2.4
12.2.5
13A.2.6

12—9
13A—9
10—11
10—14
12—12
13A—12

Table A—4 A—9
See disk files,
1—11
1.5.6

Page

Table A—4 A—9
4—4
4.2.3
D—30
D.5
Fig. D—16 D—30
Table D—12 D—31
1—7
1.3.3
4—1
4.2
4—2
Fig. 4—1
4—3
4.2.1
5—4
5.2.6
4—4
4.2.2
4—4
4.3
Fig. 4—2
4—5
See SAM files,
diskette.
5.2.5
5—3

files

‘

nonindexed

Index 5
Update B

format
keyword parameter summaries
keyword parameters
nonstandard forms of
keyword parameters
DTFIR macro
description
format
keyword parameters

UP-8068 Rev. 4

Reference

Term
DTFIR macro (cont)
nonstandard forms of
keyword parameters
summary of keyword parameters
DTFIS file table
filenameC
other addressable fields
DTFIS macro
description
format
keyword parameter summary
keyword parameters
nonstandard forms of keyword parameters
DTFMI macro
description
format
keyword parameters
nonstandard forms of
keyword parameters
summary of keyword parameters
DTFMT macro
description
format
keyword parameters
nonstandard forms of
keyword parameters
DTFNI files, output
DTFNI macro
description
format
keyword parameter summaries
keyword parameters
nonstandard forms of keyword parameters

Index 6
Update B

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Page

13.4.26
13—25
Table 13—1 13—16
11.6.1
11—49
11.6.2
1149
Table 11—4 11—49
11.3
11—6
11.3
11—7
Table 11—3 11—21
11.4
11—8
11.4.19

11—20

13B.4
13B.4
13B.5

138—8
138—9
13B13

13B.5.24
138—20
Table 13B—1 13B—10

Term

Reference

Page

15.2
15.5.1
15.5.1
Table 15—1
Table 15—7
15.6

15—3
15—8
15—8
15—9
15—58
15—20

15.6.37

15—57

DTFSD output file, extending

15.7.9.3

15—79

Dumps, checkpoint

9.2.8.2

9—29

DVC job control statement

9.3.1
16.1.1

9—31
16—1

Dynamic deallocation, disk
file (SCRTCH)

16.3

16—8

Dynamic extension, file partition

15.6.30

15—53

Dynamic tape prepping and recording
density

9.3.3.2

9—34

DTFSD macro
description
format
keyword parameter summaries
keyword parameters
nonstandard forms of keyword parameters

9.2
9—1
9.2.1
9—2
Table 9—1
9—29
9.2.9
Table 9—2 9—30
15.7.9.5

15—80

15.1
15.4
15.5.3
15:5.3
Table 15—3
Table 15—7
15.6

15—2
15—5
15—14
15—14
15—17
15—58
15—20

15.6.37

15—57

DTFPR macro
description
parameter summary

7_4
7.3
Table 7—3 7—14

DTFPT macro
basic parameters
description
file processing mode
format
summary of keyword parameters

17.5.1
17.5
17.5.2
17.5
Table 17—i

17—28
17—24
17—36
17—25
17—27

E
EBCDIC code correspondences
EBCDIC record and block formats,
magnetic tape
EBCDIC standard mode
EBCDIC volume organization,
magnetic tape
file trailer label group
first file header label
(HDR1)
multifile, end-of-file
multifile, end-of-volume
nonstandard
second file header label
(HDR2)
single file
standard
unlabeled
VOL1 label format

C—i
C.2
Table C—i C—3
8.2.5
Fig. 8—11

8—14
8—14

C.4

C—9

E.23

E—9

E.2.2.i
Fig. 8—2
Fig. 8—3
8.2.2

E—4
8—4
8—5
8—2

E.2.2.2
Fig. 8—1
8.2.1
E.2.4
8.2.3
Fig. 8—6
Fig. E—1
Table E—1

E—7
8—3
8—2
E—i4
8—8
8—8
E—3
E—4

SPERRY UNIVAC OS/3
BASIC bATA MANAGEMENT

UP-8068 Rev. 4

Reference

Term

Reference

Page

Term

End-of-data (/*) job control statement

2.3.2

2—3

Error and exception handling
card reader
data management
description
disk file extension
disk space management
flagging procedures

End-of-data processing
magnetic tape
punched card

9.2.2.5
3.3

9—12
3—5

8.2.1
Fig. 8—2
15.6.4
15.7.11.3

8—2
8—3
15—25
15—89

End-of-tile handling routine, RAM

13.4.4

13—19

End-of-file handling routine, MIRAM

13B.5.3

13B—13

End-of-file
condition, tape
input, address for routine
recording logical, disk

End-of-file label
end-of-volume coincidence
first
second
End of record stop character

17.5.6

17—60

End-of-tape routine, paper tape
input files

17.5.4

17—49

8.2.1
Fig. 8—3

8—2
8—5

End-of-volume condition
End-of-volume label
end-of-file coincidence
first
second

8—9
8.2.4.1
Fig. 8—10 8—13
See EOF1 and
EOV1 labels.
See EOF2 and
EOV2 labels.

End-of-volume procedures, forcing

See FEOV macro.

ENDFL macro

11.5.2.3

EOF1 and EOV1 labels
ASCII
contents
description
EOF2 and EOV2 labels
ASCII
contents
description

ISAM
messages, system
nonindexed disk
printer
return of control
system error messages

8.2.4.1
8—9
Fig. 8—10 8—13
See EOF1 and
EOV1 labels.
See EOF2 and
EOV2 labels.

Index 7

Error codes, disk space management
Error handling routines
card reader
IRAM
SAM
magnetic tape
MIRAM
nonindexed disk
printer
Error messages
system
tape label processing

Page

3—25
3.5
B.3.1
B—2
B. 1
B—i
B—12
B.3.3
B—10
B.3.2
See flagging
procedures.
11—49
11.6
B.2.1
B—2
See system error
messages.
15.8
15—111
7.6
7—28
1—11
1.5.5
B.2
B—i
B—2
B.3
B.3.2
B—b
Table B—2 B—il
3.3
13.4.5
11.4,3
9.2.2.4
13B.5.4
15.6.6
7.3

3—6
13—19
11—10
9—12
13B—13
15—26
7—8

See system error
messages.
9.3.7
9—43

Error processing
paper tape files
See also error handling routines.

17.5.9

Errors, parity

See parity errors.

ESETL macro

11.5.5.4

11—48

Expiration date
field, ASCII tape labels
SCRTCH macro

E.3.2.3
16.3

E—16
16—8

EXT job control statement

16.1.1

16—1

Extending existing disk files

15.7.9.2
15.7.9.3

15—78
15—79

Extension, tape files

9.3.6

9—41

Extension error handling, disk file

B.3.3

B—12

17—65

11—30

Fig. E—10
Table E—10
Table E—4
E.2.3
Fig. E—4

E—23
E—24
E—11
E—9
E—10

Fig. E—11
Table E—11
Table E—5
E.2.3
Fig. E—5

E—25
E—26
E—13
E—9
E—12

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Term

Reference

Page

F
FEOV macro
magnetic tape
nonindexed disk

9.4.8
15.7.7

959
15—73

Figure scan table

17.5.5

17—50

Figure shift character

17.3.2

17—6

Figure shifting and translation
input files, character mode
output files, character mode

17.5.3
17.5.5

17—39
17—50

File accessing options

11.4.1

11—8

File control block (FCB), SCRTCH
macro

16.3

16—8

File creation date

9.3.4.4

939

File description labels, diskette

4.2
0.5

4—3
D-30

File expiration date

9343

9—38

File header labels, tape
first (HDR1)
second (HDR2)
See also HDR1 and HDR2 labels.

E.2.2.1
E.2.2.2

E—4
E—7

File identifier

9.3.4.1

9—36

File information group labels, disk
chain
description
format 1
format 2
format 3

File label information (LBL) statement
File lock, suppressing
IRAM
ISAM
nonindexed disk
MIRAM
File lock feature

Fig. 0—7
D.3
D.3.1
Fig. 0—8
Table D—6
D.3.2
Table D—7
0.3.3
Fig. D—13
Table 0—11

D—12
D—12
0—13
D—13
D—14
D—18
D—21
D—25
D—26
D—27

9.3.4

9—36

13.4.15
11.4.11
15.6.16
13B.5.12

13—22
11—16
15—38
13B—16

16.1.4
16—3
Table 16—1 16—4a

Index 8
Update C

Term

Reference

Page

File organization
IRAM
ISAM
magnetic tape
MIRAM
nonindexed disk

12.2
10.2
8.2
13A.2
14.2

12—3
10—3
8—1
13A—3
14—2

15.6.25
15.6.30
10.2
Fig. 10—1
15.7.6
12.2
12.2.3
Fig. 12—5
14.2.1

15—49
15—53
10—3
10—4
15—72
12—3
12—6
12—7
14—3

15.7.18
15.7.4

15—108
15—68

15.6.17
15.6.27
15.7.5

15—39
15—50
15—70

File partitions
assigning initial disk space
dynamic extension
indexed ISAM
initializing position
RAM
nonindexed disk
positioning to relative
block address
selected, accessing
specifying address for
DTFNI fifes
subfile processing
File processing
mode, changing for an I/O
tape file
mode, setting (SETF macro)
optional
specifying with one volume
online at a time

9.4.5
9—54
15.7.8
15—74
See optional file
processing.
13.4.24
13B.5.22
3.3
9.2.2.3
1.7.5

13—24
13B—19
3—10
9—11
1—18

File protection

1.7.3

1—17

File recovery support
RAM files
MIRAM files

13.5.1
13B.6.1

13—26
13B—21

File sequence number

9.3.4.5

9—39

File serial numbers, checking

9.3.4.2

9—36

File sharability

11.4.1
11—8
16.1.4
16—3
Tale 16—1 16—4a

TYPEFLE keyword
utility

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Term

File trailer label group
description
EOF1 and EOV1
descriptions
EOF1 and EOV1
EOF2 and E0V2
descriptions
EOF2 and EOV2

Reference

Page

Term

E.2.3

E—9

Fixed-length records
diskette
ISAM

field
formats
field
formats

Table E—4 E—11
Fig. [—4
E—10
Table E—5 [—13
Fig. E—5
E—12

File type specification (TYPEFLE)
IRAM
ISAM
magnetic tape
paper tape
punched card

13.4.21
11.4.15
9.2.2.3
17.5.1.1
3.3

Filename-addressable fields, DTFIS
file table

Table 11—4 11—49

FilenameC
card reader
description
ISAM
magnetic tape files
nonindexed
paper tape files
printer
significance of bits

3.5.1
B.4.1
11.6.1
9.2
15.8.1
17.5.9
Table 17—2
7.5.1
Table B—3

13—23
11—18
9—11
17—28
3—10

3—25
B—13
11—49
9—2
15—111
17—65
17—66
7—28
B—13

Files
ASAM
assigning
DAM
disk
diskette
IRAM
SAM
magnetic tape
MIRAM
multivolume
nonindexed disk
optional
paper tape
printer
punched card
SAM

10.3
10—18
16.1
16—1
See DAM files.
See disk files.
See diskette files.
See RAM files,
See ISAM files.
See magnetic tape
files.
See MIRAM
files,
See multivolume
files.
See nonindexed
disk files.
See optional
file processing.
See paper tape
files.
See printer files.
See punched card
files,
See SAM files.

Index 9
Update C

Reference

Page

4.3.1
10.2.1
Fig. 10—2
Fig. 14—4
14.3.1
Fig. 14—2

4....4
10—5
10—6
14—12
14—7
14—8

Fig. 17—5
Fig. 17—6
Fig. 17—7
17.3.3
Fig. 17—9

17—10
17—11
17—13
17—10
17—15

Flagging procedures, error
description
filenameC
other DTF fields

B.4
B.4.1
B.4.2

B—12
B—13
B—iS

Format labels, retrieving specific items

16.4.1.1

16—14

keyed, nonindexed disk files
nonindexed disk files
See also record formats.
Fixed, unblocked records
(paper tape)
followed by interrecord gaps
format
shifted, work areas

Format 0 label, disk
contents
description
Format 1 label, disk
contents
description
Format 2 label, disk
contents
description
IRAM/MIRAM information area
ISAM file information area
library file information area
nonindexed files
Format 3 label, disk
contents
description
Format 4 label, disk
contents
description

Table D—5 D—11
D.2.5
D—11
Fig. D—6
D—i1
Table D—6 D—14
D.3.i
D—13
Fig. 0—8
D—13
Table 0—7
D.3.2
Fig. 0—11
Table D—9
Fig. 0—10
Table 0—8
Fig. 0—12
Table D—10
Fig. D—9

0—21
0—18
D—20
0—24
0—20
D—23
D—21
D—25
D—19

Table D—11 D—27
D.3.3
D—25
Fig. D—13 D—26
Table D—2 D—6
0.2.2
D—4
Fig. D—3
D—5

Index 10
Update C

SPERRY UNIVAC 05/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Reference

Term
Format 5 label, disk
contents
description

Page

Table D—3 D—9
D—8
D.2.3
D—8
Fig. D—4

Format 6 label, disk
contents
description

Table D—4 D—10
D—9
D.2.4
D—10
Fig. D—5

Forms, printer

See printer forms.

Forms overflow
code, DTFPR macro
print action (PRTOV macro)
VFB statement

7,3
7.4.4
6.4.4.2

7—11
7—24
6—9

Forms advance

7.3

7—10

G
1—18

1.7.5

Gaps, interrecord

See interrecord
gaps.

General registers

See save area
specification.

Generation number, file

9.3.4.6

9—39

5.4.2
11.5.5.2
9.4.4
15.7.12
3.3
17.4.3
3.4.2

5—8
11—44
9—52
15—94
3—8
17—20
3—15

Table 15—9 15—95

H
Hardware constraints
HDR1 label
ASCII ciolume
contents
description
field description, ASCII volume

HDR2 label
ASCII volume
contents
description
field description, ASCII
volume

1.5.6
Fig. E—8
Table E—2
E.2.2.1
Fig. E—2
Table E—8

1—11
E—19
E—6
E—4
E—5
E—20

Reference

Page

Fig. E—9
Table E—3
E.2.2.2
Fig. E—3

E—21
E—9
E—7
E—8

Table E—9 E—22

Header labels
file

See file header
labels.
See user header
labels.
See VOL1 label.

user
volume

3.3

Hole-count errors, DTFCD macro
Hollerith code
ASCII/EBCDIC/Hollerith
correspondences

3—5

C—i
C.2
Table C—i C—3
C—2
C.2.i

description

Gangpunch—reproduce

GET macro
diskette
ISAM
magnetic tape
nonindexed disk
overlap mode
paper tape
punched card
use of IOREG keyword, processing
input disk files sequentially

Term

Home paper control character codes

Table 7—2 7—8

Home paper position, VFB statement

6.4.4.1

6—9

C.4

C—9

I
Image mode
Imperative macroinstructions
description
diskette
indexed ISAM
invalid
ISAM files
ISAM files without index
structure
magnetic tape
nonindexed disk
paper tape
printer
punched card

1.6.2
1—14
5—6
5.4
11—2
11.2.1
Table 11—111—3
17—65
17.5.9
11—23
11.5
11.2.2
Table 11—2
9.4
15.7
Table 15—8
17.4
7.4.
3.4

11—3
11—4
9—43
15—59
15—61
17—15
7—15
3—13

UP-8068 Rev. 4

Term

Reference

INDAREA
buffer
table in main storage

10.2.5
Fig. 10—8

Page

10—16
10—17

13.4.7

13—20

Index area length, MIRAM
(INDS keyword)

13B.5.6

Index blocks, IRAM
coarse- and mid-level
fine-level, three sectors
naming main storage location

format
loading top index into
main storage
Index partition, -IRAM

Index registers
Index structure
IRAM
ISAM, eliminating
(INDEXED keyword)
MIRAM
Indexed RAM files
adding records during retrieval,
index active
creating
deleting records
extending
processing
reorganizing
retrieval and update, index
inactive
retrieving and updating,
index active

Term

processing
reorganizing
retrieving and updating records

I Indexed. random access method

Index area length, IRAM
(INDS keyword)

Index blocks, ISAM
calculating space
describing in main storage
description

Index 11 :,

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Reference

Page

13B.3
13B:3.6
138.3.3

13B—5
13B—8
138—7

See IRAM.

Indexed sequential access method

See ISAM.

13B—14

Input blocks, updating

See updating
input blocks.

Fig. 12—4
Fig. 12—3
13.4.6

12—6
12—5

10.2.4
11.4.4
10.2
10.2.3
Fig. 10—6

10—14

Input files
diskette
label processing, ASCII tape
paper tape
punched card SAM
tape, specifying direction
TYPE keyword

4.2.1
4—3
E.3.1.2.
E—15
See paper tape files.
3.2.1
3—1
9.2.5.1
9—22
13.4.21
13—23

Input/output, multisector

5.2.4

5—3

10.2.5

10—16

112.2
12:2.3
Fig. 12—5

12—3
12—6
12—7

3.3
13.4.9
13.4.10
13.4.11
11.4.6

3—6
13—20
13—21
13—21
11—12

10.2.5.
9.2.2.1
9.2.3.1
15.6.9
15.610
17.5.1.4
Fig. 17—4
7.3.

10—16
9—10
9—13
15—33
15—34
17—30
17—9
7—8

Input record processing
diskette SAM files
IRAM files

5.2:1
13.4.25

5—1
13—24

Interlace, record

15.6,8

15—30

Interrecord gaps, paper tape files
description
input, binary mode
input, standard mode
output, either mode

17.3.4
Fig. 17—7
Fig. 17—6
Fig.17—.5

17—10
17—13
17—12
17—11

13—20

11—1 L

10—3
10—12
10—12

See register
specification.

input/output buffers (areas)
card reader
RAM
ISAM
loading top index in main
storage
magnetic tape
nonindexed disk

12.2.3

12—6

11.4.5
13A.2.3

11—12
13A—7

13:2.4
13.2.1
13.2.6
13.2.2
13.2
13.2.7

13—12
13—10
13—14
13—11
13—9
13—14

13.2.5

13—13

13.2.3

13—11

Indexed SAM files

11.2.1

11—2

Indexed MIRAM files
adding records during retrieval
creating
deleting records
extending

13B.3.4
138.3.1
138.3.5
138.3.2

13B—8
138—6
13B—8
13B—6

paper tape
printer

IRAM files
adding records, input
buffer size
defining (DTFIR macro)
direct
end-of-file handling routine
error routines

13.4.2
13—19
13.4.3
13—19
13.3
13—15
See direct RAM
files.
13.4.4
13—19
13—19
13.4.5

UP-8068 Rev. 4

Term
IRAM files (cont)
file accessing options
file type
index area length
indexed
input or output record
processing, work area
I/O area identification
key lengths
key retrieval
locating relative disk
address
naming location for index blocks
number of bytes preceding keys
optional files
pointing to current I/O area
processing, nonindexed
processing, one volume online
at a time
processing by key
record length
retrieval and lead modules
sequential
suppressing file lock
updating records
verifying ascending record key
order during file creation
verifying output records
IRAM formats and file conventions
coarse- or mid-level index sector
concepts
data partition
data records spanning disk sectors
on fixed sector disk
data records with and without keys
description
entries in index partition
estimating disk space
file organization
fine-level index block of
three sectors
index structure
search of 4-level index
ISAM error handling
ISAM file information area, disk
format 2 label

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Reference

Page

13.4.1
13.4.2 1
13.4.7
See indexed
files.

13—18
13—23
13—20
IRAM

13.4.25
13.4.9
13.4.10
13.4.13
13.4.12

13—24
13—20
13—21
13—21
13—21

13.4.19
13.4.6
13.4,14
13.4.17
13.4.11
13.1

13—23
13—20
13—22
13—22
13—21
13—1

13.4.24
13—24
13.4.8
13—20
13.4.18
13—23
13.4.16
13—22
See sequential
IRAM files.
13.4.15
13—22
13.4.22
13—24
13.4.20
13.4.23

13—23
13—24

Fig. 12—4
12.1.1
12.2.1

12—6
12—1
12—3

Fig. 12—2
Fig. 12—1
12.1
12.2.2
12.2.4
12.2.5
12.2

12—5
12—4
12—1
12—3
12—9
12—12
12—3

Fig. 12—3
12.2.3
Fig. 12—6

12—5
12—6
12—8

B.2.1

8—2

D.3.2
D—18
Fig. D—1O D—20
Table D—8 0—23

Term
ISAM files
addressable fields in DTFIS file
table
ASAM files
ASAM record formats
current record pointer
cylinder overflow
data blocks
defining (DTFIS macro)
deleting records
description
error exit
file accessing options
filenameC
functions and operation
imperative macro instructions
index area in main storage
index area space requirements
index blocks
index structure
indexed, processing
initializing (OPEN macro)
inserting new records
I/O buffers
loading and extending
loading top index
multivolume
organization
parity check
random processing
record formats
record keys
record size and format
record work areas
retrieval search argument
sample load program
save area
sequential processing
space requirements
structure
suppressing file lock
terminating (CLOSE macro)
type of retrieval

Index 12

Reference

Page

11.6.2
Table 11—4
10.3
10.3.1
11.4.7
11.4.12
10.2.2
11.4.2
11.3
11.2.3
1.5.1
10.1
11.4.3
11.4.1
11.6.1
11.1
11.5
11.4.4
10.2.4
10.2.3
11.2.2
11.4.5
11.2.1
11.5.1.1
11.5.3
11.4.6
11.5.2
10.2.5
Fig. 10—8
10.4
10.2
11.4.17
11.5A
10.2.1
11.4.10
11.4.13
11.4J8
11.4.9
11.7.1
11.4.14
11.5.5
10.2.2.1
Fig. 10—7
11.4.11
11.5.1.2
11.4.15

11—49
11—49
10—18
10—22
11—13
11—17
10—8
11—9
11—6
11—4
1—10
10—1
11—10
11—8
11—49
11—1
11—23
11—11
10—14
10—12
11—3
11—12
11—2
11—24
11—31
11—12
11—26
10—16
10—17
10—22
10—3
11—19
11—35
10—5
11—15
11—17
11—19
11—14
11—50
11—18
11—40
10—11
10—13
11—16
11—25
11—18

Index 13

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

UP-8068 Rev. 4

Reference

Term

Page

Term

Job control statements
assigning tape device (DVC)
defining your logical file (LFD)
end-of-data (/*)
magnetic tape files
sample programs
SCR
specifying tape file label
information (LBL)
specifying tape volume
information (VOL)
start-of-data (1$)
use

1.7.2

1—16

Label processing routine

15.6.14
D.4

15—37
D—28

9.3.1
9.3.2
2.3.2
9.3
3.7
16.1.3

9—31
9—32
2—3
9—31
3—25
16—2

Label standard level field, ASCII
tape labels

E.3.2.2

E—16

9.3.4

9—36

9.3.3
2.3.1
16.1.1

9—33
2—3
16—1

Labels
disk files
EBCDIC
format
LBL statement
magnetic tape
processing
standard
user

15—30

9.3.4.2
9:3.4
16.1.1
Table 9—3rn
9.3.4.4
9.3.4.3
9.3.4.6
9.3.4.1
9.3.4.5

9—36
9—36
16—1
9—37
9—39
9—38
9—39
9—36
9—39

LBRET macro
magnetic tape
nonindexed disk

9.4.9
15.7.3

9—60
15—64

LCB job control statement

16.1.1

16—1

LCB statement specification
description
0768 printer
0770 and 0776 printers
0773 and 0778 printers

6.4.2
6.4.2.3
6.4.2.2
6.4.2.1

6—7
6—8
6—8
6—8

Leader, paper tape

17.2.2

17—3

Letter scan table

17.5.5

17—50

Letter shift character

17.3.2

17—6

Letter shifting and translation
input files, character mode
output files, character mode

17.5.3
17.5.5

17—39
17—50

LBL job control statement
checking volume and file
serial numbers
description

Key search
assigning to multiple tracks
ISAM
nonindexed disk

14.3.3
Fig. 14—4
15.6.26
11.4.9
15.6.12

14—10
14—12
15—50
11—14
15—35

Keys
direct retrieval and updating
of input blocks
IRAM data records
IRAM processing
ISAM files
length of block, nonindexed
disk files
lengths, IRAM
number Of bytes preceding, IRAM
output of sequential DTFNI files
record, length and location
record, verifying ascending order
during file creation
retrieval, IRAM

15.7.14.2
Fig. 12—1
13.4.8
10.1

15—101
12—4
13—20
10—1

15.6.13
13.4.13
13.4.14
15.7.9.5
11.4.10

15—36
13—21
13—22
15—80
11—15

13.4.20
.13.4.12

13—23
13—21

See disk file labels.
See EBCDIC volume
organization.
See format labels.
See LBL job con
trol statement
See magnetic tape
labels.
See LBRET macro.
See standard labels.
See user labels.
15.6.8

Lace factor

Key fields, nonindexed files

Page

J
Job control functions

Reference

effects on OPEN transient
file creation date
file expiration date
file generation and version numbers
file identifier
file sequence number

UP-8068 Rev. 4

SPERRY UNIVAC OS/3
BASIC DATA MANAGEMENT

Term

Reference

Page

LFD job control statement

9.3.2
16.1.1

9—32
16—1

D.3.2
Fig. D—12

D—18
D—21

Library file information area,
disk format 2 label
Lines
skipping and spacing
truncation

6.1
7.5.2

6—-1
7—28

Linkage editor, description

1.7.4

1—17

Load code buffer
definition
interchangeability
LCB statement specification

6.1
6.4.1
6.4.2

6—1
6—7
6—7

Load program, sample ISAM

11.7.1

11—50

I Term

Reference

Magnetic tape files
description
extending
imperative macros
labels
multivolume
organization
record and block formats
volume and file organization

11.5.2.1
11.5.2.3

11—27
11—30

Logical end-of-file, recording

15:7.11.3

15—89

Logical file definition (LFD)

9.3.2

9—32

Fig. 10—4 10—9
10.1
10—1
10.2.1
10—5
17.4.4
17—22
See GET macro.

punching, paper tape
reading

Page

1.3.5
1—7
9.3.6
9—41
9.4
9—43
See magnetic
tape labels.
9.3.5
9—40
Fig. 1—2
1—8
8.2.5
8—14
Fig. 8—11 8—14
See magnetic
tape volume and
file organization.

UP 8068_Rev4d_Systems_90 25_90 30_90 40_Operating_System_3_(OS3)_Basic_Data_Management_User_Guide_Jun83 8068 Rev4d Systems 90 25 30 40 Operating System 3 (OS3) Basic Data Management User Guide Jun83

UP-8068_Rev4d_Systems_90-25_90-30_90-40_Operating_System_3_%28OS3%29_Basic_Data_Management_User_Guide_Jun83 user guide pdf -FilePursuit

UP-8068_Rev4d_Systems_90-25_90-30_90-40_Operating_System_3_(OS3)_Basic_Data_Management_User_Guide_Jun83 UP-8068_Rev4d_Systems_90-25_90-30_90-40_Operating_System_3_(OS3)_Basic_Data_Management_User_Guide_Jun83

Navigation menu

Versions of this User Manual:

Views

Navigation