Najprv holé minimálne pozadie. FISA bola založená v dôsledku finančnej krízy v New Yorku v roku 1975 („Ford to City: Drop Dead!“), aby vyriešila dva problémy: (1) Nebol rozpočet na celé mesto vs. skutočný účtovný systém. (2) Rôzne mestské úrady vyplácali zamestnancov, pre ktorých nemali žiadne rozpočtové položky. FISA najala prominentnú konzultačnú firmu, aby vytvorila dva systémy: (1) integrovaný systém finančného riadenia a (2) systém mzdového manažmentu Systém, ktorý – okrem toho, že robí všetky bežné veci, ktoré robí mzdový systém – je napojený na IFMS, aby sa zabezpečilo, že žiadny zamestnanec bez rozpočtu zaplatené.
Obidva tieto systémy boli napísané pomocou kompilátora OS/VS COBOL od IBM rôznymi tímami dodávateľov. Základným problémom bolo, že kompilátor OS/VS COBOL bol len prepracovanou verziou pôvodnej verzie IBM kompilátor COBOL-65 na úrovni F pred štandardizáciou ANSI dokázal spracovať príkazy, ktoré boli skôr rozšíreniami IBM než súčasťou CODASYL COBOL-65. Niektoré z týchto rozšírení splnili okamžité potreby, ktoré ANSI neskôr uspokojila odlišnou syntaxou/sémantikou, ale niektoré z týchto rozšírení tvorili zdrojovú úroveň ladiaci podjazyk (COBOL bol pôvodne navrhnutý na písanie aplikácií na dávkové spracovanie), ktorý nedisciplinovaní programátori nemohli odolať použitiu na neladenie kód. IBM napísalo svoj kompilátor kompatibilný s COBOL II ANSI-85 úplne od začiatku pomocou nedávno vyvinutých techník CS a neimplementovalo znova rozšírenia na úrovni F.
Skupina vývojárov FISA PMS (nešťastná skratka) najprv skonvertovala svojich 900+ zdrojových programov, čo trvalo podstatne menej ako jeden človekorok. Bolo to hlavne preto, že medzi nimi bol aj celkom skvelý bývalý sovietsky programátor, ktorý napísal 5 „filtračných“ programov typu source-to-source v mainframe assembleri IBM (samozrejme bez akýchkoľvek komentárov ;-) ). Štyri z jeho piatich filtrovacích programov konvertovali príkazy rozšírenia IBM, ktoré boli iba nahradené príkazmi ANSI COBOL s odlišnou syntaxou/sémantikou. Iba jeden z jeho filtrovacích programov potreboval konvertovať ladiaci podjazykový príkaz, pretože posádka dodávateľa PMS a následní programátori „údržby“ FISA boli dobre disciplinovaní.
Vedenie programovania FISA si myslelo, že všetko, čo potrebujú, je nechať troch programátorov spustiť 2100+ zdrojové programy IFMS prostredníctvom tých istých 5 PMS napísaných „filtračných“ programov. Ako jediný z troch s výcvikom CS som musel manažmentu vysvetliť, že – pretože posádka dodávateľa IFMS a následní programátori FISA boli menej disciplinovaní – budeme musieť napísať 7 ďalších „filtrov“ programy. Napísali sme ich – päť pre mňa a jeden pre každého z ďalších dvoch konverzných programátorov – v IBM Rexx interpretoval skriptovací/makro jazyk, pretože bezprostredný šéf konverzného tria IFMS bol nadšenec OS/2 a pretože Rexx bol dostupný na našich sálových počítačoch.
Keď prišiel čas na rekompiláciu 2100+ zdrojových programov pomocou kompilátora COBOL II, napísal som program v COBOL II na vytvorenie zoznamu z IFMS. linkage-edit-control-card znázorňujúci poradie, v ktorom je potrebné programy – počnúc podprogramami najnižšej úrovne – skompilovať a upravený odkazom. V prípade, že to znie ako základná logika „vyrobiť“, máte pravdu – ale mainframový softvér IBM bol navrhnutý 10 rokov pred Unixom.
Konverzia IFMS OS/VS-na-COBOL-II bola dokončená v marci 1996 a koncom mája som odišiel z FISA na programovanie v C++ v súkromnom priemysle. Neskôr som počul, že IFMS aj PMS boli prepísané novou skupinou dodávateľov o menej ako 5 rokov neskôr. Som si istý, že časť dôvodu, prečo to FISA urobila, bol rozsah potrebnej konverzie Y2K. Som si však istý, že ďalším dôvodom prepísania bolo, že pôvodné systémy IFMS a PMS boli technologicky trochu príliš pokročilé. Oba systémy využívali systémy IBM Systém správy informácií. IMS/DB bol predrelačný hierarchický systém správy databáz a IMS/DC bol dobrý manažér transakcií (IFMS aj PMS používali online terminály), ktorý prehral s CICS na sálovom počítači.
Aký je teda zmysel tohto príbehu? Ide o to, že vládna agentúra vyžaduje veľké úsilie, aby udržiavala svoje informačné systémy technologicky aktuálne pomocou vlastných zamestnancov. Ako sa ukázalo, pre vedenie FISA mohlo byť lepším nápadom zostať pri OS/VS COBOL ešte niekoľko rokov aj napriek prosbám IBM, spoliehajúc sa na pravdepodobnosť, že by mohli použiť „scenár skazy“ Y2K na vystrašenie starostu a kontrolóra, aby sa vykašľali na peniaze na dôkladné prepísať.
David H.
P.S.: Softvér IBM mainframe bol navrhnutý len 10 rokov pred Unixom. Bohužiaľ, táto oprava sa nedostala do propagovanej verzie môjho komentára. Som dobrý v 8. triede aritmetiky, ale niekedy mám problémy s 3. triedou.
P.P.S.: Napísali sme celkovo sedem Rexx filtrov — nie päť; pôvodne šesť a ešte jeden v roku 1995. Vždy som si pamätal celkovo sedem; Len som nemohol vidieť jednu z prvých šiestich, keď som si prvýkrát prečítal poznámku z roku 1994. ;-) Ani táto oprava sa do propagovanej verzie môjho komentára nedostala.
To neznie až tak zle, až na to, že niektoré zariadenia boli zlacnené dlhšie, ako niektorí čitatelia tu boli NAŽIVO. Telekomunikačná infraštruktúra pre E911 je extrémne modulárna a pozostáva väčšinou z kariet navrhnutých tak, aby boli vymeniteľné bez nástrojov a bez toho, aby ste robili veľa, ak vôbec nejaké, terénne práce na samotných kartách, okrem toho, že ste vložili „nový“ jeden. VŠETKO bolo na karte. Videli by ste zásuvnú kartu s jediným kondenzátorom zabaleným v papieri, alebo transformátor alebo celú kartu s ničím iným ako so štyrmi poistkami automobilového typu prispájkovanými ku konektorom. Prečo by si do pekla spájkoval poistku? Takže nemôžu vypadnúť. Niet pochýb o tom, že keď sa jeden z nich vrátil, nejaká miazga si musela sadnúť na lavičku a vysať všetku starú spájku, vymeňte poistku a ešte viac zapnite, potom položte POS späť na poličku, aby ju nabudúce zožrala veverička drôt.
8-palcová disketa môže byť bezpečnejšia ako moderné šifrovanie.
Väčšina hackerov totiž ani netuší, ako fungovala technológia z dôb ich starých rodičov.
Ako sa nabúrate do 8-palcovej diskety?
.
Som ohromený, že veci stále existujú mimo múzeí.
Moja posledná úloha pri riadení programu pred odchodom do dôchodku zahŕňala úsilie o modernizáciu sálového počítača. Prišiel som do toho uprostred prúdu, ale úsilie bolo dobre premyslené a je na dobrej ceste k úspechu. Ale nie v blízkosti pôvodného plánu. Trvá to roky dlhšie, ako sa plánovalo, nie kvôli neschopnosti, ale preto, že agentúra stále hľadá ďalšie funkcie, ďalšie rozhrania a ďalšiu zložitosť. Časti systému, ktoré boli zmodernizované, pristupujú k možno najväčšej databáze Oracle na svete. Všetko je potrebné preskúmať, zdokumentovať, preveriť komunitou používateľov, určiť dopady na iné systémy a organizácie a ďalej a ďalej. A, samozrejme, nie je to len otázka reprodukovania existujúcich funkcií. Vďaka zmenám vo svete, mandátom Kongresu, priemyselným zmenám a technologickým zmenám neustále pribúdajú nové požiadavky. A nemyslite si, že odpoveďou je len začať od nuly s novými požiadavkami. Používatelia nerozumejú celému backendovému spracovaniu, ktoré prebieha - jediný spôsob, ako to pochopiť, je spätne to analyzovať. (Mali sme celý tím vývojárov COBOL pre mainframe, ktorí boli v podstate prevedení na analytikov požiadaviek, ktorí dokumentovali, čo robia staršie aplikácie.)
História IT je plná neúspešných snáh o modernizáciu. V niektorých prípadoch viacnásobné zlyhania modernizácie toho istého systému. Nie je to jednoduché ani vo vláde, ani v súkromnom sektore. Faktor v rozpočtových obmedzeniach a konkurencia medzi financovaním nových systémov vs. modernizujú staré a vôbec sa nečudujem, že sa používajú 50 rokov staré systémy. (Táto agentúra používa aplikáciu FoxPro pre DOS, ktorá bola podľa mňa pôvodne nasadená v roku 1995. Neustále sa aktualizuje, zapĺňa jedinečné miesto a stále funguje. Ak však vývojár odíde alebo odíde do dôchodku, bude mať veľké problémy.)
Skutočný problém nie je v tom, že na sálových počítačoch IBM bežia staré systémy. Je to tak, že už čoskoro nemusí zostať nikto, kto by ich vedel udržiavať. Pokúsili ste sa v poslednej dobe najať nejakých čerstvých absolventov vysokých škôl, aby pracovali na aplikáciách COBOL? Nedeje sa.
[url= http://arstechnica.com/civis/viewtopic.php? p=31257861#p31257861:3quvkg5d povedal:
beleg[/url]":3quvkg5d][url= http://arstechnica.com/civis/viewtopic.php? p=31257407#p31257407:3quvkg5d povedal:
anurodhp[/url]":3quvkg5d]Ak nie je poškodený, nemusíte ho opravovať.
Kliknutím rozbalíte...
V tomto tvrdení je toľko nesprávnych vecí, že nemôžem ani poškriabať povrch, ale skúsim to...V CS existujú pokroky, ktoré vedú k zlepšeniu výkonu, a teda k vyššej produktivite
Existujú pokroky v dizajne používateľského rozhrania, ktoré vedú k vyššej produktivite
Došlo k pokroku v našom chápaní procesov a pracovných postupov, ktoré vedú k... uhádli ste, zlepšila sa produktivita
Existuje pokrok v spôsobe, akým systémy komunikujú, zdieľajú informácie, prezentujú informácie, umožňujú ľuďom komunikovať, spolupracovať atď., čo vedie k vyššej produktivite...
Nie je dôvod mať vo výrobe 30 rokov starý IT systém (okrem postoja „ak nie je pokazený, netreba ho opravovať“)
Existuje len veľmi málo dôvodov, ak vôbec nejaké, prečo mať namiesto platformy SOA mainframe pre HR alebo ERP systém
a ani sa nebudem snažiť vysvetľovať výhody súčasných riešení na skladovanie dát, veľkých dát, analytiky atď. v porovnaní s tým, čo bolo dostupné pred 30-40 rokmi...Kliknutím rozbalíte...
Napriek tomu, ak robí prácu, ktorá je potrebná... prečo to meniť?
Prečo zavádzať riziko, keď je prínos malý alebo neexistuje?
Iste, nový systém môže byť v mnohých smeroch lepší... ale ak táto funkčnosť nie je potrebná alebo nestojí za náklady alebo riziko, ktoré nasleduje po prepísaní?
Niekedy to urobí obyčajné staré kladivo.
Nie je potrebná sociálna produktivita a spolupráca riadená udalosťami, pretože ako služba sa stane pozoruhodný cloudový systém.
Čo sa týka ministerstva obrany s jeho jadrovým arzenálom: používanie 8-palcových diskiet v súčasnosti znamená, že musia mať personál stále vyškolený na údržbu a opravu disketových jednotiek. Musia mať o tom veľmi podrobnú dokumentáciu a ja by som bol zvedavý, či ich môžu sprístupniť verejnosti (možno prostredníctvom žiadosti FOIA? Nebudem to vedieť, keďže nie som občanom USA), keďže opravu starého FDD potrebuje každý z nás rovnako starých zberateľov počítačov a dokumentácia k tejto konkrétnej téme (údržba diskiet) je trochu chýba.
Funguje E-911 vôbec? Mal som dojem, že to malo pomôcť zistiť, odkiaľ ľudia volajú.[url= http://arstechnica.com/civis/viewtopic.php? p=31264301#p31264301:1ta32o98 povedal:
Peevester[/url]":1ta32o98]Fuj, nenechaj ma začať na E911. V práci z predchádzajúceho dňa sme mali obrovské skľučovadlo skladového priestoru určeného na skladovanie horúcich náhradných dielov (musí byť pravidelne testované, aby funkčné a správne nakonfigurované) všetkých rôznych častí infraštruktúry E911, pripravené na doručenie kuriérom kamkoľvek na chvíľkové upozornenie.To neznie až tak zle, až na to, že niektoré zariadenia boli zlacnené dlhšie, ako niektorí čitatelia tu boli NAŽIVO. Telekomunikačná infraštruktúra pre E911 je extrémne modulárna a pozostáva väčšinou z kariet navrhnutých tak, aby boli vymeniteľné bez nástrojov a bez toho, aby ste robili veľa, ak vôbec nejaké, terénne práce na samotných kartách, okrem toho, že ste vložili „nový“ jeden. VŠETKO bolo na karte. Videli by ste zásuvnú kartu s jediným kondenzátorom zabaleným v papieri, alebo transformátor alebo celú kartu s ničím iným ako so štyrmi poistkami automobilového typu prispájkovanými ku konektorom. Prečo by si do pekla spájkoval poistku? Takže nemôžu vypadnúť. Niet pochýb o tom, že keď sa jeden z nich vrátil, nejaká miazga si musela sadnúť na lavičku a vysať všetku starú spájku, vymeňte poistku a ešte viac zapnite, potom položte POS späť na poličku, aby ju nabudúce zožrala veverička drôt.
Kliknutím rozbalíte...
Naposledy, keď som musel volať 911, bola jedna z najdesivejších a najdesivejších vecí, aké som kedy zažil – a to som ani nebol ten, kto potreboval sanitku.
Vracal som sa domov a videl som, ako sa auto opakovane otáča a prevracia v strede, tak som zastavil (spolu s mnohými ďalšími ľuďmi). Vedel som, že som do 1 míle od čiary medzi 2 okresmi a bol som na jedinej hlavnej diaľnici, ktorá bola v tejto oblasti. Nikto, kto sa zastavil, si nebol celkom istý, kde sme presnejšie, a pokiaľ sme videli, bola to len poľnohospodárska pôda. Dispečeri požadovali vedieť, v ktorom kraji sme a neustále ma presúvali tam a späť. Konečne som dostal telefonického operátora šerifa, ktorý ma skutočne vypočul s mojím problémom a poslal zástupcu, aby poľoval na miesto nehody, ale pri presune stratili moje meno a spätné volanie číslo.
Keď niekoho poslali, aby sa pozrel, našli nás v priebehu niekoľkých minút a on potom zavolal do rádia, aby zavolal hasičské autá (pre dymiace prevrátené auto), sanitku (pre vodiča, ktorý sa okoloidúci pokúšali pokračovať v rozprávaní a odrádzať od pohybu) a štátnu hliadku (na riešenie cesty, na ktorej je teraz tucet okoloidúcich zastavené).
Keď som sa vrátil domov, získal som zemepisnú šírku/dĺžku z videa z palubnej kamery a ukázalo sa, že som presne odhadol, kde som bol, boli sme v kraj, o ktorom som si myslel, že sme (a povedal som to operátorovi) a bolo to 0,6 míle od okresnej linky (uviedol som menej ako 1 míľu v hovor).
Ak by môj „inteligentný“ telefón neprešiel do „užitočného“ núdzového režimu, keď som zavolal na číslo 911, mohol som spustiť Google alebo Waze a zistiť, kde sa nachádzame, v okruhu niekoľkých metrov. Ale namiesto toho ide o zbytočnú vec, kde blokuje všetky ostatné aplikácie a iba udržiava špeciálnu obrazovku hovoru, ktorá obmedzuje to, čo môžete tlačiť (pravdepodobne aby ste sa vyhli odpojeniu).
Skutoční programátori...
Nepoužívajte COBOL. COBOL je pre programátorov Wimpy aplikácií.
Nepoužívajte FORTRAN. FORTRAN je pre slabučkých inžinierov, ktorí nosia biele ponožky, šialencov namáhaných potrubím a kryštalografických čudákov. Sú nadšení z analýzy konečných stavov a simulácie jadrového reaktora.
Nepíšte v PL/I. PL/I je pre programátorov, ktorí sa nevedia rozhodnúť, či písať v COBOL alebo FORTRAN.
Nepoužívajte LOGO. V skutočnosti žiadny programátor nepoužíva LOGO po dosiahnutí puberty.
Nepoužívajte APL, pokiaľ sa celý program nedá napísať na jeden riadok.
Nepoužívajte Pascal, BLISS, Ada ani žiadny z tých sissy-pinko počítačových jazykov. Silné písanie je barličkou pre ľudí so slabou pamäťou.
Nenoste si do práce obedy v hnedej taške. Ak to automat predá, zjedia to. Ak to automat nepredá, tak to nezjedia. Predajné automaty quiche nepredávajú.
(prevzaté z návodu z apríla 1985)
[url= http://arstechnica.com/civis/viewtopic.php? p=31257175#p31257175:18s83gkn povedal:
fuzzyfuzzyfungus[/url]":18s83gkn], ale „starý softvér = hrozný softvér“ je najdramatickejšie pravdivý pri komerčnom softvéri postavenom pod silným „prvý na trhu/súťažiaci o pridanie nových funkcií“, menej už s „postavené podľa náročných štandardov pre hlboko zarytých a paranoidných zákazníkov“ veci....
Vzhľadom na skutočne nočnú moru, ktorou sa projekty aktualizácie softvéru často stretávajú; Bol by som veľmi, veľmi nervózny z upgradovania vecí iba za to, že som starý; namiesto toho, aby bol zlomený.
Kliknutím rozbalíte...
Súhlasím. Trápi ma, že z celej tejto správy a článku vyplýva, že systém je napísaný v starom jazyku jazyk je zastaraný systém, ktorý je potrebné prepísať do „nového“ jazyka, pretože máme radi nové a lesklé veci. Toto je klasický príklad snahy opraviť niečo, čo nie je pokazené, a v skutočnosti je pravdepodobné, že štatisticky veci pokazíte prepísaním.
Chápem, že náklady na údržbu systému v jazyku ako COBOL alebo FORTRAN sa môžu zvýšiť, pretože jazyky sa stávajú menej bežnými a je ťažšie nájsť niekoho, kto ich pozná, ale úprimne povedané, ako často sa robia úpravy na úrovni zdroja na 40+ ročnom kóde základňa? Ak je odpovedí veľa, potom si to zaslúži preštudovať; inak to nechaj tak.
(upraviť: gramatika, interpunkcia)
[url= http://arstechnica.com/civis/viewtopic.php? p=31257861#p31257861:34z6ugtg povedal:
belleg[/url]":34z6ugtg]
V tomto tvrdení je toľko nesprávnych vecí, že nemôžem ani poškriabať povrch, ale skúsim to...V CS existujú pokroky, ktoré vedú k zlepšeniu výkonu, a teda k vyššej produktivite
Existujú pokroky v dizajne používateľského rozhrania, ktoré vedú k vyššej produktivite
Došlo k pokroku v našom chápaní procesov a pracovných postupov, ktoré vedú k... uhádli ste, zlepšila sa produktivita
Existuje pokrok v spôsobe, akým systémy komunikujú, zdieľajú informácie, prezentujú informácie, umožňujú ľuďom komunikovať, spolupracovať atď., čo vedie k vyššej produktivite...
Nie je dôvod mať vo výrobe 30 rokov starý IT systém (okrem postoja „ak nie je pokazený, netreba ho opravovať“)
Existuje len veľmi málo dôvodov, ak vôbec nejaké, prečo mať namiesto platformy SOA mainframe pre HR alebo ERP systém
a ani sa nebudem snažiť vysvetľovať výhody súčasných riešení na skladovanie dát, veľkých dát, analytiky atď. v porovnaní s tým, čo bolo dostupné pred 30-40 rokmi...Kliknutím rozbalíte...
Prepáčte, ale vaše tvrdenie je nesprávne.
Vylepšovanie softvéru pre jeho vlastné dobro je skvelý spôsob, ako dodať projekt, ktorý je prehnaný, zaostáva za harmonogramom, je náchylný na chyby a je náročný na údržbu. Keď hovoríte o kritických systémoch, ktoré nikdy nemôžu zlyhať, aby nespustili KONIEC SVETA, jediné dôležité je, že špecifikácie systému sú správne a dodaný systém ich spĺňa technické údaje.
Ako uviedli iné plagáty, staršie projekty aktualizácie softvéru sú ako otvorenie plechovky červov. Aby bolo možné zdôvodniť riziká spojené s projektom modernizácie, existujúci systém musí mať jasné nedostatky v plnení súčasných požiadaviek. V opačnom prípade sa jednoducho neoplatí otvárať plechovku.
Nostalgia - oh, za tie roky, keď sme boli mladí! IBM mainframe Assembly - v tom som robil postgraduálny projekt. Zvládol polovicu úlohy, dostal A! Šialené veci. 8" diskety - myslím, že som spracoval niekoľko tisíc, ale to bolo neskôr. Niekto niekde sedí na kopci 8" diskiet a dojí rozpočet krajiny - niečo ako jediný drogový díler, ktorý ovládol trh!
[url= http://arstechnica.com/civis/viewtopic.php? p=31266013#p31266013:3lloqcgq povedal:
mmiller7[/url]":3lloqcgq]Funguje E-911 vôbec? Mal som dojem, že to malo pomôcť zistiť, odkiaľ ľudia volajú.[url= http://arstechnica.com/civis/viewtopic.php? p=31264301#p31264301:3lloqcgq povedal:
Peevester[/url]":3lloqcgq]Fuj, nenechaj ma začať na E911. V práci z predchádzajúceho dňa sme mali obrovské skľučovadlo skladového priestoru určeného na skladovanie horúcich náhradných dielov (musí byť pravidelne testované, aby funkčné a správne nakonfigurované) všetkých rôznych častí infraštruktúry E911, pripravené na doručenie kuriérom kamkoľvek na chvíľkové upozornenie.To neznie až tak zle, až na to, že niektoré zariadenia boli zlacnené dlhšie, ako niektorí čitatelia tu boli NAŽIVO. Telekomunikačná infraštruktúra pre E911 je extrémne modulárna a pozostáva väčšinou z kariet navrhnutých tak, aby boli vymeniteľné bez nástrojov a bez toho, aby ste robili veľa, ak vôbec nejaké, terénne práce na samotných kartách, okrem toho, že ste vložili „nový“ jeden. VŠETKO bolo na karte. Videli by ste zásuvnú kartu s jediným kondenzátorom zabaleným v papieri, alebo transformátor alebo celú kartu s ničím iným ako so štyrmi poistkami automobilového typu prispájkovanými ku konektorom. Prečo by si do pekla spájkoval poistku? Takže nemôžu vypadnúť. Niet pochýb o tom, že keď sa jeden z nich vrátil, nejaká miazga si musela sadnúť na lavičku a vysať všetku starú spájku, vymeňte poistku a ešte viac zapnite, potom položte POS späť na poličku, aby ju nabudúce zožrala veverička drôt.
Kliknutím rozbalíte...Naposledy, keď som musel volať 911, bola jedna z najdesivejších a najdesivejších vecí, aké som kedy zažil – a to som ani nebol ten, kto potreboval sanitku.
Vracal som sa domov a videl som, ako sa auto opakovane otáča a prevracia v strede, tak som zastavil (spolu s mnohými ďalšími ľuďmi). Vedel som, že som do 1 míle od čiary medzi 2 okresmi a bol som na jedinej hlavnej diaľnici, ktorá bola v tejto oblasti. Nikto, kto sa zastavil, si nebol celkom istý, kde sme presnejšie, a pokiaľ sme videli, bola to len poľnohospodárska pôda. Dispečeri požadovali vedieť, v ktorom kraji sme a neustále ma presúvali tam a späť. Konečne som dostal telefonického operátora šerifa, ktorý ma skutočne vypočul s mojím problémom a poslal zástupcu, aby poľoval na miesto nehody, ale pri presune stratili moje meno a spätné volanie číslo.
Keď niekoho poslali, aby sa pozrel, našli nás v priebehu niekoľkých minút a on potom zavolal do rádia, aby zavolal hasičské autá (pre dymiace prevrátené auto), sanitku (pre vodiča, ktorý sa okoloidúci pokúšali pokračovať v rozprávaní a odrádzať od pohybu) a štátnu hliadku (na riešenie cesty, na ktorej je teraz tucet okoloidúcich zastavené).
Keď som sa vrátil domov, získal som zemepisnú šírku/dĺžku z videa z palubnej kamery a ukázalo sa, že som presne odhadol, kde som bol, boli sme v kraj, o ktorom som si myslel, že sme (a povedal som to operátorovi) a bolo to 0,6 míle od okresnej linky (uviedol som menej ako 1 míľu v hovor).
Ak by môj „inteligentný“ telefón neprešiel do „užitočného“ núdzového režimu, keď som zavolal na číslo 911, mohol som spustiť Google alebo Waze a zistiť, kde sa nachádzame, v okruhu niekoľkých metrov. Ale namiesto toho ide o zbytočnú vec, kde blokuje všetky ostatné aplikácie a iba udržiava špeciálnu obrazovku hovoru, ktorá obmedzuje to, čo môžete tlačiť (pravdepodobne aby ste sa vyhli odpojeniu).
Kliknutím rozbalíte...
Roky som s týmito technikmi nehovoril, takže nemôžem povedať, ale mám dojem, že údaje mobilného GPS sú veľmi zle, ak vôbec, integrované do systému, takže áno, budú sa vás pýtať, kde sú.
Ďalší problém, ktorý tu máte, nie je so samotným E911, ale s odoslaním nesprávnym ľuďom. To sa často stáva pri rýchlostných cestách, pretože z geografie často vôbec nie je jasné, kto to je.
Po prvé, len tri zo siedmich Rexx zdrojových „filtrov“, ktoré sme napísali, boli potrebné kvôli nedostatku disciplíny programátorov IFMS. Štvrtý „filter“ – ten, ktorý som napísal ako prvý – bol pôvodne potrebný, pretože niektoré názvy údajov a odsekov používané v programoch IFMS sa stali vyhradenými slovami pre nové funkcie v COBOL II. Toto je nepríjemný problém pri dlhodobej údržbe programov COBOL. Musel som však „filter“ rozšíriť, aby som sa zaoberal prípadmi, keď bolo dovolené použiť nevhodné slová vyhradené zákonom kombinácie pomocou analyzátora OS/VS COBOL od IBM – väčšinou „načechrané“ slová, ktoré boli vložené do CODASYL COBOL-65, aby poskytli programy menej strohý pocit pre čitateľov manažmentu (položka 1c). IBM vo svojom Sprievodcovi migráciou priznala, že – nepochybne preto, že jej kompilátor COBOL-65 na úrovni F bol zostavený pomocou syntaktického analyzátora s rekurzívnym zostupom – nevedel akú nadmnožinu štandardu ANSI COBOL-74 akceptoval jeho analyzátor kompilátora OS/VS. Kompilátor COBOL II od IBM bol zostavený s moderným syntaktickým analyzátorom a neakceptoval žiadne neštandardné „chumáče“.
Piaty a šiesty „filter“ Rexx – ktoré som tiež napísal – boli potrebné kvôli zhluku IBM z konca 60. a začiatku 70. rokov. IBM vytvorilo svoj skorý disk-to-print SPOOLers takže tlačili riadok po riadku (to bolo pred príchodom stranových tlačiarní) rýchlejšie, ak bolo ovládanie vozíka pre tlačový riadok špecifikované priamo v riadku samotnom. Preto do COBOL-65 na úrovni F pridal príkaz rozšírenia IBM, ktorý zapisoval tlačové riadky s predradeným znakom ovládania vozíka ANSI FORTRAN. IBM potom vyzvala svojich zákazníkov, aby používali tento príkaz rozšírenia IBM namiesto zodpovedajúceho príkazu CODASYL COBOL a aby používali verziu, v ktorej bol znak FORTRAN na ovládanie vozíka výslovne špecifikované. Dodávateľská skupina, ktorá vyvinula PMS, a programátori "údržby" PMS si toto povzbudenie vzali k srdcu. Keď teda príkaz IBM-extension line-printing nebol zahrnutý v COBOL II, programátor PMS sovietskeho emigranta musel napísať komplikovaný „filter“ v mainframe assembleri na rozšírenie takýchto príkazov pre tlač riadkov do viacerých príkazov prijateľných pre COBOL II kompilátor. Dodávatelia, ktorí vyvinuli IFMS – a jeho programátori „údržby“ FISA –väčšinou nepočúval IBM o výslovne špecifikované FORTRAN ovládanie vozíka. V čase konverzie to už nebol problém, pretože IBM spravilo svoje SPOOLery sofistikovanejšie. Napísal som teda „predfilter“, aby som určil, či príkazy na tlač riadkov v konkrétnom programe COBOL potrebujú „filtrovanie“ z jedného príkazu na viacero príkazov (čo by, keby akýkoľvek riadkovej tlače výslovne špecifikované znak riadenia vozíka FORTRAN) alebo iba „filtrovanie“ z jedného príkazu na jeden príkaz a napísal som „filter“ to by bolo adekvátne, ak by riadkové príkazy programu vyžadovali iba jeden príkaz od jedného príkazu k druhému „filtrovanie“.
Programový manažment FISA prišiel s pomerne sofistikovanou dvojstupňovou stratégiou na konverziu programov IFMS. Spoliehalo sa na skutočnosť, že štandardné Jazyk ANSI COBOL-74, ktorý zvládol aj kompilátor OS/VS, bol takmer riadna podmnožina jazyka ANSI COBOL-85. Náš trojčlenný konverzný tím teda najprv konvertoval 2100+ programov IFMS, jeden po druhom, na štandard ANSI COBOL-74. Ostatným „údržbovým“ programátorom bolo povedané, že ak upravujú program, ktorý bol konvertovaný, tak áno vyžaduje sa, aby ste ho ponechali v štandarde ANSI COBOL-74 – a dávajte pozor, aby ste nepoužívali žiadne mená, ktoré boli novými rezervovanými slovami v COBOL-85. Výnimkou bolo, že mohli naďalej používať jeden konkrétny príkaz rozšírenia IBM – riadený tabuľkou prevodník znaku za znak, pre ktorý bola definovaná náhrada za ANSI COBOL-85, ktorý nebol dostupný v Kompilátor OS/VS COBOL. Keď nastal čas, aby konverzný tím skutočne znova skompiloval a prepojil už skonvertované programy IFMS pomocou COBOL II kompilátora, najprv sme spustili všetkých 2100+ programov cez siedmy Rexx „filter“ – ktorý som napísal – aby sme skonvertovali posledný príkaz rozšírenia IBM typu.
Pracovníci oddelenia počítačových operácií FISA museli prežiť jedno sklamanie z konverzie COBOL II, ktoré sa týkalo problému s Excel-makro Kopáč spomenuté vyššie v tomto vlákne. Neskoršie verzie operačného systému MVS od IBM mali Extended Architecture, ktorá rozšírila adresovateľnú oblasť RAM využiteľnú programom na 2 GB zo 16 MB. Ale na spustenie v 32-bitovom režime adresovania musel „načítací modul“, pozostávajúci z programu a všetkých podprogramov, ktoré boli spoločne upravované, pozostávať výlučne z modulov s opakovaným vstupom. Kompilátor COBOL II mohol vydávať moduly opakovaných objektov, ale všetky programy/podprogramy v jazyku zostavy v zavádzacom module museli byť výslovne napísané opätovný vstup. Na začiatku svojej vývojovej práce pre FISA pracovníci dodávateľov napísali sadu podprogramov v jazyku montáže, ktoré volali takmer všetky programy. Zdrojový kód pre tieto podprogramy sa pred rokmi stratil počas presunu z budovy do budovy, pravdepodobne preto, že ich vlastníctvo neprevzalo ani IFMS, ani manažment programovania PMS. V dôsledku môjho návrhu počas stretnutia jeden zo systémových programátorov FISA Operations rozobral niektoré podprogramy; samozrejme mali nie bol napísaný znovu okolo roku 1975. Takže, keďže nikto nebol ochotný uvažovať o opätovnom vývoji týchto podprogramov z ich (neexistujúcich) špecifikácií, spustenie skutočne veľkých záťažových modulov na sálových počítačoch FISA zostalo nemožné.
David H.
P.S.: Napísali sme celkovo sedem Rexx filtrov — nie päť; pôvodne šesť a ešte jeden v roku 1995. Vždy som si pamätal celkovo sedem; Len som nemohol vidieť jednu z prvých šiestich, keď som si prvýkrát prečítal poznámku z roku 1994. ;-)
Existuje veľmi reálna a veľmi veľká šanca, že nový systém môže obsahovať viac chýb, než súčasný systém obsahuje. Existujúce chyby môžu byť veľké a malé; niektoré budú mať riešenia, ktoré môžu zahŕňať procedurálne „mäkké opravy“ (to znamená – oprava bude niečo, čo urobí osoba, pravdepodobne to nebude zapísané, ale odovzdáva sa, keď sú ľudia najímaní/prepúšťaní/povýšovaní/atď. – alebo ak je to zapísané, je to v nejakej nejasnej poznámke v kartotéke alebo zakladači kto-vie-kde). Existuje nebezpečenstvo, že niektoré opravy v existujúcom kóde boli vykonané s cieľom obísť chyby v pôvodnom operačnom systéme – ak tento základný operačný systém mal tieto chyby boli opravené (alebo vôbec neexistovali, alebo má inú implementáciu tej istej chyby) - potom tieto opravy na obídenie týchto chýb OS pravdepodobne budú zlyhať.
To všetko za predpokladu, že zdrojový kód všetkých týchto starších programov je chápaný tak, ako sú presne fungovať a vzájomne spolupracovať (alebo potenciálne nie!) – špecifikácie kódu sa nemusia zhodovať s kód; komentáre v kóde sa nemusia zhodovať s kódom, ktorý je komentovaný - alebo so špecifikáciami. Kód sa musí považovať za „správnu“ verziu – a aj keď je zjavne nesprávna, rozhodnúť sa zmeniť ju tak, aby bola správna (či už špecifikáciu, komentár alebo niečo nové) – môže porušiť iné veci, o ktorých sa neuvažovalo mimo oblasti, v ktorej je „pokazený“ kód beh. Následné efekty alebo efekty znižovania, ktoré v pôvodnom kóde mohli byť zmiernené v iných oblastiach systému (napríklad, možno iný program prevezme výstup a "opraví" to, pretože to bolo nesprávne - ale ak ste to opravili v prvom programe, neuvedomujúc si, že druhý program to opraví - a možno ani neviete, kde ten druhý program je; možno ani nie je súčasťou hlavného systému, ale v inej časti vlády alebo mimo nej atď.).
To sa stáva stále v oveľa "mladších" softvérových systémoch - predstavoval by som si, že starší systém môže mať takéto nezrovnalosti minimálne v rovnakom množstve, ak nie viac. Aktualizácia kódu alebo jeho implementácia v inom programovacom jazyku (och – skoro som zabudol – možno bol nejaký kód napísaný, aby sa obišli chyby v kompilátor) môže vytvoriť systém, ktorý je nestabilný, alebo ešte horšie - je stabilný, ale údaje, ktoré generuje, v určitom stave alebo stavoch, vychádzajú údaje, ktoré sú nesprávne (možno len takým spôsobom, že to nie je na prvý pohľad viditeľné, ale môžu sa ako snehová guľa pri prechode cez iné systémy) ich rozbitie). Existuje potenciál pre problémy s nesprávnym výpočtom (najmä v prípade vecí IRS), ktoré by mohli spôsobiť daňové a rozpočtové problémy ľudia, vláda, IRS atď. – pretože zaokrúhľovanie alebo niečo podobné sa nerobí rovnakým spôsobom ako starý systém, alebo preto, kvôli komplexnej povahe pôvodného systému tu niečo chýba alebo nie je identifikované, že sa deje kvôli vznikajúcej vlastnosti alebo podobne. Myslite na niečo také zvláštne, ako je THERAC-25 – veľké písmo (hoci to ľudí nemusí stáť život – dúfajme).
Táto možnosť by nemala spôsobiť, že ľudia nebudú aktualizovať tieto systémy – ale mala by dať každému pauzu a zabrať čas – dlhý čas - dôkladne preskúmať a celkovo pochopiť, ako všetky tieto systémy fungujú a vzájomne spolupracujú pred tým, ako budú aktualizované alebo zmenené drasticky. Okrem toho je potrebné tieto zmeny zavádzať pomaly a opatrne, pričom sa musí vykonať množstvo testov, kým sa uvedú „naostro“ a potom starostlivo monitorované počas stanoveného časového obdobia (v ideálnom prípade by ste mohli dokonca spustiť starý a nový systém paralelne a skontrolovať výstup oboch, aby boli rovnaké).
