Newsgroup: it.comp.appl.access
Titolo: ACCESS Vs COBOL (Spero non OT)

Ciao a tutti,
Sperando di non essere OT, mi piacerebbe confrontarmi con qualcuno su
questo argomento.
IMHO, tra i due ambienti di sviluppo non c'è proprio paragone: Access
è troppo superiore. Quando mi trovo a dover lavorare con un programma
scritto in cobol mi sembra di fare un salto indietro nel tempo
(interfacce ORRIBILI, intuitività nulla, macchinosità incredibile) e
mi sento male al solo pensiero di dovermi studiare l'utilizzo dei
tasti funzione, senza dei quali non si può far nulla.
Mi chiedo... ma perchè ancora tanti programmi vengono sviluppati
ancora in questo ambiente. Ok, è leggero, ma con i pc attuali che
bisogno c'è di utilizzare un linguaggio così (a me pare) obsoleto?
Ma c'è di più, ed è questo il motivo del mio intervento: Ogni volta
che mi confronto con un programmatore di COBOL ho l'impressione di
parlare con qualcuno che possiede VERITA' ASSOLUTE (una di queste, ad
esempio, è che tutto ciò che attiene a windows è sia una schifezza) e
la discussione finisce inevitabilmente in "rissa".
Opinioni a riguardo...




Opinioni a riguardo...
[Risposta]
Beh, io purtroppo (per ragioni d'età non più verdissima) ho lavorato
parecchi anni in Cobol in ambiente Unix: capisco il tuo punto di vista ma,
tutto sommato, anche il suo  ;-)
E' ovvio che non si pone il confronto tra un'applicazione base carattere e
una visuale: un abisso di flessibilità ed ergonomia, tutto a vantaggio della
seconda.
Peraltro il confronto si protrarrà per poco tempo ancora: in fondo solo il
mondo AS/400 è ancora solidamente legato al mondo carattere (forse ancora
più RPG che Cobol) ... e le nuove leve di oggi non sanno nemmeno cosa siano
quei linguaggi.
Però su un punto hanno ragione i vecchi Cobolari: saranno stati programmi
limitati e spartani fin che vuoi ma funzionavano  ;-)
Il problema di Microsoft è che essendo una multinazionale che prospera
principalmente sulla vendita è costretta a sfornare con logica industriale
ogni due/tre anni una nuova versione di qualcosa.
E le novità (vere o di facciata) debbono essere molte per convincere il
mercato a comprare.
La conseguenza è l'entropia assoluta: dopo cinque anni di "beta" test di win
XP, dopo service pack e aggiornamenti di ogni genere, quando finalmente la
cosa funzionicchia .... TAAAM, ti sbatte in mezzo ai denti il nuovo VISTA
;-)
Un discorso analogo si può far per tutto il resto: Office, SQL Server e
quant'altro.
Sarebbe diverso se ogni copia di un prodotto venduto avesse una (congrua)
assistenza annuale: in tal caso i prodotti sarebbero evoluti con grande cura
e attenzione, privilegiando l'affidabilità all'evoluzione da baraccone.
E in fondo il successo dei sistemi IBM nasce da una filosofia di questo
genere.
Certo, loro sono stati fin troppo conservatori, ma qui il discorso
s'allargherebbe!
Saluti.

 wrote in message
news:1174163519.1...@p15g2000hsd.googlegroups.com

Ciao, mi permetto di fare qualche considerazione (sia ben chiaro senza
alcuna polemica),
visto e considerato che un pò di anni li ho anch'io!! Sob :-(
Premetto che sono anni che non programmo in Cobol ...
Un pò di storia:
Gli ambienti HW/SW su cui girano o giravano i programmi COBOL sono
sostanzialmente IBM, vale a dire:
DOS/VSE (non quello della Microsoft ovviamente)
MVS/TSO (bastavano 2M per far lavorare parecchie decine di utenti!)
VM/370 (Ambiente a macchine virtuali con ben  360K di ram simulata!)
su hardware del tipo 4041, 4341, 3090 proprietario della IBM!
Questi ambienti hanno il CICS (un TP-monitor) che permettere ai
programmi COBOL di essere interfacciati con un operatore, altrimenti
erano/sono programmi tipicamente BATCH.
Esistevano anche ambienti alternativi ad IBM come il VAX/VMS della
Digital Equipment(di cui esiste ancora la versione del s.o. OpenVMS che
non so ora come si chiami,
aquisita prima da Tandem, poi da Compaq ed infine da HP )su cui
girava/gira
il COBOL ed anche qui c'era un programma di interfacciamento a maschere
detto FMS (Form Management System) se ben ricordo.
Le aziende su cui girano/giravano le procedure COBOL sono tipicamente:
bancario,  assicurativo e grosse aziende (vedi Fiat)
Detto ciò basti pensare:
1) che gli investimenti fatti per lo sviluppo di questi programmi sono
stati ingenti e sono durati parecchi anni! (pensi allì'anno 2000);
2) la sicurezza è elevatissima per via del fatto che sia l'HW che il SW
di base (S.O:, Database, tool di sviluppo erano forniti dalla casa
madre, vedi IBM/Digital!)
3) la probabilità di beccare un visus è molto bassa per via della
conoscenza che di questi ambienti si ha! Cioè lo smanettone che vuole
fare un virus ha più difficoltà a procurarsi una macchina IBM/Digital e
poi voglio vedere quanti anni ci deve mettere per studiare in profondità
le sia l'HW che il SW!
4) oltre al COBOL ci sono delle procedure scritte anche in assembler e
che sicuramente svolgono il loro lavoro egregiamente; aggiungiamo pure
la considerazione che molta gente che ha sviluppato questo software
probabilmente è già arrivata alla pensione (e qui si apriebbe un
dibattito: che fare?)
Alcune considerazioni tecniche:
a) il COBOL ha 4 parti per definire cio che gli serve e tutto è fatto
in modo ordinato, per cui la manutenzione è meno soggetta
ad stili di programmazione personali che non linguaggi come il "C";
ad esempio c'è una sezione in cui si dichiara qual'è l'input/output, i
dati e la
parte relativa al codice (sto cercando di ricordare!)
b) il tempo di apprendimento, almeno per me, sono inferiori che non
quelli, ad esempio, di DOT NET per essere operativi presso un cliente; 
Escludo da questo Access che è sicuramente più facile da apprendere!
c) una cosa che qualcuno forse ricorda è ad esempio l'istruzione
REDEFINES che permette di fare delle cose che con i linguaggi moderni è
più faticoso!
Prendiamo ad esempio una data = 18/03/2007
se voglio l'anno il mese o il giorno in formato caratteri devo
convertire da data o meglio parte di essa in una stringa
In COBOL si faceva una cosa del genere:
01 DATA     
REDEFINES DATA
  02 GG      9(2)
  02 Filler  X(1)
  02 MM      9(2)
  02 Filler  X(1)
  02 AAAA    9(2)
oppure una cosa del genere 
01 DATA     
REDEFINES DATA
  02 GG      X(2)
  02 Filler  X(1)
  02 MM      X(2)
  02 Filler  X(1)
  02 AAAA    X(2)
(dove X sta per carattere esadecimale e 9 per cifra decimale)
ed una volta assegnata DATA = 01/03/2007
e vi garantisco che era molto comodo (le conversioni o il casting erano
automatiche)
d) esisteva la possibilità di interfacciarsi con procedure scritte in
altri linguaggi
e) chiaramente è utilizzato soprattuto in ambiente amministrativo, anche
se personalmente l'ho utilizzato anche in ambito industriale (....
voluntas tua)
Per Concludere:
1) tutti i "casini" che ci sono oggi NON ci SONO MAI STATI! 
Ve lo immaginate se ci fossero errori sui conti correnti delle banche?
2) questi linguaggi (COBOL/FORTRAN) erano stai dichiarati "quasi morti"
già negli anni ottanta :-)
3) E' chiaro che dal punto di vista dell'interfaccia grafica ora è tutto
più facile. ma il cuore delle procedure deve essere affidabile e quindi
perchè rischiare? basta interfacciarsi ai programmi COBOL!
4) Esistono anche dei compilatori moderni (mi sembra ad es. AccuCobol)
per poter continuare ad utilizzare il Cobol sui PC!
5) E' chiaro che pian pian queste procedure saranno sostituite, ma credo
solo dopo che le nuove diano prova di affidabilità pari se non superiore
a quelle COBOL.
Ciao e scusate per la lunghezza del testo
Roberto
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 
Spero di averti dissipato i tuoi dubbi.
Alla prossima.
	MAX

 REDEFINES DATA
se ti pesca un esperto di cobol ti fa nero ;<)
[cut]
p.s PIC X e' un alfanumerico
     PIC 9 e' un numerico "zoned"
il tipo esadecimale non c'era. Mi sembra sia apparso con il cobol-2. 
Quest'ultimo spuntato piu' o meno una ventina di anni fa e con il cobol 
sui pc (Microfocus e CA-Realia, principalmente, che contenevano gli 
emulatori per i sottosistemi CICS e IMS dei "mainframes" IBM)
-- 
ac
y-1=x