How CA Ideal for CA Datacom Application Components Are Stored

This section outlines the idcm internal modules and describes how components of idcm applications are stored.
cadts151
This section outlines the 
CA Ideal™ for CA Datacom®
 internal modules and describes how components of 
CA Ideal™ for CA Datacom®
 applications are stored.
 
CA Ideal™ for CA Datacom®
 is comprised of a number of Assembler modules, falling into the following categories:
  •  
    Compiler
    -
    CA Ideal™ for CA Datacom®
     has its own compiler used online and in batch to build object modules of programs, panels, and reports.
  •  
    Executor
    -Control the 
    CA Ideal™ for CA Datacom®
     run-time environment.
  •  
    Online Services
    -These panels and processors create and maintain user and system definitions and process commands such as DISPLAY INDEX, CREATE, DELETE, DUPLICATE, MARK, PRINT, DISPLAY, CATALOG DATAVIEW, and SUBMIT.
  •  
    Editors
    -A separate editor or processor is available in 
    CA Ideal™ for CA Datacom®
     for each 
    CA Ideal™ for CA Datacom®
     application component. For more information, see the next section, Application Components, VLS, and the Datadictionary.
  •  
    Batch Utilities
    -Used for site administration functions.
For a list of individual 
CA Ideal™ for CA Datacom®
 internal modules as they relate to the 
CA Ideal™ for CA Datacom®
 Trace Facility, see Dial Trace Codes.
This page contains the following topics:
 
 
Application Components, VLS, and the Datadictionary
The following table shows how 
CA Ideal™ for CA Datacom®
 application components (systems, users, dataviews, data members, panels, reports, programs, and plans) are recorded in the Datadictionary, stored on a VLS library, or both.
 
VLS Libraries
 
 
Component
 
 
Dictionary
 
 
Source
 
 
Object
 
 
Panel
 
 
*IDDVW
 
 
IDDAT
 
SYSTEM
x
 
 
 
 
 
USER
X
 
 
 
 
 
DATAVIEW
X
 
 
 
X
 
MEMBER
 
 
 
 
 
X
PANEL IDENT
X
 
 
 
 
 
LAY/SUM/EXD, etc.
 
 
X
X
 
 
REPORT IDENT
X
 
 
 
 
 
PAR/HEA/DET/COL
 
X
 
 
 
 
PROGRAM IDENT
X
 
 
 
 
 
RESOURCE
X
 
 
 
 
 
PARAMETER
X
X
X
 
 
 
WORKING DATA
 
X
X
 
 
 
PROCEDURE
X
X
X
 
 
 
*PLAN
X
 
 
 
 
X
 
*
 A DB2 site can define a separate plan library.
Storing Application Components
Entries in the Datadictionary and VLS members for 
CA Ideal™ for CA Datacom®
 components are created at various times during the application development process.
The first 
CA Ideal™ for CA Datacom®
 entity-occurrences are stored in the Datadictionary when 
CA Ideal™ for CA Datacom®
 is installed. At that time, the first 
CA Ideal™ for CA Datacom®
 system and user are created, the appropriate entity-occurrences are added to the Datadictionary, the VLS source library, object library, and panel libraries are specified, and the appropriate relationships are created on the Datadictionary.
When additional users and systems are defined, 
CA Ideal™ for CA Datacom®
 adds other entries to the Datadictionary.
The Database Administrator defines modeled dataviews in the dictionary. In 
CA Ideal™ for CA Datacom®
, the CATALOG DVW command reads the dictionary tables and creates an object module in the IDDVW VLS library.
  •  
    Unmodeled Dataviews
    Defines in 
    CA Ideal™ for CA Datacom®
     and added to the dataview source library and the Datadictionary. The CATALOG DVW command accesses the source library and the dictionary tables and creates an object module in the IDDVW VLS library. You can create unmodeled dataviews for sequential files and VSAM files.
    CA Ideal™ for CA Datacom®
     data members are stored in the VLS library IDDAT. They are not modeled in the Datadictionary.
  •  
    Panels and Reports
    Are modeled in the Datadictionary and stored as VLS members. A dictionary entity-occurrence is created when the panel or report identification is entered. A single VLS member is added to the source library when the report parameter, header, detail, and column sections are created. This member contains all of these report components. A VLS member is added to the panel library for the panel layout, summary data, extended field definitions, input edit and validation rules, output edit rules, and facsimile. This member contains all of these panel components.
  •  
    Programs
    Are modeled in the Datadictionary and an entity-occurrence is created in the dictionary when the program identification is entered. Relationship occurrences are added when the program resource table is entered. Separate VLS members are added to the source library for each program component. That is, members are added for the program parameter data, working data, and procedure. Each member is added when the corresponding component is first edited.
Compilation and VLS Object Modules
The first time a 
CA Ideal™ for CA Datacom®
 application is compiled:
  • The program working data, parameter data, and the attributes of each panel are compiled into separate object modules, which are not deleted after compilation.
  • These objects, along with any cataloged dataviews, are merged into composite object modules.
  • The program procedure and report definitions are compiled and merged with the composite object module into an executable object.
The program symbol table is also built at compile time.
Each time a program is recompiled the program procedure is recompiled into the executable object module. Other parts of the program are only recompiled if they were changed since the last compile.
 
CA Ideal™ for CA Datacom®
 VLS Operations
This section describes how various 
CA Ideal™ for CA Datacom®
 commands affect VLS members.
CREATE
 
DVW
 
Creates an unmodeled dataview that is a single member in the IDDVW library (type K).
 
MEM
 
Creates a single member in the IDDAT library (type Z).
 
PGM
 
CREATE PGM does not create any VLS members. See EDIT.
 
PNL
 
Creates a single member in the PANEL library (type U). This member contains all the components of the panel (parameters, layout, summary, field, and facsimile).
 
RPT
 
Creates a single member in the SOURCE library (type R). This member contains all the components of the report (parameters, heading, detail, and column).
EDIT
 
DVW
 
For an unmodeled dataview, a copy of the member on IDDVW is made with an edit-indicator of E. At normal end of EDIT, the E member is deleted.
  •  
    MEM
    Makes a copy of the data member on the IDDAT library with an edit-indicator of E. At normal end of EDIT, the E member is deleted.
  •  
    PGM
    A single program can result in up to three separate source members on the source library: Procedure (type L), working data (type W), and parameter data (type P). Each member is first created when the corresponding component is first edited. In addition, any time an EDIT is issued for a given component (including when it is first created), a copy of the member is made on the SOURCE library with an edit-indicator of E. When the RESOURCE definition is edited, a temporary member (type E) is created in IDDAT, as well as a copy of the member with an edit-indicator of E. At normal end of EDIT, the E members are deleted.
  •  
    PNL
    Defines a copy of the panel member on the panel library with an edit-indicator of E. At normal end of EDIT, the E member is deleted.
  •  
    RPT
    Defines a copy of the report member on the source library with an edit-indicator of E. At normal end of EDIT, the E member is deleted.
 
Note:
 If E members are left on the source or IDDAT libraries due to edit sessions being abnormally terminated, VLSUTIL DELETE may be used to remove old E members.
DUPLICATE
 
DVW
 
For an unmodeled dataview, a copy of the IDDVW member is made with the NEWNAME or NEXT version. The DUP command internally invokes the EDIT command for the new dataview.
 
MEM
 
Defines a copy of the data member with the new name. For a different user, the user ID is changed to the new user ID. In addition, the DUP command internally invokes an EDIT command for the new member.
 
PGM
 
Defines a copy of any of the three possible program members that exist (work, parameter, procedure) with the new name. For the NEXT option, the version number is changed to one higher than the highest next version number. For the NEWNAME option, the program name is changed to the new name, and the version is changed to 001. In addition, the DUP command internally invokes an EDIT command for the new program.
 
PNL
 
Defines a copy of the panel member with the new name. For the NEXT option, the version number is changed to one higher than the highest version number. For the NEWNAME option, the panel name is changed to the new name, and the version is changed to 001. In addition, the DUP command internally invokes an EDIT command for the new panel.
 
RPT
 
Defines a copy of the report member with the new name: For the NEXT option, the version number is changed to one higher than the highest version number. For the NEWNAME option, the report name is changed to the new report name, and the version is changed to 001. In addition, the DUP command internally invokes an EDIT command for the new report.
MARK STATUS
 
PGM
 
The only VLS members affected by the MARK STATUS command are program object members. For the program executable object (type T) and symbol table (type J), the members are renamed so that the version number is changed to PRD. In addition, if there is a previous PRD version of the same program, the associated members are renamed so that the PRD is changed back to the original numeric version number.
 This description of the MARK STATUS process is only valid within the CA Ideal environment. The VLS members are not affected by STATUS changes made only in the Datadictionary environment to the dictionary ENTITY.
This lets the run-time executor locate the appropriate members in a system that was the target of the Transport Utility, when no Datadictionary entity-occurrence exists. This is necessary to support the command RUN 
xxxxxxxx
 VER PROD, since otherwise 
CA Ideal™ for CA Datacom®
 has no means of determining which of the multiple possible versions of the object members were the production versions.
 
Example
 
Suppose that in SYS ACC, PGM UPDATE VER 005 is currently in PROD status. VER 006 and 007 are in TEST and VER 006 is to become the new PROD version. Before the MARK STATUS command, the following members exist in the object library. If you run a VLSUTIL LIBRARY listing, the member names are shown in strict collating sequence order instead of the order shown:
ACCUPDATE PRDJA ACCUPDATE PRDTA ACCUPDATE PRDTB ACCUPDATE 005VA ACCUPDATE 006JA ACCUPDATE 006TA ACCUPDATE 006TB ACCUPDATE 006VA ACCUPDATE 007JA ACCUPDATE 007TA ACCUPDATE 007TB ACCUPDATE 007VA
This program contains working data but no parameter data. We can determine this because there is a type V member (working data object) but no type Q member (parameter object). Also, the original MARK command for VER 005 changed only the names of the type J (symbol table) and T (executable object) members to reflect PRD instead of 005: The type V member was never changed. A type Q member would not change either.
In this example, only two members are shown for each executable object module: A and B. There can be more members (C, D, E, and so forth), but two is the minimum.
The following is now executed:
MARK STATUS PGM UPDATE VER 6 TO PROD
 
CA Ideal™ for CA Datacom®
 determines that there is an existing previous PROD version of the program by accessing the Datadictionary. After the above command is executed, the following members exist on the object library (if you run a VLSUTIL LIBRARY listing, the member names are shown in strict collating sequence order, instead of the order shown here):
ACCUPDATE PRDJA ACCUPDATE PRDTA ACCUPDATE PRDTB ACCUPDATE 006VA ACCUPDATE 007JA ACCUPDATE 007TA ACCUPDATE 007TB ACCUPDATE 007VA
All members for the old PROD version 005 were deleted (since 
CA Ideal™ for CA Datacom®
 could determine from the Datadictionary that version 5 was the previous PROD version). The former 006 members were renamed to PRD since the command directed 
CA Ideal™ for CA Datacom®
 to mark version 6 to PROD status. Also, neither of the type V members (working data object) was affected by the MARK STATUS command. These members are used only at compilation time.
For all other entities, MARK STATUS only affects the Datadictionary definition. The corresponding VLS members are not updated.
DELETE
 
DVW-
The IDDVW members, both K and D types, are deleted.
  •  
    MEM-
    The data member is deleted.
  •  
    PGM-
    All program source and object members are deleted.
  •  
    PNL-
    The panel source and object members are deleted.
  •  
    RPT-
    The report source member is deleted.
The DELETE command deletes all appropriate VLS members, even if the Datadictionary entity-occurrence, or one or more of the VLS members themselves, are missing.
CATALOG
 
DVW 
Creates or replaces the dataview object member (type D) in the IDDVW library.
Processing the Field Attribute and Symbol Tables
The maximum number of symbols-such as names and identifiers-in a 
CA Ideal™ for CA Datacom®
 application depends greatly on the amount of storage 
CA Ideal™ for CA Datacom®
 has available for the Field Attribute Table and the Symbol Table.
The Field Attribute Table, referred to here as the FAT, contains an entry for each dataview, dataview field, panel, panel field, working data field, literal, and FOR construct. Each entry is 20 bytes long and contains information such as the length, type, displacement, and the offset into the Symbol Table.
The Symbol Table contains an entry for each dataview name, dataview field name, panel name, panel field name, working data field name, report name, procedure name, and label name. The length of these entries varies according to the length of the symbol. Each entry contains information, such as the length of the symbol and the address of the symbol in the FAT, and the literal that identifies the symbol.
During compilation, 
CA Ideal™ for CA Datacom®
 creates a variety of blocks. None of these blocks can exceed 32KB. The FAT and Symbol Tables can span multiple blocks. A single data entity occurrence, which means a 01 level data item, dataview, or panel, cannot exceed the 32KB limit. This means that no 01 level can have more than 1,600 fields or it exceeds the FAT table limit. A 01 level can have between 800 and 1,600 fields (depending on the size of the symbols) or it exceeds the Symbol Table limit.
The following graphic shows the compilation process in 
CA Ideal™ for CA Datacom®
 application:
Compilation Process in CA Ideal for CA Datacom Application
Compilation Process in CA Ideal for CA Datacom Application
Application Load Modules (Phases)
You can convert 
CA Ideal™ for CA Datacom®
 application programs and panels in Production status from VLS members to z/OS load modules or to VSE phases. If a program is converted to load module format, load modules are created for the executable object and the symbol table.
 For the sake of convenience, load module to both load modules and phases.
For each program, separate load modules are created for the reentrant and non-reentrant data, respectively, and for the symbol table. If a panel is converted to load module format, a single load module is created. The panel load module contains the panel member from the panel library, comprising both reentrant and non-reentrant data.
Even when VLS members are converted to load modules, the original object members are retained and can be used again. MODULE entity occurrences in the Datadictionary record which programs or panels were converted to load modules and which were deleted as load modules. If an entity accessed from 
CA Ideal™ for CA Datacom®
 is not recorded as a load module, 
CA Ideal™ for CA Datacom®
 retrieves it from the VLS library.
Execution of 
CA Ideal™ for CA Datacom®
 Applications in a CICS Environment
At run time for a single program, there are always at least three independent VLS object members (or load modules): one reentrant, one non-reentrant, and one for the symbol table. There can be more, depending on the size of the program.
The executable object is loaded from the VLS object library or load library and executed. The reentrant portion (the program procedure and report) can be shared among users. The non-reentrant portion (program parameter data, working data, and dataview buffers) is not shared, and each user gets a copy.
When a panel is accessed, the panel definition (as opposed to the panel object) is retrieved from the panel library or load library.
The panel member and module is also grouped into reentrant and non-reentrant parts. The reentrant part (the panel definition) can be loaded into global storage and shared among users. The non-reentrant part (the panel data) is not shared and each user gets a copy.
The distinction between reentrant and non-reentrant is significant because the execution of 
CA Ideal™ for CA Datacom®
 applications online takes place in pseudo-conversational mode. At the end of each CICS transaction, some or all of the in-core resources are written to CICS auxiliary temporary storage and CICS ESDSA.
If programs and panels were converted to load modules, they are controlled by CICS, and the 
CA Ideal™ for CA Datacom®
 run status has no effect.
The program symbol table is loaded only when a run-time error occurs.
In a DB2 environment, execution of programs containing SQL in static mode requires an application plan.
In 
CA Datacom®/DB
, SQL access plans are built at compile time.