The Rebuild Data Base file command is designed to assist in those
cases where the data base definition of a physical file has changed
and it is necessary to re-create all of the associated logical files
and programs.
RBLDBF will re-create:
- Named data base files (either physical or logical)
- Dependent logical files
JOIN files are created, but not the members
See later section on 'ADDLFM to Join files'
- Programs that use the files (per the information in DSPPGMREF)
- See later discussion of ILE programs
- Display and printer files that are used by the programs
Journaling will be restarted if needed. Authorizations are copied
from the original object. An optional copy of the data can also
occur.
The command is useful when one or more data base files must be
recreated and the entire network of files and programs must be
recreated.
Only a user with *ALLOBJ authority can use RBLDBF.
Assume you have a library named PRODUCTION with the following
objects:
FILEA Physical file
FILEB Physical file
FILEAL Logical file over FILEA
FILEBL Logical file over FILEB
FILEAB Logical file over FILEA and FILEB
PGM1 Uses FILEA
PGM2 Uses FILEB
PGM3 Uses FILEAL and FILEBL
PGM4 Uses FILEAB
You want to add a field to FILEA. This will require the physical
file, the dependent logicals and the dependent programs to be
recreated. Rather than individually specifying these recreate steps,
you could change the source for the FILEA DDS and issue the following
command:
RBLDBF LIB(PRODUCTION) FILE(FILEA) RCTPGMFIL(*NO)
The command rebuilds the objects in the TAARBLLIB library. The
physical file (FILEA) is created using the attributes from the
existing file and the DDS source member name used to create the
original file. Members are added, the data is copied using the the
CPYF FMTOPT(*MAP) option and journaling is restarted if needed. The
object owner is changed to that of the original owner and any
existing authorizations are copied to the new object.
The dependent logical files (FILEAL and FILEAB) are then found using
DSPDBR and created using a similar technique as described for a
physical file.
The DSPPGMREF function is used to determine the programs that use all
the files that were recreated. The programs (PGM1, PGM3, PGM4) are
then recreated using the source member that was used to originally
create the program.
When an object is created, the system keeps track of the source
member and file used for the create. RBLDBF requires the source to
be in the same member and file. An option exists for source stored
in a Source Archive (TAA tool SRCARC). The RBLDBF command first
tries to find the source in the original member. If it does not
exist and an archive library was specified, CPYSRCARCM is used to try
and find the source in the archive. If it exists in the archive, the
source is copied back to the original member and then used for the
re-create. The source is not removed from the original member.
A report is printed to QPRINT which identifies what was recreated.
It identifies the objects created, if they are a dependent file, what
they are dependent upon, any failures that have occurred, the members
created, the number of records copied and any comments.
The report will identify any problems during the recreate steps. For
example, it will note where the object could not be re-created for
such errors as:
- The file was originally created without DDS
- The source cannot be found
- The create step failed
- A Join file was created, but failed on ADDLFM
See later section on 'ADDLFM to Join files'
The dependent files are described. If a failure occurs, ** will
appear in the 'Fail' column along with a comment describing the
failure. The spool number of the create listing appears in the
'Splnbr' column.
The sample RBLDBF command specified RCTPGMFIL(*NO). The default is
*YES. If *YES is specified, any externally described display or
printer files used by the programs will be re-created before the
programs are re-created. The intent of this parameter is to allow
for the case where a data base field is being changed rather than
added. Re-creating the display and printer files allows the use of
the field reference functions in these files in case they are
referring to the new field definition. Normally, there is no harm in
re-creating the display and printer files regardless of whether a
field is being added or changed in the data base.
There are several instances (e.g. with CL programs) where the file
used in the program cannot be determined. For example, if a variable
is used for the name. The program will bypass any file names that
begin with a blank, an * or a &.
The RBLDBF command is a long running function because of the number
of create commands which must be executed, copying of data,
rebuilding of access paths, etc. Therefore, it can best be done in
offshift operations or in a low priority batch job.
The intent of the RBLDBF command is to create the objects so they are
ready to replace the corresponding objects in the PRODUCTION library.
ADDLFM will fail on a joined file
After reviewing the QPRINT output and ensuring it is now safe to
delete your original objects (i.e. no failures occurred and no one
is using the existing objects), you would issue the following
command:
RPLRBLOBJ
To replace FILEA in the PRODUCTION library, it is necessary to first
delete any dependent logical files. Then FILEA is deleted. This
occurs and then all of the files are moved to the production library.
The objects to be replaced are then deleted and the corresponding
objects are moved from the TAARBLLIB library.
A report is printed to QPRINT to identify the results of the command
and note any problems.
In summary, the first command (RBLDBF) rebuilds the objects to the
separate library TAARBLLIB. If anything goes wrong, your original
objects are still intact. The second command (RPLRBLOBJ) deletes
your original objects and moves the rebuilt objects.
ADDLFM to Join files
--------------------
RBLDBF will re-create the Join LFs, but cannot add a member.
Programs using the file should re-create normally.
The problem occurs because the DATAMBRS parameter that is generated
to add the member in TAARBLLIB will not agree with the source member
that describes how to join the file.
You can recover after RPLRBLOBJ by using CRTLF (assuming you still
have the source) or issue the ADDLFM command as required.
ILE Programs
------------
Only CRTBNDRPG and CRTBNDCL are supported and these commands have
restrictions because of system limitations. See the discussion with
RPLPGM.
Restrictions
------------
** The source member used to originally create the object must be
available in the same file/library/member for the recreate
step. There are several cases where problems may occur:
-- CRTPF was used with the RCDLEN parameter (No DDS ever
existed).
-- The source used for the original creation has
subsequently been moved, renamed or deleted.
-- If the TAA tool SRCARC is being used to archive the
source, an option exists on RBLDBF to name the archive.
If the source does not exist in the original member and
an archive is specified, CPYSRCARCM is used to copy the
source back to the original member.
** Some DDS source keywords allow a qualified name (e.g. PFILE).
This can cause an incorrect creation. Unqualified names
should be used. Because of the sequencing of recreation and
the ordering of the TAARBLLIB library before user libraries,
the proper match of dependent files will normally be found
with unqualified names.
** Re-create of all dependent logical files will occur regardless
of whether they use the same format as the physical or not.
This may result in re-creating logical files and dependent
programs even though they are not impacted by the physical
file change made. For physical files, only the files
specified on the command are re-created.
** Join logical files will be re-created, but ADDLFM will fail.
See the section on 'ADDLFM to Join files'
** The DFU and Query objects cannot be recreated because no
source exists. The S/38 compatibility DFU and Query do have
source and are properly recreated.
** No check is made to ensure the date of last change to the
source is the same as that described in the DSPOBJD
information. The command assumes that the current source is
what is desired.
** The current attributes for physical/logical files and their
members are extracted from the existing objects and used on
the appropriate create and add member commands.
** For all HLL programs, the existing values for USRPRF, TEXT,
OPTIMIZE, RMVOBS, and USEADPAUT are used. For CL programs,
the parameters LOG and ALWRTVSRC are also used. For RPG, the
IGNDECERR parameter is not used. Parameters like OPTION and
GENOPT are defaulted for all HLLs.
** Only data base files are supported on the command. DSPPGMREF
output is used to find the dependent programs. For each
dependent program, DSPPGMREF output is also used to determine
other files used by the program which may also be re-created.
If they are data base files, they are ignored. If they are
printer or display files, they are re-created if
RCTPGMFIL(*YES) is specified. Other file types (e.g. ICF)
are not re-created.
If a program described printer file is used by the program,
DSPPGMREF does not contain the actual library where the file
was found. If the object exists in the libraries provided, a
create will be attempted and will fail with the message
stating that 'No DDS could be found'. If the objects cannot
be found, a unique error message exists to describe that the
file is probably program described and does not need to be
re-created.
To re-create printer and display files, the TAA Tool RTVPRTFA,
RTVSPLA and RTVDSPFA commands are used. All display file
parameters are used. For printer files, there are a few
exclusions like RPLUNPRT for which defaults are assumed.
** When an object is created in TAARBLLIB, the DSPPGMREF function
will always refer to that library rather than the actual
library where the object is eventually moved to.
If the same object is again re-created by RBLDBF, the code
assumes that since the library of the referenced objects is
TAARBLLIB, the DSPOBJD function should be searched by a key
that does not include library name. If the object is found,
it's library is assumed to be the location of the object to be
rebuilt. If unique names are used, this should not present
any problems.
** Only the first unique name/type in all the libraries specified
is re-created. For example, if you have the same program name
in two different libraries dependent on a file which is being
created, only a single version of the program can exist in the
TAARBLLIB library. Therefore, any duplicate name/type
combinations are diagnosed.
** The RBLDBF and RPLRBLOBJ commands assume that you are not
making changes to the libraries (e.g. new dependent objects)
from the time RBLDBF is issued until RPLRBLOBJ completes. If
you have made some changes, the rebuild/replace function
cannot perform properly.
** The RBLDBF command defaults to use CPYF FMTOPT(*MAP). An
option exists to not copy and to also use the FMTOPT(*DROP)
function. If you are splitting a field in your existing data
base, you will need to prevent the copy performed by RBLDBF
and write a program to reformat the data. It is still
possible to use the functions provided, but your reformat
program needs to be executed after RBLDBF completes and before
RPLRBLOBJ is executed.
** The recreation of programs is dependent upon the DSPPGMREF
capability to store the file names used by the program. If
the file name used by the program does not represent the real
file to be processed (e.g. overrides are used), all of the
dependent programs will not be recreated.
RBLDBF command parameters *CMD
-------------------------
LIB A list of up to 10 library names that describe the
libraries that contain the objects you want rebuilt.
Dependent programs that are outside of these
libraries will not be rebuilt. The order in which
you specify the libraries determines their order on
the library list. The TAARBLLIB library will appear
before these libraries.
FILE A list of up to 20 file names that need to be
rebuilt. Either physical or logical files may be
named, but physical files should be named first.
Other file types are invalid. Dependent files need
not be named as they will be created automatically.
A qualified name may be used, but the library
specified must appear in the list provided for the
LIB parameter. The default for the library is
*FSTLIB meaning the first library specified on the
LIB parameter.
Because the files and programs from multiple
libraries will be built in the TAARBLLIB library,
the file and program names must be unique.
JOBD The qualified JOBD name to use to submit to batch.
*USRPRF is the default. The command is designed to
be entered interactively with the creates being done
in batch. If the command is executed in batch, the
JOBD is ignored.
CPYF Determines if CPYF should be executed. The default
is *YES which means CPYF will be used. The other
entries are *NO and *TEST.
The *TEST value specifies that one record will be
copied and then the file in the TAARBLLIB library
will be cleared. This option can be used if you are
testing the use of RBLDBF, but still want to ensure
that the CPYF command and it's options are tested.
For example, you may choose the *TEST option in
conjunction with RCTPGM(*NO) to ensure the files
properly recreate and can be copied before
recreating all the programs.
MAP Determines if CPYF FORMAT(*MAP) should be used.
*YES is the default. *YES means to map the data
using the corresponding field names. *NO does not
cause CPYF.
DROP Determines if CPYF FORMAT(*DROP) should be used.
*NO is the default. *YES should only be specified
when you are dropping fields from an existing file
definition.
RCTPGM Determines if dependent programs should be
recreated. The default is *YES. *NO may be
specified. This applies to any HLL program
including CLP types as well as the S/38
compatibility DFU and Query applications. If you
are changing some DDS which will not change the
level ID of the file (e.g. Text description of a
field), you do not need to recreate the programs
that use the file. Specify RCTPGM(*NO) when you
will not have a level check mismatch.
SRCARCLIB Determines if the source may be stored in a source
archive (TAA tool SRCARC). *NONE is the default.
When an object is created, the system stores the
name of the source member and file used for the
create in the object. RBLDBF requires that the
source exist in the same file and member. If it
does not exist and an archive library is named,
CPYSRCARCM is used to attempt to copy the source
back to its original member.
Use of the archive in this manner allows the new
object to properly reflect where the source existed
at the time of the create. The source is not
removed after the copy. This allows the UPDSRCARC
function to capture a new version because the source
change date does not agree with the archive current
version. The reason for not removing a 'copied out'
member is so the archive version will have the same
'last source change date' that agrees with the date
kept within the object.
RCTPGMFIL Determines if the files used by the dependent
programs should be recreated before the programs are
recreated. The default is *YES. The files to be
recreated are only the types *DSPF and *PRTF.
The intent of this parameter is to allow for the
case where a field in the data base is being changed
in size and the field is also used in an externally
described display or printer file. If the display
or printer file uses the reference function to
define the field (either references the data base
file that will be re-created or a field reference
file), the display or printer file will be
re-created before the program is re-created.
This parameter is ignored if RCTPGM(*NO) is
specified. If you are only adding a field to the
data base, you could specify RCTPGMFIL(*NO) as the
display and printer files used by the dependent
programs should not need to be re-created.
There should be no harm in taking the default of
RCTPGMFIL(*YES) if you are only adding a field to
the data base. This will cause unnecessary creates
of the display and printer files, but should not
cause any problems.
REPLACE Determines if recreated objects should be replaced
at the completion of the RBLDBF function. *NO is
the default meaning the recreated objects will be
left in the TAARBLLIB library. *YES may be
specified in which case the RPLRBLOBJ command is
implicitly executed. The RPLRBLOBJ command will
only be executed if *YES is specified and no
failures occurred on RBLDBF. If any failures occur,
you may choose to execute the RPLRBLOBJ command
after reviewing the failures. If REPLACE(*YES) is
specified, CPYF(*YES) must also be specified.
OUTQ The qualified name of the output queue for the
results of the job. The default is *JOB meaning to
use the output queue assigned to the job (e.g. the
job description). This allows all output to be
directed to a special queue so you may decide to
clear the queue if the compilation listings are not
needed. The default library qualifier is *LIBL.
The library is not used if *JOB is specified.
After the RBLDBF command completes you should do the following:
** Review the QPRINT listing.
** Correct or account for any errors
** Use the RPLRBLOBJ command if needed
It is not necessary to use the RPLRBLOBJ command. You can totally
ignore the results. If you decide not to use the created objects,
you should consider clearing the TAARBLLIB. You can run RBLDBF
again. It will replace any objects created in TAARBLLIB.
RPLRBLOBJ command parameters *CMD
----------------------------
RPLRBLOBJ is only valid on a single use of RBLDBF. For example, you
cannot run RBLDBF multiple times and use all of the created objects
with a single RPLRBLOBJ command. RPLRBLOBJ uses information stored
in controlling files to determine what should be replaced. It will
only operate on the objects created by the last use of RBLDBF.
JOBD The qualified JOBD name to use to submit to batch.
*USRPRF is the default. The command is designed to
be entered interactively with the replacements being
done in batch. If the command is executed in batch,
the JOBD is ignored.
After the RPLRBLOBJ command completes, you should do the following:
** Review the QPRINT listing.
** The TAARBLLIB library should have only the following objects:
RBLOBJP DSPOBJD output (no records will exist)
RBLPGMP DSPPGMREF output (no records will exist)
RBLPGML Logical over RBLPGMP by obj and type
RBLRCTP Recreated objects from the last RBLDBF
RBLRCTL Logical file over RBLRCTP by obj and type
RBLRCTLA Logical file over RBLRCTP in arrival seq
RBLDLTP Deleted objects from the last RPLRBLOBJ
RBLCMP A data area containing a completion code
Any other objects are the result of you placing objects into
the TAARBLLIB library or a failure from a previous RBLDBF
command. Any unwanted objects can be deleted. There is no
harm in clearing the TAARBLLIB library. The work objects
needed will be automatically recreated each time RBLDBF is
used.
** If you are journaling some of the physical files that were
re-created, you should save these files now to provide a
recoverable situation by use of the journal.
Security Considerations
-----------------------
Only a user with *ALLOBJ special authority can use RBLDBF.
The objects are created as owned by QSECOFR and then ownership is
transferred to the original owner. While this avoids security
problems during the recreates, it also allows any object to be
recreated.
You must have *ALLOBJ authority to create the RBLDBF command.
Flow of the rebuild steps
-------------------------
The RBLDBF command begins by diagnosing the command parameters and
submits the RBLDBF job to batch (if the command is executed from
batch, a call occurs). A main controlling program then takes over.
The program checks for required work objects in the TAARBLLIB library
and if they do not exist, they are created. The program ensures that
only one user at a time is using the TAARBLLIB library for the RBLDBF
function.
DSPOBJD is used on all of the libraries specified on the LIB
parameter to build an outfile. This contains the objects in the
libraries specified and each record also contains the information on
where the source existed that was used to create the objects. If
RCTPGM(*YES) is specified, DSPPGMREF is run against the same
libraries to build a file of program/file references.
The files specified on the file parameter are then checked for
existence and the rebuild process begins. If a file of the same name
exists in the TAARBLLIB library, it is deleted along with any
dependent files. This allows for successive uses of RBLDBF without
moving the objects from the TAARBLLIB library. Note that RPLRBLOBJ
will only operate on the objects created from the last use of RBLDBF.
The recreate process will only allow for unique name/types to be
created. For example, if you have the same program name in multiple
libraries that are dependent on the same file, only the first program
will be recreated as there is only room for one version in the
TAARBLLIB library. The duplicates are diagnosed.
DSPFD is used to extract the attributes of each physical file to be
created. The DSPOBJD information is used to locate the source member
that was originally used for the DDS. The CRTPF command is executed.
Member attributes are also extracted and the same list of members as
exists in the original file is created using ADDPFM.
If CPYF(*YES) is specified, the data is copied from the corresponding
members. The CPYF FMTOPT values of *MAP and *DROP are passed thru
from the RBLDBF command.
If the file has journaling specified, journaling is restarted at this
point. Both STRJRNPF and STRJRNAP are used if the original files had
specified them. Note that journaling is started after the data is
copied. The file should be saved at the completion of the command to
ensure proper journal recovery.
If a logical file is specified, the same sequence of events occurs
except for CPYF. The DTAMBRS information is specified for the ADDLFM
command based on the existing attributes. Join and multi-format
logical files are supported along with multi-member logical files.
When the files have been processed that were specified on the FILE
parameter of RBLDBF, the dependent files are accessed using DSPDBR.
Each of these files is then created in the TAARBLLIB library as per
the previous description.
When all files have been created, the DSPPGMREF information is
accessed for each of the recreated files. If a program is dependent
on the file, the program cross reference information is found in the
DSPPGMREF file.
The files used by the program are checked. If RCTPGMFIL(*YES) is
specified, the externally described display and printer files used by
the program are re-created. This requires the attributes to be
extracted from the existing objects and used to create the new
objects. The TAA Tool RTVPRTFA, RTVSPLA and RTVDSPFA commands are
used. The DSPOBJD information is used to determine the source file
and member that were used to create the file. The same file, library
and member name are used for the re-create. See also the SRCARCLIB
option.
After the display and printer files are created, the dependent
programs are created.
The DSPOBJD information for a program is used to determine where the
source existed when the program was originally created. This same
name and library is used as the source file/member containing the HLL
statements. The TAA Tool RTVPGMA command is used to extract the
program parameters such as USRPRF. The object text from the original
object is used for the TEXT parameter on the CRTxxxPGM commands (the
source member text is not used). There is no support for the RPG
IGNDECERR parameter.
RBLDBF will re-create CL, RPG, COBOL, PL/I, or BASIC programs. The
S/38 type versions are also properly re-created. The S/36 versions
of RPG and COBOL are properly re-created. You must have the
appropriate compiler on your system to create the corresponding type.
After determining the CRTxxxPGM command exists, the program executes
the command using QCMDEXC. Therefore, it is not necessary to modify
the code if you do not have one of the compilers.
RBLDBF can be used with the S/38 compatibility DFU and Query
products. The DFU and Query do not have a source form and therefore
cannot be re-created.
If a S/38 compatibility DFU or Query application is dependent on the
recreated files, the application is recreated in the TAARBLLIB
library. The USRPRF and TEXT parameters are retrieved from the
object and used on the QSYS38/CRTxxxAPP command. The
QSYS38/RTVxxxSRC command is used to retrieve the existing DFU or
Query source and it is placed in a file in QTEMP. Because the DFU
and Query source are for a specific library, the DFU or Query
applications are recreated only to ensure a successful process. The
recreated applications in the TAARBLLIB library are not used to move
back to the original library.
After an object has been created, the CHGOBJOWN command is executed
to make the owner the same as the original object. The original
owner of the rebuilt object is revoked.
When the objects are created in the TAARBLLIB library, they are
created with AUT(*NONE). The authorizations are then copied from the
original object to the rebuilt version including the proper status of
public authority and any authorization list reference.
A report is prepared as each object is created, member added etc.
Any errors are posted. If REPLACE(*YES) was specified and errors
exist, the objects are not replaced. Instead, they are left in the
TAARBLLIB library. After reviewing the results, you may issue the
RPLRBLOBJ command to replace those objects which were successfully
created.
If REPLACE(*YES) is specified and no errors exist, the RPLRBLOBJ
command is invoked automatically.
The RPLRBLOBJ command submits a job to batch. If the job is already
in batch, a CALL command occurs. The program checks to see if the
RBLDBF function has been run previously. If not an error occurs and
the command terminates. The RPLRBLOBJ command can only be executed
once per each use of the RBLDBF command. If the RBLDBF command
requested REPLACE(*YES) and the replace occurred, the RPLRBLOBJ
command cannot be executed.
A file of created objects is built by the RBLDBF command. This file
is read and the replacement of objects begins. To replace an object
requires that it be deleted in the original library. If there are
dependent files, they must be deleted first. The object is then
moved to the original library.
If an S/38 compatibility DFU or Query application is to be replaced,
the processing differs. Since the DFU and Query objects are tied to
a specific library, a QSYS38/CRTxxxAPP is used instead of a move.
The QSYS38/RTVxxxAPP command is used to access the application
source. The QSYS38/DLTxxxAPP command deletes the original object and
the QSYS38/CRTxxxAPP command occurs with the original values for
USRPRF and TEXT. The object in the TAARBLLIB library is then used as
a reference object to grant authorizations to the newly created
application in the original library. Ownership is changed to the
owner of the original version. The application in the TAARBLLIB
library is then deleted.
A listing is prepared identifying all the objects that have been
deleted and those which have been replaced. Any failures are noted.
TAARBLLIB Library
-----------------
The TAARBLLIB library must exist on your system. It contains a few
controlling objects as well as the objects which have been recreated
and not yet moved. You cannot use TAARBLLIB in the LIB or FILE
parameters.
The RBLDBF command is written so that it will replace any user
objects of the same name if they happen to exist in the TAARBLLIB
library. At the conclusion of successful RBLDBF and RPLRBLOBJ
commands, the TAARBLLIB library will also contain the controlling
objects described with the RPLRBLOBJ command description.
The TAARBLLIB library may be cleared after each usage. The required
objects will be rebuilt if they do not already exist. Any rebuilt
objects that have not been moved will still be in the TAARBLLIB
library. You may move or delete these.
The TAARBLLIB library does not need to be saved.
Restrictions
------------
Only a user with *ALLOBJ authority can use the RBLDBF functions.
Prerequisites
-------------
The following TAA Tools must be on your system:
ADDDTAARA Add data area
CHKALLOBJ Check all object authority
CHKAPOST Check apostrophe
RPLPGM Replace program
RPLDSPF Replace display file
RPLPRTF Replace printer file
RTVPGMA Retrieve program attributes
RTVSPLA Retrieve spool attributes
SNDCOMPMSG Send completion message
SNDESCMSG Send escape message
SRCARC Source archive
The RBLPRT and RBLPRT2 commands used by the RBLDBF tool are created
as part of RBLDBF and are used by some of the programs. These are
internal commands that have no external purpose.
Implementation
--------------
The tool is ready to use, but you must create the library TAARBLLIB:
CRTLIB LIB(TAARBLLIB) TEXT('Library used by TAA Tool +
RBLDBF tool')
Objects used by the tool
------------------------
Object Type Attribute Src member Src file
------ ----- --------- ---------- -----------
RBLDBF *CMD TAADBFP QATTCMD
RPLRBLOBJ *CMD TAADBFP2 QATTCMD
RBLPRT *CMD TAADBFP3 QATTCMD
RBLPRT2 *CMD TAADBFP4 QATTCMD
RBLRCTP *FILE PF TAADBFPP QATTDDS
RBLDLTP *FILE PF TAADBFPP2 QATTDDS
RBLOBJP *FILE PF TAADBFPP3 QATTDDS
RBLPGMP *FILE PF TAADBFPP4 QATTDDS
RBLRCTL *FILE LF TAADBFPL QATTDDS
RBLPGML *FILE LF TAADBFPL2 QATTDDS
RBLRCTLA *FILE LF TAADBFPL3 QATTDDS
RBLOBJL *FILE LF TAADBFPL4 QATTDDS
TAADBFPC *PGM CLP TAADBFPC QATTCL
TAADBFPC2 *PGM CLP TAADBFPC2 QATTCL
TAADBFPC3 *PGM CLP TAADBFPC3 QATTCL
TAADBFPC4 *PGM CLP TAADBFPC4 QATTCL
TAADBFPC5 *PGM CLP TAADBFPC5 QATTCL
TAADBFPC6 *PGM CLP TAADBFPC6 QATTCL
TAADBFPC7 *PGM CLP TAADBFPC7 QATTCL
TAADBFPC8 *PGM CLP TAADBFPC8 QATTCL
TAADBFPC9 *PGM CLP TAADBFPC9 QATTCL
TAADBFPC10 *PGM CLP TAADBFPC10 QATTCL
TAADBFPC11 *PGM CLP TAADBFPC11 QATTCL
TAADBFPC12 *PGM CLP TAADBFPC12 QATTCL
TAADBFPC13 *PGM CLP TAADBFPC13 QATTCL
TAADBFPC14 *PGM CLP TAADBFPC14 QATTCL
TAADBFPC15 *PGM CLP TAADBFPC15 QATTCL
TAADBFPC16 *PGM CLP TAADBFPC16 QATTCL
TAADBFPC17 *PGM CLP TAADBFPC17 QATTCL
TAADBFPC18 *PGM CLP TAADBFPC18 QATTCL
TAADBFPC19 *PGM CLP TAADBFPC19 QATTCL
TAADBFPC20 *PGM CLP TAADBFPC20 QATTCL
TAADBFPC25 *PGM CLP TAADBFPC25 QATTCL
TAADBFPR *PGM RPG TAADBFPR QATTRPG
TAADBFPR3 *PGM RPG TAADBFPR3 QATTRPG
TAADBFPR4 *PGM RPG TAADBFPR4 QATTRPG
TAADBFPR5 *PGM RPG TAADBFPR5 QATTRPG
Note that no TAADBFPR2 source or program exists.
Structure
---------
RBLDBF command
TAADBFPC Cl pgm
Submits to batch TAADBFPC18
TAADBFPC18 - Controlling re-create program in batch
TAADBFPR RPG pgm - Determines what to create
TAADBFPC7 - Does DSPDBR for named files
TAADBFPC3 - Prints error messages using RBLPRT
TAADBFPC4 - Controls object create
TAADBFPC13 - Deletes dependent logicals in TAARBLLIB
TAADBFPC5 - Re-create PFs
TAADBFPC25 - Re-create trigger pgms and ADDPFTRG
TAADBFPR5 - Place trigger pgms in RPL list
TAADBFPC6 - Re-create PF with no member
TAADBFPC11 - Start journaling function
TAADBFPC12 - Determines based on files
TAADBFPC10 - CPYF function
TAADBFPC11 - Start journaling function
TAADBFPC12 - Determines based on files
TAADBFPC8 - Re-create LFs
TAADBFPC9 - Re-create LF with no member
TAADBFPC11 - Start journaling function
TAADBFPC12 - Determines based on files
TAADBFPC15 - DFU and Query re-create
TAADBFPC14 - Re-create programs
TAADBFPC19 - Re-create display files
TAADBFPC20 - Re-create printer files
Some of the programs use the RBLPRT command to print
the output. This is an internal command for the RBLDBF
function and has no external purpose.
RBLPRT command
TAADBFPR3 RPG program
RPLRBLOBJ command
TAADBFPC2 CL program
Submits to batch TAADBFPC17
TAADBFPC17 - Controlling replace program in batch
TAADBFPC13 - Deletes dependent logicals in original library
TAADBFPC16 - DFU and Query re-create
The TAADBFPC17 program uses the RBLPRT2 command to
print the output. This is an internal command for the
RPLRBLOBJ function and has no external purpose.
RBLPRT2 command
TAADBFPR4 RPG program
|
