Remnants from Dynix

When we migrated from Dynix to Spydus I was keen that we didn't lose more management information than we needed. I ran copies of the canned reports and all the usual suspects but there were two things I particularly wanted to preserve:

• I wanted to be able to give the stock manager an overview of the state of the collections at each library.
• We had 21 years' worth of data in Dynix's Statistical Reports Manager and I wasn't keen to lose all that management information.

So I wrote some Recall reports to strip out the data in text format. These are the Recall Vocs and the local dictionary items that I used.

     COLLECTIONS.REPORT
0001 PA Saved at 15:15:22 23 SEP 2005 by steveh
0002 CS
0003 DISPLAY
0004 DISPLAY
0005 DISPLAY          The system is now sorting all the Holdings records
0006 DISPLAY          A report will be sent to the screen
0007 DISPLAY
0008 DISPLAY          This will take some time
0009 DISPLAY
0010 DISPLAY          If you want a copy of this report in Word or Excel
0011 DISPLAY          please ask the Systems Manager
0012 DISPLAY
0013 DISPLAY         working.....
0014 DISPLAY
0015 SORT HOLDINGS BY AGENCY2 BY COLLECTION BY L-ITEM.AGE BREAK-ON L-LIBNAME "TOTAL FOR 'V'" BREAK-ON T-COLL "TOTAL FOR 'V'" BREAK-ON L-ITEM.AGE "'V'" TOTAL COUNTER HEADING "LIBRARY CATALOGUE STOCK AS OF 'TL'" (CDIP

 
Enter DICT NAME : L-ITEM.AGE
1  FIELD NAME         1/ YEARS
                      2/ OLD
2  FIELD NUMBER          0
3  JUSTIFICATION         L
4  DISPLAY LENGTH        25
5  CONVERSION         1/ MCT
6  CORRELATIVE        1/ A; IF N(L-YEARS.OWNED2) < "5" THEN "LESS THAN FIVE YEARS OLD" ELSE IF N(L-YEARS.OWNED2) > "10" THEN "MORE THAN TEN YEARS OLD" ELSE IF N(L-YEARS.OWNED2) = "" THEN "MORE THAN TEN YEARS OLD" ELSE "5 TO 10 YEARS OLD"


Enter DICT NAME : L-YEARS.OWNED2
1  FIELD NAME         1/ YEARS OWNED
2  FIELD NUMBER          0
3  JUSTIFICATION         R
4  DISPLAY LENGTH        10
5  CONVERSION         1/
6  CORRELATIVE        1/ A;(D-N(DATE.ADDED))/"365"

 

     STAT.MGR.DUMP.REPORT
0001 PA Saved at 16:29:48 30 APR 2012 by steveh
0002 SELECT STAT.MGR WITH L-PERIOD="DAY"
0003 SELECT STAT.MGR WITH L-KEY NOT "[.OV"
0004 SELECT STAT.MGR WITH L-KEY NOT "[.PO.]"
0005 SORT STAT.MGR BY L-DATE BY L-CODE.TRANSLATE BY L-LIBRARY L-DATE L-CODE.TRANSLATE L-LIBRARY L-TOTAL (CHIP


     STAT.MGR.MONTH.DUMP
0001 PA Saved at 10:55:50 10 MAY 2012 by steveh
0002 SETPTR ,500,5000,,,3
0003 SELECT STAT.MGR WITH L-PERIOD="MONTH"
0004 SELECT STAT.MGR WITH L-ELEMENT2 GT "3000"
0005 SORT STAT.MGR BY L-PERIOD BY L-DATE BY L-CODE.TRANSLATE BY L-LIBRARY L-PERIOD L-DATE L-CODE.TRANSLATE L-LIBRARY L-TOTAL HEADING "Monthly issue statistics from Dynix as of 'TL'" (NIP
 

Enter DICT NAME : L-PERIOD
1  FIELD NAME         1/ PERIOD
2  FIELD NUMBER          0
3  JUSTIFICATION         L
4  DISPLAY LENGTH        10
5  CONVERSION         1/
6  CORRELATIVE        1/ A;IF N(L-ELEMENT1)="M" THEN "MONTH" ELSE IF N(L-ELEMENT1)="D" THEN "DAY" ELSE ""

Enter DICT NAME : L-ELEMENT1
1  FIELD NAME         1/ FIRST BIT
2  FIELD NUMBER          0
3  JUSTIFICATION         L
4  DISPLAY LENGTH        10
5  CONVERSION         1/
6  CORRELATIVE        1/ G.1
 
Enter DICT NAME : L-KEY
1  FIELD NAME         1/ KEY
2  FIELD NUMBER          0
3  JUSTIFICATION         L
4  DISPLAY LENGTH        80
5  CONVERSION         1/
6  CORRELATIVE        1/
 
Enter DICT NAME : L-DATE
1  FIELD NAME         1/ DATE
2  FIELD NUMBER          0
3  JUSTIFICATION         L
4  DISPLAY LENGTH        10
5  CONVERSION         1/ D2
6  CORRELATIVE        1/ G1.1

Enter DICT NAME : L-CODE.TRANSLATE
1  FIELD NAME         1/ TRANSLATED CODE
2  FIELD NUMBER          0
3  JUSTIFICATION         L
4  DISPLAY LENGTH        50
5  CONVERSION         1/ MCT
6  CORRELATIVE        1/ G3.2
                      2/ TCODES;X;;1

Enter DICT NAME : L-LIBRARY
1  FIELD NAME         1/ LIBRARY
2  FIELD NUMBER          0
3  JUSTIFICATION         L
4  DISPLAY LENGTH        35
5  CONVERSION         1/
6  CORRELATIVE        1/ A;"EX.";N(L-AGENCY);:
                      2/ TCODES;X;;1

Enter DICT NAME : L-AGENCY
1  FIELD NAME         1/ AGENCY
2  FIELD NUMBER          0
3  JUSTIFICATION         L
4  DISPLAY LENGTH        25
5  CONVERSION         1/
6  CORRELATIVE        1/ G2.1

Enter DICT NAME : L-TOTAL
1  FIELD NAME         1/ TOTAL
2  FIELD NUMBER          0
3  JUSTIFICATION         R
4  DISPLAY LENGTH        6
5  CONVERSION         1/
6  CORRELATIVE        1/ F;2;S
 
Enter DICT NAME : L-PERIOD
1  FIELD NAME         1/ PERIOD
2  FIELD NUMBER          0
3  JUSTIFICATION         L
4  DISPLAY LENGTH        10
5  CONVERSION         1/
6  CORRELATIVE        1/ A;IF N(L-ELEMENT1)="M" THEN "MONTH" ELSE IF N(L-ELEMENT1)="D" THEN "DAY" ELSE ""

Enter DICT NAME : L-ELEMENT2
1  FIELD NAME         1/ SECOND BIT
2  FIELD NUMBER          0
3  JUSTIFICATION         R
4  DISPLAY LENGTH        10
5  CONVERSION         1/
6  CORRELATIVE        1/ G1.1
 

Improving stock management

I mentioned a while back that we've bought into smartsm and that we want to do a lot with it. To give you some idea of the scope of our ambition, the only part of the lending stock life cycle that we don't see being directly influenced by smartsm is the actual process of procurement. Once the item's arrived it'll be included in the smartsm processes.

Which isn't to say that we're going to be doing everything at once. Realistically, the first stage is going to be the running of reports for stock that's either sitting idly on the shelves or else perhaps being physically overworked and needing replacement. We should then be able to move on to working up an evidence-based transfer régime that ensures that stock is moving to meet local demand rather than somebody's best guess (or long-standing organisational tradition).

Talking to other smartsm users it seems that it takes the best part of a year to build up enough data and trends analysis to be able to start using it effectively in the stock selection process. This is fine by us: the fact we can use smartsm at all for this purpose is icing on the cake so we don't mind waiting.

Between stock analyses on Dynix, smartsm reports and issue statistical reports on Dynix we should be able to take a more holistic approach to stock selection and location; make individual items of stock work harder by moving it on when it has fulfilled the local market; and demonstrate that we’re getting value for money.

At the moment we are only likely to be using smartsm as a lending stock management tool as we have chosen not to record evidence of use of reference stock. There is no technical reason why evidence-based stock management cannot be applied to reference stock: we could use Dynix's "In-House Use" function to generate the usage data for this stock.

The answer's always in the question

I'm probably the only person in the known universe who's going to be doing this but it's worth my noting it down as a reminder of the general principle.

We've bought into smartsm, which is an evidence-based stock management tool. We're working on Dynix, which provides a ton and a half of really useful data but which provides far too much detail for everyday working. The idea is that we can use smartsm to pull together the data into reports which can be run by front-line staff who can then take whatever action is appropriate. (The idea's a bit more and a bit bigger than that, but that'll do for the purposes of this narrative.)

Dynix is an old library management system and interoperability isn't it's strong suit, by a very long chalk. The good news, though, is that it's very easy to do snapshots of any combination of data and then export that out as text. Being an old Pick system, the data's not held in tables like you'd see in an SQL database; the best way I can describe it is that for all practical purposes the data's held suspended in mid air connected together by bits of string. These bits of string ("dicts") are one of the most powerful data manipulation tools I've had the pleasure of playing with and I'll miss them greatly when we eventually move onto a new LMS. They do three jobs:

• They define which piece of data you're looking at;
• They define how you're going to see the data; and
• They can link the data in one file to that in another file.

So, for instance, the dict called BARCODES in the bibliographic record file called BIB reports the data found in the first line of a BIB record in columnar format 16 characters wide. The dict called L-COLLECTION reads the data in the first line of a BIB record, uses those barcodes to look for the appropriate records in the HOLDINGS file, reads the code in the fifteenth line of each record, translates the code(s) into the appropriate collection labels and reports these in Title Format in a column 40 characters wide. And once a dict is set up and shown to work OK you can forget about all the intermediate steps and just get the data.

So what's this got to do with smartsm?

We need to do a monthly extract of our catalogue data providing the bibliographical data for each item plus its location, collection, current status and its use. And smartsm need this as comma-delimited data in a set format so that they can map it against their reporting processes. Most of which is easy enough to do: if you tell me that you need the title of each book up to a maximum of 100 characters it's literally less than a minute's work to do. You want it comma-delimited, it'll take a minute or two to remember how to impose a constant comma in front of the reporting data. And for the most part it really has been that easy. In some cases I've wanted to aggregate the data into something more useful, for instance we have umpteen item statuses providing different reasons why these items are not available for loan (being repaired; being boxed up for transfer to another library; audio items bought then held back under the terms of the performance licence, etc.), which are usually useful when you're looking for a particular item but drag in a bit too much confusing detail for reporting purposes, so I set up a dict that just reports these as "not available." A few bits were more complicated but I got there in the end.

And then there was the date format.

Date formats are a pain in the arse, no two ways about it. The data extract had to provide the dates in a particular format, which isn't any of the date formats available on Dynix. I spent six weeks trying, and failing, to write a dict that jiggled the components around a bit to give the right format. I was beside myself with frustration.

On the bus home one night I realised I'd been a prat.

We need comma-delimited data, right? If I downloaded the entire catalogue database and stuck a comma at the beginning and a comma at the end this would be treated as one piece of data, one column wide and one row deep. I didn't need a dict that juggled the day, month and year data. I needed a dict for day, a dict for year and a dict for month. With a comma before the day data. Which was five minutes' work the next day.

Note to self: in future, pay attention to all the question. The answers come easier that way.