Dai programmi batch a quelli interattivi a quelli Web

L’ elaborazione meccanografica dei dati parte dalla modalità batch, cioè a blocchi, si evolve poi nell’ elaborazione interattiva tramite terminali ed arriva alle attuali elaborazioni WEB.

Ai giorni nostri, in un normale ambiente informatico sono presenti tutte e tre le metodologie. Infatti ad esempio l’ emissione delle fatture con periodicità mensile mentre una volta era una necessità dettata da una tecnologia non ancora sviluppata, oggi la stessa soluzione può essere dettata da esigenze applicative e non più tecnologiche, basti pensare alle fatture relative alle utenze domestiche di energia elettrica, telefonia ecc …  

 

L’ elaborazione interattiva

Negli anni settanta furono introdotti i primi terminali (3270) il cui utilizzo rispondeva a tre precise esigenze:

1)      Immissione dei dati con immediata segnalazione degli errori. Questo permetteva un più rapido processo di correzione.

2)      Più semplice accesso ai dati da parte dei vari settori aziendali che non erano più costretti a lavorare  su voluminosi tabulati nei quali andare a cercare l’ informazione desiderata, ma la potevano ora ottenere in maniera molto più diretta e semplice.

3)      Informazioni molto più aggiornate di quelle ottenibili dai tabulati. Questi ultimi infatti venivano generati settimanalmente o mensilmente ed il dato in essi presente era spesso ormai superato. Con i terminali invece era possibile accedere ai dati in “tempo reale” come si diceva a quel tempo.

 

L’ interfaccia hardware e software

L’ introduzione dei terminali evidentemente comportava nuovi aspetti da tenere in considerazione sia come interfacciamento hardware che software che applicativo, il tutto però su un sistema operativo nato quando i terminali ancora non c’ erano e che quindi non poteva certo supportarli.

Allo scopo furono sviluppati i “Monitor TP” (TP sta per Tele Processing) che erano dei grossi programmi di sistema che si curavano dell’ interfacciamento hardware e software dei programmi applicativi con i terminali (locali o remoti). Degli esempi di questi programmi di sistema erano il CICS per i grossi sistemi IBM o il CCP per i medi sistemi IBM (S/3 mod 8,10,12,15).

L’ utilizzo dei Monitor TP introduceva però dei vincoli che, anche per altre motivazioni, di fatto imponevano che l’ inserimento di nuovi programmi o terminali, o la modifica di programmi già esistenti richiedeva la chiusura ed il riavvio del Monitor TP e quindi anche di tutte la applicazioni interattive. Considerato che questo ovviamente interessava anche il test dei programmi, si comprende come fosse molto laborioso lo sviluppo del software in ambiente interattivo. Per alcune applicazioni come ad esempio la vendita al banco, per le quali non era ammissibile nessuna interruzione, si è arrivati a poter lavorare sullo sviluppo software solo all’ intervallo di pranzo o dopo l’ orario normale di lavoro.

Fu quindi accolto come una vera liberazione l’ avvento del S/34 IBM che aveva integrata nel sistema operativo la gestione dei terminali (5250). Con tale elaboratore non sussistevano i gravi vincoli sopra menzionati.

 

L’ accesso al data base per tempi di risposta ragionevoli

Un altro aspetto importante nella programmazione interattiva era la necessità di avere tempi di risposta ragionevoli. Se ad esempio si richiedeva l’ estratto conto di un cliente, era necessario fornire la videata di risposta nel giro di pochi secondi. Viceversa in un’ elaborazione batch la generazione del tabulato settimanale degli estratti conto poteva anche impiegare ore ed un’ ora in più o in meno era del tutto trascurabile per qualcosa che doveva durare una settimana.

La risposta a questa esigenza era un’ opportuna gestione del data base che, nell’ esempio in questione, permettesse di accedere agli archivi (anagrafici e di movimento) per codice cliente.

Il S/34 con la sua sola gestione degli archivi ad indici rispondeva solo in parte a questa esigenza. Vennero quindi ideate tecniche di accesso che tramite catene di puntatori (numero relativo di record) permettevano rapidi accessi al data base, a fronte però di un certo impegno in termini di programmazione.

Un passo avanti fu fatto con il S/36 nel quale venne introdotta  la possibilità di avere indici alternativi, anche con più chiavi, per un file di dati.

Ancor meglio con il S/38 (antesignano dell’ AS/400 e dei Power System con O.S. IBM i) che fu il primo elaboratore dotato di data base relazionale integrato e microcodificato nel sistema operativo (CPF).

Attualmente i moderni sistemi Power System  con O.S. IBM i sono dotati di data base DB2/400 che è l’ attuale edizione del data base relazionale nato con il S/38.  

 

 

 

La riservatezza e la sicurezza degli accessi

Con l’ introduzione dei terminali locali e remoti nacque un nuovo problema: quello della riservatezza e della sicurezza degli accessi al sistema informatico. Infatti prima dell’ avvento dei terminale era il personale del centro meccanografico ad avere accesso al sistema e quindi il problema non sussisteva. Viceversa con l’ introduzione dei terminali l’ accesso al sistema veniva decentrato e non si aveva la sicurezza che davanti al terminale ad operare ci fosse la persona giusta. Questo tanto più quanto più numerosi erano i terminali. Proprio per questo già dal S/34 fu introdotto il concetto di utente e password, che fu poi sempre più sviluppato fino al Power System che ha tutta una serie di strumenti sia per controllare gli accessi che per definire le operazioni autorizzate per ogni singolo oggetto e per ogni singolo utente e questo anche per l’ ambiente WEB di cui si parlerà più avanti. 

L’ elaborazione batch

In tale modalità i dati da elaborare venivano preparati a priori partendo da documenti cartacei e raggruppati su opportuno supporto meccanografico (schede perforate, minidischi, nastri, archivi su disco). Successivamente avveniva la loro  elaborazione che dava luogo all’ aggiornamento di archivi, alla generazione di documenti (fatture, ordini di acquisto ecc..) e liste e tabulati che potevano essere usati nella gestione aziendale (per es. estratti conto).

L’ elaborazione era divisa in due fasi:

1)      Controllo dei dati di input

2)      Elaborazione dei dati

A secondo dei casi la fase 2) si faceva eseguire sui soli dati di input corretti, oppure veniva eseguita solo se tutti i dati di input erano corretti. In entrambi i casi, in presenza di dati errati questi dovevano essere corretti e riproposti per una nuova elaborazione.

Sostanzialmente quindi le fasi 1) e 2) sopra menzionate venivano ripetute più volte fino a che non ci fosse nessun errore sui dati di input e quindi potessero essere tutti elaborati..

E’ evidente  come la correzione dei dati di input fosse particolarmente laboriosa perché comportava la ripresa dalla massa dei documenti cartacei di quello relativo al movimento in errore e l’ individuazione se il problema fosse dovuto ad un errore di battitura a avesse altra motivazione comunque da risolvere. Proprio per limitare la laboriosità della correzione degli errori si usava spesso affiancare  alla funzione di immissione quella della verifica, che in pratica voleva dire digitare due volte i dati da immettere e controllare (automaticamente) che la seconda immissione fosse uguale alla prima. In tal modo si eliminavano in modo pressocchè completo gli errori di battitura poiché era statisticamente estremamente improbabile che nelle due digitazioni di verificasse lo stesso errore di battitura. E’ evidente come però rimanevano scoperti altri tipi di errore come quello di lettura, legato al fatto che i documenti cartacei erano spesso compilati a mano anche con calligrafia non troppo chiara.

Web modalità realizzative – Programmazione PHP

Modalità realizzative

Sul sistema AS/400 ( successivamente chiamato iSeries, poi System i ed ora Power System con Sistema Operativo IBM i) la scrittura di programmi e applicazioni WEB è possibile utilizzando tre diverse metodologie:

In questo ultimo articolo parleremo di: Programmazione PHP.

     La programmazione PHP è un linguaggio di scripting interpretato che contiene all’ interno della pagina HTML le specifiche che governano la logica elaborativa e di presentazione dell’ applicazione. E’ una programmazione multipiattaforma ed in quanto tale è stata approntata anche per il sistema AS/400.

Il concetto di fondo è analogo a quella del punto 2) (Programmi ILE). Infatti anche nel caso ILE il programma costruisce la pagina HTML; nel caso PHP lo fa a partire dalla pagina HTML che contiene le specifiche PHP, mentre la programmazione ILE parte da una (o più) pagine HTML prototipo. In un’ ottica multipiattaforma la programmazione PHP è un’ ottimo strumento, ma in ambiente AS/400 la sua logica di fondo trova una migliore e più nativa realizzazione nella programmazione ILE. Infatti avere la logica di presentazione separata  da quella elaborativa è sicuramente un vantaggio che permette di intervenire sull’ una senza avere fastidiose interferenze sull’ altra. Inoltre con ILE l’ accesso al data base avviene  in forma nativa con “navigazione” sulle vie di accesso, mentre con PHP l’ accesso avviene con statement SQL e quindi in forma a blocchi meno performante.

 

 

leggi anche:

  •  

    Web modalità realizzative – Java con WAS

    Modalità realizzative

    Sul sistema AS/400 ( successivamente chiamato iSeries, poi System i ed ora Power System con Sistema Operativo IBM i) la scrittura di programmi e applicazioni WEB è possibile utilizzando tre diverse metodologie.

    In questo primo articolo parleremo di:  Java con WAS (Websphere Application Server).

          Con tale metodologia le applicazioni vengono scritte in Java e girano sotto WAS (Websphere Application Server) che può considerarsi un grosso programma di gestione e amministrazione degli accessi ad internet che si incarica di dialogare con l’ HTTP Server, analogamente a quanto avveniva negli anni 70 con il “Monitor TP” per i primi terminali 3270. L’ accesso al data base dell’ AS/400 avviene tramite driver JDBC e quindi tramite richieste SQL. Questo è notoriamente un accesso di tipo batch, cioè a “blocchi”, che non permette “navigazione” sulle vie di accesso. Ad esempio se si deve generare la fattura relativa ad un ordine cliente lo statement SQL richiede tutti i record dell’ archivio righe d’ ordine relative al numero d’ ordine del cliente; il programma dovrà memorizzare i dati dei record ritornati in opportune schiere e poi elaborare le schiere in sequenza, elemento per elemento. In RPG un caso del genere sarebbe gestito con SETLL e loop di READE nel quale per ogni ciclo viene elaborata una riga d’ ordine. 

    Considerazione. Il fatto che i programmi scritti in Java debbano girare all’ interno del Web Application Server, analogamente a quanto avveniva negli anni 70 con il “Monitor TP” ripropone alcune delle problematiche viste a quel riguardo. In particolare molte modifiche ai programmi vanno resa “attive” chiudendo e riavviando l’ “applicazione” WAS corrispondente. Questo comporta che o si fanno fermare gli utenti dell’ applicazione o le modifiche vanno rese attive a fine giornata. Questo rallenta molto la produttività e la facilità di manutenzione del software, includendo in esso anche i semplici aspetti grafici.

    E’ da aggiungere che solo alcune funzionalità del sistema operativo sono disponibili e questo solo se si utilizza il prodotto software Toolbox for Java.

     

    leggi anche:

  • Pubblicato su Articoli. Tag: , , . 2 Comments »