• Article Type: General
• Product: Aleph
• Product Version: 18.01

Description:
I am testing whether I can use two different loan periods for the same item status. On Monday through Thursday, the item status 23 will circulate for 24 hours. But if the item is borrowed Friday through Sunday, it will be due the following Monday.

In the v.18.08 System Librarian's Guide/Circulation on pages 107-108, there are directions to create two tab 16 tables which allow the same item status to be defined with different loan periods. The directions then say to add procedures to the job list which switch back and forth between these tables. And so...

I set up TWO tab16 tables:
1) abc50/tab/tab16.1
defines item status 23 circulating to 52 (Fast TRAX) only for 1 day

2) abc50/tab/tab16.2
defines item status 23 circulating to 52 (Fast TRAX) only to a defined day (the following Monday). This table will have to be edited weekly prior to Fridays.

and wrote a job procedure:
01 05:30:00 Y tab16_1.log csh -f /aleph/proc/p_switch_tab16_2 ABC50
05 05:30:00 Y tab16_2.log csh -f /aleph/proc/p_switch_tab16_2 ABC50

uploading it to:

/ABC_DEV/alephe/tab/job_list

the aleph/tab/job_list contains the two jobs switching between table 16.1 on Mondays; table 16.2 on Fridays (5:30 a.m.).

Best I can tell, Aleph continues to reference tab16 rather than 16.1/16.2. Have I written all this correctly?

Resolution:
Am I correct in understanding that, even though you want these items to not be due on Sat or Sun, the library is open on Sat and Sun? (If the library is closed on Sat and Sun, then the lines in tab17 indicating Closed will prevent the item from becoming due on that day.)

Assuming that the library is open on Sat and Sun, then, yes, what you describe is the way to do it. The programs never look for tab16.1 or tab16.2. All they know about is "tab16", so your procedures need to copy tab16.1 to tab16 and copy tab16.2 to tab16 -- which is what I assume they are doing.

Note: when a change is made to tab16, two things need to happen to make it take effect:

1. the pc_server needs to be restarted;

2. either the date needs to change (from, for instance, today to tomorrow) or the z301 table needs to be dropped/created. This issue is discussed in KB 150.

• Article last edited: 10/8/2013