Perché le applicazioni mainframe non presentano bug?

Question

Sembra che il vecchio ferro sia un software solido come una roccia.Perché?È perché il software è così maturo che tutti i bug sono stati risolti?O è perché le persone si sono così abituate ai bug che non li riconoscono nemmeno e non riescono più ad aggirarli?Le specifiche del software erano perfette fin dal primo giorno e una volta scritto il software, tutto ha funzionato?Sto cercando di capire come siamo passati dai giorni dell'informatica mainframe, che tutti ora considerano semplicemente funzionanti, alla sensazione che TDD sia ora la strada da percorrere.

Answer 1

Perché mai pensi che non abbiano insetti?

IBM ha un vasto supportare l'infrastruttura per la segnalazione e la risoluzione dei bug (PMR, APAR e PTF), che è ampiamente utilizzata.

Il software mainframe che non è stato toccato per molti anni sarà sicuramente ben compreso (almeno in termini di idiosincrasie) e probabilmente avrà avuto molti bug corretti o risolti.Tutto il nuovo materiale sviluppato oggigiorno prevede in realtà un certo numero di bug e patch da GA (disponibilità generale) ad almeno GA + 36 mesi.In effetti, un mio ex capo alla IBM era solito rifuggire dal fatto di essere costretto a fornire cifre per i bug pianificati con la frase:"Non erano pianificazione avere qualche bug".

Il mainframe sposa i principi RAS (affidabilità, disponibilità e manutenibilità) oltre ciò a cui la maggior parte dell'hardware e del software desktop potrebbe mai aspirare: questa è solo la mia opinione ovviamente, ma ho ragione :-)

Questo perché IBM sa fin troppo bene che il costo della correzione dei bug aumenta notevolmente man mano che si procede nel ciclo di sviluppo: è molto più economico correggere un bug nei test unitari che correggerne uno in produzione, sia in termini di denaro che di produzione. E reputazione.

C'è una grande quantità di sforzi e costi spesi solo per rilasciare software privo di bug, ma anche loro non riescono sempre a farlo bene.

Answer 2

Non ci sono bug nel software del frame principale, solo funzionalità.

Answer 3

Lavoravo su app mainframe.Le app precedenti non avevano molti bug perché non facevano molto.Abbiamo scritto centinaia se non migliaia di righe di FORTRAN per fare quello che faresti ora con un paio di formule in Excel.Ma quando siamo passati da programmi che ricevevano input inserendo un valore nelle colonne 12-26 della scheda 1 e un altro valore nelle colonne 1-5 della scheda 2, ecc., a programmi che ricevevano input da uno schermo ISPF interattivo o da una luce penna e l'output su un plotter Calcomp 1012 o su un terminale Tektronix 4107, il conteggio dei bug è aumentato.

Answer 4

Ci sono MOLTI bug sul software mainframe, semplicemente non vengono pubblicizzati tanto a causa del gruppo relativamente piccolo di sviluppatori interessati.Basta chiedere a qualcuno che si occupa di sviluppo mainframe quanti ABEND vedono ogni giorno!

Answer 5

Ho imparato a usare i debugger e ad analizzare i core dump su grandi mainframe di ferro.Credimi, sono nati solo a causa di bug.Ti sbagli semplicemente.

Tuttavia, le architetture mainframe sono state progettate per la stabilità in condizioni di stress elevato (ben rispetto, ad esempio, ai sistemi non mainframe), quindi forse si può sostenere che sono migliori in questo modo.Ma dal punto di vista del codice?No, i bug sono ancora lì...

Answer 6

La mia esperienza con il software applicativo mainframe (al contrario dei sistemi operativi) è piuttosto obsoleta, ma ricordo che la maggior parte delle applicazioni sono applicazioni batch che sono, logicamente, molto semplici:

a) Leggere un file di input
b) Elabora ogni record (se ti senti audace, aggiorna un database)
c) Scrivere un file di output

Nessun evento di input dell'utente di cui preoccuparsi, un team di operatori qualificati per monitorare il lavoro mentre viene eseguito, poca interazione con sistemi esterni, ecc. Ecc.

Ora la logica aziendale può essere complessa (specialmente se è scritta in COBOL 68 e il database non è relazionale) ma se è tutto ciò su cui devi concentrarti, è più facile creare software affidabile.

Answer 7

Personalmente non ho mai lavorato su software per mainframe, ma mio padre era un programmatore COBOL negli anni '70.

Quando scrivevi software a quei tempi, trovare bug non era così semplice come compilare il codice sorgente e guardare i messaggi di errore che il compilatore ti rispediva o eseguire il tuo programma e vedere cosa stava facendo di sbagliato.Un dattilografo doveva inserire il programma in schede perforate, che sarebbero poi state lette nel computer, che avrebbe stampato i risultati del programma.

Mio padre mi raccontò che un giorno qualcuno arrivò con un carrello pieno di scatole di carta e le mise accanto alla porta della stanza dove lui lavorava.Ha chiesto "Cos'è quello?!", e il ragazzo gli ha detto "Questo è l'output del tuo programma".Mio padre ha commesso un errore che ha fatto sì che il programma stampasse un'enorme quantità di parole senza senso su una risma di carta che avrebbe potuto consumare un intero albero.

In questo modo impari velocemente dai tuoi errori...

Answer 8

Oh, hanno sicuramente dei bug: vedi thedailywtf.com per alcuni esempi più divertenti.Detto questo, la maggior parte delle applicazioni "mainframe" che si vedono oggi hanno avuto 30 anni per risolvere tutti i problemi, quindi hanno un piccolo vantaggio rispetto alla maggior parte delle applicazioni create negli ultimi anni.

Answer 9

Anche se non ho esperienza con i mainframe, immagino che sia il primo punto che hai sottolineato:il software esiste da decenni.La maggior parte dei bug rimanenti sarà stata risolta.

Inoltre, non dimenticare i fiaschi come Y2K.Tutti i bug in cui le persone si sono imbattute sono stati risolti e tra 20 anni probabilmente si sarà verificata la maggior parte delle situazioni.Ma ogni tanto, una nuova situazione fa riescono a far sì che anche il software vecchio di 20 anni smetta di funzionare.

(Un altro esempio interessante di ciò è il bug trovato, credo, in BSD Unix.È stato ritrovato circa un anno fa, ed è in circolazione da 20 anni senza che nessuno se ne sia imbattuto).

Answer 10

Penso che la programmazione fosse solo un campo avanzato in cui solo gli ingegneri selezionati potevano lavorarci.Il mondo della programmazione ora è molto più grande con barriere all’ingresso più basse sotto ogni aspetto.

Answer 11

Penso che siano alcune cose.Il primo è che il ciclo di correzione di un bug e ricompilazione era solitamente più costoso nei mainframe.Ciò significava che il programmatore non poteva semplicemente eliminare il codice e "vedere se funziona".Eseguendo simulazioni di compilazione e runtime nella tua testa puoi individuare più bug di quanto non lasciare che sia il compilatore a rilevarli.

In secondo luogo, tutti e il loro fratello non erano "programmatori". Di solito erano specialisti altamente qualificati.Ora i programmi provengono da ragazzi seduti nel seminterrato con un diploma di scuola superiore.Non c'è niente di sbagliato in questo!!!ma tende ad avere più bug dell'ingegnere che lo fa professionalmente da 20 anni.

In terzo luogo, i programmi mainframe tendono ad avere meno interazione con i loro vicini.In Windows, ad esempio, un'app difettosa può mandare in crash quella accanto o l'intero sistema.Sui mainframe di solito hanno una memoria segmentata, quindi tutto ciò che può bloccarsi è se stesso.Date le tonnellate di cose in esecuzione sul tuo tipico sistema desktop da tutti i tipi di fonti marginalmente affidabili, tende a rendere qualsiasi programma instabile in una certa misura.

La maturità è sicuramente un fattore.Un programma COBOL per l'elaborazione delle carte di credito scritto 20 anni fa e perfezionato più e più volte per eliminare i bug ha meno probabilità di avere problemi rispetto a una versione 0.1 di qualsiasi programma.Naturalmente, c'è il problema che questi vecchi programmi riscritti infinite volte di solito finiscono per creare un codice spaghetti che è quasi impossibile da mantenere.

Come ogni cosa, dipende principalmente dai programmatori e dalla loro metodologia.Fanno test unitari?Documentano e scrivono codice pulito?Si limitano a inserire il codice nel compilatore per vedere se ci sono bug (sperando che il compilatore possa rilevarli tutti)?