Sottomissione delle richieste tramite file

Prerequisiti

Affinchè il lancio di richieste batch possa essere fatto tramite file, è necessario:

    Che il parametro generale Utilizzo dei file batch sia uguale a Si nei parametri del server batch.

    Che il parametro EXTBATCH sia uguale a Si. Questo parametro, che appartiene al gruppo SUP, può essere definito a livello dossier e utente. E' così possibile vietare completamente il lancio di richieste batch per un dato dossier, accordando se necessario un'eccezione a determinati utenti.

I file di richiesta (estensione .req)

Il lancio di una richiesta batch può essere realizzato tramite il deposito di un file di estensione .job nella directory dedicata a questi file. Questo file deve essere di tipo ascii, strutturato in righe chiuse da <CR> o <CR><LF>, ogni riga definisce il valore di un parametro sotto forma:

PARAMETRO=VALORE

Alcuni parametri sono obbligatori ed identificano il contedto di esecuzione della richiesta. Altri parametri dipendono dalla richiesta da lanciare; il loro nome corrisponde al nome dei parametri definiti nella videata associata al lancio della richiesta. In alcuni casi, un riquadro di parametri è definito nella videata; la sintassi è allora PARAMETRO(indice)=VALORE, dove indice è un valore numerico.

Per facilitare la creazione di un simile file, è possibile lanciare la richiesta dal software, contrassegnando la casella modello nella videata di lancio delle richieste. Se si fa ciò, nella directory di lancio sarà creato un file contenente la lista completa dei parametri di lancio e il loro valore. Questo file è creato con il nome della richiesta e l'estensione .mod.

Nella riquadro qui sotto si trovano il nome dei parametri obbligatori e la loro definizione.

Si noti che i valori del parametro sono indicati senza nessun separatore e che è possibile mettere delle righe di commenti prefissati dal carattere #. Così, si potrà mettere nel file delle richieste:

         # Parametri obbligatori

         DOSSIER=DEMO

         DATE=20020614

        …

       # Parametri complementari

       PARAM(1)=TEST

        PARAM(2)=ABC

Cinematica dell'elaborazione dei file di richiesta

Il server batch ispeziona a intervalli regolari il contenuto della directory dedicata ai file di richiesta. Al momento dell'ispezione, legge i file presenti nella directory prendendoli nell'ordine ascii. Si consiglia quindi di chiamare questi file con una radice fissa e un numero sequenziale su una lunghezza fissa. Si potrebbe per esempio nominarli REQ000001.req, REQ0000002.req…

Durante l'elaborazione di ogni file, vengono creati dei file successivamente nelle varie directory definite dai parametri del server batch. Tali file sono definiti qui in basso:

Si noti che il fatto che un file xxxxx.run esista non significa necessariamente che la richiesta in questione giri. Infatti, se il server batch è stato arrestato senza arrestare le richieste che giravano, i file xxxxx.run corrispondenti esisteranno sempre anche se la richiesta avrà terminato la sua elaborazione. In questo caso, neanche il file xxxxx.sta verrà creato. Al contrario, quando il server sarà lanciato di nuovo, il file xxxxx.run verrà cancellato, un filexxxxx.stache contiene uno stato particolare viene allora creato.

Il numero di richieste batch in corso di elaborazione non deve necessariamente dedursi dal numero dei file xxxxx.run presenti nella directory dedicata.

Descrizione dei file XXX.sta, XXX.run, XXX.kil

Questi file sono dei file ascii, codificati in ascii 8 bits, presenti in diverse directory, secondo la parametrizzazione:

• Il file .kil può essere vuoto o contenere un commento che sarà ripreso nel file di estensione .sta
• Il file .run contiene una riga conforme alla struttura definita qui in basso, le informazioni indicate sono il numero della richiesta, la data e l'ora di inizio e il codice del job (le altre informazioni sono alimentate con degli 0 o degli spazi)
• Il file .sta contiene una riga il cui formato è definito qui in basso, tutti i campi sono alimentati.

La struttura della riga unica contenuta nei file .run e .sta è la seguente:

• La riga è composta da 8 campi di lunghezza fissa con dei separatori (il carattere due punti ‘ :’).
• La lunghezza totale è di 154 o 155 caratteri

Lo schema esatto è il seguente:

Il campo messaggio permette, se necessario, di spiegare il codice errore. E' memorizzato nella lunghezza fissa di 80 caratteri (il messaggio è completato, se necessario, da spazi)

Il numero di richiesta è memorizzato su 8 caratteri, se necessario prefissato da degli zero. Questo numero permette di conoscere il nome del file di traccia generato all'esecuzione della richiesta. Infatti, questo file si chiama RQTNNNNNNNN.tra (dove NNNNNNNN è il numero di richiesta su 8 caratteri). Lo si trova nella sottodirectory TRA del dossier SERVX3. Si noti che questo numero può essere nullo in alcuni casi di errore, se non è stato possibile lanciare nessuna richiesta.

Il codice del job corrisponde al job o al concatenamento di job lanciati, così come conosciuto nella tabella dei job o dei concatenamenti.

Il codice stato, su 5 caratteri numerici, permette di conoscere il risultato dell'esecuzione. La prima cifra determina il risultato globale dell'esecuzione, mentre le cifre successive forniscono delle informazioni complementari. Quando la richiesta è terminata senza errori e senza avvisi, si ha un codice errore uguale a 00000. Il dettaglio dei codici è fornito qui in basso:

Osservazioni

Nel quadro della modellizzazione dei job batch (modello GTRAITE), occorre notare che l'utente dispone delle seguenti variabili, accessibili nei job specifici o in jobs standard tramite entry point :

• La variabile GOK è uno stato aggiornato a partire dal lancio del job. Vale 1 se non ci sono problemi, 0 in caso di errore di lock, -1 su un errore grave e 2 su un errore grave di coerenza del server. Questa variabile è gestita dai jobs standard: se non vale 1 alla fine dell'elaborazione batch, il job appare in stato Errore in controllo dei jobs; in questo caso, se il job fa parte di un gruppo di jobs, i jobs successivi sono bloccati e non saranno mai lanciati.
• La variabile GERREUR viene valorizzata solo in caso di errore all'esecuzione di un'istruzione (è il numero di errore che corrisponde ad un'eccezione elaborata dall'istruzione Onerrgo). Se questa variabile non è nulla alla fine del job, lo stato del job è posizionato su Fallito in controllo dei jobs, e i jobs che seguono sono bloccati, se il job fa parte di un gruppo.
• La variabile GERRTRACE permette di contare il numero di righe di traccia di errore create dal job. E' gestita anch'essa dai jobs standard. Il fatto che sia positiva mette il job in Errore nel job di controllo, senza però bloccare il concatenamento dei jobs successivi in un gruppo. Infatti si tratta del conteggio di un numero di righe di errore che si suppongono non essere gravi.
• La variabile GERRBATCH è una variabile numerica supplementare, che permette di dare un codice di errore che dipende dal job se si considera che il job non è terminato bene (indipendentemente dal fatto che delle righe di traccia di errore siano state o meno generate). Se il valore GERRBATCH è inferiore a 100, si considera che si tratta di uno stato di errore non grave. Se in compenso il valore di GERRBATCH è maggiore o uguale a 100, lo stato del job nella funzione di controllo dei job passa a Errore alla fine dell'esecuzione, e se il job fa parte di un gruppo, il concatenamento dei job successivi si interrompe. Questa variabile è stata creata per permettere una gestione di errore specifico tramite un entry point..
• La variabile GMESSBATCH è una variabile alfanumerica che permette di dare un messaggio di errore complementare. Questo messaggio è inserito nel contenuto del file di estensione .sta se si verifica un errore.

Salvo errore di coerenza al lancio, i job batch standard del software considerano in tutti i casi che gli errori riscontrati non sono gravi e aggiornano semplicemente la traccia incrementando GERRTRACE. Ciò significa che ogni errore grave che deve interrompere l'elaborazione deve essere trattato in modo specifico tramite entry point, dando a GERRBATCH un valore superiore a 100.

Descrizione del file server.tra

Questo file, presente nella sotto-directory TRA della directory SERVX3, contiene la traccia del server. La struttura delle righe è conforme a quella di un file di traccia classico (testata normalizzata e stati numerici su 5 caratteri). Ogni riga è composta da un testo eventualmente prefissato da un numero (questo numero è lui stesso preceduto dal carattere < se si considera che si tratta di un errore, da = se si tratta di un avviso.

I numeri degli stati successivi esistono (sono prefissati da 4 e 5 per delle ragioni di continuità di numerazione con gli stati precedenti). Si osservi che gli stati che cominciano con 4 sono degli stati gravi che non dovrebbero capitare in una gestione normale (problemi di aggiornamento, di gestione dei jobs, di lock del server batch) e possono provenire da problemi sistemistici, sia da una cattiva installazione, o ancora da specifici. Gli stati che cominciano con 5 sono stati normali dell'attività del server batch:

Descrizione dei file RQTNNNNNNNN.tra

Questi file, presenti nella sotto-directory TRA della directory SERVX3, contengono la traccia associata alla richiesta stessa. La struttura delle righe è conforme a quella di un file di traccia classico (testata normalizzata e stati numerici su 5 caratteri). Ogni riga è composta da un testo eventualmente prefissato da un numero (questo numero è preceduto dal carattere < se si considera che si tratta di un errore o di un avviso). Questi file possono essere letti direttamente dal gestore delle richieste con un clic destro / Lettura traccia.

Superata la riga di testata, la prima riga di un tale file si presenta sotto forma di una riga dal seguente formato (integra lo stato Attivazione richiestadefinito qui in basso):

=51000 NNNNNNNNGG/MM/AA hh :mm :ss Attivazione richiesta (51000)

(NNNNNNNNrappresenta qui il numero del job)

Le righe di traccia classica del job seguono questa prima riga (se l'elaborazione in questione non è lanciata in batch, queste righe sarebbero scritte in un file di traccia classico FNNNNN.tra nella directory TRA del dossier di lancio). Poi, salvo nel caso in cui il job sia stato arrestato bruscamente (con un killadx, per esempio), si troverà una riga finale di struttura identica, ma il cui numero è conforme allo stato di fine corretto (00000) o di errore (1NNNN) descritto sopra.

Tabelle utilizzate

Le tabelle utilizzate dalla funzione sono le seguenti:

• Tabella ABATRQT
• Tabella ABATTAC
• Tabella ABATGRP