četrtek, 2. januar 2003

Opis komunikacijskih transakcij [10]

UVOD


Za distribucijo nalogov plačilnega prometa sem uporabil sistem, ki je bil razvit leta 1985 in bazira na distribuciji on line aplikacij. Tem aplikacijam nudi sistemsko podporo produkt, ki je znan pod imenom CICS (Customer Information Control System). Tak način pošiljanja podatkov med  različnimi velikimi računalniki in osebnimi računalniki predstavlja v svetu strateško razvojno filozofijo na bazi CICS aplikacij.

Distribucija nalogov plačilnega prometa poteka v 3 fazah:

  1. prenos podatkov z osebnega računalnika - PC na glavni računalnik,
  2. distribucija in
  3. povratna informacija.

Prenos s PC na glavni računalnik


Podatki so bili preneseni iz poštnih predalov na osebni računalnik. Z osebnega računalnika prenesemo podatke na glavni računalnik v Ljubljani s send ukazom v 3270 okolju, ki na strani glavnega računalnika starta CICS aplikacijo. Le-ta prenese vse podatke virmanskega naloga (pakete) v skupno zbirno datoteko, ki se prazni ob koncu obdelave za tekoči datum obdelave. Informacije o prenesenih podatkih se hkrati beležijo tudi v kontrolno datoteko, ki jo uporabljam za ponovitev (restart) distribucije nalogov plačilnega prometa, kadar je to potrebno zaradi tehničnih problemov (izpad povezave med računalniki).

Distribucija


Distribucija nalogov plačilnega prometa bazira na SNA LU6.2 konverzaciji med dvema ali več CICS sistemi na oddaljenih lokacijah (Celje in Kranj). Ko je prenos podatkov z osebnega računalnika končan, CICS zazna spremembo v zbirni datoteki in avtomatsko starta proces distribucije ne glede na število nalogov.

Proces distribucije je podprt s tremi CICS aplikacijami. Prva aplikacija zbere podatke po sedežih obremenitve npr. SDK Celje (minusni stavek) s pripadajočimi računi v dobro (plusni stavki) in formira novo logično celoto v obliki, ki se lahko vključi v obdelavo nalogov plačilnega prometa. Oddaljeni (remote) računalnik (sedež) jih vidi kot prispele avize v breme računa v minusnem stavku. V tej fazi aplikacija preda kontrolo naslednjemu programu in čaka na povratno informacijo (sporočilo) od tega programa. Ta program avtomatsko vzpostavi zvezo s CICS sistemom na oddaljeni lokaciji in prenese podatke, ki jih je pripravila prva aplikacija v datoteko na oddaljeni lokaciji. Po uspešnem prenosu (povezavo oziroma prenos aplikacija sama inicira vsakih 30 sekund, če s komunikacijami ni kaj v redu) ta program starta poseben program na oddaljeni lokaciji, ki sprejete podatke vključi (ažurira) v plačilni promet (prometna datoteka).

Zatem se formira sporočilo (back-end) sedežu iniciative (Ljubljana). To sporočilo se na sedežu iniciative zabeleži v datoteko sporočil, ki je last tega programa (message.log.file). Program preda kontrolo prvi aplikaciji na sedežu iniciative, ki je čakala na sporočilo z oddaljenega računalnika. Prva aplikacija sedaj formira minusni stavek s sedežem odobritve (npr. SDK Kranj) in pripadajočimi računi v dobro (plusni stavek) in zopet formira logično celoto, ki se lahko vključi na oddaljeni lokaciji v plačilni promet in jih le-ta vidi kot prispele avize v dobro računa v minusnem stavku. Iz številke sedeža v žiro računu minusnega stavka program zazna, na katero oddaljeno lokacijo (sedež SDK) mora poslati novo formirano logično celoto (lahko pa tudi pošlje domačemu sedežu na katerem teče aplikacija. V tej fazi se zopet starta program, ki avtomatsko vzpostavi zvezo s CICS sistemom oddaljenega računalnika in prenese pripravljene podatke na oddaljeni računalnik v datoteko VSAM organizacije.

Ko je prenesen zadnji stavek (kar je pomembno), program zopet starta na oddaljenem računalniku poseben program, ki vključi sprejete podatke v plačilni promet. Potem formira sporočilo, da so bili nalogi obdelani npr. v Kranju v dobro računa iz minusnega stavka, kot povratno informacijo "back-end transaction" za sedež iniciative (Ljubljana), ki zabeleži v kontrolno datoteko, da so bili nalogi obdelani v celoti (v breme in v dobro na pripadajočih sedežih) ter jih označi kot obdelane. Naslednji iniciran prenos podatkov z osebnega računalnika piše podatke v zbirno datoteko od tu dalje, od koder starta tudi naslednja distribucija. Podatki na sedežu iniciative se ne brišejo tekom delovnega dne in se na koncu delovnega dne prepišejo na magnetni trak za vsak dan v tednu, od koder se lahko restavrirajo za morebitno reševanje reklamacij oziroma nejasnosti.

Povratna informacija


Na podlagi sporočil v datotekah na sedežu iniciative se formira sporočilo, ki se prenese na osebni računalnik za uporabnika, ko se starta na osebnem računalniku ukaz receive v okolju 3270. To sporočilo se potem prenese v uporabnikov (pravna oseba) poštni predal.

OLISS je treba še dogradi za primer, ko ne bo mogoča povezava z določenim sedežem SDK. V ta namen bi pripravljene podatke pisali v "VSAM queue file", kjer bi bili na listi čakanja  in bi se vključili (obdelali) na isti način takoj, ko bi bila povezava z računalniki mogoča in obdelava nalogov plačilnega prometa v prvi fazi (vnos in kontrola). Kadar pa to ne bi bilo mogoče, bi se ob koncu delovnega dne prepisali na prenosljiv magnetni medij (trak ali disketa) in poslali po pošti.

Za take primere ima operater na sistemu možnost nasilne prekinitve sicer avtomatske vzpostavitve komunikacije "CICS to CICS". To bi bilo v primeru, da sedež iniciative samodejno začne pošiljati podatke v večernih urah, ker je bil prej računalnik v okvari, na sedežu kamor so podatki namenjeni pa je obdelava že v zaključni fazi (konec vnosa in kontrole nalogov plačilnega prometa).

Prav tako bi morali še dograditi ponovno pošiljanje že poslanega materiala v primeru, da določen sedež SDK začne tekom dneva z včitavanjem materiala od začetka, oziroma vrne določeno stanje prometa (TD), kjer še ni zajet poslani material zaradi tehničnih problemov. Aplikacije so že sedaj tako projektirane, da se iste logične celote ne morejo obdelati dvakrat za isti datum obdelave in so s tega vidika varne (ne pride do dvojnih ažuriranj).

Gornje aplikacije lahko tudi prilagodimo za pošiljanje materiala podružnicam SDK, ki so opremljene z UNISYS računalniki in to bi pošiljali po ustaljeni poti preko "punch queue-a" ali pa bi morali na strani Unisysa instalirati produkt, ki simulira CICS sistem. Takšna povezava bi delovala kot "CICS-TO-IMS/VS ISC" aplikacija (Information Management System/Virtual Storage Inter System Communication).

Za izvedbo zgoraj navedenega projekta je potrebno detajlno znanje CICS-a in VTAM-a, saj je projekt vezan na veliko sistemsko podporo, torej je potrebno poleg aplikativnega dela tudi precej sistemskega programiranja. Na podružnicah (Ljubljana, Celje, Maribor, Kranj) poteka projekt na obstoječi IBM računalniški opremi, že vzpostavljenem sistemskem programju in komunikacijah tako, da s tega vidika ni potrebnih nobenih dodatnih stroškov pri zgoraj opisanem poteku dela na centralnih računalnikih.

Ni komentarjev:

Objavite komentar