I uploaded another, much smaller certificate without problems. Same OS, same Primo version. The trick with putting multiple certificates into one zip archive and "sneaking in" the difficult one did not work.

I am confused.

I am suspending indefinitely my work on the composites:
[code]
[CENTER][B]Resources used by your IP[/B] ([URL="http://www.factordb.com/help.php?page=1"]?[/URL])
Page requests 14
IDs created 6
Database queries 252
CPU (Wall clock time) 1,507.3 seconds
[COLOR=#FF0000][B]You have reached your hourly limit of 750 seconds CPU-time.[/B][/COLOR]
Counting since January 29, 2018, 4:45 pm [/CENTER]
[/code]

Finally back down below 500,000 composites <= 120 digits. The C100s still look like a formidable barrier.

I think I found a bug dating back to when the DB first started:

[url]http://www.factordb.com/index.php?id=1100000000000000001[/url]
[url]http://www.factordb.com/index.php?id=1100000000000000002[/url]

They both say "is a factor of 20[sup]99999999951179977[/sup]-1", yet that number (with 130102999502881806 digits) is far too large to be in the DB.

The list of composites with no known factors, [url]http://factordb.com/listtype.php?t=3[/url] shows blank output. The problem seems to be the first 98 digit number, from experimenting with various limits.

Chris

[QUOTE=chris2be8;483180]The list of composites with no known factors, [URL]http://factordb.com/listtype.php?t=3[/URL] shows blank output. The problem seems to be the first 98 digit number, from experimenting with various limits.

Chris[/QUOTE]
For me, it appears to be the last 97 digit composite (even though a 98 start won't display):
[code]
http://www.factordb.com/stat_1.php
[/code]shows nine 97 digit composites, but:
[code]
http://factordb.com/listtype.php?t=3&mindig=97&perpage=9&start=1&download=9
[/code]won't show them. However,:
[code]http://factordb.com/listtype.php?t=3&mindig=97&perpage=8&start=1&download=8
[/code]shows the first 8. If I try to get all 98s and some 99s,:
[code]
factordb.com/listtype.php?t=3&mindig=98&perpage=20&start=1&download=20
[/code]it works fine. Perhaps, the first 98 is misrepresented as a 97. Maybe I'll concentrate a machine there and see what it does.

[QUOTE=EdH;483187]Maybe I'll concentrate a machine there and see what it does.[/QUOTE]I've been concentrating on 97s and 98s on two i7s since the above post. More are showing up faster than I'm processing them.

If anyone does contact Syd about this current issue, they might also mention that the following two numbers are prime, but listed in the composites:
[code]
id=1100000000900935563
id=1100000000938546746
[/code]On their pages, if you click the "Factorize!" button, they will change to Prime, but it isn't persistent.

This is not causing any real issue, but if he would like to know of minor things to possibly address when he does work on the db, these may be of interest.

[QUOTE=EdH;483268]If anyone does contact Syd about this current issue, they might also mention that the following two numbers are prime, but listed in the composites:
[code]
id=1100000000900935563
id=1100000000938546746
[/code]On their pages, if you click the "Factorize!" button, they will change to Prime, but it isn't persistent.

This is not causing any real issue, but if he would like to know of minor things to possibly address when he does work on the db, these may be of interest.[/QUOTE]

They actually don't change to P. The problem is that there are pairs of records of the same numbers.
I.e.
[url=http://factordb.com/index.php?id=1100000000900935563]id=1100000000900935563[/url] = [url=http://factordb.com/index.php?id=1100000000902314000]id=1100000000902314000[/url]
[url=http://factordb.com/index.php?id=1100000000938546746]id=1100000000938546746[/url] = [url=http://factordb.com/index.php?id=1100000000938611710]id=1100000000938611710[/url]

[QUOTE=DukeBG;483648]They actually don't change to P. The problem is that there are pairs of records of the same numbers.
I.e.
[URL="http://factordb.com/index.php?id=1100000000900935563"]id=1100000000900935563[/URL] = [URL="http://factordb.com/index.php?id=1100000000902314000"]id=1100000000902314000[/URL]
[URL="http://factordb.com/index.php?id=1100000000938546746"]id=1100000000938546746[/URL] = [URL="http://factordb.com/index.php?id=1100000000938611710"]id=1100000000938611710[/URL][/QUOTE]
They don't change permanently, hence the words "isn't persisitent." They do change status to "P" and the "Report factors" box goes away (at least for me), until you leave the page. Thanks for the duplicate info. Of this, I was unaware. Interestingly, all forms of the number point to the correct prime page, so if the affected indices were removed all would be well with nothing lost (other than the index. I wonder what a missing index might do, though)...

The (atm) 4 smallest PRP´s cant get proven by Primo due to failture.
Again, its n## which is causing problems. I wonder how they passed pfgw.



I was aware of the numbers duke reported, booth are Primes instead of composite. If Syd finds some time he will fix it.