˙WPCúL ű˙2'B ZR#ŹXĎ#|xHP LaserJet IIISiHPLIIISI.PRSŰx Œ @ɇĎ,\,đU6X@Courier 10cpiCourier 10cpi (Bold)ŕ˙˙‰?xxx,ŰLôxţ6X@ɓ8Ç;X@ţţţţţţţ˙ţ˙˙˙˙˙ţ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙’˙˙‰?xxx,äóôxĐ `ɕBÇ;X€ţţţţţţţ˙˙˙˙˙˙˙˙ţ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ű˙2…YŢ09-24-91 06:01p NETLOCK Paper wp ˙Ç ˙I*É$4€€€€€€€€€€€€ŔŔŔ˙˙˙˙˙˙˙˙˙˙˙˙ ˙€ü)@ŕKK€˙€!€d€˙˙‡˙ˆ˙€„€„€€€‡˙€€R€/‡˙€€€˙˙‡˙ˆ˙€„€„€€€‡˙€€R€/‡˙€€ƒ€˙˙€ €€˙˙€˙˙˙˙˙˙€€€€€=€/€€„€ƒ€˙˙€ €€˙˙€˙˙˙˙˙˙€€€€€=€/€€„€„˙˙˙˙€ €€€˙˙€˙˙˙€€€€€=€/€€„˙˙˙˙€ €€€˙˙€˙˙˙€€€€€=€/€€„˙˙˙˙€ €€€˙˙€„€ €€„˙˙€˙˙„˙˙…€„€ˆ€<€/€€…€ €„˙˙˙˙€ €€€˙˙€„€ €€„˙˙€˙˙„˙˙…€„€ˆ€<€/€€…€ € ˙˙˙˙†€€€€˙˙€ƒ€ †/˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ƒ˙˙€=€/† ˙˙˙˙˙˙€ € ˙˙˙˙†€€€€˙˙€ƒ€ †/˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ƒ˙˙€=€/† ˙˙˙˙˙˙€ € ˙˙˙˙€ €€€˙˙€„€ €˙˙˙˙˙˙˙˙˙˙€˙˙€„˙˙€€=€/€ ˙˙˙˙€ € ˙˙˙˙€ €€€˙˙€„€ €˙˙˙˙˙˙˙˙˙˙€˙˙€„˙˙€€=€/€ ˙˙˙˙€ €˙˙„˙˙€ €€€˙˙€˙€€˙˙˙˙˙˙˙˙˙˙€˙˙€ ˙˙˙€€=€/€ ˙˙˙˙€ €˙˙„˙˙€ €€€˙˙€ ˙˙˙˙€€ ˙˙˙˙˙˙ˆ˙˙€˙˙˙˙˙˙˙˙€€=€/€ ˙˙˙˙€ €€ƒ˙˙€ €€˙˙€ ˙˙˙˙€€€ ˙˙˙˙€˙˙€˙˙˙˙˙˙˙˙˙˙˙€€=€/€˙˙˙˙˙˙€€€€ƒ˙˙€ €€˙˙€ ˙˙˙˙€€€ ˙˙˙˙€˙˙€˙˙˙˙˙˙˙˙˙˙˙€€=€/€˙˙˙˙˙˙€€€€˙˙‡€€‡€„€„€€€€€„€˙˙€„˙˙˙˙€…˙˙€€<€/€€…˙˙€€€€˙˙‡€€‡€„€„€€€€€„€˙˙€„˙˙˙˙€…˙˙€€<€/€€…˙˙€€€Ë€?€ß€;˙˙€ß€<„€ŕ€˙€!€èo€e€J€o€e€˙˙˙ƒ„đ€ đ˙˙đ˙˙đ€%€o€e€˙˙€đ˙đ€ ˙˙˙˙˙˙€€ €o€e€˙˙€đ˙đ˙˙đ˙đđ˙đ˙đ€€ €o€e€˙˙€đ˙đ˙˙đ˙đđ€€đđ˙đ˙˙˙đ˙đđ€ €o€e€đ˙ƒ˙˙đ˙đ˙˙đ˙đđ€€đ˙˙˙˙˙˙˙˙˙˙˙€ €o€e€đ˙€đ˙đ˙˙đ˙đđ€€đ˙ƒ ˙˙˙˙˙ƒ˙€€ €o€e€˙˙€đ˙đ˙˙đ˙đđ€đ€đ˙€ ˙˙˙˙€đ˙€ €o€e€˙˙€đ˙đ˙˙đ˙đđ˙đ˙˙€đ˙€ ˙˙˙˙€˙€ €o€e€˙đ˙€đ˙đ€'˙˙˙˙˙˙đ˙˙đ˙˙˙˙˙˙˙˙˙˙˙€ €o€e€˙˙˙ƒ˙đ˙đƒ)˙đ˙˙đ˙˙˙˙˙đ˙đ˙đ˙đ˙đ˙đ˙đ€ €o€e€0€€o€e€J€o€e€đ€đ€€o€e€€đđ€€o€e€ đ˙˙đ„€˙đ˙˙˙đ˙˙˙đ€€o€e€(˙đđđđđ˙˙đđđđđđđđđđđđ€€o€e€˙˙đđđđđ€đđđđđđđđđđ€€o€e€˙˙đđđđđ€đđđđđđđđđ˙˙đ€€o€e€(˙˙đđđđđ˙˙đđđđđđđđđđ˙˙đ€€o€e€(˙˙đđđđđ˙˙đđđđđđđđđđđđ€€o€e€˙˙˙˙đđđ€đđ˙˙˙đđ˙˙đ€€o€e€J€o €e€đ˙đƒ˙˙€đ€€o€e€đ˙˙đ€đđ€đ€ đ€€o€e€đ˙đđ€˙˙€đ€ đ€€o€e€đ˙đđ€€đ˙˙˙˙˙đ˙˙˙˙˙€€o€e€ đ˙đđ˙€đđđđđ˙˙đđđđđđđđ€€o€e€đ˙đđ€€đđđđ˙˙đđđđđđđ€€o€e€đ˙đđ€€đđđ˙˙đ˙˙đđđđđđđ€€o€e€đ˙đđ€˙˙đđđ˙˙đ˙˙đđđđđđđ€€o€e€đ˙˙đ€ đđđđđđđ˙˙đđđđđđđđ€€o€e€đ˙đƒ ˙˙˙đđ˙˙˙˙˙đđ˙˙˙˙€€o€e€J€o €èo€…€™€„đ€™€„ƒ€˜€ƒđ„€˜€ƒ…€—€‚đ†€—€…€™€…€đ€’€…€€’€…€đƒ€‘€…€đ„€‘€…€…€‘€…˙˙đƒđ€‘€…˙˙ƒ˙đ€‘€… ˙đ˙đ€‘€…˙ƒ˙˙đ€‘€…ƒ˙˙đ€‘€……€đ€‘€…„€đ€‘€…ƒ€đ€‘€…ƒ€đ€‘€…€đ€‘€…€đ€‘€đ€‘€‹†€Ž€‹đ…€€Œ„€€€€đ€‘€èo€e€J€o€e€˙˙˙ƒ„đ€ đ˙˙đ˙˙đ€€o€e€˙˙€đ˙đ€ ˙˙˙˙˙˙€€o€e€˙˙€đ˙đ˙˙đ˙đđ˙đ˙đ€€o€e€˙˙€đ˙đ˙˙đ˙đđ€€€o€e€đ˙ƒ˙˙đ˙đ˙˙đ˙đđ€€€o€e€đ˙€đ˙đ˙˙đ˙đđ€€€o€e€˙˙€đ˙đ˙˙đ˙đđ€đ€€o€e€˙˙€đ˙đ˙˙đ˙đđ˙đ˙˙€€o€e€˙đ˙€đ˙đ€ ˙˙˙˙˙˙đ€€o€e€˙˙˙ƒ˙đ˙đƒ˙đ˙˙đ˙˙˙€€o€e€J€o€_‡€J€o€_đ†€J€o€`†€Iđ€o€`đ…€Iđ€n€a…€Iđ€m€ađ„€Iđƒ€m€a…€Jƒ€l€`đ…€J„€k€_đ†€Jđƒ€k€_ƒđ€J˙ƒ€j€^đƒ˙˙đ€J˙˙ƒ€i€^ƒ€€J˙˙đƒ€i€]đ€€J€ƒ€h€]ƒ€€J€ƒ€g€\ƒ€€J€đƒ€g€[đƒ€€J€ƒ€f€[ƒ€€J€ƒ€f€Zđ€€J€đƒ€e€Zƒ€€J€ƒ€d€Yƒ€€J€đƒ€d€Xđƒ€ €J€đƒ€c€Xƒ€ ̀ ƒ€b€Wđ€ ̀ đƒ€b€Wƒ€0€/đƒ€a€Vđ€/đ€0ƒ€`€Uđƒ€0ƒ€/đƒ€`€Uƒ€/đ„€0đƒ€_€Tđƒ€0…€0ƒ€^€Tƒ€0đ†€0đƒ€^€Sđ€3€3đ€]€Rđƒ€4€4ƒ€\€Rƒ€4€4đƒ€\€Qđƒ€5€5ƒ€[€Qƒ€6€6ƒ€Z€Pđ€6€6đƒ€Z€Pƒ€7€7ƒ€Y€Oƒ€7€8ƒ€X€Nđƒ€8€8đƒ€X€Nƒ€8€9ƒ€W€Mđ€9€:ƒ€W€Mƒ€:€:đƒ€V€Lđ€:€;ƒ€U€Kđƒ€;€;đƒ€U€Kƒ€;€<đƒ€T€Jđƒ€<€=ƒ€S€Jƒ€=€=đƒ€S€Iđ€=€>đƒ€R€Hđƒ€>€?ƒ€Q€Hƒ€>€?đƒ€Q€Gđƒ€?€@đƒ€P€Gƒ€@€Aƒ€O€Fđ€@€Ađƒ€O€Fƒ€A€Bđ€N€Eƒ€A€Cƒ€M€Dđƒ€B€Cđƒ€M€Dƒ€B€Dƒ€L€Cđ€C€Eƒ€K€Cƒ€D€Eđƒ€K€Bƒ€D€Fƒ€J€Ađƒ€E€Gƒ€I€Aƒ€E€Gđƒ€I€@đ€F€Hƒ€H€@ƒ€G€Iƒ€G€?đ€G€Iđƒ€G€>đƒ€H€Jƒ€F€>ƒ€H€Kƒ€F€=đƒ€I€Kđƒ€E€=ƒ€J€Lƒ€D€<đ€J€Lđƒ€đ€?€;đƒ€K€Mđƒ€€?€;ƒ€K€Nƒ˙đ€?€:đƒ€L€Nđƒ˙€?€:ƒ€M€Ođ…€?€9đ€Jđ†€N…€?€9ƒ€L…€Nđ„€?€8ƒ€Lđ„€Ođ„€?€7đƒ€Nđ€P’€2€7ƒ€O€O˜€-€6đ€JŽ€Fž€*€5đƒ€F˜€?ˆ˙€ đˆ€(€5ƒ€Cž€;„€đ„€'€4đƒ€Bˆ€đˆ€8€ đ€&€4ƒ€A„€đ„€6€$€%€,đ€=€ đ€4đ€$đ€%€'đ—€7€$€3đ€$đ€%€$đ€3đ€$đ€3đ€$đ€%€"đˆ€ˆ€1đ€$đ€4€#ƒ€%€!đ„€„€0đ€$đ€4ƒ€ đƒ€%€ đ€!€0€#ƒ€4„€đ„đ€%€đ€#đ€/ƒ€ đƒ€4˙ˆ€đˆ˙đ€%€€%€/„€đ„đ€4€ž€đ€%€€%€/˙ˆ€đˆ˙đ€4€˜€đ€%€€%€/€ž€đ€4€ Ž€ đ€%€đ€"đ€/€˜€đ€4€$đ€%€đƒ€!ƒ€/€ Ž€ đ€4€$đ€%€đđ„€„€/€$đ€4€$đ€%€đ˙đˆ€ˆ˙€/€$đ€4€$đ€%€đ€đ€€/€$đ€4€$đ€%€đ€đ—€€/€$đ€4€$đ€%€đ€ đ€ €/€$đ€4€$đ€%€đ€%€/€$đ€4€$đ€%€đ€%€/€$đ€4 ˙˙đ˙đđƒđƒ€€˙đ˙€đ€%€đ€%€/€$đ€4 ˙˙đ˙đđ€˙˙€ đđ˙đđđđ€đ€%€đ€%€/ ˙˙đ˙đđƒđƒ€€˙đ˙€đ€4 ˙˙đđđ€˙˙€ ˙˙˙˙˙đ€đ€%€đ€%€/ ˙˙đ˙đđ€˙˙€ đđ˙đđđđ€đ€4 ˙˙đđđ€˙˙€˙˙˙€đ€đ€%€đ€%€/ ˙˙đđđ€˙˙€ ˙˙˙˙˙đ€đ€4˙˙đđđ˙˙˙˙€˙˙˙€đ€đ€%€đ€%€/ ˙˙đđđ€˙˙€˙˙˙€đ€đ€4 ˙˙đđđ€˙˙€˙˙˙€đ€đ€%€đ€%€/˙˙đđđ˙˙˙˙€˙˙˙€đ€đ€4 ˙˙đđđ€˙˙€˙˙˙€đ€đ€%€đ€˙˙˙ƒ„đ€ đ˙˙đ˙˙đ€€/ ˙˙đđđ€˙˙€˙˙˙€đ€đ€4 ˙˙đđđ€˙˙€ ˙˙˙˙˙đđ€đ€%€đ€˙˙€đ˙đ€ ˙˙˙˙˙˙€€/ ˙˙đđđ€˙˙€˙˙˙€đ€đ€4 ˙˙đ˙đ€˙˙€ đđ˙đđđ˙€đ€%€đ€˙˙€đ˙đ˙˙đ˙đđ˙đ˙đ€€/ ˙˙đđđ€˙˙€ ˙˙˙˙˙đđ€đ€4 ˙˙đ˙đđƒ˙˙˙˙ƒ˙€ ˙đ˙đ˙˙đ€%€đ€˙˙€đ˙đ˙˙đ˙đđ€€€/ ˙˙đ˙đ€˙˙€ đđ˙đđđ˙€đ€4€$đ€%€đ€đ˙ƒ˙˙đ˙đ˙˙đ˙đđ€€€/ ˙˙đ˙đđƒ˙˙˙˙ƒ˙€ ˙đ˙đ˙˙đ€4€$đ€%€đ€đ˙€đ˙đ˙˙đ˙đđ€€€/€$đ€4€$đ€%€đ€˙˙€đ˙đ˙˙đ˙đđ€đ€€/€$đ€4€$đ€%€đ€˙˙€đ˙đ˙˙đ˙đđ˙đ˙˙€€/€$đ€4€$đ€%€đ€˙đ˙€đ˙đ€ ˙˙˙˙˙˙đ€€/€$đ€4€$đ€%€đ€˙˙˙ƒ˙đ˙đƒ˙đ˙˙đ˙˙˙€€/€$đ€4€$đ€%€đ€%€/€$đ€4€$đ€%€đ€%€/€$đ€4€ ˙˙˙˙˙ƒ˙˙đƒ€đ€%€đ€%€/€$đ€4€˙˙˙˙˙˙˙đ˙˙˙€ đ€%€đ€%€/€$đ€4€ đ˙˙˙˙˙˙˙˙˙€ đ€%€đ€%€/€$đ€4€ đ˙˙˙˙˙˙˙˙˙˙€ đ€%€đ€%€/€$đ€4€ ˙˙˙˙˙˙˙˙˙˙€ đ€%€đ€%€/€ ƒ˙˙ƒ€đ€4€ ˙˙˙˙˙˙˙˙˙˙€ đ€%€đ€%€/€ ˙đ˙˙˙€đ€4€ ƒ˙˙˙˙˙˙˙˙˙€ đ€%€đ€%€/€ ˙˙˙˙˙€đ€4€đ˙đđđ˙˙đ˙˙˙€ đ€%€đ€%€/€ ˙˙˙˙˙€đ€4€ đ˙đ˙˙˙ƒ˙˙˙˙€ đ€%€đ€%€/€ ˙˙˙ƒ€đ€4€$đ€%€đ€đ˙đƒ€˙ƒ˙đđƒđ€€/€ ˙˙˙˙˙€đ€4€$đ€%€đ€˙˙đ˙đ˙˙˙€ ˙˙˙˙˙˙đ€€/€ ˙˙˙˙˙€đ€4€$đ€%€đ€đ˙đđ˙đ˙˙˙€ đ˙đ˙˙˙˙˙đ€€/€ ˙˙˙˙˙€đ€4€$đ€%€đ€đ˙đđ˙đ˙˙˙€đ€˙˙€€/€ ˙đ˙˙˙€đ€4€$đ€%€đ€đ˙đđƒ€˙ƒ˙đ€˙˙đ€€/€ ƒ˙˙ƒ€đ€4€$đ€%€đ€đ˙đđ˙đ˙˙˙€đ€€đ€€/€$đ€4€$đ€%€đ€đ˙đđ˙đ˙˙˙€đ€€đ€€/€$đ€4€$đ€%€đ€đ˙đđ˙đ˙˙€ đ˙đ˙˙˙˙˙đ€€/€$đ€4€$đ€%€đ€˙˙đ˙đ˙˙€ ˙˙˙˙˙˙đ€€/€$đ€4€$đ€%€đ€đ˙đƒ˙đ˙ƒ ˙đ˙˙˙˙đ€€/€$đ€4€$đ€%€đ€%€/€$đ€4€$đ€%€đ€%€/€$đ€4€ đ€đ˙„€ đ€%€đ€%€/€ ƒ€˙đƒ€ đ€4€ đ˙˙˙đ˙˙đ€ đ€%€đ€%€/€ ˙đ˙˙€€ đ€4€ đ˙đ˙˙˙đ€ đ€%€đ€%€/€ ˙˙˙đ˙˙€ đ€4€ đ˙đ˙˙˙đ€ đ€%€đ€%€/€ ˙˙˙đ˙˙€ đ€4€ đ˙đ˙đ˙˙đ€ đ€%€đ€%€/€ ˙˙˙đ˙˙˙€ đ€4€ đ˙đđđ˙đ€ đ€%€đ€%€/€ ˙˙˙˙˙˙€ đ€4€ đ˙đđđ˙đ€ đ€%€đ€%€/€ ˙˙˙˙˙˙€ đ€4€ đ˙đđ˙đ€ đ€%€đ€%€/€ ˙˙˙ƒ˙˙€ đ€4€ đđ˙˙˙˙˙đ€ đ€%€đ€%€/€ ˙˙đđ˙đ˙€ đ€4€ đđ˙˙˙˙đ€ đ€%€đ€ ƒ€˙đƒ€ €/€ ˙ƒ˙đ˙đ˙€ đ€4€$đ€%€đ€ ˙đ˙˙€€€/€$đ€4€$đ€%€đ€ ˙˙˙đ˙˙€€/€$đ€4€$đ€$€đ€ ˙˙˙đ˙˙˙€€/€$đ€3€$đ€$€đ€ ˙˙˙˙˙˙€€/€$đ€3€$đ€$€đ€ ˙˙˙˙˙˙€€/€$đ€3đ€"đ€$€đ€ ˙˙˙ƒ˙˙€€/€$đ€3đƒ€!€&€đ€ ˙˙đđ˙đ˙€€/đ€"đ€3đđ„€„€&€đ€ ˙ƒ˙đ˙đ˙€€/đƒ€!€8đˆ€ˆ€'€đ€$€/đđ„€„€:đ€)€đ€$€2đˆ€ˆ€>đ—€,€đ€$€4đ€Eđ€1€ €#ƒ€7đ—€ˆ€ ƒ€ đ€>đ€€ „€đ„€Ú€#ˆ€đˆ€Ű€%ž€Ý€(˜€ŕ€-Ž€ĺ€˙€! $4€€€€€€€€€€€€ŔŔŔ˙˙˙˙˙˙˙˙˙˙˙˙ ˙€|@ŕKK€˙€!€ ‡˙€„€€˙˙‡˙ˆ˙€„€„€€€€€…€‡€‡˙€€<€ €€˙˙€ƒ€˙˙€ €€˙˙€˙˙˙˙˙˙€€€€˙˙€€ €€€€'€ €˙˙€„˙˙˙˙€ €€€˙˙€˙˙˙€ƒ€ƒ˙˙€˙˙€€ €€€€'€ €€…€€„˙˙˙˙€ €€€˙˙€„€ƒ€ƒ˙˙€€€ €€„˙˙€˙˙„˙˙…€„€ˆ€&€ † ˙˙˙˙˙˙€ € ˙˙˙˙†€€€€˙˙€ƒ€„˙˙„˙˙€€€ †/˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ƒ˙˙€'€ € ˙˙˙˙€ € ˙˙˙˙€ €€€˙˙€„€„˙˙„˙˙˙˙„˙˙‡€€˙˙˙˙˙˙˙˙˙˙€˙˙€„˙˙€€'€ € ˙˙˙˙€ €˙˙„˙˙€ €€€˙˙€˙€˙„˙˙˙€˙˙€€ €˙˙˙˙˙˙˙˙˙˙€˙˙€ ˙˙˙€€'€ € ˙˙˙˙€ €˙˙„˙˙€ €€€˙˙€ ˙˙˙˙€˙„˙˙˙€˙˙€€ € ˙˙˙˙˙˙ˆ˙˙€˙˙˙˙˙˙˙˙€€'€ €˙˙˙˙˙˙€€€ €ƒ˙˙€ €€˙˙€ ˙˙˙˙€€ ˙˙˙˙€€˙˙€€ € ˙˙˙˙€˙˙€˙˙˙˙˙˙˙˙˙˙˙€€'€ €€…˙˙€†˙˙€ €˙˙‡€€‡€„€„€€˙˙˙˙˙˙€„˙˙˙€€ €€„€˙˙€„˙˙˙˙€…˙˙€€&€0€î€,˙˙€î€-„€ď€˙€!€èo€e€J€o €e€ đ˙đđƒđƒ€€ ˙đ˙˙€˙˙˙ƒ€€o€e€ đ˙đđ€˙˙€đđ˙đđđđ˙€ ˙đ˙˙˙˙€€o€e€ đđđ€˙˙€˙˙˙˙˙đ˙˙˙đ˙˙˙đ˙˙˙€€o€e€ đđđ€˙˙€˙˙˙€ đ˙˙˙đ˙€˙˙€€o€e€ đđđ˙˙˙˙€˙˙˙€đ€˙˙€˙˙€€o€e€ đđđ€˙˙€˙˙˙€đ˙˙˙˙˙˙ƒ€€o€e€ đđđ€˙˙€˙˙˙€đ˙˙đ˙˙˙˙˙˙€€o€e€ đđđ€˙˙€˙˙˙˙˙đđ˙đ˙˙˙˙˙˙€€o€e€ đ˙đ€˙˙€đđ˙đđđ˙˙˙˙˙đ˙˙˙˙€€o€e€ đ˙đđƒ˙˙˙˙ƒ˙€˙đ˙đ˙˙˙˙đ˙˙˙đ€ €o€e€J€o€e€,đ€€o€e€(€€€o€e€$đđ˙đ˙˙˙đ˙đđ˙đ˙˙đ„€€o€e€đ˙˙˙˙˙˙˙˙˙˙˙€˙đđđđđ€€o€e€đ˙ƒ ˙˙˙˙˙ƒ˙€€˙˙đđđđđ€€o€e€đ˙€ ˙˙˙˙€đ˙€˙˙đđđđđ€€o€e€đ˙€ ˙˙˙˙€˙€˙˙đđđđđ€€o€e€đ˙˙˙˙˙˙˙˙˙˙˙€˙˙đđđđđ€€o€e€)đ˙đ˙đ˙đ˙đ˙đ˙đ˙˙˙˙˙˙đđđ€€o€e€€/€o€e€J€o€e€đ€ ƒ˙˙ƒ˙đ€€€o€e€đđ€ ˙đ˙€˙€ € €€o€e€đđ€ ˙˙˙€đ˙đ€ € €€o€e€ ˙đ˙˙˙đ˙˙˙đ˙˙˙˙˙€đ€˙đđ˙˙˙đ˙đ˙đ˙˙€o€e€đđđđđđđđđđđđ€˙˙˙ƒ˙đ€ ˙˙˙˙€˙˙˙˙˙˙˙˙˙€o€e€đđđđđđđđđđ€˙˙˙€đ€˙˙ƒ˙€ ˙˙˙˙˙˙ƒ˙˙€o€e€đđđđđđđđđ˙˙đ€˙˙˙€đ€˙˙€€ ˙˙˙˙˙˙€€o€e€đđđđđđđđđđ˙˙đ€˙˙˙€ đ˙đ˙˙˙€€ ˙˙˙˙˙˙€€o€e€đđđđđđđđđđđđ€˙đ˙€ ˙˙˙˙˙˙€˙˙˙˙˙˙˙˙˙€o€e€đđ˙˙˙đđ˙˙đ€ƒ˙˙ƒ$˙đ˙˙˙đ˙đ˙˙˙˙đ˙đ˙đ˙˙€o€e€J€o€èo€†đ€˜€†€—€…đƒ€—€…„€–€„đ…€–€„†€•€†đ€˜€†đ€€€†đ€đ€€†đ€ƒ€€†đ€„€€†đ€đ„€€†đ€ƒ€€† đ˙˙đ˙€€†đ˙˙ƒ˙˙€€† đ˙đ˙˙€€†đđƒ€€€†đ„€€€†đ„€€€†đƒ€€€†đ€€€†đ€€€†đ€€€€€Œđ†€€…€€đ„€Ž€Žƒ€Ž€Žđ€€èo€e€J€o€e€ ˙˙˙ƒ„đ€đ˙˙đ˙˙đ˙€˙đƒ˙ƒ€€o€e€ ˙˙€đ˙đ€˙˙˙˙˙˙˙˙˙đ˙˙đ˙˙˙€€o€e€ ˙˙€đ˙đ˙˙đ˙đđ˙đ˙đ˙˙˙đ˙€˙˙€€o€e€ ˙˙€đ˙đ˙˙đ˙đđ€€˙˙€˙˙€€o€e€ đ˙ƒ˙˙đ˙đ˙˙đ˙đđ€€˙˙€ƒ€€o€e€ đ˙€đ˙đ˙˙đ˙đđ€€đ˙˙˙˙˙€€o€e€ ˙˙€đ˙đ˙˙đ˙đđ€đ˙˙đ˙˙˙˙˙˙€€o€e€ ˙˙€%đ˙đ˙˙đ˙đđ˙đ˙˙˙˙˙˙˙đ˙˙˙˙€€o€e€ ˙đ˙€đ˙đ€˙˙˙˙˙˙đ˙˙˙˙˙đ˙˙˙đ€ €o€e€ ˙˙˙ƒ˙đ˙đƒ˙đ˙˙đ˙˙˙˙˙˙˙˙đ˙˙˙đ€ €o€e€J€o€`đ…€J€o€a…€J€o€ađ„€J€o€b„€Iđ€o€bđƒ€Iđ€n€bđƒ€Iđ€m€b„€Iđƒ€m€ađ€Jƒ€l€a˙đ€J„€k€`đ˙˙€Jđƒ€k€`€€J˙ƒ€j€_đ€€J˙˙ƒ€i€_€€J˙˙đƒ€i€^đ€€J€ƒ€h€^€€J€ƒ€g€]đ€€J€đƒ€g€]€€J€ƒ€f€\đ€€J€ƒ€f€\€€J€đƒ€e€[đ€€J€ƒ€d€[€€J€đƒ€d€Zđ€€J€đƒ€c€Z€ ̀ ƒ€b€Yđ€ ̀ đƒ€b€Y€`đƒ€a€Xđ€aƒ€`€X€bđƒ€`€Wđ€cđƒ€_€W€eƒ€^€Vđ€eđƒ€^€V€gđ€]€Uđ€hƒ€\€U€iđƒ€\€Tđ€jƒ€[€T€lƒ€Z€Sđ€lđƒ€Z€S€nƒ€Y€R€oƒ€X€Qđ€pđƒ€X€Q€rƒ€W€Pđ€sƒ€W€P€tđƒ€V€Ođ€uƒ€U€O€vđƒ€U€Nđ€wđƒ€T€N€yƒ€S€Mđ€yđƒ€S€M€{đƒ€R€Lđ€|ƒ€Q€L€}đƒ€Q€Kđ€~đƒ€P€K€€ƒ€O€Jđ€€đƒ€O€J€‚đ€N€Iđ€ƒƒ€M€I€„đƒ€M€Hđ€…ƒ€L€H€‡ƒ€K€Gđ€‡đƒ€K€G€‰ƒ€J€Fđ€Šƒ€I€F€‹đƒ€I€Eđ€Œƒ€H€E€Žƒ€G€Dđ€Žđƒ€G€?đ€€ƒ€F€?đ˙˙đ€‘ƒ€F€?đ˙˙€’đƒ€E€?đđ€“ƒ€D€?đ„€”đƒ€đ€?€?đƒ€•đƒ€€?€?đƒ€—ƒ˙đ€?€?đƒ€–đƒ˙€?€2𑀗đ…€?€-đ—€–…€?€*đ€“đ„€?€(đˆ€ˆ€‘đ„€?€'đ„€„€’€2€&đ€!€Ž˜€-€%đ€#đ€Šž€*€%€%€ˆˆ˙€ đˆ€(€%€%€‡„€đ„€'€%€%€†€ đ€&€%đ€"đ€…€$€%€%đƒ€!ƒ€„đ€$đ€%€%đđ„€„€„đ€$đ€%€%đ˙đˆ€ˆ˙€„đ€$đ€%€%đ€đ€€…€#ƒ€%€%đ€đ—€€…ƒ€ đƒ€%€%đ€ đ€ €…„€đ„đ€%€%đ€%€…˙ˆ€đˆ˙đ€%€%đ€%€…€ž€đ€%€%đ€%€…€˜€đ€%€%đ€%€…€ Ž€ đ€%€%đ€%€…€$đ€%€%đ€˙˙˙ƒ„đ€ đ˙˙đ˙˙đ€€…€$đ€%€%đ€˙˙€đ˙đ€ ˙˙˙˙˙˙€€…€$đ€%€%đ€˙˙€đ˙đ˙˙đ˙đđ˙đ˙đ€€…€$đ€%€%đ€˙˙€đ˙đ˙˙đ˙đđ€€€…€$đ€%€%đ€đ˙ƒ˙˙đ˙đ˙˙đ˙đđ€€€… ˙˙đ˙đđƒđƒ€€˙đ˙€đ€%€%đ€đ˙€đ˙đ˙˙đ˙đđ€€€… ˙˙đ˙đđ€˙˙€ đđ˙đđđđ€đ€%€%đ€˙˙€đ˙đ˙˙đ˙đđ€đ€€… ˙˙đđđ€˙˙€ ˙˙˙˙˙đ€đ€%€%đ€˙˙€đ˙đ˙˙đ˙đđ˙đ˙˙€€… ˙˙đđđ€˙˙€˙˙˙€đ€đ€%€%đ€˙đ˙€đ˙đ€ ˙˙˙˙˙˙đ€€…˙˙đđđ˙˙˙˙€˙˙˙€đ€đ€%€%đ€˙˙˙ƒ˙đ˙đƒ˙đ˙˙đ˙˙˙€€… ˙˙đđđ€˙˙€˙˙˙€đ€đ€%€%đ€%€… ˙˙đđđ€˙˙€˙˙˙€đ€đ€%€%đ€%€… ˙˙đđđ€˙˙€ ˙˙˙˙˙đđ€đ€%€%đ€%€… ˙˙đ˙đ€˙˙€ đđ˙đđđ˙€đ€%€%đ€%€… ˙˙đ˙đđƒ˙˙˙˙ƒ˙€ ˙đ˙đ˙˙đ€%€%đ€%€…€$đ€% €%đ€ ƒ˙˙ƒ€€…€ ˙˙˙˙˙ƒ˙˙đƒ€đ€%€%đ€ ˙đ˙˙˙€€…€˙˙˙˙˙˙˙đ˙˙˙€ đ€%€%đ€ ˙˙˙˙˙€€…€ đ˙˙˙˙˙˙˙˙˙€ đ€%€%đ€ ˙˙˙ƒ€€…€ đ˙˙˙˙˙˙˙˙˙˙€ đ€%€%đ€ ˙˙˙˙˙€€…€ ˙˙˙˙˙˙˙˙˙˙€ đ€%€%đ€ ˙˙˙˙˙€€…€ ƒ˙˙˙˙˙˙˙˙˙€ đ€%€%đ€ ˙đ˙˙˙€€…€đ˙đđđ˙˙đ˙˙˙€ đ€%€%đ€ ƒ˙˙ƒ€€…€ đ˙đ˙˙˙ƒ˙˙˙˙€ đ€%€%đ€%€…€$đ€%€%đ€ đ˙˙đ˙„€ €…€$đ€%€%đ€ đ˙˙˙đ˙˙đ€ €…€$đ€%€%đ€ đ˙đ˙˙˙đ€ €…€$đ€%€%đ€ đ˙đ˙đ˙˙đ€ €…€$đ€%€%đ€ đ˙đđđ˙đ€ €…€ €˙đƒ€ đ€%€%đ€ đ˙đđđ˙đ€ €…€ ˙đ˙˙€€ đ€%€%đ€ đ˙đđ˙đ€ €…€ ˙˙˙đ˙˙€ đ€%€%đ€ đđ˙˙˙˙˙đ€ €…€ ˙˙˙đ˙˙€ đ€%€%đ€ đđ˙˙˙˙đ€ €…€ ˙˙˙đ˙˙˙€ đ€%€%đ€%€…€ ˙˙˙˙˙˙€ đ€%€%đ€%€…€ ˙˙˙ƒ˙˙€ đ€%€%đ€%€…€ ˙˙đđ˙đ˙€ đ€%€%đ€%€…€ ˙ƒ˙đ˙đ˙€ đ€%€%đ€%€…€$đ€%€%đ€$€…€$đ€%€&€#ƒ€…€$đ€$€&ƒ€ đ€‡€$đ€$€&„€đ„€‡€$đ€$€)ˆ€đˆ€ˆ€$đ€$€+ž€Šđ€"đ€$€.˜€đƒ€!€&€3Ž€’đđ„€„€&€Öđˆ€ˆ€'€Řđ€)€Űđ—€,€ŕđ€1€˙€!Ô ‰? ÔÁŕČ ěÁĂ ĂNETLOCK: A Utility for Lock Managementƒ Ô ‰?Č ÔÁŕˆěÁAcross a DECnet NetworkÄ Äƒ Áŕ,ě"ÁRoger G. Ruckertƒ Áŕhě#ÁMedtronic, Inc.ƒ Áŕl ěÁ7000 Central Ave., Mail Stop 111ƒ ÁŕÄěÁMinneapolis, MN 55432ƒ Áŕ0 ěÁInternet: rucker@a1.medtronic.comƒ ĂĂAbstract.ÄÄ As more users need dedicated access to shared resources, the potential for concurrent use of the resource increases. While the lock management facilities of VMS are sufficient for clusterŞwide locking, there is no corresponding facility for networkŠwide locking. This paper describes one implementation of a DECnetŠwide lock management system. ĂĂOverview.ÄÄ Since the beginning of multiprogramming, locks have been an indispensable part of the programmer's toolkit. Techniques from the older mutual exclusion (MUTEX) to the newer spinlocks of VMS version 5 have had a common goal: to keep multiple processes from having access to the same resource at the same time. Such simultaneous access can have unpredictable results, including data corruption (from multiple disk access) to system crashes (from multiple memory access). Different operating systems include varying facilities to help the programmer manage locks. For example, OS/400, the operating system on IBM's AS/400 machines, has "Allocate Object" and "Deallocate Object" commands. This allows a program to get a lock on a predefined object and hold it until the lock is explicitly released by the program or the system's lock manager determines that the program is no longer active, in which case the operating system frees up the lock. This simple pair of commands allows for very easy access to the operating system's lock management facilities. ĂĂVMS and Lock Management.ÄÄ VMS implements lock management in 2 ways, one indirect and the other direct. Indirectly, multiple processes may be prevented from accessing the same resource at the same time due to a VMS design decision. To illustrate, two DCL programs cannot open the same file for writing simultaneously, or the following error is returned to the second program: ĂĂÁŕpěÁ%RMSŠEŠFLK, file currently locked by another userÄă However, there is no way to prevent a second user from renaming the file while the first program has the file open for write, even though this may be undesirable. We have found that indirect lock management is not robust enough to satisfy our needs. At the other extreme from indirect lock management is direct lock management. The lock management system services of $ENQ (enqueue lock request), $DEQ (dequeue lock request), and $GETLKI (get lock information) provide a rigorous set of routines for lockÔh)0*0*0*°°Ô management. While they can be useful in and of themselves, they may also be useful as building blocks for more sophisticated lock management techniques. (For a recent overview of these system services in this publication, refer to the article "VMS Kernels: What's a Lock?" in the August, 1990 issue.) ĂĂLimitations of the VMS Lock Management Services.ÄÄ Our environment consists of a central VAXcluster and many remote DECnet nodes. Due to the specialized needs we have in our multivendor environment, we employ many DCL command procedures to shield operators and users from the necessity of machine specific knowledge. These two observations reveal what for us were the two critical limitations of the VMS lock management services: 1. It is impossible to coordinate locks across a nonŠclustered DECnet network, as locks are node or cluster specific. We had a specific application that needed to ensure only one remote node would be performing maintenance on a database located on the VAXcluster. We were unable to accomplish this using these services. 2. While a lock is granted to a process, it is typically granted and released during the same image execution. In the usual case, this means that obtaining a lock, performing the desired task, and releasing the lock must all take place within the same program image, as all process locks are released as part of image rundown. (A lock converted from processŠowned to systemŠowned would not have served our purposes, as there would be no owning process, and deadlocks could occur.) Since our command procedures consisted of multiple image activations interspersed with DCL commands, the VMS lock management services were useless to us. Clearly, we needed a solution to these problems. After we queried software vendors and looked at DECUS tapes, it became evident that it would have to be a locally written utility to handle the job. ĂĂDescription of Components.ÄÄ The two main components of the NETLOCK system are programs called NETLOCK and NETLOCKMGR. These programs manipulate a NETLOCK database, which is local to each node and contains all active locks on this node. There is also an audit file with records for each old lock, telling who had the lock, when it was granted, and when it was released. Finally, there is an objects file, containing all of the objects that may be locked at this node. For instance, you wouldn't want each node in the cluster to have the same objects in their objects file, or the purpose for NETLOCK would be defeated. The objects could be spread among the different nodes of the cluster. (Due to the nature of DECnet taskŠtoŠtask programming, the programs and sequence of events described are identical on all participating nodes, even when locks are requested on the same node as the requestor.) The NETLOCK program runs in one of two modes. If it is making a request of another NETLOCK program, meaning the calling process is the one wishing to lock or unlock an object, it issues its request. Ôh)0*0*0*°°Ô If its process mode is "network", it is being called by a remote node to either lock or unlock an object. For locks, Úy!"čxČČČ$ddƒNETLOC.PCXx<yÚÔ$°°(#(#X°°(#(#!°'#$Ô NETLOCK verifies that no one else has a lock on that object. It then checks the objects file to see if the requested object can be locked at this node. If so, the request is granted. For incoming unlock requests, the lock is released and a record is written to the audit file. The NETLOCKMGR program serves two main functions: to provide a list of active locks on a particular node; and to verify if a process holding a lock is still active. (This is the deadlock prevention component of the NETLOCK system.) Accordingly, there are three process modes that NETLOCKMGR can run in. If it is "interactive", NETLOCKMGR will return all objects locked on the specified target node. When run as a "network" process, the program does one of two things, depending on what it is requested to do. It either passes a list of locks on the local node to the requesting program, or verifies that a process is still active that has an outstanding lock on the requesting node. In "detached" mode, NETLOCKMGRÔ0h)0*0*0*°°Œ°'#ĺ!0Ô awakens every 15 minutes and verifies that all processes holding locks on the local node are still ÚyA"čxČČČ$ddƒNTLOCMGR.PCXx<yÚÔ$°°(#(#X°°(#(#A°'#$Ô active. It does this by communicating with NETLOCKMGR on the nodes of the processes holding locks on the local node. ĂĂSample Scenario.ÄÄ User RUCKER on node MSPV2 wants to use a command procedure called RESTORE to restore a particular file. Since RESTORE is defined as on object on node MSPV1, a NETLOCK request is issued to MSPV1. Assuming that the object is not currently in use, a lock is assigned to MSPV2::RUCKER for object RESTORE. (If a user were to use NETLOCKMGR to get a list of locked objects on MSPV1 at this time, he would see that RESTORE is locked by MSPV2::RUCKER.) If another user wanted a lock on RESTORE, his process would get an error message indicating that a lock already existed on object RESTORE. At this point, NETLOCKMGR on MSPV1 awakens and determines that there are outstanding locks on this node. It communicates with NETLOCKMGR on node MSPV2 to ensure that RUCKER is still an activeÔ0h)0*0*0*°°Œ°'#ĺA0Ô process there. Assuming that it is, NETLOCKMGR now goes to sleep for 15 minutes. Let's suppose that process MSPV2::RUCKER now terminates abnormally, thus not releasing the lock on RESTORE. When MSPV1's NETLOCKMGR awakens again and realizes there are outstanding locks on this node, it will again communicate with MSPV2::NETLOCKMGR. At this point, MSPV2::NETLOCKMGR realizes that process RUCKER no longer exists, so it passes this information along to MSPV1::NETLOCKMGR, which releases the lock on that object. ĂĂProgrammer Interface.ÄÄ One of the design goals was to keep the programmer interface as simple as possible. Therefore, there is a command procedure corresponding to the program for each of NETLOCK and NETLOCKMGR. These commands are typically in turn embedded within other command procedures so the end user is usually unaware that such a procedure is even in use. Here is the usual command that the programmer will use: Áŕ€ěÁ$ NETLOCK ƒ This command has parameters which are selfŠexplanatory. It is good programming practice, after issuing a LOCK and performing the task, to issue an UNLOCK rather than wait for NETLOCKMGR to detect a potential deadlock and release the lock. The "WAIT/NOWAIT" parameter indicates whether the command will wait and retry if an object is currently locked. This is especially useful for batch jobs that run overnight, where a "WAIT" option is almost always chosen. The NETLOCKMGR command just provides a list of current locks on the specified node. It is typically used by the system manager in case of a problem. The syntax is simply: Áŕxě!Á$ NETLOCKMGR ƒ ĂĂAreas for Improvement.ÄÄ This program was written using transparent DECnet programming. From a security point of view, it could be enhanced to use nonŠtransparent DECnet so that the NETLOCK account used by the various network processes would not have the potential security weaknesses that the transparent DECnet implementation has. For our particular environment, we feel it is secure enough. From the object contention perspective, each user is "on his honor" to lock an object before using it. If a user doesn't, then the purpose of the system is circumvented. There might be more sophisticated ways to disallow access to particular files unless the corresponding object lock exists. Again, for our purposes, the current implementation is sufficient. Please send any comments and/or suggestions to the author at the above address. ĂĂAcknowledgement.ÄÄ The author would like to thank Scott Fisher and Chuck Perrin for their contributions to this article.