BETA /0295 - ARTICOLI

---

a cura di Fernando Carello

---

Lo standard SCSI

di Andrea Nenni

Adesso piú che mai, grazie all'esplosione dei CD-ROM e alla diffusione di dischi fissi di grossa capacitá, si fa un gran parlare di SCSI, per molti un oggetto misterioso con dei vantaggi in prestazioni non meglio specificati e un costo alto. Cerchiamo quindi di approfondirne la conoscenza e tracciarne l'evoluzione e di metterne in luce i pro e i contro anche per poterlo confrontare meglio con le soluzioni alternative che esistono per il collegamento di periferiche: ATA oppure interfacce proprietarie. Lo SCSI, per le sue caratteristiche avanzate, puó essere considerato un vero e proprio bus secondario del PC, a un livello piú alto rispetto a quello primario della scheda madre, giá in effetti sdoppiato in un bus locale veloce e nel vecchio e piú lento ISA. Il progetto è stato sviluppato nel lontano 1981 da NCR e Shugart Associates (l'odierna Seagate) come SASI per poi assumere l'attuale nome durante la standardizzazione ANSI, peraltro portata a termine solo nel 1986; ha trovato per la prima volta grande diffusione con l'uso generalizzato sui Macintosh dal 1984 fino ad oggi. Lo SCSI originale, detto oggi SCSI 1, è un bus parallelo a 8 bit che puó collegare fino a 8 periferiche, ognuna caratterizzata da un suo numero identificativo (ID), che possono essere indifferentemente esterne o interne, ma delle quali una è in realtá il controller (anche detto host adapter) che collega il bus SCSI con quello di scheda madre; il numero reale quindi si riduce a un massimo di 7 unitá. Le comunicazioni sul bus si svolgono sempre fra sole 2 periferiche per volta, una funziona da iniziatore e l'altra da destinatario: c'è da notare che l'iniziatore non è necessariamente il controller ma una qualsiasi periferica che ne è in grado per le sue caratteristiche costruttive. Tipicamente durante una lettura da hard disk il controller inizia la comunicazione mandando le richieste al disco, poi il bus viene liberato per eventuali altre operazioni (Disconnect) e solo quando il disco è pronto a trasmettere le informazioni richieste prende possesso del bus e manda i dati al controller (Reconnect). In questo modo si ha la massima efficienza nell'uso condiviso del bus poichè non si deve aspettare il termine di ogni operazione, sopratutto quelle delle periferiche piú lente, visto che fra le unitá previste, divise in gruppi distinti ci sono: dischi ad accesso diretto (Hard Disk), unitá ad accesso sequenziale (streamer e DAT vari), stampanti, WORM, dispositivi a sola lettura ad accesso diretto, processori. Tutte le periferiche SCSI, essendo dotate di una maggiore logica di controllo a bordo, sono in genere piú "intelligenti" e permettono utili feature aggiuntive, come nel caso degli HD che conservano in genere uno o piú settori liberi per traccia per sostituirne eventuali difettosi trasparentemente al sistema operativo e al suo file-system. La velocitá massima di questa prima implementazione è di 5MB/s in modalitá sincrona e circa 2 in modalitá asincrona, piú che adeguata per le esigenze delle periferiche e per i lenti bus di personal e mini computer degli anni '80. Bisogna notare peró che lo SCSI 1 non prevede nè uno standard di programmazione per il controller, costringendo all'uso di driver software specifici per ogni modello e sistema operativo, nè uno standard completo nelle comunicazioni tra controller e periferiche ,visto che praticamente solo gli HD vengono pilotati senza bisogno di driver aggiuntivi attraverso il set standard dei comandi CCS. Il problema era particolarmente sentito sui PC in ambiente DOS, fra i quali lo SCSI era molto poco diffuso e quindi vi era carenza di driver; fu creato quindi uno standard di programmazione per il controller, sul quale si potessero appoggiare i driver delle periferiche e gli applicativi che ne facessero uso: il suo nome è CAM. Oggi peró è universalmente diffuso uno standard alternativo ed incompatibile, l'ASPI, generalmente supportato da tutti i principali produttori di controller sotto forma di driver software per il DOS. Per risolvere il problema dei driver di periferica invece è nato lo SCSI 2, ancora non ratificato definitivamente dall'ANSI, ma praticamente standardizzato dal mercato, nel quale il CCS e' stato esteso per supportare meglio CD-ROM, magneto-ottici e WORM, scanner e modem. In pratica quindi queste periferiche cosí vengono supportate trasparentemente o tramite un driver unico per il tipo di periferica ma se un costruttore di hardware vuole realizzare delle funzionalitá aggiuntive rispetto a quelle basilari previste puó sempre farlo ricadendo peró nella necessita di un driver specifico. Inoltre sono state anche definite meglio le comunicazioni sul bus con una serie di informazioni di controllo aggiuntive, fra cui quelle per le cache, e introducendo per esempio l'obbligatorietá del controllo di paritá e della fase di arbitraggio, punto piuttosto delicato dello SCSI a causa del numero elevato di periferiche e della dinamicitá dei trasferimenti. Nell'ambito dello SCSI 2 col tempo sono nate alcune sigle il cui significato, grazie anche alla parziale mancanza di standard ufficiali, non è spesso troppo chiaro neanche fra i rivenditori. La prima di queste, oggi ormai molto diffusa, è FAST, un vero e proprio protocollo di trasmissione che, se supportato da controller e periferica, aumenta la velocitá massima fino a 10MB/s in modalitá sincrona. Poi c'è il WIDE, presente solo su controller e HD di fascia alta, che non fa altro che raddoppiare l'ampiezza del bus dati da 8 a 16bit, tramite connettori a piú pin, e quindi anche la velocitá massima che raggiunge i 20MB/s nel caso, non necessario, ma universalmente adottato di accoppiamento FAST-WIDE. Ultima della serie ULTRA, di recentissima definizione (i primi prodotti si vedranno nel corso dell'anno), in grado di raddoppiare la frequenza del bus e quindi anche le prestazioni: 40 e 20 MB/s rispettivamente per le realizzazioni WIDE e normali a 8 bit. A parte le periferiche Wide che necessitano di un cavo piú ampio, nell'ordine ULTRA SCSI, FAST SCSI 2, SCSI 2, SCSI (con queste ultime che peró, a parte gli HD, vengono ad aver bisogno di un driver) generalmente c'è compatibilitá verso il basso del controller nel gestire le unitá ma, non essendoci regole ferree a riguardo, il tutto è lasciato alle decisioni dei costruttori hardware e in taluni casi le prestazioni dell'intero bus possono calare fino a quelle del protocollo piú lento in uso. Con un controller SCSI 1 invece gli HD SCSI 2 (anche FAST) funzionano quasi sempre senza problemi (eventualmente settando un apposito jumper) mentre la maggioranza dei CD-ROM si adatta ugualmente ma necessita di uno specifico switch. Spinto dalla crescente fame di velocita' degli HD moderni e dai crescenti problemi di affidabilitá del segnale e di interferenze sopratutto per le unitá esterne, il prossimo standard SCSI 3 attualmente in fase di definizione porterá un cambiamento radicale nel bus che si trasformerá da parallelo in seriale. Grazie a tecnologie seriali quali FC-AL oppure SSA che fanno uso di costosissimi cavi in fibre ottiche o metalliche, improponibili con l'elevato numero di conduttori di un interfaccia parallela, saranno possibili velocitá massime da 100 fino a ben 1000MegaByte/s. Altri miglioramenti probabili sono finalmente l'adozione standard dell'interfaccia di programmazione CAM rivista e finalmente supportata in hardware (cosí come è successo nelle VGA con la VESA), un ulteriore estensione del CCS e l'autoconfigurazione delle periferiche il cui numero massimo poi è destinato ad aumentare notevolmente: tutti punti necessari per un effettivo Plug&Play e una maggiore diffusione dello SCSI. Dopo averne analizzato la storia e le principali caratteristiche veniamo ai vantaggi effettivi in termini di prestazioni che puó comportarne l'adozione; i controller SCSI, infatti, sono governati da veri e propri microprocessori RISC dedicati, con potenze anche dell'ordine dei 10 MIPS, che se adeguatamente sfruttati sgravano il microprocessore centrale da un notevole carico di lavoro. In ambiente DOS/Windows non c'è alcun vantaggio prestazionale a causa della struttura obsoleta di questi sistemi operativi; sotto Windows for Workgroups 3.11 invece c'è addirittura un'inferioritá marcata rispetto alle soluzioni IDE poichè, a parte il caso isolato dei controller Future Domain che si rivelano in questi ambienti un ottimo acquisto, non c'è disponibilitá del driver per attivare il 32 bit disk-access, essenziale per i guadagni prestazionali delle componenti a 32 bit di questa versione di Windows. Qualsiasi sistema operativo moderno come OS/2, UNIX o Windows NT invece permette di sfruttare a fondo caratteristiche, presenti quasi universalmente nei controller SCSI, che sono il presupposto stesso per la nascita degli ambienti multitasking, multithread e client-server: DMA, coda dei comandi e il giá visto Disconnect-Reconnect. Il DMA permette al controller, una volta ricevuta la richiesta di lettura o scrittura, di effettuare i trasferimenti con la memoria autonomamente, lasciando la CPU libera di svolgere altri compiti; tradotto in vantaggi per l'utente vuol dire la sparizione dell'odiata clessidra e dei suoi tanti succedanei, a meno che non si stia aspettando proprio il caricamento di un file specifico per lavorarci, ma anche in questo caso è comunque possibile usare lo stesso programma in altre sue parti e opzioni e gli altri non vengono rallentati. Se non si fa uso ricorrente del multitasking o di efficienti programmi multithread, il PIO, utilizzato dai controller SCSI Future Domain e dalla quuasi totalitá degli IDE è altrettanto efficace a causa della sua intrinseca maggior velocitá sulla singola operazione; c'è da dire comunque che anche alcuni EIDE permetteranno il DMA nel futuro prossimo con gli opportuni driver. La coda dei comandi invece permette al controller di ricevere una serie di richieste successive e di indirizzarle al singolo disco, anche scisse in piú parti, secondo l'ordine piú vantaggioso per la posizione della testina e, grazie al Disconnect, di distribuirle fra i vari dischi per poi raccoglierne gli eventuali risultati secondo l'ordine di completamento. Rispetto alla limitazione del DOS, che fa una sola richiesta alla volta e ne aspetta il completamento, si puó ottenere un aumento globale di efficienza e velocitá della memoria di massa impressionante, sopratutto se poi si dispone di piú dischi e di unitá intrinsecamente piú lente come CD-ROM e magneto-ottici vari. Poi esistono controller che con poca logica aggiuntiva, talvolta disponibile su schedine opzionali, realizzano trasparentemente efficienti configurazioni RAID e cacheing dei dati e sono quindi la soluzione obbligata per qualsiasi server di rete. Per questi motivi lo SCSI è da tempo l'unica soluzione non proprietaria onnipresente su tutti i micro, server e workstation che lavorano tipicamente con sitemi operativi UNIX o Novell Netware e su alcune realtá alternative ai PC come Macintosh e Amiga. Solo ultimamente, prima per motivi di capienza e flessibilitá, adesso, grazie al graduale successo di sistemi operativi moderni a 32 bit, anche per le prestazioni, c'è stata una certa diffusione in ambito PC con calo di prezzo non trascurabile. In un prossimo articolo affronteremo piú da vicino il problema del montaggio e della configurazione delle periferiche SCSI.

[ Sommario | Redazione | Informazioni | Vai a... ]

a cura di Luciano Giustini

---

Installazione di un Point (seconda parte)

di Luciano Giustini

Avete letto l'articolo della volta scorsa? Si? Era piuttosto introduttivo, lo ammetto, ma vi erano spiegate due o tre cose che costituiscono poi la base del perfetto neo-Point ... Scherzi a parte, non mi dilungheró ulteriormente sulla suddivisione dei programmi, ricordando che per poter installare un Point in una rete in tecnologia Fidonet servono:

un mailer (programma che chiama il boss e prende/manda la posta)
un mail processor (programma che smista/scandisce la posta nella base messaggi)
un editor (programma che permette la lettura/scrittura, off-line, della posta)

Ricordo, se ce ne fosse bisogno, che stiamo parlando del mondo shareware/freeware, non dimenticate che di commerciale in questa rubrica non sentirete mai parlare (o almeno spero).

La scelta dei programmi per il Point deve basarsi essenzialmente su due fattori: il sistema operativo che usate (o che usate per il maggior tempo) e il tipo di base messaggi in cui vorrete tenere la posta. La seconda scelta in realtá è molto piú semplice della prima, in quanto ormai le basi piú usate sono rispettivamente la squish (in assoluto la piú diffusa) e la jam, un tantino piú veloce. La base squish deve il suo successo anche a uno dei piú famosi e diffusi tosser, "Squish" appunto, freeware, giunto alla release 1.11 e provato nel numero scorso di BETA. Tenete presente che non tutti i programmi esistono per tutti i sistemi operativi, con l'eccezione del DOS, per cui c'è tutto o quasi; e con l'eccezione di un mailer, "BinkleyTerm", in versone nativa per ben 3 piattaforme senza cambiamenti (DOS, OS/2, Windows NT). Un altro mailer c'è sia per DOS che per OS/2, "Xenia" ora giunto alla release 1.98, mentre per il lato tosser abbiamo Squish per DOS e per OS/2.

Gli editor sono stati scritti un pó per tutte le piattaforme, e per DOS il piú diffuso (e veloce) è sicuramente "GoldED", seguito a ruota da SemPoint per Windows provato nel numero scorso di BETA, e da "FleetStreet" per OS/2 PM. Difficile dire quale sia il migliore tra questi tre best-seller, ognuno di essi propone soluzioni ad hoc per il sistema operativo per cui è destinato. GoldEd per esempio predilige la velocitá se eseguito con il suo extender DOS a 32 bit; SemPoint sfrutta la grafica di Windows per le impostazioni, la visualizzazione, i colori, dimensionamento, ecc.; FleetStreet sfrutta il multithreading di OS/2 per tenere attive piú finestre sulla stessa scena di lettura, ecc.

INSTALLAZIONE

La scelta dei programmi per questo nostro viaggio potrá scatenare guerre di religione, ma non è affatto necessario: viene infatti dettata solo dalla disponibilitá dei programmi per piú piattaforme, e quindi per poter raggiungere un maggior numero di potenziali utenti (oltre che per poter portare il proprio Point da un sistema operativo all'altro cambiando solo gli eseguibili). Partiamo quindi con l'accoppiata Binkleyterm + Squish. Per il primo rimando la palla all'articolo di Cesare tensi su questo stesso numero, mentre per Squish ne parliamo ora.

Squish

SQUISH.CFG

Address 2:333/201.2010
Address 175:391/1.5
Address 2:335/336.26
qui specifichiamo i nostri indirizzi in rete (in questo caso tre indirizzi per due reti)

NetFile C:\COMM\INBOUND
questa è la directory dei file in arrivo (posta, file request, ecc.)

;AreasBBS Areas.BBS
questa keyword è commentata (disabilitata), e dice a Squish dove eventualmente leggere il file di aree. Ricordate che lo standard areas.bbs non prevede il multi-aka (also known as, indirizzi diversi) con zone differenti.

;BinkPoint
controversa keyword, in realtá andrebbe abilitata (ricordo che nel nostro point di esempio stiamo usando Binkleyterm come mailer), ma contro ogni logica spiegazione pare creare meno problemi se è disabilitata. In caso di dubbi, non resta che provare.

Compress Compress.Cfg
; For most people, the default COMPRESS.CFG is all that is required.
il commento dell'autore mi sembra esauriente. Solo nel caso della versione per OS/2, nel file COMPRESS.CFG vanno apportate le seguenti modifiche alla voce ZIP:

; Phil Katz's PKZip
Archiver ZIP
Extension ZIP
Ident 0,504b0304 ; "PK^c^d"
Add zip -k -9 -j %a %f
Extract unzip -j %a %f
View zip -v %a

;End Archiver

Routing Route.Cfg
di questo file parleremo piú tardi

OUTBOUND C:\COMM\OUTBOUND
questa è la directory (in realtá diventa un insieme di directory) dove vengono depositati i pacchetti in uscita dal nostro sistema

Quelle che seguono sono keyword a scelta dell'utente (e per la cui descrizione rimando al commento dell'autore) e poco importanti ai fini del funzionamento del Point
CheckZones
Duplicates 1000
DupeCheck Header MSGID
LogFile Squish.Log
LogLevel 6
LinkMsgId
QuietArc
KillDupes
KillBlank
SaveControlInfo
Statistics Squish.STT
Swap C:\Temp\$$SQUISH.SWP
Buffers Large
TossBadMsgs

;Password 175:391/1 xxxxxxxx
ecco un'altra keyword controversa. Di primo acchito verrebbe spontaneo segnare i giusti valori, eppure vi assicuro che anche commentata (come è ora) funziona tutto ugualmente.

; The official FidoNet standard for mail compression is ARC.
DefaultPacker ZIP
In realtá il compattatore ormai piu' usato in Fidonet (e anche in altri net) è il Pkzip, o comunque non certo l'ARC.

ForwardFrom World
ForwardFrom File All:All
due keyword utili per un sistema BBS, meno per un Point

Definiamo le aree di posta privata (matrix, o Netmail) distinte per i due net, e opzionalmente le aree di messaggi in bad e i duplicati

NetArea NETMAIL2 C:\COMM\MAIL\NETMAIL\NETMAIL -$ -h
NetArea NETMAIL175 C:\COMM\MAIL\NETMAIL\NETM175 -$ -h -p175:391/1
BadArea BADMSGS C:\COMM\MAIL\BADMSGS -$
DupeArea DUPEMSGS C:\COMM\MAIL\DUPEMSGS -$

Quello che segue è un elenco delle varie aree echomail definite in questo esempio per 2 net diversi. Rimando al commento originale dell'autore per la definizione esatta delle keyword ausiliarie. Ricordo inoltre che queste definizioni non servono se si usa il file areas.bbs

; FIDONET - 2:333/201
EchoArea 2MANO.ITA C:\COMM\MAIL\FIDONET\2MANOITA -$ -p2:333/201.2010 2:333/201
EchoArea OS2_DEV.ITA C:\COMM\MAIL\FIDONET\OS2DEV -$ -p2:333/201.2010 2:333/201

; FIDONET - 2:335/336
EchoArea 2MANO.300 C:\COMM\MAIL\FIDONET\2MANO300 -$m500 -p2:335/336.26 2:335/336

; CAESARNET - 175:391/1
EchoArea AFORISMI.I C:\COMM\MAIL\CAESAR\AFORISMI -$ -p175:391/1.5 175:391/1
EchoArea CHATTER.I C:\COMM\MAIL\CAESAR\CHATTER -$ -p175:391/1.5 175:391/1
EchoArea BTA_ARTE C:\COMM\MAIL\CAESAR\BTAARTE -$ -p175:391/1.5 175:391/1
EchoArea HARDWARE.I C:\COMM\MAIL\CAESAR\HARDWARE -$ -p175:391/1.5 175:391/1
notate che alla fine del path e dopo la definizione di tipo di base ("-$", che sta per squish) compare la keyword "-p" seguita dall'indirizzo 4D (point) e da quello del nostro boss: solo cosi' Squish saprá gestire correttamente questo che viene chiamato il multi-aka

; END OF FILE

ROUTE.CFG

La logica di questo file di configurazione (del tutto simile a quella di altri file "fratelli") è quella di stabilire dove e per chi mandare i nostri pacchetti di posta nel momento in cui li inviamo fino a quando arriveranno a destinazione. La sintassi per il route, in particolar modo, corrisponde a un "manda per questo_nodo tutti i messaggi per questo_indirizzo" ed è molto utile (se non indispensabile) per i casi di multi-aka come nel nostro esempio.

Send Crash 2:335/336
Send Crash 2:333/201
Send Crash 175:391/1

abbiamo appena definito a chi mandare i nostri pacchetti posta: gli indirizzi del/i nostro/i boss.

Route Crash 2:333/201 2:334/All
Route Crash 2:333/201 2:333/All
Route Crash 2:335/336 1:All 2:All 3:All 4:All 5:All 6:All

ora abbiamo definito la logica di routing a cui deve sottostare Squish per le aree Fidonet: a partire dalla prima riga abbiamo detto che i messaggi per il net 334 (il "all" equivale a dire "tutti" nel pezzo di nodo che si sostituisce, nel nostro caso tutti gli hub del net 334) devono passare per il 2:333/201, in modo Crash, ovvero per chiamata diretta. La stessa cosa per la seconda linea, mentre nella terza abbiamo lasciato tutto il resto nelle..mani del boss 335/336. Attenzione a rispettare l'ordine in cui vengono prima le eccezioni rispetto al routing principale (piu' generale), in questo caso appunto i messaggi del nodo 2:333/201 rispetto a quelli del nodo 2:335/336.

Route Crash 175:391/1 175:All
Route Crash 175:391/1 200:All

qui è la stessa cosa detta finora, applicata al secondo network di cui siamo Point.

; END OF FILE

Per questa volta è tutto. Leggete ora l'articolo su BinkleyTerm di Cesare Tensi e..ci vediamo nel prossimo numero di BETA!

- fine seconda parte -

[ Sommario | Redazione | Informazioni | Vai a... ]

a cura di Luciano Giustini

---

BinkleyTerm, configurazione

di Cesare Tensi

Nel numero precedente della rivista è stato introdotto il concetto di point e della struttura tecnica della rete Fidonet (e di tutte le reti che rispondono alle specifiche techiche della rete stessa). Per una migliore comprensione dell'argomento ne vado a riprendere alcuni concetti. Un point è nello stesso tempo sia un utente di una BBS amatoriale, come lo puó essere una associata alla rete Fidonet, che un nodo vero e proprio ovvero "speciale". Infatti, a un point è concesso d'ufficio, dal sysop della BBS di qui il point fa parte, un numero di nodo "reale" nella rete Fidonet a cui in modo univoco corrisponde quella determinata persona (un pó come il vostro nome e la via in cui abitate) in un formato che puó essere assimilato al seguente:

xxxx:yyyy/zzzz.wwwww

Per maggiori informazioni sia sulla nascita di Fidonet, e parimenti quella delle altri reti amatoriali, che su come sia strutturato la costruzione di un numero di nodo, vedere l'articolo "Un approccio a Fidonet" nel numero precedente di BETA.

Come è stato detto per diventare point di una BBS bisogna prima di tutto contattare il sysop (d'ora in poi chiamato Boss per semplicitá di discorso) al quale si vuole fare riferimento come messaggistica e/o file. Il sysop è un punto di riferimento costante, che dipana eventuali dubbi, che aiuta nei momenti di difficoltá del point, aiutandolo nelle varie configurazioni di tutto.

Ma dato che c'è stata una enorme produzione di software che permette l'uso di una tecnologia "point" certe volte anche lo stesso sysop incontra qualche difficoltá a capire bene il funzionamento concettuale di un determinato programma che usa un point (ma basilarmente sono tre i programmi fondamentali), quindi molte volte capita che non riesce a risolvere problemi incontrati dall'installazione del software. Quindi da qui inizio, in collaborazione con Luciano Giustini nella stessa rubrica Telematica, una piccola descrizione sia dei software a disposizione dei point (e anche dei Boss, perchè no?) che della loro installazione corretta, cercando di dipanare tutti quei dubbi, tutti quei problemi che gli stessi point della mia BBS incontrano nel momento di installarli. Parleró quindi di tre software "principi" per un point che abbia un PC IBM compatibile, sia che abbia il sistema DOS che OS/2, il sistema operativo che finalmente consente un vero multitask nel PC di casa senza avere una macchina molto potente.

I quattro (tre se non si hanno connessioni particolari, cioè appartenere a piú reti) software principi sono i seguenti:

BinkleyTerm v.2.59a.
Squish v.1.11
GoldED v.2.50.Beta5
Compilatore di Nodelist, normalmente FastLst, di produzione italiana (v.1.20)

Come potrete notare quando, eventualmente, scompatterete i file compressi, tutti e tre i programmi hanno come file di configurazione dei file di testo, cioè nulla di configurabile via finestre, opzioni, bottoni e cosi' via (come ci ha abituato la programmazione con il Turbo Vision). E vi chiederete il perchè. Io posso azzardare una risposta: certe volte i file di testo, che configurino un programma complesso o meno, sono piu' "leggibili" di tutte le altri tipi di configurazione, perchè permettono principalmente di leggere il testo riga per riga e modificare le varie keyword (o metacomandi) con valori opportuni limitando al minimo la possibilitá di errore o malconfigurazione. Questo è una cosa normale sia sotto DOS che OS/2 o Unix, dove tutti i file di configurazione (che hanno una estensione comune: *.CFG) sono file di testo. Certamente è una configurazione piú lunga, piú complessa, per vari motivi. Ma state certi che una volta che siete arrivati alla fine, e se avete messo i valori giusti, tutto funzionerá senza alcun problema. E' una mia idea, io preferisco programmi che possono essere configurati in questo modo che tutte quelle finestre dove molte volte si dimentica qualche cosa con qualche malfunzionamento...

Tutti e quattro i software sono disponibili sia per DOS che per OS/2 (BinkleyTerm anche per Windows NT), quindi hanno un ampio parco macchine a disposizione, non credo che ci possano essere problemi (ho intenzione comunque di realizzare un articolo che spieghi come installare un point anche sotto Macintosh) sia a un loro eventuale reperimento che del loro uso. Una volta configurati al meglio si avrá un point funzionante al 100% e cosi' potrete utilizzare la rete Fidonet senza alcun problema...

Per un point sotto il sistema operativo DOS, c'è prima da installare un fossil che rimando, per la sua comprensione, a un altro articolo nella stessa rivista.

---

BinkleyTerm, configurazione

Dopo l'introduzione di rito, passiamo a vedere una tipica configurazione di BinkleyTerm, cioè quel software che permette la connessione con il Boss, usando la linea telefonica, per spedire/ricevere posta (cioè trasmettere la posta che si è scritta e ricevere la posta nuova). BinkleyTerm è un programma strutturato a caratteri e che occupa l'intero monitor (Fig.1), se si vuole si puó differenziare ogni singola finestrella specificando un colore diverso (è quasi sempre possibile).

Qui di seguito un tipico file di configurazione, standard, che puó spiegare alla perfezione come funzionano tutti le varie keyword che possono essere usate dai point, il Normal le keyword di BinkleyTerm, in Bold (grassetto) il commento, le parti precedute dal punto e virgola non hanno significato all'interno del file di configurazione e vengono ignorate da Binkley:

; BINKLEY.CFG - Configuration File for BinkleyTerm 2.50.

; MODEM AND DIAL SETTINGS

Port 1
Rappresenta il numero della porta, fisica, della seriale, quindi 1=COM1, 2=COM2, 3=COM3 ecc.

Baud 19200
Va inserito la massima velocitá supportata dal modem. Normalmente, anche con un 28.8Kbps (V.34), che rappresenta l'ultimo standard delle comunicazioni asincrone via rete telefonica commutata, consiglio il valore di 38400, poichè la totalitá dei files che saranno trasmessi sarannó giá compressi all'origine quindi è perfettamente inutile sovraccaricare il sistema impostando una velocitá della seriale superiore ai 38400.

Carrier 80
E' un valore standard. va lasciato cosi'.

Lockbaud
Blocca la porta al valore prefissato dal comando Baud. In parole semplici, la seriale avrá sempre la velocitá massima e non si adatterá alla velocita della linea (cioè ad esempio: 14.4Kps se chiamate un modem che supporti il V.32bis, eccetera).

; LockBaud /ARQ
Limita, con opportune chiavi, il bloccaggio della porta. In questo caso, solamente se i due modem colloquiano con la correzione d'errore (v42bis e/o MNP5).

; AutoBaud
Imposta automaticamente la velocitá della porta seriale attraverso opportuni valori indicati nella nodelist, l'elenco telefonico delle BBS in formato testo.

NoARQ /None
NoARQ /V32/None
Init ATZ0E0H0&K4#P4141538627|
La stringa di inizializzazione del modem. Non c'e' una stringa univoca per tutti i modem. La piu' semplice è la seguente: ATZX3|. Il carattere "|" lo si ottiene con la successione Shift+"\" e rappresenta il "carriage return". Ricordatevi che la totalitá dei modem provenienti dall'America e piu' in generale dall'estero, o comunque non omologati in Italia, non riconoscono il tono di libero e quello di occupato delle centrali telefoniche italiane e quindi per evitare che il modem abbia qualche problema (del tipo "NO DIALTONE") bisogna inserire, nella stringa di inizializzazione, X3.

TermInit AT E1H0S0=0|
La stringa con il quale il programma pone fine alla comunicazione e/o alla terminazione dello stesso.

Prefix ATDT
Va inserito il modo con il quale il modem chiama un numero, ATDT= usa i toni (per le centrali digitali), ATDP= usa gli impulsi (per le centrali elettromeccaniche, oramai presenti solamente in piccoli centri).

; Suffix
Busy ATS0=0|
La stringa con il quale il modem viene re-impostato ai valori di default quando il Boss è occupato.

Answer ATA|
Questo parametro è ininfluente per un Point. Imposta la stringa quando il modem riceve una chiamata. E' preferibile che sia il programma (in questo caso BinkleyTerm) a rispondere ad un eventuale chiamata e non il modem stesso (alzando il DTR) poichè in eventualitá di blocco del computer non c'è risposta e quindi spreco di scatti da parte del chiamante.

PreDial `
PreInit |v`^`
Impostazioni standard. Non vanno modificati.

Janusbaud 2400
JanusOK /Arq/V32
JanusOK /V32
Queste impostazioni servono per abilitare il protocollo bidirezionale Janus (una specie di HS-Link, piú prestante), molto comodo poichè permette, nello stesso periodo, di spedire e ricevere posta quindi con un minore tempo di collegamento. Il valore da inserire dopo la key JanusBaud è il valore minimo di velocitá (in questo caso 2400) dopo il quale il protocollo janus è abilitato. Chiaramente deve essere una cosa reciproca, cioè anche il vostro boss lo deve aver abilitato.

StartBlkLen 8024

; DISK SETTINGS

Qui di seguito si configurano le directory di sistema.

StatusLog D:\Bink\log\BT01.log
Il Log di BinkleyTerm. In questo file vengono registrate tutte le chiamate che si effettuano.

Nodelist D:\Bink\nodelist\
La directory dove il programma puó trovare la Nodelist compilata.

Version7
Il numero di versione della nodelist compilata. V7 è l'ultima release, la piu' efficente.

NetFile D:\Inbound\
KnownInbound D:\Inbound\
ProtInbound D:\Inbound\
Le tre sottodirectory dove BinkleyTerm pone i file che si ricevono. Piu' precisamente:

NetFile: pacchetti posta.
KnowInbound: directory dove vengono registrati i file provenienti da sessioni conosciute, cioè transazioni con nodi in Nodelist
ProtInbound: directory, invece, configurata per nodi con password. Normalmente il Boss è configurato con Password, per limitare al minimo "intrusioni".

Hold D:\Outbound\
Dove BinkleyTerm puó trovare i pacchetti di posta da spedire.

Snoop \PIPE\LINE1
Questa keyword funziona solamente se il programma è funzionante sotto OS/2. Configura la pipe del programma stesso, cioè su quale canale Binkleyterm puó comunicare il log. Normalmente la PipeLine è utilizzata al di sotto di una LAN dove potrebbe essere impossibile seguire direttamente il computer dove viene eseguito il programma, la pipe consente di avere sotto controllo tutte le operazioni.

;MAILER SETTINGS

System MICS OS/2 Forum #1 [HFN]
Nome del sistema.

Sysop Michael Buenter
Nome del Sysop. Normalmente si mette il nome reale, per un corretto rispetto.

Domain fidonet fidonet nodex
Questa keyword è legata al programma di compilazione della Nodelist, al nome della directory nel quale Binkley puó trovare i pacchetti posta da spedire e al domain della rete. In questo modo:

Domain Domain sottodir Nome_nodelist_Compilata

Address 2:335/336.3@fidonet
Configurazione del proprio numero di point. Inserito nel modo usuale, con chiocciolina e domain. Infatti il mailer lavora fino a cinque dimensioni, avendo sotto controllo fino al domain (Fidonet, Virnet etc),.

Domain virnet virnet nodex
Address 9:395/212.2@irnet
Come si puó vedere per una corretta configurazione, prima deve essere specificato il Domain e appresso il numero di point. In questo modo si possono configurare fino a 10 AKA (Also Know As) diversi, magari per un sistema multi-point.

MyLocation Emmenbruecke CH
MyPhone 41-41-538627
MyListFlags CM,XA,V32B,V42B,FAX,OS/2
MyMaxBaud 14400
Queste servono esclusivamente per farsi riconoscere dal proprio Boss o al sistema al quale si sta chiamando.

---

Bene, a questo punto se avete seguito tutte le istruzioni BinkleyTerm sará perfettamente funzionante. Una prova scioglierá tutti i dubbi. Vi rimando al prossimo numero per la trattazione dell'editor dei messaggi, cioè di quel programma che consente la lettura dei messaggi appena importati con BinkleyTerm e processati dallo Squish.

Al prossimo mese!

[ Sommario | Redazione | Informazioni | Vai a... ]