Il foglio esce. Sembra quasi giusto. Logo al suo posto, righe dritte, margini puliti. Poi si guarda meglio: città diventa citta, oppure è si trasforma in un simbolo estraneo, l’euro sparisce, una descrizione slitta di un carattere e la colonna importi non chiude più. In un documento logistico è già un guaio. In una stampa fiscale o bancaria, peggio.
L’errore viene spesso attribuito al layout o alla stampante appena sostituita. Però il punto, molto spesso, sta prima: nella traduzione del dato verso la pagina, dove CHRID, code page e set di caratteri decidono se il contenuto resterà fedele oppure no.
L’autopsia parte dal difetto, non dal driver
I difetti di questo tipo hanno una caratteristica fastidiosa: sembrano minori. Non bloccano il job, non fanno rumore, non mandano in errore il sistema. Lasciano uscire un foglio apparentemente sano. E proprio lì sta il problema. Un accento sbagliato in una ragione sociale, un simbolo monetario corrotto, una colonna che si sposta di una posizione su un modulo a larghezza fissa: sono errori che arrivano a valle, quando il documento è già stato stampato, piegato, imbustato, archiviato o consegnato. Chi lavora sul campo lo sa: il foglio quasi corretto è spesso più insidioso del foglio palesemente rotto.
Mettiamo il caso di una distinta bancaria con causali e note descrittive, oppure di un documento di trasporto con indirizzi e località. Se il carattere accentato viene reso male, la prima reazione dell’operatore è banale: ristampare. Se il problema tocca una colonna, la reazione cambia: controllo a vista, evidenziatore, telefonata in amministrazione o in magazzino. La stampa, da attività meccanica, torna manuale. E lì arrivano i costi che nessuno vede nel progetto iniziale: tempo perso, rilavorazione, fogli scartati, dubbi sulla versione giusta.
Quasi nessuno apre il caso dicendo: controlliamo CHRID. Di solito si cambia il bersaglio, non la diagnosi.
Dal foglio risalendo a CHRID
IBM, nella documentazione su IBM i 7.6 dedicata alle considerazioni di output per set di caratteri alternativi e code page, lo scrive in modo netto: nei file di stampa descritti dal programma, il parametro CHRID determina la code page e la serie di caratteri usati per stampare i dati. Tradotto in linguaggio da reparto sistemi: il dato può essere corretto nel gestionale e diventare sbagliato nella resa su carta se il passaggio verso il dispositivo usa una mappa diversa da quella attesa. Il problema, quindi, non nasce per forza nel database e nemmeno nel testo del programma. Nasce spesso nella fase che molti trattano come dettaglio di configurazione.
La catena è più delicata di quanto sembri. C’è il contenuto, c’è il file di stampa, c’è lo spool, c’è il dispositivo o la trasformazione che porterà il documento alla stampante. In mezzo, ogni scelta sulla codifica incide su come verranno resi accenti, simboli e spaziature. Basta una combinazione incoerente per alterare il risultato finale. E quando l’applicazione usa campi a larghezza fissa o colonne calcolate al carattere, un segno apparentemente innocuo può produrre anche un disallineamento visivo che rompe la leggibilità del modulo.
Questo passaggio pesa più di quanto si ammetta perché IBM i non è una piattaforma lasciata in un angolo. IBM la presenta come un sistema che integra database, middleware, sicurezza, runtime e hypervisor in un’unica soluzione, con impatto sul TCO. Quando una stampa sbaglia i caratteri dentro un ambiente del genere, non si sta guardando un relitto del passato. Si sta guardando l’ultima tratta di un processo core che perde affidabilità proprio sul foglio, cioè nel punto in cui il dato deve smettere di essere interno e diventare documento.
E la storia non finisce domani. La roadmap IBM i riportata da Sisthema arriva fino al 2031. Chiamarlo legacy in uscita serve a semplificare la discussione, ma nei reparti dove questi sistemi mandano avanti contabilità, logistica e tesoreria la semplificazione dura poco.
Il falso colpevole è il layout
Il layout conta, certo. Chi lavora sulla composizione documentale in ambiente IBM i maneggia questioni molto concrete: fronte/retro, scelta dei cassetti carta, rotazione, formati pagina, posizionamento di moduli e aree testo. La document composition serve proprio a governare questa geometria del documento. Ma c’è un equivoco ricorrente: si pensa che una stampa ben progettata sul piano grafico sia, per definizione, una stampa corretta. Non è così. Il layout organizza ciò che riceve. Se riceve caratteri tradotti male, impagina bene un errore.
È qui che il problema diventa operativo. Un modulo A4 perfetto nella struttura può uscire con descrizioni corrotte, simboli monetari sostituiti, testi che occupano una larghezza diversa da quella prevista. In un documento logistico basta poco per far finire una data nella colonna accanto o per tagliare il nome della destinazione. In una stampa bancaria basta un carattere anomalo per obbligare a un controllo manuale su lotti che dovevano scorrere in automatico. Nei documenti fiscali l’effetto peggiore è uno solo: il foglio appare plausibile, ma non è più del tutto affidabile.
Chi conosce questi ambienti da vicino vede spesso lo stesso copione. Prima si accusa il modello della stampante. Poi il driver. Poi la rete. Il parametro che governa la traduzione dei caratteri arriva tardi, quasi per sfinimento. Eppure in Italia continua a esserci un lavoro molto concreto su stampa grafica, composizione documentale e consulenza per sistemi AS/400 e IBM i, dentro una filiera di fornitori specializzati di cui il sito di https://www.recordinformatica.it offre un esempio diretto. Non è una questione di nostalgia. È che i flussi sono ancora vivi e i fogli devono uscire bene al primo colpo.
3 verifiche prima di cambiare stampante o driver
Prima di ordinare un nuovo dispositivo o aprire l’ennesimo ticket generico, serve fermarsi su tre controlli secchi.
- Verificare dove viene deciso CHRID. Nei file di stampa descritti dal programma il parametro governa code page e serie di caratteri. Se l’applicazione produce moduli diversi, non basta controllare il primo spool difettoso che capita: va mappata la famiglia di stampe coinvolte, cercando differenze tra file, code di output e destinazioni reali.
- Seguire il percorso completo del carattere. La carta è l’ultimo anello. Prima ci sono emulazione, trasformazione di stampa, eventuale passaggio verso PDF, configurazioni del dispositivo e aspettative della stampante rispetto alla code page ricevuta. L’accento errato è spesso il sintomo finale di una traduzione incoerente lungo la catena, non il punto d’origine.
- Provare con un campione cattivo. Non il test cosmetico fatto di numeri, maiuscole e due righe corte. Servono parole con è, à, ò, simboli monetari, campi a larghezza fissa, testi a ridosso del bordo colonna, cambio formato, fronte/retro, rotazione e selezione del cassetto. Se il test passa solo sui casi facili, il problema è soltanto rimandato.
La qualità di stampa su IBM i si misura sul foglio, ma si governa molto prima. Quando gli accenti saltano, i simboli si corrompono o una colonna si sposta di un carattere, la carta sta dicendo che la traduzione del dato è stata trattata come un dettaglio. È proprio il genere di dettaglio che in magazzino rallenta, in amministrazione costringe a rilavorare e in banca fa scattare diffidenza. Un documento può essere ordinato, pulito, perfino elegante. E restare sbagliato da usare.