[LINK] Human error triggered NAB software corruption

[Roger Clarke]

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 
computing dialect.

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
>The Australian
>http://www.theaustralian.com.au/australian-it/human-error-triggered-nab-software-corruption/story-e6frgakx-1225962953523
>
>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