05 es2l lookup file inquiry maintenance
ES2L - Lookup File Inquiry and Maintenance
| Program ID: | ES2LP01 |
|---|---|
| Mapset: | ES2LMS1 |
| Files: | Lookup File (ES2LKUP) |
This is the on-line inquiry/update of the Lookup File. The screens in this program allow inquiries and updates to the Lookup File entries – NAICS codes, FIPS county codes, zones/townships (i.e., county/zone or county/township combinations), ownership codes, place codes, comment codes, ownership codes, MSA codes and their respective counties, and a host of State-specific parameters.
Processing is governed by a menu screen (shown above), similar to that used in the ES2B transaction. This screen lists the types of records that can be selected for inquiry or update within the Lookup File. Any of these categories may be selected by placing the cursor on the first hyphen character that precedes the name of the record type, then pressing the Enter key. This will replace the Lookup File menu screen with another menu, showing the records within the specified record type.
Whenever one of these secondary screens is displayed, the program will determine the user’s level of access to the ES2L transaction (inquiry or update mode). This mode is established by the Internal Security File, which first denotes whether the individual can enter the ES2L transaction at all (since its use is restricted), and then whether update authorization has been granted. For many record types, any of the displayed values can be modified simultaneously, for those with update access. Most of these changes will be rare, however, since county names, NAICS descriptions, and even editing constants seldom change. Since all displayed descriptions are updateable, up to 15 records can be modified in one operation.
Generally, each line on the ES2L sub-screens depicts a single record in the Lookup File. The record key contains a unique, two-byte record type code, followed by either the specific code in question (county, NAICS, etc.), or a two-code combination (MSA + county, or county + zone). One screen type, however, needs to disassemble a single record into multiple parts, using integer line numbers to specify elements of a complex record. This record split occurs for the State-specific processing constants record, which will be described in depth later in this document. The display for each type of record initially shows the beginning values of the sequence, and continuing in an alpha-numeric sort order. A specific key can be entered in the “NEXT-INQ:” field. This avoids repetitive entry of the F7 and F8 keys for scrolling, where hundreds of records are involved (such as NAICS codes and sub-county zones or townships). The entry of an item number restarts the browse at the specified key, listing the desired record (or the first valid key thereafter, if it is not found) at the top of the list. A partial key (such as the first two digits of a NAICS code) can also be specified, to begin the search at the first valid key after that point.
When a new value must be added to a table (such as a county split or a new MSA definition), the process is begun by pressing the F5 key. This clears the displayed entries, allowing new values in both the code and description areas to be entered. Errors such as duplicate record keys will be flagged with an error message until they are corrected. Once all entries are in, normal update mode is re-established, either by pressing the Enter key or by using the F7 (scroll backward) or F8 (scroll forward) key. Ownership code addition and deletion is limited in scope, as well. Non-standard private ownership codes can be added (values of 51 through 59), but these are only used internally, and may not be allowed at all once a standard QUEST system is in place. Other extensions, such as the obsolete ownership codes of ‘40’, ‘60’ and ‘70’, cannot be added. The sample screen above shows a county codes display. Update to counties (as shown above) is very rare indeed, but could be accomplished with the F5 key.
The county code screen, which is shown on the previous page, may display an extra, unlabeled field, with four-character entries beginning with “Q”, followed by a 3-digit number. These are QMSA entries. QMSA’s (or Quasi-Metropolitan Statistical Areas) are State-defined collections of counties that are used to subdivide the State into geographical areas. Although the QMSA’s are defined within the MSA Lookup File definitions (another table from the menu), the coding needs to be transferred to the county entries to fully utilize QMSA’s in system processing (to partition edits, regionalize macro aggregates, etc.). The QMSA assignment was first developed for Texas, but they have migrated away from this concept. These assignments are handled through a utility EXPO batch job; they do not need to be manually entered on the county screen.
Record deletions can be handled directly from the normal update mode. Any obsolete records, such as a county/zone or comment code that is no longer valid, can be removed by typing “*D” at the beginning of its description. This notation can be used on as many records as are no longer needed, deleting up to 15 records at a time. However, there is no “Undo” function. If an analyst decides to mark several records for deletion and then recognizes that this deletion was a mistake, the deleted records must be re-added with the F5 key “add” function.
The use of the F3 key within any of these subordinate screens will still cause a general system exit (to the ES2KP01 program, or a State-supplied substitute), just as in the high-level transactions. However, the F1 key has a slightly different definition in that it returns control to the Lookup File maintenance menu, rather than to the EXPO system menu in ES2B. Once at the main ES2L menu, however, the next F1 entry will indeed return to the main menu in ES2B.
The edit and estimation parameters table (shown below) provides essential information relating to all aspects of micro-level data editing. Most of these tolerances are used with the BLS-defined micro and macro edits in the micro and integrated editing jobs. Others are processed in performing multi-family balance checking in Jobs 003D and 003S. Some are required to edit the Wage Summary File against Micro File data in the 061D job. Two are used to limit the volatility of estimated fields in the micro estimation jobs. Most editing parameters can be loosened or tightened in whatever manner seems best to the individual State. However, BLS has limited the slackness of many of these tolerances to a slight extent. The limits are enforced by this program so that overly loose values (such as an employment change of 1000) are disallowed. Once these values have been set by the State, they will rarely change, other than such items as the maximum and minimum tax rate for experience-rated employers, which change annually. For a complete description of each of these tolerances, and more information on how they are used, please refer to the beginning of Appendix E (MicMac Edits processing documentation).
Unlike the standard table entries, such as NAICS and MSA codes, record keys for edit and estimation parameters are fixed. In other words, the value of the tolerances may themselves be altered, and even the description can be changed; but no records can be added or deleted in this group, as they are hard-coded into the ES2L processing logic. The notations for the F5 key and the ‘*D’ description are listed for continuity between screens, but they are nonfunctional for the editing/estimation parameters screen.
The composite record briefly mentioned earlier is the State constants collection. This screen (shown above) uses a record key of “STATE”. The first elements identify the State itself, including the State name, its two-character postal abbreviation, and the FIPS State code. The sample screen (below) shows information for the State of Utah, with a FIPS code of 49, and a postal code of “UT”. Note that these fields are in turquoise color, signaling that they are unchangeable. These are used frequently in batch processing, such as the verification that physical addresses are found in-state and to specify a State FIPS code in producing a deliverable file.
The CES left-shift digit count (item #04) is now obsolete, as it applies to an account number shifting process in the Automated Current Employment Statistics (ACES); that process no longer occurs, since the ACES process is embedded in the National Office. The U-I digit suppression count (item #05) is a zero-suppression feature used in batch reports. It enables accounts to be more readable for a State that uses fewer significant digits in the account number. When only six digits are used, for instance, the zero suppression of a U-I account number of ‘0000021521’ to ‘021521’ provides a more familiar rendition of the number.
Township or zone processing is dealt with in the zone/town usage switch and verification switch (items 06 and 07, respectively). Township usage will force the fourth digit of the quarterly zone field to a space in most system processing. The verification switch causes batch jobs to edit or ignore editing of the sub-county zone or township code against the County/Zone (or “CZ”) records in the Lookup File. On-line applications, however, most often base processing on the presence or absence of any “CZ” records on the Lookup File, rather than checking the verification switch.
The CES/202 processing switch (item #08) affects both batch and on-line applications, but is primarily SIC in basis. If CES-type processing is selected with a “C” in the switch, SIC agricultural services (SIC codes of 0740 to 0759 and 0780 to 0789) are classified in the services sector rather than in agriculture. In addition, SIC 8811 (private households) or NAICS code 814110 (same meaning) is eliminated from CES-based processing totals. Statewide totals will also eliminate agriculture (except for the SIC-based agricultural services, and NAICS-based logging (113310)) from the non-agricultural grand totals. Under the QCEW mode (a “Q” in the switch), all industries appear normally in their proper classification.
Items 09, 10, and 11 deal with the quarterly State usage field. The first two are 6-byte headers for two-line header identifiers. The third is the default value to apply to new accounts (especially in the ES2MI01 IMT processing program), when no value is declared for incoming records. Usually this is set to zeroes (for States using numeric data in the field) or spaces. There have been cases, however, where an oddity has occurred in the default value, such as “123__” (where the underscores represent the position of spaces); if the IMT finds such an oddity, the program will change it to spaces, so that the default will not be repeated throughout the quarter state use field.
Items 12 and 13 are the minimum and maximum (respectively) 5-digit zip code values for the State. These are used both by the ES2C and ES2E screens, and in batch program ES2MI28 (micro edits) to check for out-of-state physical address locations. A physical location address must have a zip code that agrees with these limits, unless the county code is ‘996’ or ‘998’ (the two standard out-of-state county codes).
Item 14 signals whether this State is a participant in the “CARS” (Centralized Annual Refiling Survey) process. Most States (except for North Dakota) now participate in the CARS system, receiving centrally-collected refiling data for all refiled singles (multi-family refiling is still handled strictly internally). Item 15 represents an additional switch that deals with EARS processing. It is used to allow or disallow the immediate update of the Micro File codes when they are entered through EARS screens. This switch is updateable on this screen, but it means that code changes are automatically transferred to the Micro File when first calendar quarter is visible. This is the same process that is handled by batch job 013D.
To progress to the second screen, press the F8 key:
On the second page (shown above), item 16 is similar to Item 14; it is a switch that signifies whether this State participates in the MWR Web process, so that some multi-families can opt to send in their MWR data via the Internet. However, ALL states participate in this system, so the switch is essentially a foregone conclusion. This information is centrally collected by BLS, then distributed to the State.
Item 17 is the maximum number of input/output operations (file reads and writes) that can be conducted in any of the CICS applications during a single “down-and-back” cycle (i.e., between user entries). Originally designed for the ES2F screen (due to its potentially massive I/O to the two Crosswalk Files and the Micro File), this tolerance has been adopted by other transactions, such as the ES2D macro and micro display. This is a five-digit numeric field, at DMA there has been no potential weakness found, but the value has varied widely from 2500 to 20,000. It should be set to represent a reasonable I/O count limit for a single CICS screen-filling cycle. The initial default value of 5000 at the time of installation, but it could range according to the various settings, but a higher value (nearer to 20,000 would be allowed).
Items 18, 19, 20, and 21 relate to the edit report selection and sorting criteria. Item 18 lists the edit and estimation report sort parameters ('A, C, E, F, G, N, O, P, R, T, V, and Z). Item 19 denotes the treatment of multi-families (with options for separating EDI’s and PEO’s into their own categories) in the sort process (B, E, M, N, P; if special action is taken, multi’s are exempted from the parameters in Item 18). Items 20 and 21 show the numeric, small-record print bypass limits for employment and wages, respectively. All of these fields originated in the Job 001Q input parameters, specified in the ES2N screen. The sort parameters are stored in the State Lookup record to keep them safe from accidental (or intentional) tampering during the quarter, which would cause great confusion in processing. The values can be modified here, however, to resequence the Micro Edit File during the next micro edit or integrated edit job run. Only persons with administrator-level access can alter these four items in mid-quarter; all other users will see the fields colored turquoise, meaning that they are non-updateable.
When Job 001Q is initially processed, the sort parameters are copied to the State record. A change to these parameters later on will show up on the ES2L screen, but will not be enacted immediately into the micro edit data. The re-sorting will not take effect until the next run of a standard set of micro edits (Jobs 001D, 002D, 028D or 242D). To alter the sort sequence of the Micro Edit File, the record key is cleared out and rebuilt for each establishment with edit exceptions, by the micro edit program (ES2MI28). The sort parameters are also copied to the header record of the Micro Edit File, stored in the editing year/quarter field. Once Job 001Q is run, any changes to the ES2L sort parameters will be rescinded by the values found in the ES2N screens for the job.
Note: Items 22 and up are not shown on the EARL screen, since this screen has not been updated since 2006.
There are both benefits and disadvantages associated with edit parameter adjustments. On the plus side, the focus of editing can be shifted in mid-stream, such as from industry or county-based sorts to error code, FESTER score, or size of employer. This can help to streamline the finalization of edit clean-up. On the negative side, there are no descriptions on the ES2L screen as to which parameter letters are available or what they mean. It also adds overhead to the edit processing time because of the rebuilding of the sort indexes for all Micro Edit records. Analysts may become confused as to where they are in edit review when the sequence changes before they have completed their portion of the edit. Should the sort parameters change more than once during the quarter, it may be difficult to ascertain which set of parameters is currently in effect when viewing the ES2E screen.
Like Item 18, the other edit-selection-and-reporting parameters (items 19, 20, and 21), can be modified by an administrator-authorized person. Item 19 can be toggled to include or exclude the multi’s under the standard sort parameters. For instance, the families may have been split out into SESA ID sequence when the singles were sorted by NAICS code and county, but may need to be merged in with the singles under an edit scoring sort. Items 20 and 21 specify special editing cutoff parameters for the Average Monthly Employment (AME) and total wages. Changes to these parameters can loosen or tighten the rules on which accounts should appear on the edit report, and which are too small to be trifled with. This pair of parameters was established for California due to their huge employer count; they are designed to reduce editing workload by ignoring the smallest establishments from all edit reports.
Items 22 and 23 are non-changeable values (turquoise in color) used to show the range of quarters present in the Micro Archive File, which can grow to contain over 30 years of additional, historical micro data. In the sample, the data range from 1998 to 2015. The archival of micro data occurs during the quarter shift process of Job 001Q. The data on this file are available in Job 020D to prepare Micro Selection reports for older historical micro data that can be found on the Micro File.
Item 24 is a switch that allows a full address to be copied into the physical location address block of an account simply by typing a “1” into the address type of the address appearing on the right-hand side of the ES2C first or second screen (which will be either the mailing/other address (MOA) or the U-I address (UIA). When this switch is blank or “N” (set on only 8 of 37 states), no address copying is performed. A “Y” enables the changes. Even if a different address exists in the PLA, the “1” address type entry will supersede it with the other displayed address. The one exception to this rule is found when the physical address lock switch (found on the second ES2C screen) is set to a “Y”. This lock supersedes any attempted update by the ES2L PLA-copy switch.
Item 25 is a switch that is used in the setting of quarterly status codes. If it is set to a “Y”, it will not set the account as active for a quarter that has the end-of-liability date set to the first day of the quarter (e.g., an EOL date of 7/1/2017 will not activate the account for quarter 17/3). Similarly, if the liability date (or reactivation date) is the last day of the quarter, the “Y” value on this switch will not make it active for that quarter (e.g., an initial liability date of 9/30/2017 will not activate quarter 17/3 for the entirety, since it is only active for one date). If this switch is set to an “N” or blank, it will make the account active for the entire quarter (e.g. an EOL date of 7/1/2017 will make the account active for all of 17/3, as will a liability date of 9/30/2017).
Item 26 is a switch whereby the on-line edit (ES2E) could be streamlined. If the switch is set to “Y”, it will set the ES2E to bypass any accounts with prior-quarter and admin counts both zero, a comment code present in the current quarter, and the most severe error is non-crucial (i.e., it is numbered above 090). Of course, if the switch is an “N”, it will not bypass the account from the edits, if it has only current-quarter edit exceptions, and a numeric comment code present in the current quarter.
Item 27 is a switch that is in turquoise and will probably stay that way. It allows the “Wave-2” refiling accounts to be included in the EARC, etc., displays. Of course, the “waves” were set up in the 2015 refiling as part of the quarterly processing of the refiling. However, the concept never took off, so it was put on the back burner, and that burner was shut off. The concept of waves is obsolete and will not return to the forefront.
Item 28 is updateable, but shouldn’t’ be changed from the “N” setting until after the tests are done. If this is set to “Y”, it will allow the new scoring algorithm to be enacted. This method uses a zero-to-100 scale for four different measures (employment, total wages, AQW, and error code), giving the largest score to the data in question. This was developed over a year and is better than the current score methodology, which has a -7 to +63 range; however, both the batch and on-line (CICS) versions of the new scoring algorithm have significant issues that are awaiting the line-by-line debugging facility to work from.
Modified records are rewritten to the Lookup File. This is generally a low-volume transaction, though some initial adjustment to editing parameters and other information may be required when a major Version release is first installed in the State. Since the values of certain Lookup File data settings are vital to proper system processing, the data integrity should be safeguarded by limiting access to this program through the ES2M transaction, which is described next.
The File Definitions screen (shown below) displays the FD (File Definition) record type data. These records are updated whenever a VSAM file is rebuilt by a batch job within EXPO or EARS (with a Delete/Define/Repro IDCAMS operation). Information on this screen is for display-use only, so you cannot alter file sizes or change back-up dates. The information is helpful for detecting potential problem situations.
The example shows Virginia’s data, which has over 4 million Macro records, but they take up less space than the Micro File, with barely over 300,000 records. The transaction files (Admin, MOA, and quarterly) have a cutoff date of February 10 of last year (as prescribed by the 001Q job). Looking over the other files, the most records would be found in the Predecessor/Successor Potential File with over 812,000 records, yet because of the small record size, it takes up only 51 cylinders. It is interesting that the publication file has over 1600 records, but takes up less than a cylinder all together. There are over 1400 cylinders that are taken up by Virginia files (compared to over 7000 cylinders for California, but only about 16 taken up by the Virgin Islands). You can use this total to assess your own file sizes.
When a file has not been rebuilt for months, it can become overly fragmented. If you look at the sample data, you will notice that the Refiling data had been last built on September. However, this represents a set of annual files, so it doesn’t need to be rebuilt. Since all of the other files have been rebuilt within the past quarter, they should be good to go for another few weeks.
However, when you see an old back-up date, you should run the appropriate back-up and restore jobs for that file to ensure data integrity. Notice that the ending-date is not properly set on the three micro transaction files (as all claim last November as their latest date, which was the date when the last 001Q job was run), and neither the beginning date nor the ending date of the refiling transaction file (the bottom one on the list) has a valid date. Therefore, the beginning and ending date are set to the last date of 2099. This is partially because there is no longer any transaction that needs to be written to this file, since the refiling process is so automated.
Related Links
