• Created by Unknown User (wroot), last modified by Unknown User (aldrich) on Mar 29, 2021

Management of Post Processing Reports

The ODE reports that are being returned to ITC's "Post Processing" from EMIS-R will be handled in a similar manner as to how the ODE reports were handled under the Legacy system. EMIS V3.0 will include only form files, programs and procedures needed to enhance these ODE Post Processing reports.


EMIS V3.0 includes a revised PROCESS_CSV.COM. For any Student based ODE Post Processing reports, the student name and local id will be obtained via an SQL table on the EMIS-R server. At this time, only the student based reports will be enhanced. Any Staff based reports will already include the Staff name and State Staff ID, but no local Staff id, when they are received from ODE. There will be no form files provided for the Staff based reports.


Reports being distributed by ODE for FY11 EMIS reporting through the Legacy system will not be affected by the EMIS V3.0 procedure. Therefore, if both EMIS-R Post Processing reports and Legacy based FY11 reports are unzipped and placed into the OECN$ODE_HQ directory at the same time, it will not cause any problems with the processing of either set of reports using the command procedure. The PROCESS_CSV procedure will use the fiscal year in the report name to determine which version of EMIS the report should be processed under. When the report title contains 2011, the OECN$EMIS logical will be set to OECN$EMIS_11 causing the reports to be processed using the Legacy process and data files.

No SSID/LEA IRN Match

The new process of enhancing the Student reports to include the Student name and local id does so based on a match of the combination of SSID and Reporting District IRN.  In the case where a student is reported by more than one district, that student's SSID should be in the EMSRSTURVRS.IDX file for each district that needs to report the student.  For example, a student resides in District A and  is open enrolled into District B.  Both District A and District B will be reporting the SSID of the student.  This means that there should be two records in the EMSRSTURVRS.IDX file for the student, one for District A and one for District B.  If District A fails to report the student, when post processing reports come back, District A will receive the "No SSID/LEA IRN match" on their report for the SSID.  The enhancement process will not use the EMSRSTURVRS.IDX record tied to District B to enhance District A's report.

What to check

First thing to know is that the EMSRSTURVRS.IDX file is generated from an EMIS-R SQL table.  The SQL table used is updated each time a district does a Prepare in the Data Collector.

  • Excluded
    Is the students data being excluded?  Check the Excluded records report in the data collector to determine if it is possible the student is not being included due to an issue with the data.

  • Verify Student Data in Data Collector
    In the Data Collector, using the "Review" or "Preview" link, verify the student data being reported.  Check the FS and GI records to ensure that the SSID is being reported and that the student name is in the GI data.
  • Search the EMSRSTURVRS file
    Using the DCL Search command, search the EMSRSTURVRS.IDX file for the SSID in question.
$ SEARCH OECN$EMIS_12:EMSRSTURVRS.IDX XY1234567

This should result is a string that looks similar to the following:

TD5555555111111029793123456789Last          First 
TD5555555222222012047543211234Last          First

The reporting district IRN immediately follows the SSID in the record.  Using the above example, there were two records found for SSID TD5555555.  This student is being reported by district IRN 111111 and district 222222.  This means that when these two districts prepared their data in the Data Collector, the student was included and processed.

EMISR_SSID Procedure

The EMISR_SSID procedure will pull data from the Student Reverse Crosswalk SQL table on the EMIS-R server.  The student data will be loaded into a tab-delimited file, VRF_SSID.TXT.  The tab-delimited file will then be used to created an Indexed file, EMSRSTURVRS.IDX, for use with the enhancement of the Student based Post Processing reports.  These two files will be placed in OECN$EMIS. 

Duplicate Keys

The EMISR_SSID procedure will produce "WARN" messages for duplicate keys.  These may be ignored for the time being.  As EMIS-R progresses and updates are made to the Data Collector to enhance the performance, these messages should decline.  Updates will be made to how the SQL table is updated during the collection process to help prevent the duplicate key errors that are currently being seen.  These errors should not cause any issue with the proper information being found for the Student to populate the local ID and student name on the post processing reports.

Information received from ODE on January 11, 2012 indicates the SQL table used to populate the EMSRSTURVRS.IDX file is now being cleared out (for the reporting LEA IRN) and repopulated each time a district prepares their data.  This should significantly reduce the number of duplicate key warnings that are generated in the log file.

Purging of files

The EMISR_SSID procedure will keep the most recent two versions of the tab-delimited and indexed file.  This allows a way  to revert to the prior version if there was a problem with the last file generated by the procedure. 

Requires Java 1.5-7

We have found that the EMISR_SSID procedure requires OpenVMS Java version 1.5-7.  Older versions of Java will cause the following error when the procedure is run:

Assertion failed: cl->resolved_count >= 0, file JDEV:[fastvm.srcjava.runtime]class.c;1, line 4569

You may verify which version of Java is running on your system by executing the following commands from your DCL prompt:

@OECN$:OECN$JAVA
JAVA -fullversion
  • No labels