Newsgroup: it.comp.retrocomputing
Titolo: 50 anni e non li dimostra

http://www.guardian.co.uk/technology/2009/apr/09/cobol-internet-programming
Lunga vita al Cobol! :-)
G.

 G.
Ciao Gerry,
IMS resiste, il Cobol pure (alla grande direi).
Che si dice del PL/1 che tanto mi piaceva?
Mauro

 Che si dice del PL/1 che tanto mi piaceva?
Il Cobol è immarcescibile e IMS è semplicemente mitologico! :-)
La differenza tra IMS e Cobol da una parte e PL/I dall'altra è che i primi due
hanno avuto enorme successo e si sono diffusi tantissimo, il secondo molto
meno, nonostante sia un buon linguaggio e a suo tempo sia stato molto spinto
da IBM. Pare che i primi compilatori PL/I fossero troppo pesanti per le
macchine dell'epoca e che avessero prestazioni molto scarse, quindi non si
diffusero abbastanza in un mondo già dominato da Cobol, Fortran (e Algol).
Comunque, proprio di recente mi pare di aver letto (forse su comp.os.vms) un
messaggio in cui si cercava la disponibilità di un analista PL/I e tempo fa
vidi un annuncio in cui si offriva lavoro a programmatori IMS, PL/I e DL/I!
Personalmente però il PL/I non mi attira molto, preferisco Fortran e Cobol.
Come mai a te invece piace(va) tanto? Parliamone... :-)
Ciao,
G.


Perchè arrivando fresco fresco dall'università, dopoaver usato Pascal,
C e DB relazionali (Fortran studiato alle superiori), iniziare a
lavorare in Cobol DL/1 è stato una tortura... il Cobol 2 non si poteva
usare e quindi gli unici voli di fantasia li facevo con il PL/1.
Ti dirò che, alla lunga, ho iniziato anche ad apprezzarlo (ma solo
dopo che è arrivato il DB2).
Mauro

 Personalmente però il PL/I non mi attira molto, preferisco Fortran e Cobol.
scusa, non per fare polemica, ma per curiosità, potresti spiegare questa 
  preferenza "lunisolare" ?
Saluti,
Dott. Piergiorgio.

 usare e quindi gli unici voli di fantasia li facevo con il PL/1.
Cosa intendi dicendo che il Cobol 2 non si poteva usare? Il Cobol mi risulta
che sia sempre lui, al massimo si aggiunge un pre-processore se nel sorgente
ci sono degli statement tipo EXEC DLI, EXEC SQL o EXEC CICS, no? Mi pare che
il Cobol per MVS di suo supporti solo i dataset VSAM & co., giusto?
Comunque, oltre al Cobol, che ne dici del DL/I e di IMS? I DB gerarchici mi
hanno sempre affascinato tantissimo, peccato che si trovino davvero così poche
informazioni in giro e soprattutto che non ci sia nessun DB gerarchico per VMS
o Linux (tanto per dirne due), giusto per fare qualche esperimento...
Ciao,
G.

   preferenza "lunisolare" ?
Mah, non è una cosa ben definita, infatti non ho detto che non mi piace, ma
che non mi attira. Non ho mai trafficato molto con il PL/I, però tempo fa mi
misi in testa di capirci qualcosa di più e iniziai a leggere dei manuali
online che mi hanno sempre lasciato una senzazione tipo: "L'ho già visto da
qualche parte; ci somiglia, ma non è; ci somiglia, ma è più brutto".
Sarà forse che in Cobol ci ho lavorato abbastanza, sarà che in Fortran ci ho
fatto vari esperimenti (è uno dei linguaggi più utilizzati nei programmi un
po' "furbi" per VMS: occupa il posto che che nel mondo Unix è del C), sarà
un'antipatia inspiegabile, vero è che il PL/I non riesco a "capirlo". :-)
Opinioni? Tu conosci il PL/I?
Ciao,
G.


Ma l'implementazione del DL/1 era scomodissima, era necessario
compilare ogni volta il path per arrivare ai dati (l'ACB e relativa
PSB se non ricordo male) e quindi era utilizzabile solo dagli
informatici; Pensa alla libertà dell'SQL che ti permette di accedere,
unire, filtrare etc senza nessun operazione preliminare ed alla
semplicità dell'algebra relazionale.... devo dirti che mi sono
innamorato subito dell'SQL in tutte le sue implementazioni e che non
rimpiango minimamente il DL/1.
Il grosso vantaggio dell'IMS nei confronti del CICS è che ogni
applicazione gira in uno spazio di memoria separato e quindi, se ci
sono problemi, fermo la singola applicazione senza infastidire le
altre. Nel CICS (almeno fino a quando ci ho lavorato io) tutte le
applicazioni condividono lo stesso spazio e quindi, se una
applicazione ha problemi, devo fermare tutto. Questo è il motivo per
cui normalmente nelle aziende c'è un solo IMS e decine di CICS il che
significa che, dal punto di vista sistemistico, l'IMS ti rende la vita
più facile anche se è un'applicazione pesantissima.
E' comunque possibile (potenza del relazionale) implementare una
gestione di dati gerarchica con un DB relazionale:
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
Ciao.
Mauro

ger...@no.spam.mail.com
 ha scritto:

beh, per "lunisolare" mi riferivo a Fortran e cobol, due linguaggi ben 
differenti per due ben distinte tipologie di developement (al tempo dei 
grandi mainframe, midrange e minicomputers, il development era su tre 
linee distinte: il fortran per le applicazioni scientifiche, il cobol 
per quelle commerciali/gestionali ed l' assembler per il sistema)
Ho sottomano un PL/I per CP/M (ed anche il PL/M Kildall/intel) quindi 
prima o poi ci "giocherello" ma non ho un idea definita su di esso.
Tra SIMH ed il suo fork CP/M ed gli archivi di Kossow una idea 
abbastanza vaga degli ambienti fino al 1980 presumo di averla....
Saluti,
Dott. Piergiorgio.

 prima o poi ci "giocherello" ma non ho un idea definita su di esso.
Ecco, magari dacci uno sguardo. A me è sempre sembrato un ibrido. Mi
piacerebbe leggere l'opinione di qualcun'altro. :-)
Ciao,
G.

 
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
Sì, ci sono varie pagine sull'argomento, ma a me interessa proprio il DB
gerarchico nelle sue peculiarità, molto meno il TP monitor. Conoscevo la
pagina che citi e ne avevo trovate anche altre.
Quel che più mi interessa sono le implementazioni del "problema database" al
di fuori della classica ottica relazionale e/o SQL. Mi affascinano tantissimo
i vari GU, GN, GNP, GNR e compagnia del DL/I, così come mi affascina molto il
linguaggio RDO di RDB, cioè il linguaggio di interrogazione del DBMS Digital
per VMS che fu poi venduto alla Oracle nei primi anni 90 e che le permise di
diventare quel che è ora. Anche se pochi lo sanno, Oracle vende DUE differenti
DBMS: uno è l'Oracle Database che tutti conoscono, l'altro è Oracle RDB, cioè
il diretto discendente di VAX/RDB del quale conserva ancora tutte le
caratteristiche, compresa l'interfaccia RDO (oltre a quella SQL).
Un po' di esempi di RDO presi dall'help online:
1. FOR E IN EMPLOYEES
     SORTED BY DESCENDING E.BIRTH_DATE,
               ASCENDING E.LAST_NAME
       PRINT E.*
   END_FOR
2. FOR SH IN SALARY_HISTORY
     WITH SH.EMPLOYEE_ID = "00184"
     AND SH.SALARY_END MISSING
       MODIFY SH USING
         SH.SALARY_AMOUNT = ( SH.SALARY_AMOUNT + ( 1000 * 0.025 ) )
       END_MODIFY
   END_FOR
3. FOR E IN EMPLOYEES CROSS JH IN JOB_HISTORY
     OVER EMPLOYEE_ID
     WITH JH.JOB_END MISSING
       PRINT E.LAST_NAME, JH.JOB_CODE
   END_FOR
4. FOR J IN JOB_HISTORY
     WITH J.JOB_END MISSING
     REDUCED TO J.JOB_CODE
     SORTED BY J.JOB_CODE
       PRINT J.JOB_CODE
   END_FOR
5. PRINT COUNT OF E IN EMPLOYEES WITH
     E.STATE = "MA"
6. STORE D IN DEPARTMENTS USING
     D.DEPARTMENT_CODE = "RECR";
     D.DEPARTMENT_NAME = "Recreation";
     D.MANAGER_ID = "00175";
     D.BUDGET_PROJECTED = 240000;
     D.BUDGET_ACTUAL = 127098
   END_STORE
7. START_TRANSACTION READ_WRITE RESERVING
     COLLEGES FOR EXCLUSIVE WRITE
       FOR C IN COLLEGES
         ERASE C
       END_FOR
   COMMIT
Somiglia all'SQL (almeno concettualmente), no?
Ciao,
G.


Decisamente SI
Ciao.
Mauro

 periodo, tenevo i corsi di ALL-IN-1); passare da Unix/VMS a MVS è
Eh, prima o poi ALL-IN-1 (e Datatrieve) lo installo e ci gioco un po'! :-)
Ciao,
G.