<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Edwin<br>
<br>
El problema es que hay que tomar en cuenta los límites de la
arquitectura de los registros Isis, que son diferentes si se usan
las versiones 1660, ffi o BigIsis<br>
La versión de ABCD 1.5.x usa 1660 y la versión ABCD 2.0 puede
usar, según lo defina el usaurios, cualquiera de las dos
arquitecturas,<br>
Voy a referirme a los límites para 1660, porque es la que usa
Edwin, la información que sigue no está documentada, es el
resultado de la experiencia de "try and error"<br>
<br>
Empecemos con la estructura de un registro Isis.<br>
Sería conveniente que tuvieran a mano el manual del CISIS<br>
<br>
El registro tiene tres partes: Leader, Directory, Data<br>
El Directory tiene las entradas en un array, de los datos que
están en la parte Data<br>
Pongamos un ejemplo de un registro tomado del CDS que viene de
modelo con el Winisis (que tiene límites menores al 1660)<br>
<br>
<font size="+1"><font face="Courier New, Courier, monospace"><b>mx
CDS from=4</b><br>
mfn= 4<br>
44 «Methodology of plant eco-physiology: proceedings of the
Montpellier Symposium»<br>
50 «Incl. bibl.»<br>
69 «hygrometers»<br>
69 «plant transpiration»<br>
69 «moisture»<br>
69 «water balance»<br>
24 «An Electric hygrometer apparatus for measuring
water-vapour loss from plants in the field»<br>
26 «^c1965»<br>
30 «^ap. 247-257^billus.»<br>
70 «Grieve, B.J.»<br>
70 «Went, F.W.»<br>
951 «##^aBRS»</font></font><br>
<br>
Si quiero mirar la estructura SIN datos pongo:<br>
<font size="+1"><font face="Courier New, Courier, monospace"><b>mx
CDS from=4 -all +dir</b><br>
mfn= 4|dir= 1|tag= 44|pos= 0|len= 77<br>
mfn= 4|dir= 2|tag= 50|pos= 77|len= 11<br>
mfn= 4|dir= 3|tag= 69|pos= 88|len= 11<br>
mfn= 4|dir= 4|tag= 69|pos= 99|len= 19<br>
mfn= 4|dir= 5|tag= 69|pos= 118|len= 8<br>
mfn= 4|dir= 6|tag= 69|pos= 126|len= 13<br>
mfn= 4|dir= 7|tag= 24|pos= 139|len= 89<br>
mfn= 4|dir= 8|tag= 26|pos= 228|len= 6<br>
mfn= 4|dir= 9|tag= 30|pos= 234|len= 20<br>
mfn= 4|dir= 10|tag= 70|pos= 254|len= 12<br>
mfn= 4|dir= 11|tag= 70|pos= 266|len= 10<br>
mfn= 4|dir= 12|tag= 951|pos= 276|len= 7</font></font><br>
<br>
Aqui se tiene la estructura (lay-out) del directorio de ese
registro<br>
Como verán, tiene 12 entradas de campo, y por ejemplo del campo 69
(descriptores) hay 4 ocurrencias<br>
La cantidad máxima de entradas en el directorio (no está
documentado) está entre 750 y 800 para 1660. Además la cantidad
máxima de repeticiones de un campo (ocurrencias, no está
documentado) es menor a 100, o sea, no se pueden tener 200
descriptores, porque cuando van a editarlo se rompe el registro
(prueben si gustan en Winisis ...)<br>
<br>
Entonces, veamos qué pasa cuando se genera el archivo invertido,<br>
El tema es que la FST va a generar en el proceso de indexación
campos virtuales en el registro<br>
Tomemos por ejemplo el campo v24 (titulo) y lo indexamos por
palabra.<br>
Para distinguir las entradas (tags) originales de los datos de los
tags virtuales que generarán los posts, pondremos 666 para esos
datos<br>
<b><br>
</b><font size="+1" face="Courier New, Courier, monospace"><b>mx
cds from=4 -all +dir "fst=666 8 '/TW_/',v24"</b><br>
mfn= 4|dir= 1|tag= 44|pos= 0|len= 77<br>
mfn= 4|dir= 2|tag= 50|pos= 77|len= 11<br>
mfn= 4|dir= 3|tag= 69|pos= 88|len= 11<br>
mfn= 4|dir= 4|tag= 69|pos= 99|len= 19<br>
mfn= 4|dir= 5|tag= 69|pos= 118|len= 8<br>
mfn= 4|dir= 6|tag= 69|pos= 126|len= 13<br>
mfn= 4|dir= 7|tag= 24|pos= 139|len= 89<br>
mfn= 4|dir= 8|tag= 26|pos= 228|len= 6<br>
mfn= 4|dir= 9|tag= 30|pos= 234|len= 20<br>
mfn= 4|dir= 10|tag= 70|pos= 254|len= 12<br>
mfn= 4|dir= 11|tag= 70|pos= 266|len= 10<br>
mfn= 4|dir= 12|tag= 951|pos= 276|len= 7<br>
<font color="#cc0000">mfn= 4|dir= 13|tag= 666|pos=
283|len= 17<br>
mfn= 4|dir= 14|tag= 666|pos= 300|len= 23<br>
mfn= 4|dir= 15|tag= 666|pos= 323|len= 25<br>
mfn= 4|dir= 16|tag= 666|pos= 348|len= 24<br>
mfn= 4|dir= 17|tag= 666|pos= 372|len= 18<br>
mfn= 4|dir= 18|tag= 666|pos= 390|len= 24<br>
mfn= 4|dir= 19|tag= 666|pos= 414|len= 20<br>
mfn= 4|dir= 20|tag= 666|pos= 434|len= 21<br>
mfn= 4|dir= 21|tag= 666|pos= 455|len= 19<br>
mfn= 4|dir= 22|tag= 666|pos= 474|len= 20<br>
mfn= 4|dir= 23|tag= 666|pos= 494|len= 22<br>
mfn= 4|dir= 24|tag= 666|pos= 516|len= 18<br>
mfn= 4|dir= 25|tag= 666|pos= 534|len= 19<br>
mfn= 4|dir= 26|tag= 666|pos= 553|len= 21</font></font><br>
<br>
Ahora tenemos en memoria un registro virtual ISIS que tiene 26
entradas, 12 son los datos originales y 14 los que agrega el
proceso de indexación con la FST<br>
<br>
Para hacer la historia corta, si tienen una FST muy detallada, con
extracciones múltiples por campos, subcampos, y además palabras
individuales de textos, entonces seguramente van a tener una de
dos situaciones (o las dos), (a) la FST generó más de 800 entradas
en el directorio, o tenemos 150 o 200 palabras procedentes de un
texto, y por cualquiera de las dos situaciones el registro se
quiebra y genera archivos dbn.LK1/2 corrompidos que cuando se
llega a la etapa del IFLOAD se rompe el proceso<br>
<br>
Edwin, para probar esta tesis, ingresa por comando al servidor, y
usando tu base pones<br>
<br>
mx <base> fst=@ -all +dir from=<n> count=1 now >
pepe.txt y luego mira el archivo pepe.txt <br>
<br>
La solución es tomar podar/depurar la FST para evitar postings
innecesarios.<br>
Los campos de textos largos, si se van a indexar con palabras, una
solución es limitar el largo del texto a solo el comienzo, por
ejemplo<br>
1 8 '/TW_/', s(v100)*0.100 o alguna cosa similar<br>
<br>
Saludos<br>
Ernesto Spinak<br>
<hr size="2" width="100%"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
l 24/10/2018 a las 11:03, Edwin Hübner escribió:<br>
</div>
<blockquote type="cite"
cite="mid:CABC9y26shDgJrZJrLP9cYf_nSx7v_=DL0M1aWZfGLcMUczyRdw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Agradezco a todos los que han intentado
ayudarme, pero desafortunadamente no he tenido éxito <span
class="gmail_default"
style="font-family:verdana,sans-serif">en</span> ninguno
de los métodos sugeridos.<br>
<br>
El método de Juan, no interrumpe ni en la exportación ni en
la inportación.<br>
<br>
Con el método de Alberto, ejecutando fullinv con mx, tell =
1 sucede lo siguiente:<br>
<br>
1) Con la base de datos actual termina así:<br>
+++ 13177/0<br>
+++ 13178/0<br>
+++ 13179/0<br>
+++ 13180/0<br>
+++ 13181/0<br>
+++ 13182/0<br>
+++ 13183/0<br>
+++ 13184/0<br>
+++ 13185/0<br>
+++ 13186/0<br>
+++ 13187/0<br>
+++ 13188/0<br>
+++ 13189/0<br>
fatal: fullinv / ifload<br>
Donde 13189 es el último mfn</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">2) con la base de datos exportada e importada
termina así<br>
+++ 53399 CC_ / CC_ / CD▒S GRABACIONES SEMINARIO<br>
+++ 53400 CC_ / CC_ / CD▒S SIN IDENTIFICACION<br>
+++ 53401 CC_ / CC_ / CD▒S TCC GESTIÓN FINANCIERA
EMPRESARIAL NEXTEL TURMA<br>
+++ 53402 CC_ / CC_ / CD▒S ▒ VIDEOS, AUDIO Y FOTOS ▒ QH 2011<br>
+++ 53403 CC_ / CC_ / CD▒S: DETALLE DE SERVICIOS PRESTADOS
EMBRATEL; C<br>
fatal: fullinv / ifload<br>
¿Que significa?<br>
saludos<br>
Edwin</div>
</div>
</div>
<br>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
.^. .^.
( ) ( )
=== ===
=[=]================================[=]=
| | Ernesto Spinak | |
| | <a class="moz-txt-link-abbreviated" href="mailto:spinaker@adinet.com.uy">spinaker@adinet.com.uy</a> | |
| | Montevideo, Uruguay | |
| | tel/fax (598) 2622-3352 | |
| | celular (598) 99612238 | |
=[=]================================[=]=
=== ===
( ) ( )
V V </pre>
</body>
</html>