Najprije minimalna pozadina. FISA je osnovana nakon financijske krize u New Yorku 1975. ("Ford to City: Drop Dead!") kako bi riješila dva problema: (1) nije postojao proračun za cijeli grad u odnosu na stvarni knjigovodstveni sustav. (2) Razne gradske agencije plaćale su zaposlenike za koje nisu imale proračunske stavke. FISA je angažirala istaknutu konzultantsku tvrtku za izgradnju dvaju sustava: (1) integriranog sustava financijskog upravljanja i (2) upravljanja plaćama Sustav koji se—osim što radi sve uobičajene stvari koje radi sustav obračuna plaća—zakačio na IFMS kako bi osigurao da nijedan zaposlenik koji nije u proračunu ne dobije plaćeno.
Oba ova sustava napisali su različiti timovi izvođača koristeći IBM-ov OS/VS COBOL kompajler. Temeljni problem je bio u tome što je OS/VS COBOL kompajler bio samo prerađena verzija IBM-ovog originala COBOL-65 kompajler F-razine prije standardizacije ANSI, mogao je rukovati izjavama koje su IBM proširenja, a ne dio CODASYL COBOL-65. Neka od tih proširenja ispunila su trenutne potrebe koje je ANSI zadovoljio kasnije različitom sintaksom/semantikom, ali neka od tih proširenja formirala su izvornu razinu podjezik za otklanjanje pogrešaka (COBOL je izvorno dizajniran za pisanje aplikacija za skupnu obradu) koji nedisciplinirani programeri nisu mogli odoljeti korištenju za neotklanjanje pogrešaka kodirati. IBM je napisao svoj COBOL II ANSI-85-kompatibilni kompajler od nule koristeći nedavno razvijene CS tehnike i nije ponovno implementirao ekstenzije razine F.
PMS (nesretni akronim) grupa programera FISA prvo je pretvorila svojih 900+ izvornih programa, za što je trebalo znatno manje od jedne godine. To je bilo uglavnom zato što su uključili prilično briljantnog bivšeg sovjetskog programera, koji je napisao 5 programa za "filter" od izvora do izvora u IBM mainframe asembleru (bez ikakvih komentara, naravno ;-) ). Četiri od njegovih pet programa za filtriranje pretvorilo je izjave IBM-proširenja koje su samo bile zamijenjene ANSI COBOL izjavama s drugačijom sintaksom/semantikom. Samo je jedan od njegovih programa za filtriranje trebao pretvoriti izjavu podjezika za otklanjanje pogrešaka, jer je ekipa izvođača PMS-a i kasniji programeri FISA-e za "održavanje" bili dobro disciplinirani.
Rukovodstvo FISA-e za programiranje smatralo je da sve što trebaju učiniti je imati tri programera da pokreću 2100+ IFMS izvornih programa kroz tih istih 5 programa "filtara" koje je napisao PMS. Ja, kao jedini od trojice s obukom za CS, morao sam to objasniti upravi - jer je ekipa izvođača IFMS-a a budući FISA programeri bili su manje disciplinirani—morat ćemo napisati 7 dodatnih "filtara" programa. Napisali smo ih - pet za mene i po jedan za svakog od druga dva programera za konverziju - u IBM-u Rexx interpretirani skriptni/makro jezik, jer je neposredni šef trija za konverziju IFMS-a bio entuzijast OS/2 i jer je Rexx bio dostupan na našim glavnim računalima.
Kada je došlo vrijeme za ponovno kompajliranje 2100+ izvornih programa s COBOL II kompajlerom, napisao sam program u COBOL II za stvaranje popisa iz IFMS-a linkage-edit-control-card datoteka koja prikazuje redoslijed u kojem programe—počevši od potprograma najniže razine—treba prevesti i link-uređeno. U slučaju da ovo zvuči kao bitna logika "make", u pravu ste—ali IBM-ov softver za glavno računalo dizajniran je 10 godina prije Unixa.
Konverzija IFMS OS/VS-to-COBOL-II završena je u ožujku 1996., a ja sam krajem svibnja napustio FISA-u radi posla C++ programera u privatnoj industriji. Kasnije sam čuo da je i IFMS i PMS prepisala nova grupa izvođača manje od 5 godina kasnije. Dio razloga zašto je FISA to učinila, siguran sam, bio je opseg potrebne konverzije Y2K. Međutim, siguran sam da je još jedan razlog za ponovno pisanje taj što su izvorni IFMS i PMS sustavi tehnološki malo previše napredan. Oba su sustava koristila IBM-ov Sustav upravljanja informacijama. IMS/DB je bio predrelacijski hijerarhijski sustav upravljanja bazom podataka, a IMS/DC je bio dobar upravitelj transakcija (i IFMS i PMS koristili su mrežne terminale) koji je izgubio od CICS-a na glavnom računalu.
Dakle, koja je poanta ove priče? Poanta je u tome da je vladinoj agenciji potrebno mnogo truda da svoje informacijske sustave održi tehnološki ažurnim korištenjem internog osoblja. Kako se pokazalo, možda je bila bolja ideja da FISA-ina uprava ostane uz OS/VS COBOL još nekoliko godina, usprkos molbama IBM-a, oslanjajući se na vjerojatnost da bi mogli iskoristiti "scenarij propasti" Y2K kako bi prestrašili gradonačelnika i kontrolora da iskašljaju novac za temeljitu prepisati.
David H.
P.S.: IBM mainframe softver dizajniran je samo 10 godina prije Unixa. Nažalost, taj ispravak nije ušao u promoviranu verziju mog komentara. Dobar sam u aritmetici 8. razreda, ali ponekad imam problema s aritmetikom 3. razreda.
P.P.S.: Napisali smo ukupno sedam Rexx filtera—ne pet; šest izvorno i još jedan 1995. Uvijek sam se sjećao ukupno sedam; Jednostavno nisam mogao vidjeti jedno od prvih šest prvih bezbroj puta kad sam ponovo pročitao dopis iz 1994. ;-) Ni ovaj ispravak nije ušao u promoviranu verziju mog komentara.
To i ne zvuči tako loše, osim što je neka oprema bila rasprodana duže nego što su neki čitatelji ovdje bili ŽIVI. Telekom infrastruktura za E911 je izuzetno modularna, sastoji se uglavnom od kartica dizajniranih da budu zamjenjive bez alata i bez puno rada na terenu na samim karticama, osim ubacivanja "nove" jedan. SVE je bilo na kartici. Vidjeli biste plug-in karticu s jednim kondenzatorom omotanim papirom na njoj, ili transformator, ili cijelu karticu sa samo četiri automobilska osigurača zalemljena na konektore. Zašto bi, dovraga, zalemio osigurač? Tako da ne mogu ispasti. Bez sumnje, kad se netko od ovih vratio u povratku, neki je lopuk morao sjesti za klupu, isisati sav stari lem, zamijenite osigurač i još malo napalite, a zatim vratite POS natrag na policu za sljedeći put kad vjeverica pojede žica.
Floppie od 8 inča mogao bi biti sigurniji od moderne enkripcije.
Uostalom, većina hakera nema pojma kako je funkcionirala tehnologija iz doba njihovih baka i djedova.
Kako hakirati disketu od 8 inča?
.
Zapanjen sam da te stvari još uvijek postoje izvan muzeja.
Moja posljednja uloga upravljanja programom prije nego što sam otišao u mirovinu uključivala je napore u modernizaciji glavnog računala. Ušao sam u to usred toka, ali trud je bio dobro promišljen i na putu je uspjeha. Ali ni blizu izvornog rasporeda. Traje godinama dulje od planiranog, ne zbog nekompetentnosti, već zato što agencija nastavlja pronalaziti dodatne funkcionalnosti, dodatna sučelja i dodatnu složenost. Dijelovi sustava koji su modernizirani pristupaju možda najvećoj Oracle bazi podataka na svijetu. Sve treba istražiti, dokumentirati, provjeriti sa zajednicom korisnika, utvrditi utjecaje na druge sustave i organizacije, i tako dalje. I, naravno, nije samo pitanje reprodukcije postojeće funkcionalnosti. Novi zahtjevi neprestano se dodaju zahvaljujući promjenama u svijetu, mandatima Kongresa, promjenama u industriji i tehnološkim promjenama. I nemojte misliti da je odgovor samo započeti ispočetka s novim zahtjevima. Korisnici ne razumiju svu pozadinsku obradu koja se odvija - jedini način da to shvatite je obrnuti inženjering. (Imali smo cijeli tim COBOL programera za mainframe koji su u biti pretvoreni u analitičare zahtjeva, dokumentirajući što rade naslijeđene aplikacije.)
Povijest IT-a prepuna je neuspješnih pokušaja modernizacije. U nekim slučajevima višestruki neuspjesi u modernizaciji istog sustava. To nije lako, u državnom ili privatnom sektoru. Uzmite u obzir proračunska ograničenja i natjecanje između financiranja novih sustava i modernizirati stare, i uopće me ne čudi što su u uporabi sustavi stari 50 godina. (Ova agencija koristi FoxPro za DOS aplikaciju za koju vjerujem da je prvi put postavljena 1995. Kontinuirano se ažurira, ispunjava jedinstvenu nišu i još uvijek radi. Ali ako programer ode ili se povuče, bit će u velikim problemima.)
Pravi problem nije u tome što postoje stari sustavi koji rade na IBM-ovim velikim računalima. Radi se o tome da uskoro možda više neće biti nikoga tko zna kako ih održavati. Jeste li u posljednje vrijeme pokušali zaposliti nekoga tko je nedavno diplomirao da radi na COBOL aplikacijama? Ne događa se.
[url= http://arstechnica.com/civis/viewtopic.php? p=31257861#p31257861:3quvkg5d je rekao:
ljepota[/url]":3quvkg5d][url= http://arstechnica.com/civis/viewtopic.php? p=31257407#p31257407:3quvkg5d je rekao:
anurodhp[/url]":3quvkg5d]Ako nije pokvaren, ne morate ga popravljati.
Kliknite za proširenje...
Toliko je pogrešnih stvari u ovoj izjavi da ne mogu ni zagrebati po površini, ali ću pokušati...Postoji napredak u CS-u koji dovodi do poboljšane izvedbe, a time i do poboljšane produktivnosti
Postoji napredak u dizajnu korisničkog sučelja koji vodi do poboljšane produktivnosti
Postoji napredak u našem razumijevanju procesa i tijekova rada koji dovode do... pogađate, poboljšana produktivnost
Postoji napredak u načinu na koji sustavi komuniciraju, dijele informacije, prezentiraju informacije, omogućuju ljudima da komuniciraju, surađuju itd. što dovodi do poboljšane produktivnosti...
Nema razloga imati 30 godina star IT sustav u proizvodnji (osim stava "Ako nije pokvaren, ne treba ga popravljati")
Postoji vrlo malo, ako ih uopće ima, razloga zašto imati mainframe za HR ili ERP sustav umjesto SOA platforme
i neću ni pokušavati objašnjavati prednosti trenutnih rješenja za skladištenje podataka, Big Data, analitike itd. u odnosu na ono što je bilo dostupno prije 30-40 godina...Kliknite za proširenje...
Ipak, ako radi posao koji je potreban... zašto ga mijenjati?
Zašto uvoditi rizik kada je korist mala ili je uopće nema?
Naravno, novi sustav bi mogao biti bolji na mnogo načina... ali ako ta funkcionalnost nije potrebna ili nije vrijedna troška ili rizika koji slijedi nakon ponovnog pisanja?
Ponekad će običan stari čekić obaviti posao.
Nema potrebe za društvenom produktivnošću i suradnjom vođenom događajima koji upečatljivim sustavom oblaka kao uslugom.
Što se tiče Ministarstva obrane s njegovim nuklearnim arsenalom: današnje korištenje 8 inčnih disketa znači da moraju imati osoblje koje je još uvijek obučeno za održavanje i popravak disketnih pogona. Moraju imati vrlo detaljnu dokumentaciju o tome i zanima me mogu li je učiniti dostupnom javnosti (možda putem zahtjeva FOIA? Neću znati budući da nisam državljanin SAD-a) budući da je popravak starog FDD-a potreba svakoga od nas starijih kolekcionari računala i da je dokumentacije o ovoj posebnoj temi (održavanje disketa) malo nedostaje.
Djeluje li uopće E-911? Bio sam pod dojmom da bi to trebalo pomoći da shvatim odakle ljudi zovu.[url= http://arstechnica.com/civis/viewtopic.php? p=31264301#p31264301:1ta32o98 je rekao:
Peevester[/url]":1ta32o98]Uf, nemoj da počnem s E911. Na prethodnom poslu imali smo ogroman skladišni prostor namijenjen za pohranu vrućih rezervnih dijelova (mora se redovito testirati operativan i ispravno konfiguriran) svih različitih dijelova E911 infrastrukture, spreman za slanje bilo gdje u trenutku trenutna obavijest.To i ne zvuči tako loše, osim što je neka oprema bila rasprodana duže nego što su neki čitatelji ovdje bili ŽIVI. Telekom infrastruktura za E911 je izuzetno modularna, sastoji se uglavnom od kartica dizajniranih da budu zamjenjive bez alata i bez puno rada na terenu na samim karticama, osim ubacivanja "nove" jedan. SVE je bilo na kartici. Vidjeli biste plug-in karticu s jednim kondenzatorom omotanim papirom na njoj, ili transformator, ili cijelu karticu sa samo četiri automobilska osigurača zalemljena na konektore. Zašto bi, dovraga, zalemio osigurač? Tako da ne mogu ispasti. Bez sumnje, kad se netko od ovih vratio u povratku, neki je lopuk morao sjesti za klupu, isisati sav stari lem, zamijenite osigurač i još malo napalite, a zatim vratite POS natrag na policu za sljedeći put kad vjeverica pojede žica.
Kliknite za proširenje...
Posljednji put kad sam morala nazvati 911 bila je jedna od najstrašnijih i najužasnijih stvari koje sam ikada doživjela - a čak nisam bila ni ta kojoj je trebala hitna pomoć.
Vraćao sam se kući i vidio kako se auto okreće i prevrće više puta u sredini pa sam stao (zajedno s mnogim drugim ljudima). Znao sam da sam unutar 1 milje od crte između 2 županije i da sam bio na jedinoj glavnoj autocesti koja je bila u tom području. Nitko tko se zaustavio nije bio sasvim siguran gdje smo točnije i bilo je to samo poljoprivredno zemljište koliko smo mogli vidjeti. Dispečeri su tražili da znaju u kojoj se županiji nalazimo i stalno su me prebacivali tamo-amo. Napokon sam dobio šerifovog telefonskog operatera koji nije za hitne slučajeve i koji me je saslušao s mojim problemom i poslao je zamjenika u potragu za mjestom nesreće, ali u premještaju su izgubili moje ime i povratni poziv broj.
Jednom kada su poslali nekoga da pogleda, pronašli su nas za nekoliko minuta, a on se zatim javio na radio i pozvao vatrogasna vozila (za automobil koji se zadimio), hitnu pomoć (za vozača kojeg su slučajni prolaznici pokušavali odvratiti od govora i obeshrabriti da se kreće), i državne patrole (da se pozabavi cestom na kojoj je sada bilo desetak prolaznika zaustavljen).
Kad sam došao kući, dobio sam zemljopisnu širinu/dužinu sa svog videa kamere na kontrolnoj tabli i ispostavilo se da sam bio na mjestu u svojoj pretpostavci gdje sam bio, bili smo u okrug Mislio sam da jesmo (i to sam rekao operateru) i bilo je 0,6 milja od granice okruga (naveo sam manje od 1 milje u svom poziv).
Da moj "pametni" telefon nije prešao u "korisni" način za hitne slučajeve kada sam nazvao hitnu, mogao sam povući Google ili Waze i pronaći gdje smo u krugu od nekoliko metara. Ali umjesto toga ide u beskorisnu stvar gdje blokira sve druge aplikacije i samo drži poseban zaslon za pozive koji ograničava ono što možete pritisnuti (vjerojatno kako biste izbjegli prekid veze).
Pravi programeri...
Nemojte koristiti COBOL. COBOL je za slabašne programere aplikacija.
Ne koristite FORTRAN. FORTRAN je za slabašne inženjere koji nose bijele čarape, lude za lulama i kristalografske male. Oduševljavaju se analizom konačnog stanja i simulacijom nuklearnog reaktora.
Ne piši na PL/I. PL/I je za programere koji se ne mogu odlučiti hoće li pisati u COBOL-u ili FORTRAN-u.
Nemojte koristiti LOGO. Zapravo, niti jedan programer ne koristi LOGO nakon što uđe u pubertet.
Nemojte koristiti APL, osim ako se cijeli program ne može napisati u jednom retku.
Nemojte koristiti Pascal, BLISS, Adu ili bilo koji od onih jezika za informatiku. Snažno tipkanje je štaka za ljude sa slabim pamćenjem.
Ne nosite ručak u smeđoj vrećici na posao. Ako ga proda automat, pojedu ga. Ako ga automat ne proda, oni ga ne jedu. Automati za prodaju ne prodaju quiche.
(preuzeto iz Uputa iz travnja 1985.)
[url= http://arstechnica.com/civis/viewtopic.php? p=31257175#p31257175:18s83gkn je rekao:
fuzzyfuzzyfungus[/url]":18s83gkn] ali 'stari softver = užasan softver' najdramatičnije je istinit s komercijalnim softverom izgrađenim pod jakim uvjeti 'prvi na tržištu/natječu se za dodavanje novih značajki', manje s 'izgrađenim prema zahtjevnim standardima za kupce s dubokim džepom i paranoične korisnike' stvari....
S obzirom na doista grozan obrat koji često poprimaju projekti nadogradnje softvera; Bio bih jako, jako nervozan oko nadogradnje stvari samo jer sam star; nego za to što je slomljen.
Kliknite za proširenje...
Slažem se. Smeta mi što ovo izvješće i članak impliciraju da je sustav napisan na starom jezik je zastarjeli sustav koji treba biti ponovno napisan na "novom" jeziku jer volimo novo i sjajno stvari. Ovo je klasičan primjer pokušaja da se popravi nešto što nije pokvareno, a zapravo, statistički je vjerojatno da ćete stvari pokvariti prepisivanjem.
Mogu razumjeti da troškovi održavanja sustava na jeziku kao što su COBOL ili FORTRAN mogu postati veći kako jezici postaju manje uobičajeni i postaje teže pronaći nekoga tko ih poznaje, ali iskreno, koliko se često modificira izvorna razina koda starog 40+ godina baza? Ako je odgovor velik, onda zaslužuje proučavanje i ponovno pisanje; u suprotnom, samo ga ostavite na miru.
(uredi: gramatika, interpunkcija)
[url= http://arstechnica.com/civis/viewtopic.php? p=31257861#p31257861:34z6ugtg je rekao:
ljepota[/url]":34z6ugtg]
Toliko je pogrešnih stvari u ovoj izjavi da ne mogu ni zagrebati po površini, ali ću pokušati...Postoji napredak u CS-u koji dovodi do poboljšane izvedbe, a time i do poboljšane produktivnosti
Postoji napredak u dizajnu korisničkog sučelja koji vodi do poboljšane produktivnosti
Postoji napredak u našem razumijevanju procesa i tijekova rada koji dovode do... pogađate, poboljšana produktivnost
Postoji napredak u načinu na koji sustavi komuniciraju, dijele informacije, prezentiraju informacije, omogućuju ljudima da komuniciraju, surađuju itd. što dovodi do poboljšane produktivnosti...
Nema razloga imati 30 godina star IT sustav u proizvodnji (osim stava "Ako nije pokvaren, ne treba ga popravljati")
Postoji vrlo malo, ako ih uopće ima, razloga zašto imati mainframe za HR ili ERP sustav umjesto SOA platforme
i neću ni pokušavati objašnjavati prednosti trenutnih rješenja za skladištenje podataka, Big Data, analitike itd. u odnosu na ono što je bilo dostupno prije 30-40 godina...Kliknite za proširenje...
Oprostite, ali vaša izjava je pogrešna.
Učiniti softver "boljim" radi njega samog odličan je način da se isporuči projekt koji je prekomjeran proračun, kasni u rasporedu, sklon kvarovima i težak za održavanje. Kada govorite o kritičnim sustavima koji nikada ne smiju otkazati da ne izazovu KRAJ SVIJETA, jedini bitno je da su specifikacije sustava točne i da ih isporučeni sustav ispunjava tehnički podaci.
Kao što su drugi posteri primijetili, projekti nadogradnje naslijeđenog softvera su poput otvaranja limenke s crvima. Kako bi se opravdali rizici uključeni u projekt nadogradnje, postojeći sustav mora imati jasne nedostatke u ispunjavanju sadašnjih zahtjeva. Inače se jednostavno ne isplati otvarati limenku.
Nostalgija - o, za tim godinama kad smo bili mladi! Sklapanje IBM mainframea - radio sam na diplomskom studiju o tome. Uspio pola posla, dobio peticu! Luda stvar. 8" diskete - mislim da sam podnio nekoliko tisuća, ali to je bilo kasnije. Netko sjedi na brdu disketa od 8" negdje i muze državni proračun - nešto poput jedinog trgovca drogom koji je satjerao tržište u kut!
[url= http://arstechnica.com/civis/viewtopic.php? p=31266013#p31266013:3lloqcgq je rekao:
mmiller7[/url]":3lloqcgq]Djeluje li uopće E-911? Bio sam pod dojmom da bi to trebalo pomoći da shvatim odakle ljudi zovu.[url= http://arstechnica.com/civis/viewtopic.php? p=31264301#p31264301:3lloqcgq je rekao:
Peevester[/url]":3lloqcgq]Uf, nemojte me tjerati na E911. Na prethodnom poslu imali smo ogroman skladišni prostor namijenjen za pohranu vrućih rezervnih dijelova (mora se redovito testirati operativan i ispravno konfiguriran) svih različitih dijelova E911 infrastrukture, spreman za slanje bilo gdje u trenutku trenutna obavijest.To i ne zvuči tako loše, osim što je neka oprema bila rasprodana duže nego što su neki čitatelji ovdje bili ŽIVI. Telekom infrastruktura za E911 je izuzetno modularna, sastoji se uglavnom od kartica dizajniranih da budu zamjenjive bez alata i bez puno rada na terenu na samim karticama, osim ubacivanja "nove" jedan. SVE je bilo na kartici. Vidjeli biste plug-in karticu s jednim kondenzatorom omotanim papirom na njoj, ili transformator, ili cijelu karticu sa samo četiri automobilska osigurača zalemljena na konektore. Zašto bi, dovraga, zalemio osigurač? Tako da ne mogu ispasti. Bez sumnje, kad se netko od ovih vratio u povratku, neki je lopuk morao sjesti za klupu, isisati sav stari lem, zamijenite osigurač i još malo napalite, a zatim vratite POS natrag na policu za sljedeći put kad vjeverica pojede žica.
Kliknite za proširenje...Posljednji put kad sam morala nazvati 911 bila je jedna od najstrašnijih i najužasnijih stvari koje sam ikada doživjela - a čak nisam bila ni ta kojoj je trebala hitna pomoć.
Vraćao sam se kući i vidio kako se auto okreće i prevrće više puta u sredini pa sam stao (zajedno s mnogim drugim ljudima). Znao sam da sam unutar 1 milje od crte između 2 županije i da sam bio na jedinoj glavnoj autocesti koja je bila u tom području. Nitko tko se zaustavio nije bio sasvim siguran gdje smo točnije i bilo je to samo poljoprivredno zemljište koliko smo mogli vidjeti. Dispečeri su tražili da znaju u kojoj se županiji nalazimo i stalno su me prebacivali tamo-amo. Napokon sam dobio šerifovog telefonskog operatera koji nije za hitne slučajeve i koji me je saslušao s mojim problemom i poslao je zamjenika u potragu za mjestom nesreće, ali u premještaju su izgubili moje ime i povratni poziv broj.
Jednom kada su poslali nekoga da pogleda, pronašli su nas za nekoliko minuta, a on se zatim javio na radio i pozvao vatrogasna vozila (za automobil koji se zadimio), hitnu pomoć (za vozača kojeg su slučajni prolaznici pokušavali odvratiti od govora i obeshrabriti da se kreće), i državne patrole (da se pozabavi cestom na kojoj je sada bilo desetak prolaznika zaustavljen).
Kad sam došao kući, dobio sam zemljopisnu širinu/dužinu sa svog videa kamere na kontrolnoj tabli i ispostavilo se da sam bio na mjestu u svojoj pretpostavci gdje sam bio, bili smo u okrug Mislio sam da jesmo (i to sam rekao operateru) i bilo je 0,6 milja od granice okruga (naveo sam manje od 1 milje u svom poziv).
Da moj "pametni" telefon nije prešao u "korisni" način za hitne slučajeve kada sam nazvao hitnu, mogao sam povući Google ili Waze i pronaći gdje smo u krugu od nekoliko metara. Ali umjesto toga ide u beskorisnu stvar gdje blokira sve druge aplikacije i samo drži poseban zaslon za pozive koji ograničava ono što možete pritisnuti (vjerojatno kako biste izbjegli prekid veze).
Kliknite za proširenje...
Godinama nisam razgovarao s tim tehničarima, pa ne mogu reći, ali moj je dojam da su mobilni GPS podaci vrlo loše, ako uopće, integrirani u sustav, pa da, ponovno će vas pitati gdje ste su.
Drugi problem koji imate nije sa samim E911, već sa slanjem pogrešnim ljudima. To se često događa s brzim cestama, jer često se iz geografije uopće ne vidi čiji je to teritorij.
Prvo, samo su tri od sedam Rexx izvornih "filtara" koje smo napisali bila potrebna zbog nedostatka discipline IFMS programera. Četvrti "filtar" — onaj koji sam prvi napisao — izvorno je bio potreban jer su neki nazivi podataka i nazivi odlomaka korišteni u IFMS programima postali rezervirane riječi za nove značajke u COBOL-u II. Ovo je neugodan problem kod dugotrajnog održavanja COBOL programa. Međutim, morao sam proširiti "filtar" kako bih se pozabavio slučajevima zakonski rezerviranih riječi koje se mogu koristiti u neprikladnim kombinacije IBM-ovog OS/VS COBOL parsera—uglavnom "pahuljaste" riječi koje su stavljene u CODASYL COBOL-65 da daju programe manje jezgrovit osjećaj za čitatelje uprave (stavka 1c). IBM je u svom Vodiču za migraciju priznao da je - nedvojbeno zato što je njegov F-razinski kompajler COBOL-65 izgrađen s rekurzivnim silaznim parserom - nisam znao koji nadskup standarda ANSI COBOL-74 prihvaća parser njegovog OS/VS prevoditelja. IBM-ov COBOL II kompajler izgrađen je s modernim parserom i nije prihvaćao nikakve nestandardne "paperice".
Peti i šesti Rexx "filtar"—o kojima sam također napisao—bili su potrebni zbog IBM-ove smetnje kasnih 1960-ih i ranih 1970-ih. IBM je napravio svoj rani disk za ispis SPOOLeri tako da su ispisivali redak po redak (to je bilo prije pojave pisača stranica) brže ako je kontrola reda reda za ispis navedena izravno u samom retku. Stoga je F-razini COBOL-65 dodao naredbu IBM-proširenja koja je ispisivala retke s ANSI FORTRAN kontrolnim znakom ispred. IBM je tada poticao svoje kupce da koriste tu izjavu IBM-proširenja umjesto odgovarajuće CODASYL COBOL izjave, i da koriste verziju u kojoj je FORTRAN znak za kontrolu reda eksplicitno specificirano. Tim izvođača koji je razvio PMS i programeri PMS-a za "održavanje" ovo su ohrabrenje primili k srcu. Stoga, kada izjava o ispisu linija IBM-ovog proširenja nije bila uključena u COBOL II, sovjetski emigrantski PMS programer morao je napisati prilično komplicirani "filtar" u asemblerskom jeziku glavnog računala za proširenje takvih iskaza za ispis redaka u više izraza prihvatljivih za COBOL II sastavljač. Izvođači koji su razvili IFMS—i njegovi FISA programeri za "održavanje"—uglavnom nisam slušao IBM o tome eksplicitno-određeno FORTRAN carriage-control. U vrijeme pretvorbe to više nije bio problem, jer je IBM svoje SPOOLere učinio sofisticiranijima. Pa sam napisao "predfilter" da odredim jesu li iskazi ispisa redaka u određenom COBOL programu potrebni "filtriranje" od jednog iskaza do više iskaza (što bi bili ako bilo koji iskaza za ispis retka eksplicitno navedeno FORTRAN znak za kontrolu reda) ili samo "filtriranje" od jedne naredbe do jedne naredbe, a ja sam napisao "filtar" to bi bilo prikladno da programske izjave za ispis retka zahtijevaju samo jednu naredbu na jednu naredbu "filtriranje".
Rukovodstvo programiranja FISA-e osmislilo je prilično sofisticiranu strategiju u dvije faze za pretvorbu IFMS programa. Oslanjalo se na činjenicu da je standard ANSI COBOL-74 jezik, s kojim je OS/VS kompajler također mogao rukovati, bio je skoro pravi podskup jezika ANSI COBOL-85. Tako je naš tim od tri čovjeka za konverziju prvo pretvorio 2100+ IFMS programa, jedan po jedan, u standardni ANSI COBOL-74. Drugim programerima za "održavanje" rečeno je da, ako modificiraju program koji je pretvoren, morate ga držati u standardu ANSI COBOL-74—i pazite da ne koristite nazive koji su nove rezervirane riječi u COBOL-85. Iznimka je bila to što su mogli nastaviti koristiti jednu konkretnu izjavu IBM-proširenja—tablično vođenu pretvarač znakova za znakove, za koji je definirana zamjena za ANSI COBOL-85 koja nije bila dostupna u OS/VS COBOL kompajler. Kada je došlo vrijeme da tim za konverziju stvarno ponovno kompajlira i ponovno poveže već konvertirane IFMS programe koristeći COBOL II kompilatora, prvo smo pokrenuli svih 2100+ programa kroz sedmi Rexx "filtar"—koji sam ja napisao—kako bismo pretvorili tu zadnju izjavu IBM-proširenja tip.
Osoblje računalnih operacija FISA-e moralo je živjeti s jednim razočarenjem zbog pretvorbe COBOL II, koja se odnosi na problem Excel-macro Kopač ranije spomenuti u ovoj temi. Kasnije verzije IBM-ovog MVS operativnog sustava imale su proširenu arhitekturu, koja je proširila adresibilno RAM područje koje može koristiti program na 2 GB sa 16 MB. Ali da bi se pokrenuo u 32-bitnom načinu adresiranja, "modul za učitavanje", koji se sastoji od programa i svih potprograma koji su zajedno uređivani, morao se u potpunosti sastojati od objektnih modula za ponovno ulazak. Prevodilac COBOL II mogao je ispisati objektne module za ponovni pristup, ali svi programi/podprogrami asemblerskog jezika u modulu za učitavanje morali su biti eksplicitno napisano uvučen. Na početku svog razvojnog rada za FISA-u, osoblje izvođača je napisalo skup potprograma asemblerskog jezika koje su pozivali gotovo svi programi. Izvorni kod za ove potprograme izgubljen je godinama prije tijekom selidbe iz zgrade u zgradu, vjerojatno zato što ni IFMS ni PMS programski menadžment nisu preuzeli vlasništvo nad njima. Kao rezultat moje sugestije tijekom sastanka, jedan od sistemskih programera FISA Operations rastavio je neke potprograme; naravno da su imali ne ponovno je napisan oko 1975. Dakle, budući da nitko nije bio voljan razmotriti ponovni razvoj tih potprograma iz njihovih (nepostojećih) specifikacija, pokretanje stvarno velikih modula opterećenja na FISA-inim glavnim računalima ostalo je nemoguće.
David H.
P.S.: Napisali smo ukupno sedam Rexx filtera—ne pet; šest izvorno i još jedan 1995. Uvijek sam se sjećao ukupno sedam; Jednostavno nisam mogao vidjeti jedno od prvih šest prvih bezbroj puta kad sam ponovo pročitao dopis iz 1994. ;-)
Postoji vrlo realna i vrlo velika šansa da bi novi sustav mogao sadržavati više grešaka nego što ih postojeći sustav trenutno sadrži. Postojeće greške mogu biti velike i male; neki će imati zaobilazna rješenja koja mogu uključivati proceduralne "meke popravke" (to jest - popravak će biti nešto što je učinila osoba, vjerojatno neće biti zapisano, ali se prenosi kad se ljudi zapošljavaju/otpuštaju/unaprijeđuju/itd. - ili ako je zapisano, nalazi se u nekom opskurnom dopisu u ormaru za spise ili registratoru tko-zna-gdje). Postoji opasnost da su neki od popravaka u postojećem kodu napravljeni kako bi se zaobišle pogreške u izvornom operativnom sustavu - ako je taj temeljni operativni sustav imao te greške popravljene (ili nikad nisu ni postojale, ili ima drugačiju implementaciju iste greške) - tada će te popravke za zaobilaženje tih grešaka OS-a vjerojatno iznevjeriti.
Ovo je sve pod pretpostavkom da se izvorni kod za sve ove naslijeđene programe razumije kako oni točno funkcioniraju i međusobno funkcioniraju (ili potencijalno ne funkcioniraju!) - specifikacije za kôd možda se ne podudaraju s kodirati; komentari u kodu možda se ne podudaraju s kodom koji se komentira - ili sa specifikacijama. Kod se mora pretpostaviti kao "ispravna" verzija - pa čak i ako je očito netočna, odlučiti da se promijeni da bude ispravan (bez obzira da li specifikacija, ili komentar, ili na nešto novo) - može pokvariti druge stvari o kojima se nije razmišljalo izvan područja "pokvarenog" koda trčanje. Naknadni ili silazni učinci, koji su u izvornom kodu možda bili ublaženi u drugim područjima sustava (na primjer, možda drugi program preuzima izlaz i "ispravlja" to jer nije bilo u redu - ali ako ste to popravili u prvom programu, ne shvaćajući da drugi program to popravlja - a možda čak ni ne znate gdje je taj drugi program je; možda čak i nije dio glavnog sustava, već u drugom dijelu vlade ili izvan njega, itd.).
Ovo se stalno događa u mnogo "mlađim" softverskim sustavima - pretpostavljam da stariji sustavi mogu imati takve nedosljednosti u barem istoj količini, ako ne i više. Ažuriranje koda ili njegova implementacija u neki drugi programski jezik (oh - skoro sam zaboravio - možda je dio koda napisan da bi se zaobišle greške u kompajler također) može stvoriti sustav koji je nestabilan, ili još gore - on je stabilan, ali podaci koje generira, s obzirom na određeno stanje ili stanja, izlaze podaci koji su netočni (možda samo na način da nisu vidljivi na prvi pogled, ali bi se mogli pojaviti kao grudva snijega dok prolaze kroz druge sustave - razbijajući ih). Postoji mogućnost problema s pogrešnim izračunom (posebno u slučaju porezne uprave) koji mogu uzrokovati porezne i proračunske probleme za ljudi, vlada, Porezna uprava itd. - zato što se zaokruživanje ili nešto jednostavno poput toga ne radi na isti način kao stari sustav ili zato što zbog složene prirode izvornog sustava, postoji nešto što je propušteno ili nije identificirano da se događa zbog pojavnog svojstva ili tako nešto. Zamislite nešto tako čudno kao što je THERAC-25 - na veliko (iako ljude možda neće koštati života - nadamo se).
Ova mogućnost ne bi trebala uzrokovati da ljudi ne ažuriraju te sustave - ali bi svima trebala dati pauzu i odvojiti vrijeme - dugo vremena - temeljito ispitati i razumjeti kako ovi sustavi rade i međusobno funkcioniraju prije nego što se ažuriraju ili promijene drastično. Nadalje, te se promjene moraju uvoditi polagano i pažljivo, s mnogo testiranja prije nego što se počnu "živo", a zatim pažljivo nadzirati određeno vremensko razdoblje (u idealnom slučaju, možete čak pokrenuti stari i novi sustav paralelno i provjeriti izlaz obaju jednak).