GW_4_369 factors

[code]prp60 factor: 177403006881130113063302674594810228750950806165895483532597
prp123 factor: 589203883570342218983575340055137303532176542861815435328583489006750174017203999175917086613246958570131196834769562261677
[/code]

RichD completed G[B]C[/B]_4_369 about a week ago, it is displayed on the lasieved page as still being post-processed:
[URL]http://mersenneforum.org/showpost.php?p=358574&postcount=998[/URL]

GW_5_318 factors
 

Took me about an hour to get the post-processing started. The original files had the entire number (a C225) in them. MSIEVE would find 127 as a factor by 15 digit Trial Factoring. It would then search for a C223 in the .fb and .poly which still had the C225 in them. Eventually I realized this and checked the factordb and found out two P16 were also known, so only a C192 remainded:
[B]
GW_5_318[/B]
[CODE]prp49 factor: 4261455268632083287436707603791222620930237118863
prp60 factor: 450063175620763356730945681744698257366095535261401256629363
prp84 factor: 432087545417727621877325644242496506135441396528813761437485005011126996638176541757[/CODE]

C168_130_119 (finally!) factors as:

[CODE]prp76 factor: 9094435764101492192625106166940437077708174382794083374653111205520090825523
prp92 factor: 68086751212664789039528265600039302233534265572638233049445891533014221617435036175941766901[/CODE]

That was a slog!

Edit: FactorDB seems to be down right now, but I'll add these factors when it returns.

I'll take GC_11_234 if it is still available.

GC_11_234 is currently in LA.

ETA 140 hours.

Reserving GC_11_233
 

I'll take it if still available.

GC_11_234 factors
 

[CODE]prp85 factor: 7229682174820941873563372695487534725675448372192856897563207983721936793375770327599

prp113 factor: 65086357586886271288591582353510914906890714130483592560109914639159864703876136112452835963483488138858618058513[/CODE]


Factordb is down, so I could not report these factors.

GC_11_233 has successfully entered LA.

ETA is 160 hours from time of this posting.

Reserving L1364
 

I'll do L1364 - want to see how the new i7-4930 does on linalg

L1364.dat.gz, upon decompression, contains quite a lot (several tens of thousands) of corrupted lines such as

[code]
111,7D209C2D5D1B7E7,2B151D834BAC35,305,7DF56DA12864B276B7B9B177,,885185C9,41170,EB92F7016B118131193570D6:1F47E723E291,37416D49,08A2B10A38ADDF,4FD5,95EE4B,9FA11305,7EB:1F591119,7117967,3AD711A7A38D648AA18-,2C06869562A7118:5E22501,1F43D00FB11A91D6B93907ADDB0EB5116DC99F771305,7EB:17054CB6EAB6B109159,15F78242CA25C63,18951AD32
[/code]

I'm sure the run will work despite this, but I'm a little curious as to how they got there.

This is not unprecedented, though usually there are fewer than tens of thousands of odd lines; it's led to me decompressing the files before use rather than trusting msieve-with-libz to handle weird corruption perfectly.

ETA Sunday evening British time