Ü Physical
file
·
It is a file which. Contains
the data in predefined structured format.
·
It’s type PF. By using CRTPF
command to create PF.
·
Maximum number of fields
included in a PF is 8000.
·
Maximum no of key fields
included is 120.
·
The structure of the PF is
given below:
PHYSICAL
FILE INTERNAL STRUCTURE
|
TYPE SPECIFIC ATTRITIBUTE
|
|
TYPE INDEPENDENT ATTRIBUTE
|
|
RECORD FORMAT
|
|
KEYED ACCESS PATH
|
|
RECORDS
|
TYPE SPECIFIC ATTRIBUTE: Specific to its type
TYPE INDEPENDENT ATTRIBUTE: Creation date, author,
size, expiration detail
KEYED ACCESS PATH: An area within a
physical file obj where key field data is stored in the order along with their
RRN
Ü
Levels of entries in physical file
Columns . . . : 1 71 Browse AMINEM/DDSSRC
SEU==> ACCOUNT
FMT PF .....A..........T.Name++++++RLen++TDpB......Functions++++++++++++++++++
*************** Beginning of data *****************************
0001.00 A UNIQUE >>>>> FILE LEVEL
0002.00 A R ACCOUNT >>>>> RECORD FORMAT LEVEL
0003.00 A ACLEVELID 2P 0
0004.00 A ACORGCOD 3P 0 >>>>> FIELD LEVEL
0005.00 A ACCOUNTNUM 12P 0
0006.00 A ACCURRENCY 3A
0007.00 A ACNAME 20A
0009.00 A K ACLEVELID
0010.00 A K ACORGCOD >>>>> KEYFIELD LEVEL
0011.00 A K ACCOUNTNUM
0012.00 A K ACCURRENCY
****************** End of data ********************************
I.
File level entries (optional): File level entries
give the system information of the entire file. UNIQUE, LIFO, FIFO, FCFO, REF
are the keywords used at file level.
UNIQUE: A record cannot be entered or copied into a file if its key value is
same as the key value of a record already existing in the file.
FIFO: The duplicate key
records will retrieved in first in first out order.
LIFO: The
duplicate key records will retrieved in last in first out order.
FCFO: The
duplicate key records will retrieved in first changed first out order.
REF: This keyword is used to specify the name of the file from which the fields are taking definition.
II.
Record format level entries: For a PF the record format name is specified along with an
optional text description. The record level entries can be FORMAT, TEXT.
FORMAT:
This record-level keyword specifies that the
record format being define is to share the field specifications of a previously
defined record format. The name of the record format being defined must be the
name of the previously defined record format.
The format of this keyword is:
FORMAT
(LIB-NAME / FILE-NAME)
TEXT:
This record level keyword is used to supply a
text description of the record format and it is used for documentation purposes only.
The format of
this keyword is:
TEXT
(‘description’)
III.
Field level entries: The field names and field lengths are specified along with and
optional text description for each field. (ALIAS, ALWNULL, CCSID, CHECK,
CHKMSGID, CMP, COLHDG, COMP, DATFMT, DATSEP, DFT, EDTCDE, EDTWRD, REFFLD,
REFSHIFT, TEXT, TIMEFMT, TIMESEP, VALUES, VARLEN)
IV.
Key field level entries: The field names used as key fields are specified. (DESCEND, SIGNED, ABSVAL,
UNSIGNED, ZONE, NOALTSEQ, DIGIT)
Ü File level keywords FIFO, LIFO, FCFO
FIFO: The duplicate key records will retrieved in first in first out
order.
LIFO: The duplicate key records will
retrieved in last in first out order.
FCFO: The duplicate key records will
retrieved in first changed first out order.
ü When the FIFO, FCFO, or LIFO keyword is not specified, no guaranteed
order is specified for retrieving
records with duplicate keys.
ü No specific order for duplicate key fields allows more access path
sharing, which can improve performance.
Arranging duplicate
keys:
ü
If you do not specify the
Unique (UNIQUE) keyword in data description specifications (DDS), you can
specify how the system stores records with duplicate key values.
ü
You specify that records with
duplicate key values are stored in the access path in one of the following
ways:
Last-in-first-out (LIFO):
When the LIFO keyword is specified, records with duplicate key values are
retrieved in LIFO order by the physical sequence of the records. Here is an
example of DDS using the LIFO keyword.
A LIFO
A R REC2
A .
A .
A .
A K EMPNO
Assume that a
physical file has the FIFO keyword specified (records with duplicate keys are
in FIFO order), and that the following table shows the order in which records
were added to the file.
|
Order in which records were added to
file
|
Key value
|
|
1
|
A
|
|
2
|
B
|
|
3
|
C
|
|
4
|
C
|
|
5
|
D
|
|
The sequence of
the access path is FIFO, with ascending key values.
Records 3 and
4, which have duplicate key values, are in FIFO order. That is, because record
3 was added to the file before record 4, it is read before record 4.
This would become apparent if the records were read in descending order.
This can be done by creating a logical file based on this physical file, with
the DESCEND keyword specified in the logical file.
The sequence of
the access path is FIFO, with descending key values.
|
Record number
|
Key value access order
|
|
5
|
D
|
|
3
|
C
|
|
4
|
C
|
|
2
|
B
|
|
1
|
A
|
|
If the key
value of physical record 1 is changed to C, the sequence of the access path for
the physical file is FIFO, with ascending key values.
|
Record number
|
Key value access order
|
|
2
|
B
|
|
1
|
C
|
|
3
|
C
|
|
4
|
C
|
|
5
|
D
|
|
Finally,
changing to descending order, the new sequence of the access path for the
logical file is FIFO, with descending key values.
|
Record number
|
Key value access order
|
|
5
|
D
|
|
1
|
C
|
|
3
|
C
|
|
4
|
C
|
|
2
|
B
|
|
After the
change, record 1 does not appear after record 4, even though the contents of
the key field were updated after record 4 was added.
The FCFO order
of records with duplicate key values is determined by the sequence of updates
made to the contents of the key fields. In the preceding example, after record
1 is changed such that the key value is C, the sequence of the access path is
FCFO, with ascending key values only.
|
Record number
|
Key value access order
|
|
2
|
B
|
|
3
|
C
|
|
4
|
C
|
|
1
|
C
|
|
5
|
D
|
|
Ü File level keywords REF
USE OF REFERENCE
Columns . . . : 1 71 Browse AMINEM/DDSSRC
SEU==> REFER
FMT PF .....A..........T.Name++++++RLen++TDpB......Functions++++++++++++++++++
*************** Beginning of data *************************************
0002.00 A R REF
0003.00 A RAC1 2P 0 COLHDG('LEVEL ID')
0004.00 A RAC2 3P 0 COLHDG('ORG CODE')
0005.00 A RAC3 12P 0 COLHDG('ACCOUNT NUM')
0006.00 A RAC4 3A COLHDG('ACCOUNT CURRENCY')
0007.00 A RPOSTCODE 2P 0 COLHDG('POST CODE')
0008.00 A RCOUNTRY 3P 0 COLHDG('COUNTRY CODE')
0009.00 A RNAME 20A COLHDG('NAME')
0010.00 A RDATE 3P 0 COLHDG('DATE')
****************** End of data ****************************************
Now
we can refer the file ‘REFER’ to take the field definition in the new file.
Columns . . . : 1 71 Browse AMINEM/DDSSRC
SEU==> USEREF
FMT PF .....A..........T.Name++++++RLen++TDpB......Functions++++++++++++++++++
*************** Beginning of data *************************************
0002.00 A REF(REFER)
0003.00 A R USEREF
0004.00 A ACCLVL R REFFLD(RAC1 REFER) >>>>>> field name and
0005.00 ALIAS(ACC_LVL_ID) referred file name
0007.00 A ACCORG R REFFLD(RAC2 REFER)
0008.00 ALIAS(ACC_ORG_CODE)
0009.00 A ACCNUM R REFFLD(RAC3 REFER)
0010.00 ALIAS(ACC_NUM)
0011.00 A ACCCUR R REFFLD(RAC4 REFER)
0012.00 ALIAS(ACC_CUR)
0013.00 A ACCNAME R REFFLD(RNAME REFER)
0014.00 ALIAS(ACC_NAME)
****************** End of data ****************************************
Both(COLHDG & ALIAS) are used to identify fields. COLHDG
& ALIAS is the Description of
fields. The difference is that in ALIAS we can access data based on that ALIAS
name, while COLHDG is not allowed. Suppose in PF field name as DES78, give
ALIAS as Description78, then user can access data from using Description78.
Ü
Related Command
Ø
Create
Physical File (CRTPF)
CRTPF FILE(AMITNEM/OBJ) SRCFILE(AMINEM/QDDSSRC)
SRCMBR(OBJ_SRC)
ü The above command is similar to taking option-14 against the source
member in member PDM(WRKMBRPDM).
ü If there is any data in the physical file and you are using
CRTPF/option-14, then all the data in the physical file will be lost.
Ø Change Physical File (CHGPF)
CHGPF FILE(AMITNEM/OBJ) SRCFILE(AMINEM/QDDSSRC)
SRCMBR(OBJ_SRC)
ü If you don’t want to lose the data, but you want to compile the
source member, then you can achieve this by CHGPF command.
ü We generally use CHGPF to change the attribute which are highlighted
below.
Change Physical File (CHGPF)
Type choices, press Enter.
Physical file . . . . . . . . . Name
Library . . . . . . . . . . . *LIBL Name, *LIBL, *CURLIB
System . . . . . . . . . . . . . *LCL *LCL, *RMT, *FILETYPE
Source file . . . . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Expiration date for member . . . *SAME Date, *SAME, *NONE
Maximum members . . . . . . . . *SAME Number, *SAME, *NOMAX
Access path size . . . . . . . . *SAME *SAME, *MAX4GB, *MAX1TB
Access path maintenance . . . . *SAME *SAME, *IMMED, *REBLD, *DLY
Access path recovery . . . . . . *SAME *SAME, *NO, *AFTIPL, *IPL
Force keyed access path . . . . *SAME *SAME, *NO, *YES
Member size:
Initial number of records . . *SAME 1-2147483646, *NOMAX, *SAME
Increment number of records . *SAME 0-32767, *SAME
Maximum increments . . . . . . *SAME 0-32767, *SAME
Maximum file wait time . . . . . 30 Number, *SAME, *IMMED, *CLS
Maximum record wait time . . . . 60 Number, *SAME, *IMMED, *NOMAX
Share open data path . . . . . . *SAME *SAME, *NO, *YES
Max % deleted records allowed . *NONE 1-100, *NONE, *SAME
Reuse deleted records . . . . . *YES *SAME, *YES, *NO
Sort sequence . . . . . . . . . *HEX Name, *SAME, *SRC, *JOB...
Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Can LEVEL CHECK ERROR occur if we do CHGPF?
It depends on
the value that we have set for LVLCHK (Record format level check) attribute.
If its value is
*YES then the record format level identifier is checked when the file is opened
and if it doesn’t match it throws the error.
If its value is
*NO, then the record format level identifier is not checked, hence no error.
Ø CHGPFM
Change Physical File Member (CHGPFM)
Type choices, press Enter.
Physical file . . . . . . . . . > MASTER Name
Library . . . . . . . . . . . > AMINEM Name, *LIBL, *CURLIB
Member . . . . . . . . . . . . . > *FIRST Name, *FIRST
Source type . . . . . . . . . . *NONE Name, *SAME, *NONE
Expiration date for member . . . *NONE Date, *SAME, *NONE
Share open data path . . . . . . *NO *SAME, *YES, *NO
Text description . . . . . . . ACCOUNT RELATED INFORMATION
Ø Display file description(DSPFD)
§ It is used to display the details about the file.
Ø Display file field description(DSPFFD)
§ It is used for listing details about individual fields.