Writer instructions | ||
Purpose | Use this page to display a banner announcement on each page of the space. Create the Space announcements page in the master space, outside of the Home branch. You can version the Space announcements page to enable different banners to be published into different target spaces, however, the banner that is displayed in the versioned (master) space itself only displays the most recently-published banner. If you find errors in the banner area of your versioned space and you are sure the Space announcements page is set up correctly, try publishing the page to the same space. For more information, see Space-announcements-banners. | |
Removing | When an announcement is no longer needed, remove the BMC Space Banner macro. | |
Translation | Localized spaces using the L10n Viewport theme must change the name of this page to Space announcements l10n. See Configuring-the-Scroll-ViewPort-theme-for-translated-spaces. | |
Usage | Choose one or none of the following BMC Space Banner macros. If your space requires another kind of announcement, you can use this page in coordination with your team lead and editors. |
Reorganizing databases by editing the extract file
By changing the contents of the extract file and using the modified file in the Load function, database contents and structures can be changed. Some of the changes that can be accomplished using this method are changes to segment data, segment length, segment key, adding or deleting segment occurrences, segment key length, segment format, adding or deleting segment types, and minor database restructuring. Some of these changes also require a DBD change for the new database prior to using the Load function.
When the reorganization affects the entire contents of related databases, separate extracts and loads must be done for each of the related databases. This action ensures that entire related databases are reorganized and not just those database records that participate in logical or application relationships.
Changing Segment Data
Segment data can be changed by editing the SEGMENT-DATA field of the extract file record. If the key value changes, it must also be updated in either the DATA-BASE-RECORD-ROOT-KEY PREFIX field if it is a root segment or the CONCATENATED-KEY-REMAINDER PREFIX field if it is not a root segment.
To easily reformat segment data when the segment layout changes (for example, when fields are added, deleted, or the length or data type of a field changes), BMC’s File-AID/MVS file management product can be used. Following are the steps to reformat a segment type with File-AID/MVS:
- Browse the extract file with File-AID/MVS Option 1. Notice the Prefix Length specified on the header record.
- Create a record/layout XREF for the extract file with File-AID/MVS using Option 7:
- Enter the member name of the new XREF and the name of the file containing the record layouts.
- Press <Enter>.
- Enter a Generated Filler Length equal to the Prefix Length from Step 1.
- Enter the record layout name for each segment to be reformatted.
- Enter a description of each layout (optional).
- Select Unformatted (one for each record layout).
- Enter *18 for the position.
- Enter 8 for the length.
- Enter the name of the IMS segment.
- Repeat for additional segments.
- Create another record/layout XREF for the new extract file layout (that is, with the reformatted segment data fields) with File-AID/MVS Option 7.
- Use File-AID/MVS Option 9 to reformat the extract file.
- On the FROM Layout Specification screen, enter the XREF created in Step 2, with a record type 1 value of the segment name to be reformatted.
- On the TO Layout Specification screen, enter the XREF created in Step 3, with a record type 1 value of the segment name to be reformatted.
- Enter the reformatting instructions.
- On the Dataset Specification screen, enter the extract file as the FROM dataset and the new reformatted extract file as the TO dataset.
- After the reformat is complete, load the new extract file into your database with File-AID for IMS/ISPF Option 4.2, Load.
Changing Segment Length
The segment length can be changed by increasing or decreasing the length of the records on the extract file. The segment length is computed by taking the record length and subtracting the prefix length. For variable length segments, the length of the record on the extract file is always used to determine the segment length, not the two-byte Length field that resides in the segment data. If this computed length is not valid for the segment type, the segment is padded or truncated during the load process to a valid segment length. For variable length segments, this adjustment is the minimum segment length if the segment was too short or the maximum segment length if the segment was too long.
Because the extract file has variable length records, the record length cannot be directly modified using the ISPF/PDF editor. However, BMC’s File-AID/MVS file management product enables you to directly change the record length when editing in unformatted mode. For variable length segments, it is not necessary to change the two-byte Length field in the segment data. When the segment is loaded, the two-byte Length field is computed and filled in.
Adding or Deleting Segment Occurrences Without Changing the DBD
The number of segments to be loaded can be changed by directly editing the extract file with the ISPF/PDF editor or BMC’s File-AID/MVS file management product. Under most circumstances, there are no other considerations other than to use the correct prefix on added records.
By adding or deleting records for a particular segment type on the extract file, segment types can be added to or removed from the database. This process is easiest when the added/deleted segment type does not have any subordinate segment types in the hierarchy. Following are some considerations for adding/deleting segment types:
The CONCATENATED-KEY-REMAINDER-PREFIX field for segment types below the added/deleted segment type may need to be modified to include/remove the key of the segment that is being added or deleted.
- If the added/deleted segment type has a nonunique concatenated key and is below a logical child segment type in the hierarchy, the POSITIONING-COUNT-PREFIX field may need to be set (for added segment types) or adjusted (for segments below a deleted segment type).
When adding or deleting segment types in the extract file, the existing header record is used to calculate the length of the CONCATENATED-KEY-REMAINDER field. Deletion of the header record is not recommended. However, if a header does not exist on the file, the information is calculated from the DBDs used during the load process.
Changing the DBD
To allow for minor changes to the database structure, the DBDs used during the Extract function can be different than the ones used during the Load function. If they are different, the contents of the extract file may need to be adjusted prior to the load. Following are some of the areas that can affect the contents of the extract file:
Added or deleted segment types.
See Adding or Deleting Segment Occurrences Without Changing the DBD for considerations that apply when adding or deleting segment type occurrences to the extract file. In addition, it may be necessary to make changes when the DBDs used in the Extract and Load functions are different. The following considerations apply when the DBDs used during extract and load are different:
- Any record remaining in the extract file that contains a deleted segment type is not loaded, and a message is written to the Data Base Load Exception Report.
- If the added segment type increases the length of the longest concatenated key for all segments in the databases (including logically related databases), then the following fields in the extract file must be changed:
- The length of the CONCATENATED-KEY-REMAINDER PREFIX field must be increased in all records in the extract file.
The EXTRACT-FILE-PREFIX-LENGTH field value in the header record must be increased to reflect the change in the length of the CONCATENATED-KEY-REMAINDER field.
Added or deleted logical relationships.
When a logical relationship is deleted, references to database records in the deleted logical relationship should be removed from the extract file. The use of the DATA-BASE-NUMBER and the DATA-BASE-DBD-NAME fields in the prefix can be helpful when determining which records to delete from the extract file. Any of these logically related extract records that remain on the file are not loaded, and a message is written to the Data Base Load Exception Report.
When a logical relationship is added, the HEADER RECORD and PREFIX LAYOUT fields can be affected. If the added logical relationship includes a database that affects either the longest concatenated key or the longest root key for all the databases, then the following fields must be changed:
- The length of the CONCATENATED-KEY-REMAINDER PREFIX field must be increased in all the records in the extract file if the longest concatenated key has changed.
- The EXTRACT-FILE-PREFIX-LENGTH field value in the header record must be increased to reflect the change in the length of the CONCATENATED-KEY-REMAINDER field.
- The length of the DATA-BASE-RECORD-ROOT-KEY PREFIX field must be increased in all records if the longest root key has changed.
- The EXTRACT-FILE-MAX-ROOT-KEY-LGTH field value in the header record must be increased to reflect the change in the length of the DATA-BASE-RECORD-ROOT-KEY field.
Key length changes.
The same considerations apply for differences in the key length as apply to adding/deleting a segment type with the longest key for all the databases. See to Step 1.
Converting Data Base Access Methods.
Changing the database access method (for example, from HDAM to HIDAM) does not require a change to the extract file.
Loading with a different DBD name.
Each record in the unload file contains the name of the DBD to use for that record. If the DBD used to load has a different name than the DBD used to unload, the DBD name in each record must be changed to match the DBD used at load time.
You can use the File-AID for IMS Override facility (see Load - DBD Name Override ) to accomplish loading with a different DBD name.
Comparing Data Bases
Files produced by the Extract function can be used to compare the contents of two versions of the same database. Use the following steps:
- Extract from the first database, specify N for the Select Related Data Base Records field in sub-option 3, Specify Data Base Relationship Criteria, of Option 6.
- Repeat Step 1 for the second database by specifying a different extract TO dataset.
- If the databases use the HDAM access method, sort both files in the Processing Option L sort sequence (see Sorting the Load From File ).
- Use a file compare utility (for example, PANVALET/COMPARE, File-AID/MVS COMPARE, or COMPAREX) to compare the two extract files. Check for differences starting at the first record position after the extract file prefix. The output report from the compare utility indicates the differences between the two databases.