[LINK] Human error triggered NAB software corruption
Roger.Clarke at xamax.com.au
Tue Nov 30 09:38:20 AEDT 2010
At 9:17 +1100 30/11/10, Bernard Robertson-Dunn wrote:
>This is getting more believable.
>It would seem to be a problem with change control of their batch processing.
I'd just typed the following, as BRD's came down the line:
Oh dear, why do they let a mere PR person answer questions.
However, "software code containing instructions on how systems should
operate in the batch processing cycle" is almost-understandable
I think we can infer that the cause was one of:
- a wrong parameter-setting; or
- a faulty job control deck / script.
[Tenable explanation: they changed everything forward as per the
change control package, it went wrong, they backed almost everything
out, but they forgot to change the parameter or the JCL back to what
it was before the faulty change-package went in. As a result, a
program that will disappear in the next version was omitted from the
run (a likely candidate would be a transaction-validation program),
letting dirty data through into an update program that was designed
(for good reasons) to expect clean data.
[Ah, it takes me back to 1978, when we went live with TALISMAN, the
LSX's overnight batch system to process the day's trades. We never
mucked a change up like that though. It only ran for a measly couple
of decades though, unlike the banks' 30-40 year-old code.]
We have more than a few problems with language, don't we.
JCL (mainframe era) and script (mini-computer era) have probably both
been overrun by some other term or terms, and maybe even 'parameter'
is too 1970s to use today.
>Human error triggered NAB software corruption
>Since the news broke, NAB has blamed a "corrupted file in the processing
>batch" as the cause of its nightmares.
>However, it apparently was not a "file" itself that was the problem.
>Instead, it appears that someone from NAB's IT department who had access
>to the system inadvertently uploaded a file that "corrupted" the system.
>NAB spokesman George Wright described this as a "fair" statement as he
>tried to explain exactly what went wrong.
>Mr Wright said he did not have technical details of what happened, but
>ruled out sabotage, hacking or a virus attack. He confirmed the
>corrupted file itself did not contain any customer data. The "file" was
>actually software code containing instructions on how systems should
>operate in the batch processing cycle.
>The issue had nothing to do with NAB's mainframes which, he stressed,
>did not crash.
>He rejected claims a botched mainframe upgrade was the culprit ...
Roger Clarke http://www.rogerclarke.com/
Xamax Consultancy Pty Ltd 78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 1472, and 6288 6916
mailto:Roger.Clarke at xamax.com.au http://www.xamax.com.au/
Visiting Professor in the Cyberspace Law & Policy Centre Uni of NSW
Visiting Professor in Computer Science Australian National University
More information about the Link