Mainframe Report File Elements

All Mainframe Cost Report files that are submitted to the RDS Center must include the five elements mentioned below, in the same order as they are listed:

File Header (FHDR)

The following data elements are to be included in the File Header:

Record Type The first four bytes must be the Record Type, and it should always be ‘FHDR’.
Submitter Type The fifth byte is the Submitter Type. The values are ‘P’ for Plan Sponsor and ‘V’ for Vendor. For example, in the sample file, the Submitter Type is ‘V’.

Plan Sponsor ID or Vendor ID

(Submitter ID)

The next ten bytes is the submitter id. If the Submitter Type was ‘P’, the submitted id is the Plan Sponsor ID. If the Submitter Type was ‘V’, the submitter id is the Vendor ID. This field is alphanumeric, left justified, and followed by trailing spaces if the ID is less than ten bytes. For example, in the sample file, the ID is 'A1234'. This is shown in the file as 'A1234' (with five trailing spaces).
File Creation Date The File Creation Date follows the submitter id. This field is eight bytes in a CCYYMMDD format. For example, in the sample file the File Creation Date is May 16, 2006 displayed as 20060516.
File Creation Time The File Creation Time follows the File Creation Date. This field is also eight bytes in a HH:MM:SS format. For example, in the sample file, the time is 30 seconds past 12:05 PM displayed as 12:05:30.

 

Note: Multiple Application/UBOI Detail records are allowed between Application Header and Trailer elements. Multiple Application Header and Trailer sets are allowed within the File Header/Trailer elements. The remaining 79 bytes are filler.

Application Header (AHDR)

Record Type The first four bytes are the Record Type, and it should always be ‘AHDR’.
Application ID The next ten bytes are the Application ID. This field is alphanumeric, right justified, and preceded by leading zeroes if the id is less than ten bytes. For example, in the sample file, the Application ID is ‘5678’, displayed as ‘0000005678‘ (with six leading zeroes).
Note: It is imperative the Application ID is a valid Application ID found in the RDS database to prevent the entire file from rejecting. To ensure you have the correct Application ID, compare it to the Application ID located in the RDS Secure Web Site on the Application List page.

Note: The remaining 96 bytes are filler.

Application/UBOI Detail (DETL)

Record Type The first four bytes are the Record Type, and it should always be ‘DETL’.
Unique Benefit Option Identifier The next twenty bytes are the UBOI. This field is alphanumeric, left justified, and followed by trailing spaces if the UBOI is less than twenty bytes. For example, in the sample file, the first UBOI is ‘BENEFIT OPTION E’, displayed as ‘BENEFIT OPTION E ‘ (with four trailing spaces).
Note: It is imperative the UBOI is a valid UBOI found in the RDS database to prevent the entire file from rejecting. To ensure you have the correct UBOI, compare it to the UBOI located in the RDS Secure Web Site on the Benefit Options Summary page.
Year and Month RX Cost Incurred (YYYYMM). The Year and Month RX Cost Incurred date follows the UBOI. This field is six bytes in a CCYYMM format. (It does not include the day of the month as the date in the file header.) For example in the sample file, the first detail record is for January 2006, displayed as 200601.

Estimated Premium Costs

Gross Retiree Cost

Threshold Reduction

Limit Reduction

Estimated Cost Adjustment

Although the following fields will represent distinct values: Estimated Premium Costs, Gross Retiree Costs, Threshold Reduction, Limit Reduction, and Estimated Cost Adjustment, their field format is identical. They will all be twelve bytes, with the first byte being '+' for the sign (positive). The positive sign is required even is the value is zero. The remaining eleven bytes are a numeric value, with nine plus two decimal positions. For example, in the sample file, the first value is $0, displayed as '+00000000000'. The second value is $2,059.60, displayed as '+00000205960'.

Note: The remaining 20 bytes are filler.

Application Trailer (ATRL)

Record Type The first four bytes are the Record Type, and it should always be ‘ATRL’.
Application ID The next ten bytes are the Application ID. The Application ID is in the same format as in the application header (alphanumeric, right justified, and preceded by leading zeroes if the id is less than ten bytes), and it MUST match the one in the application.
Record count for the application The next seven bytes is the Application Record Count. This field is seven bytes and is the total number of detail lines within this Application ID. It is numeric, right justified, and preceded by leading zeroes if the value is less than seven bytes. For example, in the sample file, the count is ‘12’, displayed as ‘0000012‘ (with five leading zeroes).

Total Estimated Premium Costs per Application

Total Gross Retiree Cost per Application

Total Threshold Reduction per Application

Total Limit Reduction per Application

Total Estimated Cost Adjustment per Application

The following five fields are the same as the detail (except that they are the sum of the detail lines): Estimated Premium Costs, Gross Retiree Cost, Threshold Reduction, Limit Reduction, and Estimated Cost Adjustment. Although these fields represent distinct values, their format in the file is identical. They are all fifteen bytes, with the first byte ‘+’ for the sign (positive). The positive sign is required even if the value is zero. The remaining fourteen bytes are the numeric value, with twelve plus two decimal positions. For example, in the sample file, the first value is $0, displayed as ‘+00000000000000’. The second value is $965,989.28, displayed as ‘+00000096598928’. The values in the application trailer MUST match the sum of all of the detail records for the Application ID.

Note: The remaining 14 bytes are filler.

File Trailer (FTRL)

Record Type The first four bytes are the Record Type, and it should always be ‘FTRL’.
Submitter ID The next ten bytes is the submitter id. This field is in the same format as in the file header (alphanumeric, left justified, and followed by trailing spaces if the ID is less than ten bytes), and the id MUST match the one in the file header.
Application Count The total Application Count is the next five bytes. The Application Count field is five bytes and is the total number of applications within the entire file. This filed is numeric, right justified, and preceded by leading zeroes if the value is less than five bytes. For example, in the sample file, the count is ‘1’, displayed as ‘00001‘ (with four leading zeroes).

Grand Total Estimated Premium Costs per Application

Grand Total Gross Retiree Cost per Application

Grand Total Threshold Reduction per Application

Grand Total Limit Reduction per Application

Grand Total Estimated Cost Adjustment per Application

The following five fields are the same as the detail (except that they are the sum of the application trailer): Grand Total Estimated Premium Costs, Grand Total Gross Retiree Cost, Grand Total Threshold Reduction, Grand Total Limit Reduction, and Grand Total Estimated Cost Adjustment. Although these fields represent distinct values, their format in the file is identical. They are all sixteen bytes, with the first byte ‘+’ for the sign (positive). (The positive sign is required even if the value is zero.) The remaining fifteen bytes are the numeric value, with fourteen plus two decimal positions. For example, in the sample file, the first value is $0, displayed as ‘+000000000000000’. The second value is $965,989.28, displayed as ‘+000000096598928’. The values in the file trailer MUST match the sum of all of all the application trailer records for the entire file. The sample file only has one Application ID, so the totals for the file trailer are the same as the application trailer.

Note: The remaining 11 bytes are filler.

What does a sample mainframe cost file look like?

View a sample mainframe cost file.