One tap mobile +16468769923,,831622397# US (New York) +16699006833,,831622397# US (San Jose)
Dial by your location +1 646 876 9923 US (New York) +1 669 900 6833 US (San Jose) Meeting ID: 831 622 397 Find your local number: https://cornell.zoom.us/u/apAE4wSY5
progress on saving a snapshot of voyager data in postgres that can still be used for reporting after the migration to FOLIO
dealing with the MARC has proved most difficult
geting postgres to match byte for byte voyager was a trick, but managed to do it
data type in postgres is BITA byte array
tables have moved to postgres
MARC segments have been concatenated in postgres tables (views in voyager become tables in postgres)
oraclepg to do this
the marc is byte for byte the same as what was in voyager
can we read it from a microsoft access report that uses some VBA that reads blobs? so far we haven't been able to do that. everything looks good on the surface. postgres odbc drive has option to read byte array as large object but checking the box hasn't helped. Access doesn't import the table, it creates a link. So something on the postgres side has to be providing access a way to support large objects. There's a large object ll module for postgres but AWS won't support it for RDS. Can we load it on an AWS box ourselves? Yes, now have PG with LL module, hosting the byte array marc tables as well as other tables and they all look good but microsoft access reports are still unable to read that marc. Created consistent system of records. When we read the table out, the marc is an OLE object but still can't read, just get empty result set. Suggests the VBA package that is reading through the oracle ODBC driver is doing something specific to Oracle to do that, going to get in touch with the person that wrote the package.
Cornell use cases around vernacular data which is only in the MARC
 Circ rules discussion
Andy
Cornell group looking at access services settings. A lot of trial and error at first, now getting more systematic. RA sig is also talking about circ rules right now. Missouri State and Simmons have also demo'd their work. Talked to Simmons and Chicago. Working through all the settings you have to do before you get to the circ rules. Hoping to have settings populated by April to facilitate testing in April. Hoping to have test plan in May, do tests in June/July. Each of the settings types comparing to what is in Voyager and finding areas for simplification. A lot of progress on the loan policies, also locations simplification.
How are people delegating the work? A&M catalogers looking at locations, circ looking at circ times. 131 down to 76. Working on collapsing loan policies before writing circulation rules. Documentation? Can get them out from the API as one way
Timeline? A&M testing - circ staff asked for basic rules for testing planned in mid-March, just loan policies plus request policies. For the basic patron groups.
Project management? Closer to one thing at a time than timeline but will need timelines soon. Had been focused on db clean up. Learning from MARC clean up, the mapping from marc to instance - seeing what is an error and what needs to fix
Alabama - multiple threads running, sometimes have bottlenecks because a small number of people need to make decisions. Mostly in test mode for several months.
MARC errors having to fix? URL fields that don't have a $u, the mapping requires it, if no 856$u throws it out. An improper restriction or a bug? Maybe make a ticket. OCLC had been putting hex codes in the leader to indicate if update or correction and it is throwing those out. 6xx or 7xx with no $a.
3.9 million srs records in Texas, taking a week! Alabama full collection soon. UA will load through the API. Loaded 1.3million for Missouri State with the same script. 5 colleges after that. SRS slows down as it gets filled up. Have to tweak some things or you'll never make it. Camunda workflow pulls straight out of Voyager and then into FOLIO using APIs with the triggers and syncing across the modules, it slows down. Engine let's them stop and restart which is very helpful.
High cost for loading means migrating in place is really needed
Production level loading needed by beginning of 2021
Round III/ Round IV impressions? discussion?
Balancing feature/tech development
Understanding what is needed in larger library marketplace
Being able to get in a successful loaded is needed for real testing
Getting a load that works even if it is slow is a good milestone