OLIBCOS PER SCO UNIX VERSIONE ESTESA
Specifiche Funzionali

 

1) GESTIONE PARTIZIONAMENTO DINAMICO

 

Nel CONF2 è stata nuovamente attivata la possibilità, già presente in BCOS II, di decidere la politica di partizionamento della memoria.

Per quanto riguarda il partizionamento statico, resta fissato il limite di 64 KB max per l'area utente di ogni posto di lavoro.

Se si attiva invece il partizionamento dinamico, l'area utente viene di volta in volta allocata della dimensione necessaria a contenere il programma da eseguire, con un limite massimo di 128KB.

A differenza di BCOS II, in OLIBCOS la memoria utente non viene prelevata da un pool di grandezza totale prefissata; dato che UNIX lavora in memoria virtuale le allocazioni di memoria dinamica vanno sempre a buon fine, anche in situazioni di scarsità di memoria fisica disponibile. Ovviamente aumentando la RAM si ottiene un miglioramento delle prestazioni, dato che si minimizzano le occasioni in cui UNIX è costretto ad accedere al disco per effettuare lo swap dei processi.

Ricordiamo alcune problematiche connesse con il partizionamento dinamico.

L'area utente viene allocata ad ogni entrata di un interprete per la dimensione richiesta dal programma da eseguire. Se il programma effettua una CHAIN di un altro programma di dimensione maggiore, quest'ultimo non può essere caricato.

Per ovviare a tale problema bisogna definire la region per il programma, cioè forzare il sistema ad allocare sul caricamento del primo programma un'area utente di dimensione maggiore o uguale al piu' grande dei programmi concatenati. Per definire la region bisogna utilizzare l'utility ATTRIB. Essa va lanciata sul primo programma BASIC che a sua volta ne concateni altri, oppure sull'OCP o sul JOCP che eventualmente attivi un programma BASIC con tali caratteristiche.

L'utility ATTRIB è stata modificata per scrivere nel descrittore virtuale del programma la dimensione della region non più in termini di bytes ma di settori da 256 bytes (questo per consentire di esprimere in 16 bits una dimensione maggiore di 65535 bytes). Tale modifica è trasparente per l'utente, ma va tenuta presente se per caso si trasportano programmi con region provenienti da BCOS II. In tal caso bisogna soltanto ripetere la ATTRIB in ambiente OLIBCOS esteso, superando in debug l'eventuale errore basic BAS ERR 20.

Molte delle utilities di OLIBCOS utilizzano un buffer di memoria compreso tra fine programma e fine area utente. Per esse si è provveduto a definire opportune region che consentano a tali utilities di avere a disposizione buffers sufficientemente grandi.

Al momento attuale un programma OCL non può superare il limite di 64KB, dato che non è possibile per OCLSYN la catalogazione in libreria applicativa di un modulo più grande di 255 settori. Invece per i programmi BASIC i nuovi limiti sono di max 64KB per il codice più max 64KB per le variabili. Questo è possibile perché in realtà nel modulo oggetto basic catalogato in libreria è contenuto soltanto il codice, mentre l'area variabili viene allocata dinamicamente al momento del caricamento del programma in memoria.

Sono stati reintrodotti i due comandi /STAT e /DYN, che vengono accettati in /SYS e che consentono di modificare temporaneamente il partizionamento da dinamico a statico e viceversa.

 

2) NUMERI DI LINEA DEI PROGRAMMI BASIC

Il vecchio limite di 9999 è stato ampliato a 16382 (+64%).

Il numero di linea occupa quindi un carattere in più nello statement, la cui lunghezza massima rimane comunque 80 caratteri. Questo ha causato alcuni cambiamenti nel comportamento dell'editor basic.

Quando lo statement viene visualizzato (tasti F2/F3, comandi FET[CH], LIS[T], VLI[ST]) non c'è più il blank tra il numero di linea ed il verbo basic. Quando lo statement viene inserito, il blank è facoltativo, ma non va digitato se si vuole utilizzare l'ottantesima colonna dello statement.

A parte le considerazioni estetiche questa soluzione ci consente di fare passare senza problemi tutti gli statements che riempiono la linea basic per intero anche in presenza di un line number più ingombrante.

L'unica eccezione è lo statement ON .. GOTO ...: infatti gli statements di questo tipo troppo lunghi non passano. In tal caso è necessario spezzarli in due o più statements consecutivi.

Il debugger BASIC (comandi BRE[AK], GOT[O]) ed il comportamento dello statement STOP sono stati adeguati al nuovo range dei numeri di linea.

Lo stesso dicasi per il report struttuale e la cross reference di programmi basic.

 

3) EDITOR BASIC: NUOVI COMANDI PER LIST SU FILE E STREAM EDITING.

è stato introdotto il nuovo comando

FLI[ST] [linenum1] [,linenum2].

Il risultato di tale comando è quello di dirottare il LIST del programma basic su di un file ascii editabile con vi avente pathname /bcos/system/PEDITn.

È stato introdotto il nuovo comando SED.

Il risultato di tale comando è quello di sottoporre automaticamente il contenuto del file avente pathname /bcos/system/PEDITn al compilatore di linea.

Il comando SED visualizza ed edita una riga dopo l'altra le righe di /bcos/system/PEDITn, fermandosi a fine file oppure alla prima riga contenente un errore sintattico.

Il comando SE1 ha le stesse funzionalità del comando SED, ma non visualizza le istruzioni basic, risultando quindi assai più veloce.

4) EDITOR BASIC: AMPLIAMENTO PRESTAZIONI COMANDO RESEQUENCE.

RES nnnn,pppp,iiii,ffff

dove:

nnnn = numero di riga iniziale per la rinumerazione (se non specificato assume 10)

pppp = passo di rinumerazione (se non specificato assume 10)

iiii = numero riga iniziale da cui effettuare la rinumerazione (se non specificato assume da inizio programma)

ffff = numero riga finale fino a cui effettuare la rinumerazione (se non specificato assume fino a fine programma)

 

5) EDITOR BASIC: COMANDO LINK

LIN[K] prog.libr,nnnn,pppp,mod

dove:

prog = nome programma da linkare a quello presente in memoria (puo' mancare o è ignorato se la modalità = 2)

libr = nome libreria del programma da linkare (puo' mancare o è ignorato se la modalità = 2)

nnnn = numero di riga iniziale per la rinumerazione del programma da linkare (se non specificato non effettua la rinumerazione)

pppp = passo di rinumerazione (se non specificato assume 10)

mod = modalità operativa

0 = normale

1 = non cancella il file temporaneo PEDITi su /bcos/system

2 = ignora il nome programma eventualmente specificato e linka il contenuto del file temporaneo PEDITi su /bcos/system che può essere stato editato anche con il vi. (Con questa modalità non è possibile la rinumerazione delle linee di codice, eventualmente occorre eseguirla con la modalità 1)

NUOVE SEGNALAZIONI DI ERRORE :

1) EDIT-ERR. 240: segnala una sovrapposizione di linee tra il programma in memoria ed il programma da linkare. Quando viene segnalato questo errore non è eseguito il LINK.

2) EDIT-ERR. 241: segnala un errore sintattico su una linea di codice del programma da linkare. Non è possibile segnalare di quale errore si tratti né in quale riga è stato individuato. Quando viene segnalato questo errore non è eseguito il LINK. Il file temporaneo è comunque cancellato per cui è opportuno farsi una copia di backup dopo averlo eventualmente editato con il vi prima del suo LINK.

counters