Descrizione

Solo alcuni utenti devono poter modificare i sorgenti in librerie di sviluppo.
Vanno quindi impostate le autorizzazioni in modo tale da garantire questa proprietà.

Tale proprietà deve valere anche per gli utenti QPGMR.

La modifica deve essere impedita indipendentemente dallo strumento utilizzato: nero verde, RDi, Looc.UP, Web.UP, FTP, ecc.

Dettagli

Comando B£QQ30

E' stato creato il comando B£QQ30, tramite il quale è possibile impostare la corretta autorizzazione su una libreria.

Tramite questo comando è possibile impostare:

• il tipo di autorizzazione
  
• l'eventuale AUTL (solo per tipo SVI)
  
• l'eventuale OWNER (solo per tipo SVI)
  

I tipi di autorizzazione sono i seguenti:

• DEV: come la SMEDEV distribuita - il QPGMR deve modificare e debuggare
  
• SRC: come la SMESRC distribuita - il QPGMR non deve modificare né debuggare
  
• OBJ: come la SMEUP_OBJ distribuita - il QPGMR non deve modificare ma deve debuggare
  
• SVI: librerie di sviluppo - solo alcuni utenti possono modificare, il QPGMR può debuggare
  

Note su AUTL e OWNER

Con tipo SVI gli utenti autorizzati a modificare saranno SOLO quelli inclusi in una AUTL (opzionale). Nemmeno il QPGMR potrà
modificare il contenuto della libreria.
Quindi per SVI:

• verrà applicata AUTL se presente (solo a libreria, PF-SRC, MSGF e USRSPC)
  
• verrà modificato il proprietario (solo a libreria, PF-SRC, MSGF e USRSPC) rimuovendo le autorizzazioni specifiche di quell'utente. Questo perché mantenendo proprietario QPGMR, ogni utente QPGMR potrebbe modificare le autorizzazioni concedendosele...
  

Mentre per NON SVI:
verranno rimosse eventuali AUTL da tutti gli oggetti
verrà applicato proprietario QPGMR su libreria, PF-SRC, MSGF e USRSPC

Considerazioni tecniche

Perché agiamo su libreria, PF-SRC, MSGF e USRSPC e non su tutti gli oggetti?
Dovremmo agire su tutti (per impedire ad esempio la cancellazione di qualunque oggetto). Ma se lo facciamo su *PGM (e *CMD) innanzitutto non debugghiamo più. Inoltre proprietario QPGMR ci serve per il corretto funzionamento dei programmi. PF-DTA... Da valutare queste problematiche.

La sola opzione OBJ è debole perché se QPGMR è OWNER, può concedersi le autorizzazioni alla modifica. Inoltre può creare file. Quindi, per non introdurre modifiche sulla SMEUP_OBJ, introduciamo questa opzione (SVI).

Non cambiamo l'OWNER degli oggetti che non siano libreria, PF-SRC, MSGF e USRSPC perché temiamo di avere risultati impredicibili.

Le autorizzazioni PUBLIC sono sempre e solo *USE
Le autorizzazioni QPGMR dipendono dalla tipologia di libreria:

per modificare serve *ALL sui file source
per debuggare serve almeno *CHANGE sui *PGM
per non modificare deve essere *USE sui file source (con *CHANGE non riesco da nero verde ma ci riesco da loocup)

Più precisamente, abbiamo raffinato le autorizzazioni nel seguente modo: Sulla libreria:
il gruppo QGPMR ha *OBJOPR *READ *EXECUTE.

Sugli oggetti protetti:
il gruppo QPGMR ha *OBJOPR *READ *EXECUTE. sugli oggetti sbloccati:
il gruppo QPGMR ha *OBJOPR *OBJMGT *OBJEXIST *READ *ADD *UPD *DLT *EXECUTE.

In conseguenza, gli utenti di gruppo QPGMR possono modificare i files sprotetti, leggere e copiare altrove i sorgenti protetti, NON possono compilare nella libreria di tipo SVI