Guida alle personalizzazioni in ambiente AIX e CATIA
(c) IBM Italia S.p.A
4 Novembre 1997
Michele LIBERI
IBM Italia, Business Consulting Services, Industry&Distribution
Tel.office +39 049 845058
Tel.mobile +39 335 7446070
Michele_Liberi@it.ibm.com
http://mliberi.italy.ibm.com
Guida alle personalizzazioni
in ambiente AIX e CATIA
Introduzione
SW per l'amministratore di sistema AIX
SW per l'utente AIX
SW per l'amministratore CATIA
SW per l'utente CATIA
Downsizing VM --> AIX
SW specifico FERRARI
Questo documento descrive i programmi da me sviluppati allo scopo
di fornire una guida per l'offerta di personalizzazioni in ambiente AIX
e CATIA.
Il SW descritto in questa guida è il frutto dell'attività di
amministrazione e gestione sistema svolto da IBM per FERRARI. La maggior
parte delle procedure sviluppate sono state pensate per poter essere
facilmente installate presso altri clienti.
La divisione delle procedure in categorie è stata fatta per semplificare
al massimo i criteri di offerta. A mio avviso la miglior divisione per
categorie è quella per tipologia di utente.
Le procedure descritte in questo capitolo consentono di legare
funzionalmente le macchine AIX in rete LAN. Permettono di attuare quella
che noi chiamiamo 'architettura'.
L'architettura risponde alle seguenti esigenze:
- intercambiabilità
- ovvero la possibilità per un
progettista di prendere posto su una qualunque delle
macchine della rete e trovare il proprio ambiente di lavoro, come se
la rete fosse un unico sistema. Questa caratteristica risulta essere
utile per due motivi:
- il numero delle macchine può essere minore del numero di
progettisti che
possono su esse operare, da qui la impossibilità di assegnare la
macchina al singolo progettista.
- le macchine hanno potenze di calcolo diverse per cui si ipotizza
che lo stesso progettista possa operare su una macchina di potenza
inferiore quando deve lavorare su modelli CATIA relativamente
semplici, o su macchine più potenti se, viceversa, deve operare su
modelli più pesanti.
- indipendenza
- ovvero la possibilità per ognuna
delle macchine della rete di operare, con funzionalità ridotte, nel
caso in cui il server dovesse essere temporaneamente non attivo. Il
progettista deve poter continuare il suo lavoro anche nel caso in cui
la sua macchina dovesse essere completamente sconnessa dalla rete.
- standardizzazione
- ovvero l'omogeneità di installazione e configurazione delle varie
macchine in rete.
Le suddette caratteristiche si ottengono installando tutto il SW di
base e quant'altro necessario localmente, e mantenendo l'allineamento tra
le varie macchine con i tools nel seguito descritti.
In particolare la dipendenza da un eventuale server dovrebbe limitarsi
all'accesso di archivi CATIA condivisi e alla distribuzione di
password NETLS di tipo condiviso.
La procedura Xnetcfg permette all'amministratore di rete di gestire
i seguenti aspetti:
- topologia di rete
- la lista dei nodi che fanno parte dell'architettura.
- utenze di rete
- le utenze sono identiche su tutti i nodi della rete. Ciò si ottiene
mediante distribuzione e sincronizzazione dei files di
configurazione degli utenti.
- disponibilità di dati in rete
- ogni utente ha la sua home directory sulla macchina su cui lavora
più frequentemente, ma l'accesso ai suoi dati può avvenire da
qualunque nodo della rete tramite il meccanismo dell'automount.
Lo stesso meccanismo si usa anche per l'accesso a dati presenti
sul server degli archivi CATIA.
Consente di verificare che i nodi della rete
- rispondano al ping,
- abbiano il display abilitato ai messaggi,
- siano abilitati a ricevere comandi da altri nodi.
Le tre condizioni di cui sopra sono ESSENZIALI per un buon
funzionamento dell'architettura.
Consente di mandare in esecuzione una serie di comandi sui nodi
della rete. E' possibile selezionare anche solo una parte dei nodi
su cui il comando dovrà essere eseguito.
E' essenziale per l'attività di manutenzione centralizzata dei
nodi di rete.
L'esecuzione dei comandi sui vari nodi è sequenziale ovvero il
comando viene posto in esecuzione su un certo nodo solo quando
l'esecuzione è terminata sul precedente nodo, a meno che non sia stata
specificata l'opzione -b che consente l'esecuzione in parallelo su tutti
i nodi.
Non è possibile eseguire comandi che necessitino di interattività
tipo il "vi".
Permette di copiare un file su tutti i nodi della rete. E' possibile
che la directory destinazione sia diversa dalla directory di partenza.
Basato sul programma Xpostit, permette di mandare un postit con
un messaggio a tutti i display della rete.
Questa procedura consente di mantenere traccia del verificarsi di
cadute di rete o indisponibilità di un server NFS.
Il test di disponibilità della rete e del server NFS viene eseguito
periodicamente. Su un file di log vengono registrati solo i cambi di
stato.
Questa procedura consente di mantenere allo stesso livello di
modifica un insieme di files o directories su un insieme di hosts.
E' pensata per funzionare in modo automatico ed attivata da crontab.
Dove nel seguito, per semplicità, è riportata la parola 'file' si
intende che funzioni anche per intere directory. Nel qual caso fa fede
la data di ultima modifica della directory ed i files e directory
in essa contenuti verranno trasferiti in blocco.
Ha due fasi distinte di funzionamento:
- aggiornamento dei files
il nodo richiede a tutti i nodi della rete la data di ultima modifica
dei files e si appropria dell'ultima versione. Questa fase può essere
omessa se il programma viene fatto girare in modalità MASTER.
- distribuzione dei files
il nodo distribuisce i propri files a tutti i nodi che hanno una
versione superata. E' anche possibile forzare la distribuzione
incondizionata specificando il parametro FORCE.
I programmi descritti in questa cooperano per realizzare un
avanzato sistema di backup con le seguenti caratteristiche:
- automazione
- il programma di backup lavora in modo totalmente automatico. Può essere
lanciato via crontab e, se si dispone di una unità robotizzata multicassetta
(ad esempio 7332 (12 tapes 4 mm) o 7331 (20 tapes 8 mm)),
esegue automaticamente i cambi di cassetta.
Eventuali messaggi di errore vengono notificati ad uno o più amministratori
sulla rete via 'mail' e via 'Xpostit' (cfr.).
Il programma è in grado di gestire anche unità a nastro singolo, oppure
di eseguire backup 'virtuali' in cui il device di backup è una directory
su disco.
Il programma consente di utilizzare una serie contigua di nastri
sui quali i dati verranno salvati in maniera sequenziale e
circolare .
Ciò significa che i dati vengono accodati su un dato nastro fino al
suo riempimento prima di passare al nastro successivo, e che terminata la
scrittura dell'ultimo dei nastri previsti la scrittura riprende dal primo.
- salvataggi incrementali multilivello
- la procedura è in grado di fare salvataggi completi o incrementali a più
livelli. Si possono, ad esempio, tenere nello stesso database salvataggi
incrementali giornalieri, settimanali, mensili, trimestrali ...
Sono infatti disponibili 9 livelli di salvataggio incrementale.
Ad ogni livello
vengono considerati tutti i salvataggi precedenti con numero di livello minore
o uguale a quello attuale.
- centralizzazione
- le directory da salvare possono appartenere anche ad altre macchine AIX
nella rete. Questo permette di centralizzare su un'unica macchina il
salvataggio di molte macchine in rete.
- flessibilità
- il programma funziona 'per lista di directory'. Ogni directory viene
salvata, con tutto il suo contenuto, in un blocco dedicato su nastro. In
qualunque momento è possibile aggiungere o cancellare directory da questa
lista ed il programma si adegua. Le caratteristiche di funzionamento del
programma possono essere controllate tramite un insieme di parametri
(cfr).
- velocità di accesso alle informazioni
- i backup vengono fatti 'per blocchi' per cui il posizionamento nel nastro
sulla directory che interessa e molto veloce.
Per ogni blocco scritto su nastro esiste un file in uno speciale database
che contiene un indice del contenuto del blocco. Questo fa si che la ricerca
delle informazioni da ripristinare sia molto veloce e non richieda la lettura
del supporto magnetico.
- facilità di ripristino delle informazioni
- il programma di ripristino, Xnetres, ha interfaccia MOTIF ed è di
semplice ed immediato utilizzo. Permette oltre alle classiche funzioni di
ripristino dati anche funzioni di amministrazione del database che saranno
descritte nel seguito.
- sicurezza
- ogni nastro utilizzato dalla procedura viene marcato elettronicamente
quando viene utilizzato per la prima volta e viene riconosciuto ad ogni
successivo utilizzo. Il marchio è unico per ogni database e per ogni nastro
appartenente a quel database.
Il programma bakstart è l'interfaccia di chiamata al comando
netbak da inserire nel crontab, che attua la seguente politica
di backup:
- 1/1 e 1/7 --> backup totale (livello 0)
- 1 altri mesi --> backup mensile (livello 3)
- Lunedì --> backup settimanale (livello 6)
- altri gg --> backup giornaliero (livello 9)
E' disponibile in formato sorgente per una eventuale modifica
della politica dei backup.
E' il programma che consente di avviare il salvataggio dei dati.
accoda nel file LOG nel DB di riferimento tutti i messaggi relativi
al procedere delle operazioni. Al termine delle operazioni il log
generato può essere notificato ad uno o più utenti via mail o Xpostit.
Tutte le funzionalità di rete della procedura sono realizzate con
il comando rsh, per cui la macchina centrale che gestisce i salvataggi
deve avere accesso alle macchine in rete.
Il programma Xnetres è un programma interattivo con interfaccia MOTIF
e permette di ripristinare dai nastri creati via netbak i files,
o directory intere, che si desiderano.
Permette inoltre di attuare una serie di funzionalità di gestione
del DB dei salvataggi
Una volta attivata presenta un menu con le seguenti scelte:
- ripristino di un singolo file
- verrà richiesta una stringa di selezione per selezionare i files
presenti
nel database; fra quelli selezionati si potrà scegliere quello
da ripristinare.
Verranno a questo punto proposte le versioni disponibili del file
selezionato e si potrà scegliere a che data interessa avere il file.
Il file selezionato verrà dunque ricaricato nella stessa
directory e nella
stessa macchina da cui era stato prelevato all'atto del salvataggio.
L'operazione di ripristino ricopre un file eventualmente esistente con lo
stesso nome.
- ripristino cumulativo di una directory
- consente di ricostruire la storia di una directory dall'ultimo
salvataggio
completo ad una certa data. Selezionata la directory da ripristinare (una di
quelle in DIRLIST) il programma chiederà a che data deve avvenire il
ripristino
e quindi caricherà dai nastri tutti i blocchi relativi a quella directory
dall'ultimo salvataggio completo immediatamente precedente
la data selezionata
alla data selezionata. Il ripristino avverrà sulla macchina che possedeva i
dati al momento del salvataggio e ricoprirà il contenuto della directory
con lo stesso nome eventualmente esistente.
- ripristino files da un singolo blocco
- permette di ripristinare una lista di files e directory da
un singolo blocco presente su nastro. La selezione di una directory
comporta il ripristino dell'intero contenuto della stessa.
- modifica contenuto DATABASE
- permette di modificare il contenuto del database relativo ad un certo
blocco senza modificare la data di ultima modifica
- cancella un nastro da DB
- consente di cancellare dal database tutti i files che si riferiscono ad
un certo nastro. Questa operazione va fatta solo se il nastro è già
stato fisicamente riscritto e quindi non contiene più i dati che sono
contenuti nel database.
- mappa S/N / SLOT
- visualizza la mappa di associazione nastro/slot contenuta nel DATABASE.
E' così possibile capire quali S/N sono in linea e su quali slot.
- muovi nastro su altro slot
- consente di associare un certo slot ad un certo nastro.
Questa associazione
va a modificare permanentemente il database. L'associazione dello slot 0 ha
il significato particolare di 'nastro non accessibile'.
- riciclo di un nastro
- questa operazione consente di cancellare dal database tutti i files che
si riferiscono ad un dato nastro. Il nastro viene dapprima identificato e
riconosciuto, poi tutti i blocchi ad esso relativi vengono cancellati dal
database, ed infine il nastro stesso viene reinizializzato. Dopo questa
operazione sarà impossibile recuperare da esso le informazione che vi
erano scritte.
- verifica di un nastro
- scandisce sequenzialmente i blocchi di un dato nastro a partire da un
dato blocco, e verifica la congruenza del contenuto del database con il
contenuto del nastro. Per ogni blocco non congruente verrà generato un file,
il cui nome inizia con la stringa 'tape', che contiene un listing di ciò
che il blocco su nastro effettivamente contiene. Ci sono tre possibilità:
- il blocco su nastro contiene dati:
in questo caso si consiglia di sostituire il file nel database
originale con quello generato dalla procedura di modifica.
usare il comando mv
- il blocco su nastro esiste, ma non contiene dati
in questo caso si consiglia di rimuovere il blocco da database,
avendo cura che rimanga almeno un blocco successivo
- il blocco su nastro non esiste
in questo caso il blocco va rimosso da database e presumibilmente
dovranno essere rimossi anche tutti i blocchi successivi sullo stesso
nastro. E' anche opportuno che il prossimo lancio della procedura
avvenga con l'opzione -newtape
La coppia di procedure si pone l'obiettivo di fornire un valido
strumento di comunicazione tra utenti ed amministratori di sistema.
Lo schema di funzionamento è molto semplice:
- L'utente immette un problema che è formato da una parte 'titolo' ed
un testo descrittivo
- Il problema viene memorizzato in un DataBase che gestisce le
seguenti informazioni:
- stato del problema (O=open, W=working, C=close)
- data immissione
- data presa in carico
- data chiusura
- nome dell'amministratore che ha in carico, o ha chiuso, il problema
- nome utente che ha immesso il problema
- nome host da cui il problema è stato immesso
- titolo del problema
- testo descrittivo del problema
- L'amministratore vede il problema aperto e può fare una delle seguenti
operazioni:
- ripeti selezione che consente di filtrare nuovamente la
lista dei problemi contenuti nel database in base ai criteri selezionati
- esamina che consente di visualizzare il problema
- prendi in carico che consente di mettere il problema in stato
W=working. Questa operazione consente di dare una risposta parziale al problema
che dovrà in seguito essere completata dallo stesso che ha preso in carico il
problema. Altri amministratori non possono operare sul problema.
- chiudi (risp. singola) che consente di dare una risposta
definitiva al problema, o completare una risposta parziale.
In questo caso il testo del problema con la relativa risposta viene trasmesso
via mail all'utente che lo aveva aperto e via Xpostit al video dell'host da
cui era partita la richiesta.
- chiudi (risp. a tutti) nel caso in cui l'amministratore
ritenga che il problema sia di comune interesse, con questa funzione il testo
del problema, e la relativa risposta, può essere trasmesso a TUTTI gli utenti
via Xpostit. L'utente che aveva aperto il problema riceverà la risposta anche
via mail.
- archivia senza rispondere nel caso in cui la risposta sia
già stata data per altra via è possibile archiviare il problema senza dare
risposta all'utente che lo aveva aperto.
- A questo punto l'utente ha la possibilità di riaprire il problema
aggiungendo nuovo testo ed il problema torna all'attenzione dell'amministratore
Il programma consente di accedere alla manualistica della maggior parte dei
comandi AIX. La versione Xman è un programma con interfaccia MOTIF, tman in
versione alfanumerica, mman con interfaccia classica, ovvero identica a quella
del comando 'man'.
Xman e tman accettano come parametro una stringa di selezione
che verrà utilizzata per selezionare dalla lista dei comandi
disponibili. La selezione avviene tramite il comando grep.
Dalla lista dei comandi selezionati è possibile selezionare il
comando di cui si vuole documentazione oppure specificare una nuova
stringa di selezione.
tman può essere utilizzato anche via telnet in quanto non usa
l'ambiente grafico.
mman accetta come parametro il comando di cui si vuole
visualizzare la pagina di manuale. La visualizzazione avviene in
ambiente testo con il programma pg.
Tutte le versione attingono le informazioni da un database che occupa
poco più di 2 MB di nome 'mangz.yar'. La ricerca avviene prima nella
directory /usr/man e poi nella direcotory dove risiede l'eseguibile.
La procedura permette di scrivere un file, passato come
parametro, su dischetto in vari formati e con varie opzioni.
Permette di trasformare un file da UNIX text a DOS text (opzione
da NON utilizzare in caso di files binari), di comprimerlo, di
scriverlo su dischetto in formato DOS o tar.
I compressori disponibili sono:
- pkzip
- viene creato un ZIP file compatibile con il pkzip
- gzip
- GNU zip. E' un compressore molto efficiente
- compress
- il compressore standard UNIX
- nessuno
- il file viene salvato senza alcuna compressione
In caso di scrittura in formato DOS il file viene spezzato su più
dischetti. Ogni volta che si inserisce un nuovo dischetto questo viene
riempito per l'intero spazio rimanente disponibile. E' anche
possibile, al momento del cambio del dischetto, procedere alla sua
formattazione a 1.44 MB.
Il nome del file DOS viene impostato per default ai primi 8
caratteri del file di input, ma può essere cambiato. L'estensione
proposta per default dipende dal compressore utilizzato, anch'essa può
essere modificata a piacere prima di procedere al salvataggio.
Se il file viene spezzato su più dischetti i vari blocchi vengono
numerati con un contatore che parte da 00 e fino ad un massimo di 99.
Per ricostruire dai vari blocchi il file originale, che poi dovrà
essere eventualmente decompresso, si deve dare da linea comandi DOS
il seguente comando: copy /B file.x00+...+file.xnn file.xxx
Volendo invece ricostruire il file originale su un'altro sistema
UNIX si deve dare, dopo aver letto su disco i vari pezzi, il comando
cat file.x00 ... file.xnn >file.xxx
In caso di scrittura in formato 'tar' il multivolume viene
gestito dal comando tar stesso.
Xnetpostit permette di comporre un messaggio in una finestra grafica
e mandarlo ad uno o più utenti della rete.
La procedura consente di interrogare il server delle licenze
relativamente a:
- Quali licenze di rete sono installate
- Quante di queste sono in uso
- Chi le sta utilizzando
Alla partenza la procedura visualizza una lista delle licenze di
rete installate, il numero di queste in uso ed il numero di queste
disponibili.
Selezionando una licenza e con un click su OK si può vedere da
CHI una licenza è stata allocata.
Con un OK a vuoto la lista viene rigenerata e quindi verrà
riportata la situazione aggiornata.
La procedura è basata sulle utility del netls che quindi deve
essere stato configurato correttamente. In particolare si deve copiare
il file dal server /etc/ncs/glb_site.obj a tutti i client ed il file
/etc/ncs/glb_site.txt deve contenere l'indirizzo del server.
La procedura Xcatia permette di gestire l'accessibilità e la
visibilità degli archivi CATIA.
L'accessibilità agli archivi viene mantenuta tramite un'opportuna
manipolazione del gruppo di appartenenza delle directory che ad essi
corrispondono. In ogni caso la procedura imposta i permessi di accesso
alle directory a 775 (RW per admVRM, RW per gli appartenenti al gruppo
associato, RO per gli altri).
Riguardo all'accessibilità gli archivi sono di due tipi:
- accesso libero tutti gli utenti CATIA hanno accesso in
READ-WRITE. Questa situazione viene gestita impostando il gruppo associato
all'archivio al gruppo di appartenenza di tutti gli utenti CATIA.
- accesso limitato solo una parte degli utenti ha accesso in
READ-WRITE. Questa situazione viene gestita creando un nuovo gruppo con i
primi 8 caratteri del nome dell'archivio, ed assegnando a questo gruppo solo
gli utenti che possono scrivere.
Riguardo alla visibilità, gli archivi sono di due tipi:
- visibilità per tutti tutti gli utenti CATIA vedono l'archivio.
Questa situazione viene gestita inserendo la dichiarativa che definisce
l'archivio al CATIA nel file comune CATIA.dcls
- visibilità per alcuni solo alcuni utenti vedono l'archivio.
Questa situazione viene gestita inserendo la dichiarativa che definisce
l'archivio al CATIA nel file privato USRENV.dcls dei soli utenti che devono
avere visibilità.
La procedura Xcatia permette di svolgere le seguenti operazioni:
- Crea nuovo archivio il nuovo archivio sar^Å visibile
per tutti e READ-WRITE per tutti
- Cancella un archivio
La cancellazione di un archivio pu^Õ avvenire solo se l'archivio ^Ê stato
svuotato di tutto il suo contenuto, operazione che, per la sua delicatezza,
va fatta a mano.
- Modifica la politica di accesso agli archivi
E' possibile far passare un archivio da READ-WRITE per tutti (gruppo base
del catia) a READ-WRITE solo per alcuni (gruppo definito ad hoc per il
singolo archivio). L'assegnazione degli utenti a questo gruppo (quelli che
potranno scrivere nell'archivio) viene fatta con una delle prossime due
voci a menu.
- Modifica i permessi di accesso per UTENTE
Permette di assegnare, o revocare, ad un utente CATIA l'accesso
in scrittura ad uno o pi^× archivi.
- Modifica i permessi di accesso per ARCHIVIO
Permette di assegnare, o revocare, l'accesso in scrittura ad un archivio
CATIA ad uno o pi^× utenti.
- Modifica la politica di visibilit^Å degli archivi
E' possibile far passare un archivio da 'visibile per tutti' (dichiarazione
in CATIA.dcls) a 'visibile per alcuni' (dichiarazione negli USRENV.dcls privati
degli utenti). Una volta fatto passare l'archivio nello stato 'visibile per
alcuni' si dovr^Å assegnare la visibilit^Å con una delle due seguenti voci
a menu.
- Modifica la visibilit^Å per UTENTE
Permette di rendere visibile, o invisibile, da CATIA ad un certo utente
uno o pi^× archivi a visibilit^Å limitata.
- Modifica la visibilit^Å per ARCHIVIO
Permette di rendere visibile, o invisibile, da CATIA un certo archivio
ad uno o pi^× utenti.
Al termine delle operazioni le modifiche relative all'accessibilità
degli archivi vengono diffuse
automaticamente su tutta la rete, ma diventano effettive solo dal
prossimo login dell'utente interessato. Le modifiche relative alla
visibilità degli archivi invece diventano effettive dalla prossima ripartenza
del CATIA.
Il programma consente di effettuare salvataggi e ripristini su
unità nastro di modelli e librerie CATIA V4 in ambiente AIX V4 o V3.
Può essere lanciato solo da utente CATIA ed opera solo sugli
archivi che l'utente vede e sui quali ha i necessari permessi di
accesso.
Il salvataggio viene fatto in formato tar e consta di due
blocchi: il primo contiene solo l'indice degli archivi e dei modelli
salvati, il secondo contiene i modelli stessi. Il salvataggio avviene
con pathname assoluto per cui il ripristino è possibile solo nella
directory di provenienza. La struttura in due blocchi è stata fatta
per consentire un rapido accesso alle informazioni in caso di
ripristino. All'inizio del secondo blocco, come prima cosa, viene
sempre salvato il project file.
Al termine dell'operazione di salvataggio una finestra di colore
verde segnala con opportuno messaggio l'avvenuta conclusione. Una
finestra di colore rosso segnala invece che ci sono stati problemi, i
messaggi di errore vengono successivamente visualizzati e salvati per
futura consultazione in un file di nome /tmp/Xbakres.n, con n numero
progressivo. L'amministratore di sistema avrà cura di cancellare
questi files quando non servono più.
Il salvataggio può avvenire con varie modalità:
- Salvataggio completo. Vengono salvati tutti i modelli di tutti gli
archivi e librerie.
- Salvataggio locale. Vengono salvati solo gli archivi memorizzati
sui dischi collegati alla macchina su cui gira la procedura.
- Salvataggio con selezione. E' possibile, con ulteriore finestra di
interazione grafica, scegliere quali archivi salvare e la data minima
dalla quale salvare i modelli.
E' anche possibile far partire il salvataggio con un tempo di
ritardo. In questo modo si potranno impostare i parametri del
salvataggio e continuare a lavorare. Il salvataggio avrà luogo in
serata senza interferenze.
Il ripristino può avvenire nelle seguenti modalità:
- Ripristino completo. Da attivare nel caso disastroso che sia
andato perso il contenuto di tutti gli archivi e librerie. Ripristina
tutti i files del nastro senza chiedere ulteriori interazioni.
- Ripristino del project file. Ricarica dal nastro solo il contenuto
del project file. Ovviamente l'utente che lancia l'operazione deve
poter scrivere sulla directory che lo contiene.
- Ripristino di uno o più archivi completi. Per evitare di
sovrascrivere per errore modelli più nuovi con quelli salvati
precedentemente su nastro, la procedura rinomina quelli su disco prima
del ripristino aggiungendo al nome il suffisso ".old"
- Ripristino di singoli modelli. Con questa funzione l'interazione
con il programma è spinta fino al dettaglio del singolo modello che si
vuole ripristinare. Come sopra il modello con lo stesso nome
eventualmente presente su disco viene rinominato con suffisso ".old".
Nel caso si debbano rileggere più modelli dello stesso archivio è
consigliabile operare una scelta multipla per evitare di dover leggere
lo stesso nastro più volte.
La procedura Xfaix permette di creare un file sequenziale a partire
da un modello CATIA o, viceversa, di importare un file sequenziale in
ambiente CATIA. Può essere attivata solo da un utente CATIA.
I file sequenziali di norma vengono creati per spedire un modello ad
un fornitore, e devono essere importati quando un fornitore spedisce un
modello su supporto magnetico. Possono essere creati con molti parametri
diversi, e quando vengono importati devono essere usati i parametri
corrispondenti.
La procedura richiede, per un corretto funzionamento, che i fornitori
vengano catalogati in relazione ai parametri che dovranno
essere utilizzati per lo scambio di modelli CATIA.
La lista dei fornitori con i relativi parametri di comunicazione è
contenuta nel file Xforn.for . Ogni riga del file che non inizia
con il carattere '#' (riga di commento) identifica un fornitore ed è
composta dai seguenti campi separati da uno o più spazi:
- fornitore il nome del fornitore
- tipo può essere 'tar' o 'backup'. Identifica il programma da
usare quando si generano supporti magnetici da spedire al fornitore. Nel caso
di supporto che arriva da fornitore identifica il programma da usare per la
lettura del supporto. (tar --> tar, backup --> restore)
- Allin può essere 'yes' o 'no'. Indica se il project file del
fornitore è allineato a quello della FERRARI o no.
Se il project file del fornitore è allineato l'utility CATEXP userà il
parametro *SEND per generare il file sequenziale, e l'utility CATIMP userà
il parametro *RECEIVE, altrimenti CATEXP userà il parametro *EXPORT e la
CATIMP userà il parametro *IMPORT. E' sempre preferibile, ove possibile che
i due project file siano allineati perché l'operazione *IMPORT tende a
'sporcare' il project file.
- input parametro non utilizzato. Questo stesso file di
configurazione viene utilizzato anche dalla procedura Xforn (cfr.) che usa
questo parametro per decidere se spedire il file in ASCII o in EBCDIC.
- output codepage utilizzata dal fornitore
- CatVer è la versione CATIA usata dal fornitore. Questo
parametro influenza solo il processo di creazione di un file da spedire
a fornitore. Può essere:
- SAME: indica che il fornitore ha la stessa versione CATIA
- V.R.M: il fornitore ha CATIA Version V, Release R, Modification M. Prima
di essere scritto su supporto magnetico il file sequenziale viene processato
con l'utility CATBACK.
- V.R.FRx: il fornitore ha CATIA Version V, Release R, Refresh x. Anche in
questo caso il file verrà processato con opportuna CATBACK.
- compress mettere 'yes' se si vogliono comprimere con il
comando 'compress' i files da spedire a fornitore. I files in arrivo da
fornitore vengono automaticamente decompressi se hanno il suffisso .Z
In ogni caso esiste la possibilità di selezionare la voce 'altro
fornitore' che permette di indicare quali parametri usare nel processo di
generazione, o integrazione, del file sequenziale, nel caso che il fornitore
non sia censito o i parametri nel file di configurazione non siano corretti. In
questo caso si dovrebbe quanto prima correggere l'anomalia.
In caso di spedizione di un modello a fornitore vengono
eseguite, nell'ordine, su ognuno dei modelli selezionati,
le seguenti operazioni:
- copia su /temp del modello si lavora su una copia per evitare
di danneggiare il file originale. La directory di lavoro CATIA /temp deve
avere spazio libero sufficiente a contenere la copia del modello.
- se necessaria, CATBACK alla versione usata dal fornitore questa
operazione viene effettuata solo se il parametro CatVer ha un valore diverso
da 'SAME'.
- CATEXP in modalita\` SEND o EXPORT
- CATAIX in codepage del fornitore
- eventuale compressione con il comando compress
in caso di errore il processo si interrompe e visualizza un
messaggio di errore che ne identifica la causa.
Tutti i files sequenziali compressi vengono stoccati in una
directory temporanea creata in /temp. Il riempimento di /temp è una causa
comune di errore.
Al termine del ciclo di generazione dei files sequenziali, la directory
dove sono stati stoccati viene salvata su nastro o dischetto con il
comando tar o backup. Ogni file sequenziale ha lo stesso nome del modello
da cui proviene e suffisso '.dlv3.Z'.
In caso di lettura di un modello in arrivo da fornitore
le operazioni sono le seguenti:
- Lettura del supporto magnetico con il comando opportuno.
I files vengono scaricati in una directory temporanea in /temp
- Se il supporto contiene più di un file viene presentata una schermata che
consente di scegliere quelli da importare.
- se il file è in formato compresso viene decompresso
- viene convertito nella code page corrente
- viene IMPORTATO con l'utility CATIMP nell'archivio scelto dall'utente
La procedura consente di importare come modello CATIA un file in
formato IGES o DXF o, simmetricamente, di generare un IGES o DXF a
partire da un modello CATIA.
Il risultato della conversione nel caso IGES/DXF --> CATIA verrà
scritto nel commento del modello generato.
Il dispositivo di lettura/scrittura del file IGES/DXF può essere
il dischetto (/dev/fd0), l'unità nastro (/dev/rmt0), o il disco fisso.
Per comodità il programma propone la home dir dell'utente, ma si può
successivamente scegliere qualunque altra directory.
Se il dispositivo di uscita è il dischetto, per la scrittura
viene richiamata la procedura Xdskt (cfr).
Nel caso di conversione da iges o dxf a CATIA è anche possibile
specificare se si vuole solo la parte SPACE, solo la parte DRAW o
entrambe.
Ogni operazione di conversione viene riportata sul file di LOG.
Il programma Xwhere permette di ottenere la lista di tutti i
modelli, il cui nome contiene una certa stringa, all'interno
di uno o più archivi CATIA. Deve essere lanciato da utente CATIA.
Da interfaccia grafica è possibile selezionare uno o più nomi di
archivi. Se non viene selezionato alcun archivio la ricerca si effettua
su TUTTI.
E' inoltre possibile impostare tre stringhe di selezione dei modelli:
un nome di modello verrà selezionato se contiene tutte e tre le stringhe
specificate.
Se tutti e tre questi campi vengono lasciati vuoti verranno listati TUTTI
i modelli.
I modelli così selezionati verranno visualizzati in una finestra
grafica divisi per archivio.
Si tratta di un programma scritto da IBM, ma integrato nell'ambiente
CATIA che permette di stabilire opportune codifiche per i nomi dei
modelli nei vari archivi CATIA. E' possibile stabilire regole diverse
per archivi diversi.
Il nome dei modelli CATIA viene visto come somma di campi distinti,
e su ognuno di essi è possibile attivare un opportuno controllo. Ogni
campo inizia dal carattere immediatamente successivo il termine del
campo precedente.
Il programma intercetta la chiamata alle sottofunzioni
della funzione FILE del CATIA INTERATTIVO ed interviene
solo se il nome del modello in scrittura non rispetta i vincoli impostati.
Non viene eseguito alcun controllo in modalità batch.
Il programma può lavorare in tre modalità distinte:
- trasparente
- è il funzionamento standard del CATIA. Non verrà eseguito alcun controllo
sui nomi dei membri in scrittura.
- ostativa
- se il nome del modello non rispetta le regole
stabilite per il dato archivio, ne viene impedita la scrittura. In questo
caso CATIA visualizzerà un messaggio di errore della forma
nncnn invalid .....................
- le prime due cifre 'nn' rappresentano il punto in cui inizia il campo
che non rispetta la regola
- il carattere centrale 'C' rappresenta il tipo di regola violata con
la stessa codifica usata nel file di configurazione.
- le due cifre finali 'nn' rappresentano la lunghezza del
campo in errore.
- ciò che segue la stringa fissa 'invalid' è il nome del campo che
non rispetta la regola.
- costruttiva
- se il nome del modello non rispetta le regole
stabilite per il dato archivio, verrà proposta una finestra che facilita
la corretta composizione del nome. Dalla finestra si può uscire con il
tasto OK solo se tutti i campi sono corretti. L'uscita con il tasto CANCEL
riporta al caso precedente ed il modello non verrà scritto nell'archivio.
Non è possibile lavorare in modalità costruttiva con la funzione
RENAME.
La procedura permette di copiare o muovere un modello CATIA da un
archivio gestito da CATIA su RISC a uno gestito da CATIA su HOST o
viceversa. E' essenzialmente un'interfaccia che consente di lanciare le
utility CATIA in maniera sicura e semplice.
La comunicazione tra HOST e RISC avviene utilizzando il
protocollo tcp/ip ed utilizzando le utility batch del CATIA in
ambiente AIX ed ambiente VM. Poichè più utenti AIX possono utilizzare
la stessa macchina VM, la procedura ne sequenzializza l'accesso.
L'interazione con l'utente avviene con finestre MOTIF di semplice
ed intuitivo utilizzo.
Nel caso di trasferimento da HOST a RISC vengono eseguite le
seguenti operazioni:
- su HOST viene eseguita una CATEXP in modalità SEND
- il file sequenziale CATIA.SEQ.D viene trasferito su RISC
- viene portato nella code_page corrente
- viene eseguita la CATIMP modalità RECEIVE
- eventualmente viene eseguita la cancellazione su HOST
Nel caso di trasferimento da RISC a HOST vengono eseguite le
seguenti operazioni:
- il modello da trasferire viene copiato su /temp con trasformazione
nella code_page corrente
- viene eseguita sulla copia in /temp una CATBACK per portarlo a
livello 3.2. N.B. in questa fase vanno perse tutte le feature
introdotte nella versione 4 di CATIA, ad esempio i solidi e le quote
create con text2, dimens2 etc.
- viene eseguita una catexp in modalità SEND
- viene convertito in EBCDIC
- viene spedito all'host con nome CATIA.SEQ.D
- su HOST viene eseguita una CATIMP modalità RECEIVE
- la copia di lavoro viene cancellata da RISC
- eventualmente viene cancellato anche l'originale su RISC
In caso di trasferimento di più modelli il ciclo viene ripetuto
per ogni modello. Non viene fatta una CATEXP/CATIMP unica per avere la
ragionevole certezza che i files sequenziali che le suddette utilities
generano non superino le dimensioni impostate per la directory /temp.
La procedura permette di preparare un nastro o dei dischetti
contenenti uno o più modelli CATIA da spedire a fornitore o,
simmetricamente, leggere un nastro o dischetto in arrivo da un
fornitore ed importare il modello su CATIA HOST.
La comunicazione tra HOST e RISC avviene utilizzando il
protocollo tcp/ip ed utilizzando le utility batch del CATIA in
ambiente AIX ed ambiente VM. Poichè più utenti AIX utilizzano una o
più macchine VM la procedura sequenzializza l'accesso alle macchine
VM tramite l'utilizzo di files di lock.
La procedura viene lanciata con un parametro, gruppo, che identifica
un insieme di parametri da usare per la comunicazione con HOST. Questi
parametri sono memorizzati in un file di configurazione di nome 'Xforn.cfg'.
La procedura cmparc serve per confrontare il contenuto di archivi
corrispondenti in mondo VM e mondo AIX. E' una procedura batch che può
essere attivata da crontab e genera una lista di files che contengono i
nomi dei modelli comuni negli archivi corrispondenti.
Valgono le seguenti equazioni sul numero di linee dei files:
host = hnly + comm
risc = rnly + comm
Il programma esegue le seguenti fasi distinte:
- Fase 1: acquisizione del contenuto degli archivi CATIA VM
Per ogni archivio HOST presente nel file di configurazione viene:
- eseguito su VM il comando 'CATSPC ARCHIVIO FSM (7'
- ricevuto, tramite esecuzione su VM del comando 'FERFTP', il file
'ARCHIVIO.XIST.A' generato su host dal comando precedente
- il file ricevuto viene concatenato al file ARCHIVIO.host
- ordina lessicograficamente il file così ottenuto
- Fase 2: creazione del contenuto degli archivi CATIA AIX
Per ogni archivio RISC presente nel file di configurazione viene:
- generato un file con nome 'ARCHIVIO.risc' contenente la lista dei
modelli presenti nell'archivio
- Fase 3: confronto degli archivi corrispondenti
Per ogni archivio RISC presente nel file di configurazione vengono generati
i seguenti files:
- ARCHIVIO.host contiene la lista dei modelli presenti in tutti
gli archivi HOST che corrispondono all'archivio su RISC
- ARCHIVIO.risc contiene la lista dei modelli presenti
nell'archivio su RISC
- ARCHIVIO.comm contiene la lista dei modelli comuni
- ARCHIVIO.hnly contiene la lista dei modelli presenti
solo su HOST
- ARCHIVIO.rnly contiene la lista dei modelli presenti
solo su RISC
La procedura è stata progettata per operare un trasferimento di massa
di modelli CATIA da mondo HOST a mondo RISC.
Può essere lanciata via crontab e genera su standard output una lista
delle attività svolte e dei return code delle varie utility chiamate.
Gli archivi vengono passati a gruppi di (N) modelli per ottimizzare
i tempi di setup delle utility CATIA. Il parametro (N) viene stabilito su
HOST nella routine VOGLIO EXEC che risiede sul disco delle personalizzazioni
SW su host.
Il controllo del flusso delle operazioni viene controllato da RISC che,
per ognuno degli archivi da trasferire, esegue le seguenti operazioni:
- setup su host crea la lista dei blocchi di modelli da
trasferire. Avviene chiamando la funzione VOGLIO con numero di blocco 0.
- per ognuno dei blocchi
- richiesta del blocco
avviene tramite chiamata alla funzione VOGLIO su host. Il blocco di (N) modelli
viene estratto dall'archivio HOST con una CATEXP *EXPORT e spedito a Risc
tramite ferftp. Un errore in questa fase viene evidenziato con il messaggio
di errore: "can't get block (N), (rexec error message)"
- conversione alla code page corrente
un errore in questa fase genera nella directory WDIR un file con nome
(nome archivio).cataix.(N)
- IMPORT nell'ambiente CATIA RISC. Un errore in questa fase
genera nella directory WDIR un file con nome (nome archivio).catimp.(N)
- pulizia files temporanei su host. Avviene chiamando la
procedura VOGLIO con numero di blocco uguale a -1.
In questo capitolo sono raggruppati i programmi sviluppati in ambiente
FERRARI che possono essere portati in altri ambienti, che presentino
caratteristiche simili, solo dopo un'analisi di adattamento.
La procedura hostplot si occupa di portare su host i files di
plottaggio generati dai vari RISC ed attivare le procedure perchè
questi files vengano effettivamente stampati.
Le procedure di plottaggio sui vari RISC non fanno che generare il
file di stampa e depositarlo con nome opportuno in una directory
condivisa in rete (/export/pltspool).
hostplot controlla periodicamente il contenuto di questa directory e
spedisce al VM i files accumulati richiamando la procedura STAMP_A con
opportuni parametri. E' quest'ultima che gestisce il plottaggio vero
e proprio.
Il plotter su cui deve essere stampato il disegno viene
selezionato in funzione del nome del file sottoposto a stampa.
La codifica del nome del file immesso nella directory /export/pltspool
consente di selezionare il plotter su cui dovrà essere stampato. Il nome
del file è nella forma 'PLOTTER.user@nodo.N' con:
- PLOTTER
- il nome del plotter su cui si dovrà stampare. Questa stringa viene
semplicemente passata come parametro alla procedure STAMP_A. La lista
dei plotter attualmente configurata è la seguente:
- PLTCALC (calcomp)
- PLTMANU (calcomp)
- PLTELE (calcomp) via impag
- PLTVERS (versatec)
- PLOT400 (hpgl) su file AS/400
- PLT406 (calcomp ges)
- PLT407 (calcomp ges)
- PLT408 (calcomp rs232)
- PLT409 (calcomp rs232)
I due plotters rs232 al momento non possono essere utilizzati per
mancanza, su Risc, del SW che permette di generare i files nel giusto
formato.
- user
- il nome dell'utente che ha richiesto il plottaggio
- nodo
- nome della macchina da cui è partita la richiesta
- N
- numero progressivo per evitare conflitti sui nomi dei files
La procedura viene lanciata automaticamente dal server e si
occupa di aggiornare dei pannelli IUA su HOST. Ciò consente ai
progettisti che lavorano su CATIA HOST di sapere quali modelli sono
presenti sugli archivi della rete di RISC.
Vengono generati, via utility CATIA, e spediti a HOST le liste
dei disegni presenti nei seguenti archivi CATIA
- AUTOTELAIO
- DEFINITIVI
- MOTORE
- PROGETTISPECIALI
- SCOCCA
Il programma genera su stdout un log di tutte le operazioni in
svolgimento. Si consiglia di redirigere lo standard output su un file
di log.