Code glitch leads BLS to post data early again

For the second time in three months, the Bureau of Labor Statistics accidentally posted
financial data on its Web site before it was set for official release.


Last time, an economist posted the data early; this time the information technology
staff erred.


“A person who has been in our group for five years, has a sterling work record and
has apologized profusely made a mistake,” said Carl J. Lowe, associate commissioner
for technology and survey processing.


On Jan. 12, the Producer Price Indexes for December, scheduled for release at 8:30 a.m.
on Jan. 13, were posted on the agency’s Web site at 1:00 p.m. BLS immediately removed
the data from the site. But after BLS learned that there had been between 40 and 50
downloads of the data, it reposted the PPI materials at 5:00 p.m. that same day.


In November, a similar blunder occurred when BLS posted employment data for the
previous month on its Web site a day early [GCN, Nov. 23, 1998, Page 1]. The errant posting sparked a miniature bond rally as investors
traded on the information.


“The first was a management control problem, which allowed economists—in that
case a young economist—to put data up,” Lowe said.


At that time, BLS commissioner Katharine G. Abraham said that BLS had rigorous
procedures for placing its publications and timely data on the Web but had not applied
them to supplementary materials, such as the employment data. The agency said it would
apply the same review and posting rules to all its data.


But PPI data is what BLS calls a timed-series release and would, even before the first
blunder, have had tight controls on its review and posting.


The posting of PPI data is automated.


But BLS has been modifying its posting program, and the systems programmer let a
version of the software that controls releases go into production before it was fully
tested.


After code changes were made, the authorized individual put the software into the
production library instead of the test library, Lowe said.


BLS has a dual-checking process, but two programmers each thought the other had tested
the software, he said. “It was a communication problem as well,” Lowe said.


The modifications caused the software to incorrectly read the time and automatically
post the data to the BLS Web site.


BLS plans to make two changes in how it puts software into production. First, all
software must undergo a team review, instead of a check by two people, Lowe said. It will
slow the process, but it is the only way to ensure against future problems, he said.


Secondly, BLS will allow the entry of modified versions to the production library only
during prescribed periods, Lowe said.


“No punishment has been meted out at this point for the employees involved, Lowe
said. “That determination will be made at some later point.”


In the meantime, BLS has removed the faulty software and replaced it with the program
that worked, Abraham said. The bureau had been customizing its release software to add an
automated e-mail distribution feature.


Although the changes were not related to year 2000 work, “it does suggest we have
to take a hard look at what we are doing in the testing arena,” Abraham said.


BLS expects to complete testing for 2000 readiness by the end of the month, Lowe said.


The testing is done in a third environment, separate from the agency’s regular
systems testing library, he said.

inside gcn

  • A forward-located Control and Reporting Center. Air Force photo.

    Data security at the tactical edge: Rightsizing solutions

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above