CHAIN e SETGT/READ

[Gatto]

Solo per curiosità, ho sempre avuto un dubbio sull'utilità o meno di
riposizionarsi dopo una chain in determinate situazioni. Forse con un
esempio mi spiego meglio.
Mettiamo caso che ho un ciclo di lettura su un file logico che devo
aggiornare solo in certe condizioni, ma in fase di READ non voglio
allocare il record. Quindi per poterlo aggiornare devo fare lòa chain
del record appena letto, modificare i valori che interessano e
aggiornare. Di solito poi rieseguo il posizionamento con SETGT prima
della READ successiva... Ma mi chiedo: in questo caso la SETGT è
proprio necessaria? Non sono già posizionato?
READ e CHAIN sono codici operativi diversi, da un certo punto di
vista, ma in effetti si posizionano in un certo punto del file.
Spero di essermi spiegato bene.

Ciao
Marco

[L'Enigmista]

Non occorre la setgt
Ciao

[Gatto]

Post by L'Enigmista
Non occorre la setgt
Ciao

Ok, grazie. Quindi è come pensavo

Ciao
Marco

[stefano[dot]tassi[at]dedanext[dot]it]

Post by Gatto
Solo per curiosità, ho sempre avuto un dubbio sull'utilità o meno di
riposizionarsi dopo una chain in determinate situazioni. Forse con un
esempio mi spiego meglio.
Mettiamo caso che ho un ciclo di lettura su un file logico che devo
aggiornare solo in certe condizioni, ma in fase di READ non voglio
allocare il record. Quindi per poterlo aggiornare devo fare lòa chain
del record appena letto, modificare i valori che interessano e
aggiornare. Di solito poi rieseguo il posizionamento con SETGT prima
della READ successiva... Ma mi chiedo: in questo caso la SETGT è
proprio necessaria? Non sono già posizionato?
READ e CHAIN sono codici operativi diversi, da un certo punto di
vista, ma in effetti si posizionano in un certo punto del file.
Spero di essermi spiegato bene.
Ciao
Marco

read(n)

[Gatto]

On 26 Lug, 20:15, "stefano[dot]tassi[at]dedanext[dot]it"

Post by stefano[dot]tassi[at]dedanext[dot]it

Post by Gatto
Solo per curiosità, ho sempre avuto un dubbio sull'utilità o meno di
riposizionarsi dopo una chain in determinate situazioni. Forse con un
esempio mi spiego meglio.
Mettiamo caso che ho un ciclo di lettura su un file logico che devo
aggiornare solo in certe condizioni, ma in fase di READ non voglio
allocare il record. Quindi per poterlo aggiornare devo fare lòa chain
del record appena letto, modificare i valori che interessano e
aggiornare. Di solito poi rieseguo il posizionamento con SETGT prima
della READ successiva... Ma mi chiedo: in questo caso la SETGT è
proprio necessaria? Non sono già posizionato?
READ e CHAIN sono codici operativi diversi, da un certo punto di
vista, ma in effetti si posizionano in un certo punto del file.
Spero di essermi spiegato bene.
Ciao
Marco

read(n)
--
--
Programming  today is  a race between software engineers  striving to
build  bigger and better idiotproof programs, and the Universe trying
to produce  bigger and better idiots. So far the Universe is winning.
(Rick Cook)

Sì, in pratica la logica sarebbe questa:

do *hival
read(n) MioFile
if %eof
leave
endif
If condizione
klist chain MioFile
...
modifiche sui campi
...
update record
klist setgt MioFile
enddo

Dove la ovviamente klist è la chiave univoca per allocare il record
appena letto e poterlo aggiornare. Quello che mi chiedevo è se dopo
aver aggiornato i dati devo riposizionarmi dopo quel record con la
"klist setgt MioFile", ma da quello che pensavo e come ha
confermato l'Enigmista è superfluo.

Ciao
Marco

[Danilo Cussini]

Post by Gatto
Solo per curiosità, ho sempre avuto un dubbio sull'utilità o meno di
riposizionarsi dopo una chain in determinate situazioni. Forse con un
esempio mi spiego meglio.
Mettiamo caso che ho un ciclo di lettura su un file logico che devo
aggiornare solo in certe condizioni, ma in fase di READ non voglio
allocare il record. Quindi per poterlo aggiornare devo fare lòa chain
del record appena letto, modificare i valori che interessano e
aggiornare. Di solito poi rieseguo il posizionamento con SETGT prima
della READ successiva... Ma mi chiedo: in questo caso la SETGT è
proprio necessaria? Non sono già posizionato?

Direi che è necessaria solo se modifichi il valore di un campo chiave. E comunque è pericolosa perchè se la chiave non è univoca rischi di saltare dei record. In casi analoghi io leggevo un LF definito input e aggiornavo il PF facendo un CHAIN col RRN. Con SQL è decisamente tutto più semplice.

[Obelix-it]

Post by Danilo Cussini
Direi che è necessaria solo se modifichi il valore di un campo chiave.

??? Direi au contraire: fa danni solo se aggiorni la chiave... se sai
che non la aggiorni, pace...

Post by Danilo Cussini
In casi analoghi io leggevo un LF definito input e aggiornavo il PF facendo un CHAIN col RRN.

Mi sfugge il perche' dell'RRN (io sempre fatto ocn logico e update del
fisico. èer via de commit). Non userei RRN nei prgrammi neanche sotto
costrizione...

Post by Danilo Cussini
Con SQL è decisamente tutto più semplice.

In linea generale, potrei dissentire (specialmente se le condizioni
includono verifiche su altri file...)

[Danilo Cussini]

Post by Obelix-it
??? Direi au contraire: fa danni solo se aggiorni la chiave... se sai
che non la aggiorni, pace...

Stiamo dicendo la stessa cosa, cioè se modifichi il valore di una colonna chiave devi riposizionarti con la vecchia chiave prima di riprendere il loop di lettura. Probabilmente Gatto esegue un SETGT per avere la sicurezza di evitare questo problema.

Post by Obelix-it
Mi sfugge il perche' dell'RRN (io sempre fatto ocn logico e update del
fisico. èer via de commit). Non userei RRN nei prgrammi neanche sotto
costrizione...

Quando non c'è una chiave primaria sei costretto ad usare RRN, quindi avevo preso l'abitudine di usare sempre RRN.

Post by Obelix-it
In linea generale, potrei dissentire (specialmente se le condizioni
includono verifiche su altri file...)

*Solo* se le condizioni includono verifiche su altri file (per me in questo caso il match finisce pari); se invece le condizioni sono tutte sul file da aggiornare, allora SQL è decisamente meglio.

[Gatto]

Post by Danilo Cussini

Post by Obelix-it
??? Direi au contraire: fa danni solo se aggiorni la chiave... se sai
che non la aggiorni, pace...

Stiamo dicendo la stessa cosa, cioè se modifichi il valore di una colonna chiave devi riposizionarti con la vecchia chiave prima di riprendere il loop di lettura. Probabilmente Gatto esegue un SETGT per avere la sicurezza di evitare questo problema.

Post by Obelix-it
Mi sfugge il perche' dell'RRN (io sempre fatto ocn logico e update del
fisico. èer via de commit). Non userei RRN nei prgrammi neanche sotto
costrizione...

Quando non c'è una chiave primaria sei costretto ad usare RRN, quindi avevo preso l'abitudine di usare sempre RRN.

Post by Obelix-it
In linea generale, potrei dissentire (specialmente se le condizioni
includono verifiche su altri file...)

*Solo* se le condizioni includono verifiche su altri file (per me in questo caso il match finisce pari); se invece le condizioni sono tutte sul file da aggiornare, allora SQL è decisamente meglio.

Ok, direi che la risposta che ho dato stamattina a Stefano Tassi
toglie il dubbio della chiave univoca, a questo punto faccio
un'ulteriore "if" (con conseguente riflessione).
If... modifico i campi chiave, dopo ì'aggiornamento è meglio fare una
setgt (o setll a questo punto è indifferente dato che uno dei
presupposti è la chiave univoca) con i valori originali
else... aggiorno il record e procedo direttamente con la lettura
...endif

Da quello che intuisco modificando i campi chiave il posizionamento
nel file logico cambia, quindi devo tornare alla posizione di prima,
mentre se la chiave rimane invariata non serve.
Per quanto riguarda l'SQL mi dispiace deludervi ma sono un perfetto
ignorante: a parte qualche select, update o delete non ho mai fatto
niente di più... al massimo delle select combinando i dati di 2 files.
Quando con un SQL sono riuscito a fare un confronto fra i movimenti di
magazzino e le pelli inventariate tramite barcode per me è stato un
successone! Lo so, è una gran pecca non sfruttare di più le
potenzialità dell'SQL e sono convinto che fare delle procedure SQL e
studiare meglio anche le SELECT possa aiutare parecchio e magari
risparmiare codice RPGLE in molti casi... Ma qui sono quello che fa
più esperimenti, tanti nella mia ditta vanno in confusione quando
trovano una specifica RPGLE con l'eval, se vedono un richiamo a delle
API di sistema sembra di andare sulla luna. Se non sbaglio è stato
pochi giorni fa che si parlava di programmazione RPGLE o di programmi
in RPGIII semplicemente convertiti in ILE: ecco, la maggior parte
della ditta lavora su sorgenti ILE ma sfruttando solo l'RPGIII.


Comunque grazie a tutti per le delucidazioni
Marco

[fm]

CUT

Post by Gatto
Da quello che intuisco modificando i campi chiave il posizionamento
nel file logico cambia, quindi devo tornare alla posizione di prima,
mentre se la chiave rimane invariata non serve.

IMVVVVVHO
Se la chiave rimane invariata il problema non si pone.
Altrimenti ci andrei coi piedi di piombo...
Dubito che, in generale, sia una buona tecnica cambiare il campo chiave
di un LF mentre sto leggendo in sequenza con la read LO STESSO file
logico...

Cosa succede ad esempio se il record appena letto ed aggiornato si porta in
avanti nella
sequenza delle chiavi, fra quelli ancora da leggere ? viene aggiornato piu'
volte?
Oppure, se si creano delle chiavi doppie cosa succede?
Ancora: si puo' generare un loop infinito?

meglio usare l'SQL.....o creare una primary key (che nei files soggetti a
questo tipo di
operazioni non e' un'idea malvagia).... o un file temporaneo....
insomma usare un metodo diverso.

ciao
fm

[Obelix-it]

Post by fm
Cosa succede ad esempio se il record appena letto ed aggiornato si porta in
avanti nella
sequenza delle chiavi, fra quelli ancora da leggere ? viene aggiornato piu'
volte?

Esatto. Visto che leggi per chiave, se sposti la chiave ti ritrovi il
record di nuovo.

Se vuoi provare: creati un record con chiave numerica, caricaci un unico
record con chiave = 1, quendi fai un loop di lettura incrementando la
chiave di 1. Il loop non si ferma piu'...

Post by fm
Oppure, se si creano delle chiavi doppie cosa succede?

Vabbe', *quello* e' un normale errore, che monitorizzi tu. Il problema
delle chiavi doppie ce l'hai in qualsiasi maniera tu voglia gestirlo
(salvo ovviamente, un loop di Read/cambia chiave/chain nuova
chiave/update/ri9posizionanti sulla vecchia chiave..)

Post by fm
Ancora: si puo' generare un loop infinito?

Yup. Infinito no, ma fino al raggiungimento di *HIVAL senz'altro si.
Prima o poi si schianta..

Post by fm
meglio usare l'SQL.....o creare una primary key (che nei files soggetti a
questo tipo di operazioni non e' un'idea malvagia).... o un file temporaneo....

Uh?? Basta *Semplicemente* un IP senza chiave su un logico e aggiornare
il fisico per chiave. Nessuna delle soluzioni indicate e' veramente
utile quanto.. (SQL ti lascia il problema delle chiavi duplicate, la
Primary Key probabilmente c'e' gia' (visto che aggiorna per chiave), o
almeno una Unique Key, che non e' la stessa cosa (c) ma ci assomiglia
abbastanza, il file temporaneo non ha senso specie se hai, diciamo, un
28mln di record ...)

Post by fm
insomma usare un metodo diverso.

As usual: it depends. Personalmente, di solito uso un IP senza chiave
con accesso Update lo stesso, tanto i tempi di allocazione dei record
sono negligibili. Se devo effettuare aggiornamento 'balzellon
balzelloni', scrivo due moduli: uno legge, l'altro scrive (e un terzo,
"che sorveglia i due pericolosi intellettuali" (c) :) ), se devo
aggiornre le chiavi, Mmmmmh, ho sbagliato qualcosa nell'analisi :O

[Gatto]

Post by Obelix-it

Post by fm
Cosa succede ad esempio se il record appena letto ed aggiornato si porta in
avanti nella
sequenza delle chiavi, fra quelli ancora da leggere ?  viene aggiornato piu'
volte?

Esatto. Visto che leggi per chiave, se sposti la chiave ti ritrovi il
record di nuovo.
Se vuoi provare: creati un record con chiave numerica, caricaci un unico
record con chiave = 1, quendi fai un loop di lettura incrementando la
chiave di 1. Il loop non si ferma piu'...

Post by fm
Oppure, se si creano delle chiavi doppie cosa succede?

Vabbe', *quello* e' un normale errore, che monitorizzi tu. Il problema
delle chiavi doppie ce l'hai in qualsiasi maniera tu voglia gestirlo
(salvo ovviamente, un loop di Read/cambia chiave/chain nuova
chiave/update/ri9posizionanti sulla vecchia chiave..)

Post by fm
Ancora: si puo' generare un loop infinito?

Yup. Infinito no, ma fino al raggiungimento di *HIVAL senz'altro si.
Prima o poi si schianta..

Post by fm
meglio usare l'SQL.....o creare una primary key (che nei files soggetti a
questo tipo di  operazioni non e' un'idea malvagia).... o un file temporaneo....

Uh?? Basta *Semplicemente* un IP senza chiave su un logico e aggiornare
il fisico per chiave. Nessuna delle soluzioni indicate e' veramente
utile quanto.. (SQL ti lascia il problema delle chiavi duplicate, la
Primary Key probabilmente c'e' gia' (visto che aggiorna per chiave), o
almeno una Unique Key, che non e' la stessa cosa (c) ma ci assomiglia
abbastanza, il file temporaneo non ha senso specie se hai, diciamo, un
28mln di record ...)

Post by fm
insomma usare un metodo diverso.

As usual: it depends. Personalmente, di solito uso un IP senza chiave
con accesso Update lo stesso, tanto i tempi di allocazione dei record
sono negligibili. Se devo effettuare aggiornamento 'balzellon
balzelloni', scrivo due moduli: uno legge, l'altro scrive (e un terzo,
"che sorveglia i due pericolosi intellettuali" (c) :) ), se devo
aggiornre le chiavi, Mmmmmh, ho sbagliato qualcosa nell'analisi  :O

Giustamente mi mettete in guardia nel fatto di cambiare le chiavi, ma
a volte può rivelarsi necessario... Si pendi ad esempio ad un DDT
inserito per un cliente sbagliato: in questo caso devo leggere tutte
le righe di quel e modificare il codice cliente, ma in questo caso si
limita l'aggiornamento ad un range di dati limitato.
Ovviamente aggiornare una chiave leggendo un intero archivio deve
essere fatto con parsimonia, assicurandosi di non aggiornare di nuovo
record già elaborati, magari memorizzando le chiavi di quei record in
un file di lavoro... In questi casi devono essere fatti tutti i
controlli del caso, compreso evitare chiavi doppie.

Grazie mille a tutti per i chiarimenti.
Marco

[Obelix@Home]

Post by Gatto
Si pendi ad esempio ad un DDT
inserito per un cliente sbagliato: in questo caso devo leggere tutte
le righe di quel e modificare il codice cliente,

In quel caso, e' sbagliato il design del database: il cliente va variato
solo in un posto, ovvero la testata del documento. Se lo ripeti in piu'
righe 'e un errore di design da tripla sottolineatura rossa...

Post by Gatto
Ovviamente aggiornare una chiave leggendo un intero archivio deve
essere fatto con parsimonia,

Se aggiorni per chiave, che senso ha aggiornare l'intero archivio??