Docs: fix uneven lengths of code delimiter blocks
[Evergreen.git] / docs / admin / sip_server.adoc
1 SIP Server
2 ----------
3
4 About the SIP Protocol
5 ~~~~~~~~~~~~~~~~~~~~~~
6
7 indexterm:[Automated Circulation System]
8 indexterm:[SelfCheck]
9 indexterm:[Automated Material Handling]
10
11 +SIP+, standing for +Standard Interchange Protocol+, was developed by the +3M corporation+ to be a common 
12 protocol for data transfer between ILS' (referred to in +SIP+ as an _ACS_, or _Automated Circulation System_)  and a 
13 third party device. Originally, the protocol was developed for use with _3M SelfCheck_ (often abbreviated SC, not to 
14 be confused with Staff Client) systems, but has since expanded to other companies and devices. It is now common 
15 to find +SIP+ in use in several other vendors' SelfCheck systems, as well as other non-SelfCheck devices. Some 
16 examples include:
17
18 * Patron Authentication (computer access, subscription databases) 
19 * Automated Material Handling (AMH) 
20 ** The automated sorting of items, often to bins or book carts, based on shelving location or other programmable 
21 criteria
22
23 Installing the SIP Server
24 ~~~~~~~~~~~~~~~~~~~~~~~~~
25
26
27
28 This is a rough intro to installing the +SIP+ server for Evergreen. 
29
30 Getting the code 
31 ^^^^^^^^^^^^^^^^
32
33 Current +SIP+ server code lives at in the Evergreen git repository:
34
35    cd /opt 
36    git clone git://git.evergreen-ils.org/SIPServer.git SIPServer 
37
38
39 Configuring the Server 
40 ^^^^^^^^^^^^^^^^^^^^^^
41
42 indexterm:[configuration files, oils_sip.xml]
43
44 . Type the following commands from the command prompt: 
45
46    $ sudo su opensrf 
47    $ cd /openils/conf 
48    $ cp oils_sip.xml.example oils_sip.xml 
49
50 . Edit oils_sip.xml. Change the commented out <server-params> section to this: 
51
52    <server-params
53       min_spare_servers='1' 
54       max_spare_servers='2' 
55       min_servers='3'
56       max_servers='25' 
57                 />
58
59 . max_servers will directly correspond to the number of allowed +SIP+ clients. Set the number accordingly, but 
60 bear in mind that too many connections can exhaust memory. On a 4G RAM/4 CPU server (that is also running 
61 evergreen), it is not recommended to exceed 100 +SIP+ client connections. 
62
63 Setting the encoding
64 ++++++++++++++++++++
65
66 SIPServer looks for the encoding in the following
67 places:
68
69 1. An +encoding+ attribute on the +account+ element for the currently active SIP account.
70 2. The +encoding+ element that is a child of the +institution+ element of the currently active SIP account.
71 3. The +encoding+ element that is a child of the +implementation_config+ element that is itself a child of the +institution+ element of the currently active SIP account.
72 4. If none of the above exist, then the default encoding (ASCII) is used.
73
74 Option 3 is a legacy option.  It is recommended that you alter your configuration to
75 move this element out of the +implementation_config+ element and into
76 its parent +institution+ element.  Ideally, SIPServer should *not* look into
77 the implementation config, and this check may be removed at some time
78 in the future.
79
80 Datatypes
81 +++++++++
82
83 The `msg64_hold_datatype` setting is similar to `msg64_summary_datatype`, but affects holds instead of circulations.
84 When set to `barcode`, holds information will be delivered as a set of copy barcodes instead of title strings for
85 patron info requests. With barcodes, SIP clients can both find the title strings for display (via item info requests)
86 and make subsequent hold-related action requests, like holds cancellation. 
87
88
89 Adding SIP Users
90 ^^^^^^^^^^^^^^^^
91
92 indexterm:[configuration files, oils_sip.xml]
93
94 . Type the following commands from the command prompt: 
95
96   $ sudo su opensrf 
97   $ cd /openils/conf
98
99 . In the +<accounts>+ section, add +SIP+ client login information. Make sure that all +<logins>+ use the same 
100 institution attribute, and make sure the institution is listed in +<institutions>+. All attributes in the 
101 +<login>+ section will be used by the +SIP+ client. 
102
103 . In Evergreen, create a new profile group called +SIP+. This group should be a sub-group of +Users+ (not +Staff+ 
104 or +Patrons+). Set _Editing Permission_ as *group_application.user.sip_client* and give the group the following 
105 permissions: 
106 +
107      COPY_CHECKIN 
108      COPY_CHECKOUT 
109      CREATE_PAYMENT
110      RENEW_CIRC 
111      VIEW_CIRCULATIONS 
112      VIEW_COPY_CHECKOUT_HISTORY 
113      VIEW_PERMIT_CHECKOUT 
114      VIEW_USER 
115      VIEW_USER_FINES_SUMMARY 
116      VIEW_USER_TRANSACTIONS 
117 +
118 OR use SQL like: 
119 +
120    
121    INSERT INTO permission.grp_tree (name,parent,description,application_perm) 
122    VALUES ('SIP', 1, 'SIP2 Client Systems', 'group_application.user.sip_client'); 
123   
124    INSERT INTO 
125      permission.grp_perm_map (grp, perm, depth, grantable) 
126    SELECT 
127      g.id, p.id, 0, FALSE 
128    FROM 
129      permission.grp_tree g, 
130      permission.perm_list p 
131    WHERE 
132      g.name = 'SIP' AND 
133      p.code IN ( 
134        'COPY_CHECKIN', 
135        'COPY_CHECKOUT', 
136        'RENEW_CIRC', 
137        'VIEW_CIRCULATIONS', 
138        'VIEW_COPY_CHECKOUT_HISTORY', 
139        'VIEW_PERMIT_CHECKOUT', 
140        'VIEW_USER', 
141        'VIEW_USER_FINES_SUMMARY', 
142        'VIEW_USER_TRANSACTIONS' 
143     ); 
144 +
145 Verify:
146 +
147     
148     SELECT * 
149     FROM permission.grp_perm_map pgpm 
150         INNER JOIN permission.perm_list ppl ON pgpm.perm = ppl.id 
151         INNER JOIN permission.grp_tree pgt ON pgt.id = pgpm.grp 
152     WHERE pgt.name = 'SIP';
153     
154  
155     
156 . For each account created in the +<login>+ section of oils_sip.xml, create a user (via the staff client user 
157 editor) that has the same username and password and put that user into the +SIP+ group. 
158
159 [NOTE]
160 ===================
161 The expiration date will affect the +SIP+ users' connection so you might want to make a note of this 
162 somewhere. 
163 ===================
164
165 Running the server 
166 ^^^^^^^^^^^^^^^^^^
167
168 To start the +SIP+ server type the following commands from the command prompt: 
169
170
171    $ sudo su opensrf 
172
173    $ oils_ctl.sh -a [start|stop|restart]_sip 
174
175 indexterm:[SIP]
176
177
178 Logging-SIP 
179 ^^^^^^^^^^^
180
181 Syslog
182 ++++++
183
184 indexterm:[syslog]
185
186
187 It is useful to log +SIP+ requests to a separate file especially during initial setup by modifying your syslog config file. 
188
189 . Edit syslog.conf. 
190
191    $ sudo vi /etc/syslog.conf  # maybe /etc/rsyslog.conf
192
193
194 . Add this: 
195
196    local6.*                -/var/log/SIP_evergreen.log 
197  
198 . Syslog expects the logfile to exist so create the file. 
199
200    $ sudo touch /var/log/SIP_evergreen.log 
201
202 . Restart sysklogd. 
203
204    $ sudo /etc/init.d/sysklogd restart 
205
206
207 Syslog-NG
208 +++++++++
209
210 indexterm:[syslog-NG]
211
212 . Edit logging config. 
213
214    sudo vi /etc/syslog-ng/syslog-ng.conf 
215
216 . Add: 
217
218    # +SIP2+ for Evergreen 
219    filter    f_eg_sip { level(warn, err, crit) and facility(local6); }; 
220    destination eg_sip { file("var/log/SIP_evergreen.log"); }; 
221    log { source(s_all); filter(f_eg_sip); destination(eg_sip); }; 
222
223 . Syslog-ng expects the logfile to exist so create the file. 
224
225    $ sudo touch /var/log/SIP_evergreen.log
226
227 . Restart syslog-ng 
228
229    $ sudo /etc/init.d/syslog-ng restart 
230
231
232 indexterm:[SIP]
233
234
235 Testing Your SIP Connection 
236 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
237
238 * In the root directory of the SIPServer code: 
239
240    $ cd SIPServer/t 
241
242 * Edit SIPtest.pm, change the $instid, $server, $username, and $password variables. This will be 
243 enough to test connectivity. To run all tests, you'll need to change all the variables in the _Configuration_ section. 
244
245    $ PERL5LIB=../ perl 00sc_status.t 
246 +
247 This should produce something like:
248 +
249
250    1..4 
251    ok 1 - Invalid username 
252    ok 2 - Invalid username 
253    ok 3 - login 
254    ok 4 - SC status 
255
256 * Don't be dismayed at *Invalid Username*. That's just one of the many tests that are run. 
257
258 More Testing
259 ^^^^^^^^^^^^
260
261 Once you have opened up either the +SIP+ OR +SIP2+ ports to be accessible from outside you can do some testing 
262 via +telnet+. In the following tests:
263
264 * Replace +$server+ with your server hostname (or +localhost+ if you want to
265   skip testing external access for now);
266 * Replace +$username+, +$password+, and +$instid+ with the corresponding values
267   in the +<accounts>+ section of your SIP configuration file;
268 * Replace the +$user_barcode+ and +$user_password+ variables with the values
269   for a valid user.
270 * Replace the +$item_barcode+ variable with the values for a valid item.
271
272 ///////////////
273 Comments because we don't want to indent these numbered bullets!
274 ///////////////
275
276 . Start by testing your ability to log into the SIP server:
277 +
278 [NOTE]
279 ======================
280 We are using 6001 here which is associated with +SIP2+ as per our configuration. 
281 ======================
282 +
283    $ telnet $server 6001 
284    Connected to $server. 
285    Escape character is '^]'. 
286    9300CN$username|CO$password|CP$instid
287 +
288 If successful, the SIP server returns a +941+ result. A result of +940+,
289 however, indicates an unsuccessful login attempt. Check the +<accounts>+
290 section of your SIP configuration and try again.
291
292 . Once you have logged in successfully, replace the variables in the following
293 line and paste it into the telnet session:
294 +
295     2300120080623    172148AO$instid|AA$user_barcode|AC$password|AD$user_password
296 +
297 If successful, the SIP server returns the patron information for $user_barcode,
298 similar to the following:
299 +
300    24  Y           00120100113    170738AEFirstName MiddleName LastName|AA$user_barcode|BLY|CQY
301    |BHUSD|BV0.00|AFOK|AO$instid| 
302 +
303 The response declares it is a valid patron BLY with a valid password CQY and shows the user's +$name+.
304
305 . To test the SIP server's item information response, issue the following request:
306 +
307     1700120080623    172148AO$instid|AB$item_barcode|AC$password
308 +
309 If successful, the SIP server returns the item information for $item_barcode,
310 similar to the following:
311 +
312     1803020120160923    190132AB30007003601852|AJRégion de Kamouraska|CK001|AQOSUL|APOSUL|BHCAD
313     |BV0.00|BGOSUL|CSCA2 PQ NR46 73R
314 +
315 The response declares it is a valid item, with the title, owning library,
316 permanent and current locations, and call number.
317
318 indexterm:[SIP]
319
320 SIP Communication
321 ~~~~~~~~~~~~~~~~~
322
323 indexterm:[SIP Server, SIP Communication]
324
325 +SIP+ generally communicates over a +TCP+ connection (either raw sockets or over +telnet+), but can also 
326 communicate via serial connections and other methods. In Evergreen, the most common deployment is a +RAW+ socket 
327 connection on port 6001.
328
329 +SIP+ communication consists of strings of messages, each message request and response begin with a 2-digit 
330 ``command'' - Requests usually being an odd number and responses usually increased by 1 to be an even number. The 
331 combination numbers for the request command and response is often referred to as a _Message Pair_ (for example, 
332 a 23 command is a request for patron status, a 24 response is a patron status, and the message pair 23/24 is patron 
333 status message pair). The table in the next section shows the message pairs and a description of them. 
334
335 For clarification, the ``Request'' is from the device (selfcheck or otherwise) to the ILS/ACS. The response is… the 
336 response to the request ;). 
337
338 Within each request and response, a number of fields (either a fixed width or separated with a | [pipe symbol] and 
339 preceded with a 2-character field identifier) are used. The fields vary between message pairs. 
340
341 |===========================================================================
342 | *Pair* | *Name*              | *Supported?*          |*Details* 
343 | 01     | Block Patron        | Yes                   |<<sip_01_block_patron, 01/Block_Patron>> - ACS responds with 24 Patron Status Response 
344 | 09-10  | Checkin             | Yes (with extensions) |<<sip_09-10_checkin, 09/10_Checkin>> 
345 | 11-12  | Checkout            | Yes (no renewals)     |<<sip_11-12_checkout, 11/12_Checkout>> 
346 | 15-16  | Hold                | Partially supported   |<<sip_15-16_hold, 15/16_Hold>>  
347 | 17-18  | Item Information    | Yes (no extensions)   |<<sip_17-18_item_information, 17/18_Item_Information>> 
348 | 19-20  | Item Status Update  | No                    |<<sip_19-20_item_status_update, 19/20_Item_Status_Update>> - Returns Patron Enable response, but doesn't make any changes in EG  
349 | 23-24  | Patron Status       | Yes                   |<<sip_23-24_patron_status, 23/24_Patron_Status>> - 63/64 ``Patron Information'' preferred 
350 | 25-26  | Patron Enable       | No                    |<<sip_25-26_patron_enable, 25/26_Patron_Enable>> - Used during system testing and validation 
351 | 29-30  | Renew               | Yes                   |<<sip_29-30_renew, 29/30_Renew>> 
352 | 35-36  | End Session         | Yes                   |<<sip_35-36_end_session, 35/36_End_Session>>
353 | 37-38  | Fee Paid            | Yes                   |<<sip_37-38_fee_paid, 37/38_Fee_Paid>> 
354 | 63-64  | Patron Information  | Yes (no extensions)   |<<sip_63-64_patron_information, 63/64_Patron_Information>> 
355 | 65-66  | Renew All           | Yes                   |<<sip_65-66_renew_all, 65/66_Renew_All>> 
356 | 93-94  | Login               | Yes                   |<<sip_93-94_login, 93/94_Login>> - Must be first command to Evergreen ACS (via socket) or +SIP+ will terminate 
357 | 97-96  | Resend last message | Yes                   |<<sip_97-96_resend, 97/96_Resend>> 
358 | 99-98  | SC-ACS Status       | Yes                   |<<sip_99-98_sc_and_acs_status, 99/98_SC_and_ACS_Status>> 
359 |===========================================================================
360
361 anchor:sip_01_block_patron[]
362
363 01 Block Patron
364 ^^^^^^^^^^^^^^^
365
366 indexterm:[SelfCheck]
367
368 A selfcheck will issue a *Block Patron* command if a patron leaves their card in a selfcheck machine or if the 
369 selfcheck detects tampering (such as attempts to disable multiple items during a single item checkout, multiple failed 
370 pin entries, etc). 
371
372 In Evergreen, this command does the following:
373
374 * User alert message: _CARD BLOCKED BY SELF-CHECK MACHINE_ (this is independent of the AL _Blocked 
375 Card Message_ field). 
376
377 * Card is marked inactive. 
378
379 The request looks like: 
380
381    01<card retained><date>[fields AO, AL, AA, AC] 
382
383 _Card Retained_: A single character field of Y or N - tells the ACS whether the SC has retained the card (ex: left in 
384 the machine) or not. 
385
386 _Date_: An 18 character field for the date/time when the block occurred. 
387
388 _Format_: YYYYMMDDZZZZHHMMSS (ZZZZ being zone - 4 blanks when local time, ``Z'' (3 blanks and a Z) 
389 represents UTC(GMT/Zulu) 
390
391 _Fields_: See <<fields, Fields>> for more details.
392
393 The response is a 24 ``Patron Status Response'' with the following: 
394
395 * Charge privileges denied 
396 * Renewal privileges denied 
397 * Recall privileges denied (hard-coded in every 24 or 64 response) 
398 * hold privileges denied 
399 * Screen Message 1 (AF): _blocked_ 
400 * Patron 
401
402 anchor:sip_09-10_checkin[]
403
404 09/10 Checkin
405 ^^^^^^^^^^^^^
406
407 ~The request looks like: 
408
409    09<No block (Offline)><xact date><return date>[Fields AP,AO,AB,AC,CH,BI] 
410
411 _No Block (Offline)_: A single character field of _Y_ or _N_ - Offline transactions are not currently supported so send _N_. 
412
413 _xact date_: an 18 character field for the date/time when the checkin occurred. Format: 
414 YYYYMMDDZZZZHHMMSS (ZZZZ being zone - 4 blanks when local time, ``Z'' (3 blanks and a Z) represents 
415 UTC(GMT/Zulu) 
416
417 _Fields_: See <<fields, Fields>> for more details. 
418
419 The response is a 10 ``Checkin Response'' with the following: 
420
421    10<resensitize><magnetic media><alert><xact date>[Fields AO,AB,AQ,AJ,CL,AA,CK,CH,CR,CS,CT,CV,CY,DA,AF,AG] 
422
423 Example (with a remote hold): 
424
425   09N20100507    16593720100507    165937APCheckin Bin 5|AOBR1|AB1565921879|ACsip_01| 
426
427   101YNY20100623    165731AOBR1|AB1565921879|AQBR1|AJPerl 5 desktop reference|CK001|CSQA76.73.P33V76 1996 
428   |CTBR3|CY373827|DANicholas Richard Woodard|CV02|
429
430 Here you can see a hold alert for patron CY _373827_, named DA _Nicholas Richard Woodard_, to be picked up at CT 
431 ``BR3''. Since the transaction is happening at AO ``BR1'', the alert type CV is 02 for _hold at remote library_. The 
432 possible values for CV are: 
433
434 * 00: unknown 
435
436 * 01: local hold 
437
438 * 02: remote hold 
439
440 * 03: ILL transfer (not used by EG) 
441
442 * 04: transfer 
443
444 * 99: other 
445
446 indexterm:[magnetic media]
447
448 [NOTE]
449 ===============
450 The logic for Evergreen to determine whether the content is magnetic_media comes from  
451 or search_config_circ_modifier. The default is non-magnetic. The same is true for media_type (default 
452 001). Evergreen does not populate the collection_code because it does not really have any, but it will provide 
453 the call_number where available.
454
455 Unlike the +item_id+ (barcode), the +title_id+ is actually a title string, unless the configuration forces the 
456 return of the bib ID. 
457
458 Don't be confused by the different branches that can show up in the same response line. 
459
460 * AO is where the transaction took place, 
461
462 * AQ is the ``permanent location'', and 
463
464 * CT is the _destination location_ (i.e., pickup lib for a hold or target lib for a transfer). 
465 ===============
466
467 anchor:sip_11-12_checkout[]
468
469 11/12 Checkout
470 ^^^^^^^^^^^^^^
471
472
473 anchor:sip_15-16_hold[]
474
475 15/16 Hold
476 ^^^^^^^^^^
477
478 Evergreen supports the Hold message for the purpose of canceling
479 holds.  It does not currently support creating hold requests via SIP2.
480
481
482 anchor:sip_17-18_item_information[]
483
484 17/18 Item Information 
485 ^^^^^^^^^^^^^^^^^^^^^^
486
487 The request looks like: 
488
489     17<xact_date>[fields: AO,AB,AC] 
490
491 The request is very terse. AC is optional. 
492
493 The following response structure is for +SIP2+. (Version 1 of the protocol had only 6 total fields.) 
494
495     18<circulation_status><security_marker><fee_type><xact_date> 
496     [fields: CF,AH,CJ,CM,AB,AJ,BG,BH,BV,CK,AQ,AP,CH,AF,AG,+CT,+CS] 
497
498 Example:
499
500    1720060110    215612AOBR1|ABno_such_barcode| 
501
502    1801010120100609    162510ABno_such_barcode|AJ| 
503
504    1720060110    215612AOBR1|AB1565921879| 
505
506    1810020120100623    171415AB1565921879|AJPerl 5 desktop reference|CK001|AQBR1|APBR1|BGBR1 
507    |CTBR3|CSQA76.73.P33V76 1996| 
508
509 The first case is with a bogus barcode. The latter shows an item with a circulation_status of _10_ for _in transit between 
510 libraries_. The known values of +circulation_status+ are enumerated in the spec. 
511
512 indexterm:[Automated Material Handling (AMH)]
513
514 EXTENSIONS: The CT field for _destination location_ and CS _call number_ are used by Automated Material Handling 
515 systems. 
516
517
518 anchor:sip_19-20_item_status_update[]
519
520 19/20 Item Status Update
521 ^^^^^^^^^^^^^^^^^^^^^^^^
522
523
524 anchor:sip_23-24_patron_status[]
525
526 23/24 Patron Status 
527 ^^^^^^^^^^^^^^^^^^^
528
529 Example: 
530
531    2300120060101    084235AOUWOLS|AAbad_barcode|ACsip_01|ADbad_password| 
532
533    24YYYY          00120100507    013934AE|AAbad_barcode|BLN|AOUWOLS|
534
535    2300120060101    084235AOCONS|AA999999|ACsip_01|ADbad_password| 
536
537    24  Y           00120100507    022318AEDoug Fiander|AA999999|BLY|CQN|BHUSD|BV0.00|AFOK|AOCONS| 
538
539    2300120060101    084235AOCONS|AA999999|ACsip_01|ADuserpassword|LY|CQN|BHUSD|BV0.00|AFOK|AOCONS| 
540
541    24  Y           00120100507    022803AEDoug Fiander|AA999999|BLY|CQY|BHUSD|BV0.00|AFOK|AOCONS| 
542
543 . The BL field (+SIP2+, optional) is _valid patron_, so the _N_ value means _bad_barcode_ doesn't match a patron, the 
544 _Y_ value means 999999 does. 
545
546 . The CQ field (+SIP2+, optional) is _valid password_, so the _N_ value means _bad_password_ doesn't match 999999's 
547 password, the _Y_ means _userpassword_ does. 
548
549 So if you were building the most basic +SIP2+ authentication client, you would check for _|CQY|_ in the response to 
550 know the user's barcode and password are correct (|CQY| implies |BLY|, since you cannot check the password 
551 unless the barcode exists). However, in practice, depending on the application, there are other factors to consider in 
552 authentication, like whether the user is blocked from checkout, owes excessive fines, reported their card lost, etc. 
553 These limitations are reflected in the 14-character _patron status_ string immediately following the _24_ code. See the 
554 field definitions in your copy of the spec. 
555
556
557 anchor:sip_25-26_patron_enable[]
558
559 25/26 Patron Enable 
560 ^^^^^^^^^^^^^^^^^^^
561
562 Not yet supported. 
563
564
565 anchor:sip_29-30_renew[]
566
567 29/30 Renew
568 ^^^^^^^^^^^
569
570 Evergreen supports the Renew message. Evergreen checks whether a penalty is specifically configured to block
571 renewals before blocking any SIP renewal.
572
573
574 anchor:sip_35-36_end_session[]
575
576 35/36 End Session
577 ^^^^^^^^^^^^^^^^^
578
579    3520100505    115901AOBR1|AA999999|
580
581    36Y20100507    161213AOCONS|AA999999|AFThank you!| 
582    
583 The _Y/N_ code immediately after the 36 indicates _success/failure_. Failure is not particularly meaningful or important 
584 in this context, and for evergreen it is hardcoded _Y_. 
585
586
587
588 anchor:sip_37-38_fee_paid[]
589
590 37/38 Fee Paid 
591 ^^^^^^^^^^^^^^
592
593 Evergreen supports the Fee Paid message.
594
595
596 anchor:sip_63-64_patron_information[]
597
598 63/64 Patron Information 
599 ^^^^^^^^^^^^^^^^^^^^^^^^
600
601 Attempting to retrieve patron info with a bad barcode:
602
603    6300020060329    201700          AOBR1|AAbad_barcode| 
604    
605    64YYYY          00020100623    141130000000000000000000000000AE|AAbad_barcode|BLN|AOBR1| 
606
607 Attempting to retrieve patron info with a good barcode (but bad patron password): 
608
609    6300020060329    201700          AOBR1|AA999999|ADbadpwd| 
610
611    64  Y           00020100623    141130000000000000000000000000AA999999|AEDavid J. Fiander|BHUSD|BV0.00 
612    |BD2 Meadowvale Dr. St Thomas, ON Canada 
613
614    90210|BEdjfiander@somemail.com|BF(519) 555 1234|AQBR1|BLY|CQN|PB19640925|PCPatrons 
615    |PIUnfiltered|AFOK|AOBR1| 
616
617 See <<sip_23-24_patron_status, 23/24 Patron Status>> for info on +BL+ and +CQ+ fields. 
618
619
620
621 anchor:sip_65-66_renew_all[]
622
623 65/66 Renew All
624 ^^^^^^^^^^^^^^^
625
626 Evergreen supports the Renew All message.
627
628
629 anchor:sip_93-94_login[]
630
631 93/94 Login 
632 ^^^^^^^^^^^
633
634 Example: 
635
636    9300CNsip_01|CObad_value|CPBR1| 
637   
638    [Connection closed by foreign host.] 
639    ... 
640
641    9300CNsip_01|COsip_01|CPBR1|
642
643    941 
644
645 _941_ means successful terminal login. _940_ or getting dropped means failure.
646
647 When using a version of SIPServer that supports the feature, the Location (CP) field of the Login (93) message will be used as the workstation name if supplied. Blank or missing location fields will be ignored. This allows users or reports to determine which selfcheck performed a circulation.
648
649
650 anchor:sip_97-96_resend[]
651
652 97/96 Resend
653 ^^^^^^^^^^^^
654
655
656 anchor:sip_99-98_sc_and_acs_status[]
657
658 99/98 SC and ACS Status
659 ^^^^^^^^^^^^^^^^^^^^^^^
660
661    99<status code><max print width><protocol version> 
662  
663 All 3 fields are required:
664
665 * 0: SC is OK
666
667 * 1: SC is out of paper 
668
669 * 2: SC shutting down
670
671 * status code - 1 character 
672
673 * max print width - 3 characters - the integer number of characters the client can print 
674
675 * protocol version - 4 characters - x.xx 
676
677   98<on-line status><checkin ok><checkout ok><ACS renewal policy>
678   <status update ok><offline ok><timeout period> 
679
680   <retries allowed><date/time sync><protocol version><institution id> 
681   <library name><supported messages><terminal 
682
683   location><screen message><print line> 
684
685 Example: 
686
687   9910302.00 
688
689   98YYYYNN60000320100510    1717202.00AOCONS|BXYYYYYYYYYNYNNNYN|
690
691 The Supported Messages field +BX+ appears only in +SIP2+, and specifies whether 16 different +SIP+ commands are 
692 supported by the +ACS+ or not. 
693
694
695 anchor:fields[]
696
697 Fields
698 ^^^^^^
699
700 All fixed-length fields in a communication will appear before the first variable-length field. This allows for simple 
701 parsing. Variable-length fields are by definition delimited, though there will not necessarily be an initial delimiter 
702 between the last fixed-length field and the first variable-length one. It would be unnecessary, since you should know 
703 the exact position where that field begins already.