
	Weekly chat #17: Friday 7th May 1999


Participants: Peter Kretschmar, Carol Anne Oxborrow, Soren Brandt, Allan
	Hornstrup, Niels Joergen Westergaard, Stefan Larsson, Juhani
	Huovelin, Sami Maisala.



Subjects covered: 
	Observational versus SciWin analysis for JEM-X (QL?)
	Instrument description data structures:
		-MASK-MOD; -COLL-MOD; -DETE-MOD; -EDBS-MOD
		Energy binning tables: DFEE, DPE and PI
		Transmission parameters
		Change of name `FAKE EVENTS' to  `GREY EVENTS'
	Problems with ISDC webpages: cgi scripts
	

Action Items


AI990507_1	AH	ASAP		Arrange a meeting of ISSW/IT people
to discuss the if and when of observational, rather than Sci Win, analysis.
OPEN

AI990507_2	CAO, AH, PK, SB end May 99	To find out how the onboard
binning and PI channels will be determined  and how changeable any of these
three might/can be. This requires also consultation with the IT.
OPEN

*** IRC session log started at Fri May  7 09:31:09 1999.
<Peter:#jemxadr> Hi Carol Anne & Allan!
H oxborrow     #jemxadr 0 Carol Anne Oxborrow        ~oxborrow@130.226.216.181
H allan        #jemxadr 0 Allan Hornstrup                ~allan@apollo.dsri.dk
H Peter@       #jemxadr 0 KRETSCHMAR Peter         ~pkretsch@isdcul10.unige.ch
315 apollo.dsri.dk * End of /WHO list.      
#jemxadr> Hi Peter, and Allan. Are you ready to chat?? END
<allan:#jemxadr> YEs
<Peter:#jemxadr> I'll consider it END
*** sb <~sb@apollo.dsri.dk> joined channel #jemxadr
#jemxadr> Is soren with you Peter? Or nearby? END
#jemxadr> Talk of the devil.......END
<sb:#jemxadr> hello, do you read me End
#jemxadr> Loud and clear SB. END
#jemxadr> Will Stephane be joining in, Peter? END
<Peter:#jemxadr> Not if I don't ask him. END
*** njw <~njw@heao1.dsri.dk> joined channel #jemxadr
*** larsson <~larsson@tenma.dsri.dk> joined channel #jemxadr
<larsson:#jemxadr> Morning, sorry to be a little late. END
#jemxadr> Let's give the Finns a couple of minutes, and then we'll start...END
#jemxadr> i'm just ringing juhani now end
#jemxadr> He'll be joining us ASAP END
*** huovelin <~huovelin@taurus.astro.helsinki.fi> joined channel #jemxadr
#jemxadr> Okay, let's get started: Hi Juhani...END
<njw:#jemxadr> Can I open the discussion on instrument description data structur
+es ? END
#jemxadr> Left over AIs from previous meetings: AI981204_3AH/NJWMay 1999Determin
+e whether an observational QLA
#jemxadr> is needed for JEM-X
#jemxadr> OPEN
<huovelin:#jemxadr> Hi There, I will try to get along myself, before sami comes 
+in (takes about 15 minutes) END
#jemxadr> How's this one going NJW and AH? Observational analysis needed or what
+? END
<njw:#jemxadr> Hmm .. still ponding - we obviously need a decision - next week O
+K ? END
<Peter:#jemxadr> If we actually get it then ... END
#jemxadr> Should those of us at DSRI get together and discuss the pro's and con'
+s of ScW versus Observation? END
<njw:#jemxadr> We should, yes END
#jemxadr> When are we all available, including NL? END
<njw:#jemxadr> Mon Tue Wed END
#jemxadr> Rather than spend chat time on this, let's say we'll meet sometime
#jemxadr> withint the next 2 weeks, and make a definite decision then. 
#jemxadr> So we'll have this issue decided by the end of the month of May, which
#jemxadr> is what the AI calls for. END
<sb:#jemxadr> if we are serious about detecting transients with JEMX, more than 
+a 20-30 min obs is needed END
<sb:#jemxadr> I don't see that this is a hard decision END
<sb:#jemxadr> the answer is YES END
#jemxadr> Good, SB. Do NJW and AH think it's a hard decision? END
<allan:#jemxadr> We will be happy to hear your arguments when you are back, Sore
+n. END
<Peter:#jemxadr> OK. But then you also need to describe HOW you are going to do 
+it, i.e. marrying multiple pointings. END
<allan:#jemxadr> We will do the home work in due time, i.e. before end of MAY. E
+ND
<sb:#jemxadr> marrying multiple pointings must be done at some stage anyway... E
+ND
#jemxadr> Can I put an AI on Allan to arrange the meeting with S/W and IT people
+, so that we can thrash out if and how? END
<Peter:#jemxadr> Fine with me :-) END
<allan:#jemxadr> That is not a new AI, is it? END
<sb:#jemxadr> I will just put one argument here: the initial phase of the X-ray 
+nova is one of the most important goals of JEMX/Integral END
#jemxadr> And for that we need an observational analysis? END
<allan:#jemxadr> Can we break this discussion and go on with agenda item 1? END
#jemxadr> Yes, I agree, lets
#jemxadr> keep this discussion internal. END
#jemxadr> The other AI's due now have to do with getting NL and the onboard SW p
+eople to divulge their secrets regarding telemetry.
#jemxadr> Allan, Soren and I have all done our bit to get them to produce an off
+icial new description of the telemetry packets, includeing
#jemxadr> the countrate packet, and promises have been made on their side....
#jemxadr> however, we haven't seen anything concrete yet....I think our AI's are
<Peter:#jemxadr> You should let them sign in blood ... Oh well, NL is the PI aft
+er all ... END
#jemxadr> closed, but we're still waiting for the results to appear...END
<allan:#jemxadr> The EM will be delivered May 17, and then the telemetry formats
<allan:#jemxadr> are final - (almost:-) END
<sb:#jemxadr> so did you at DSRI talk with Ib this week about it ?
<sb:#jemxadr> Sorry i forfot the END
#jemxadr> Our last outstanding AI is due in June, for the skeleton version of th
+e DDD... so we'll forget than now. END
#jemxadr> Next on the agenda: instrument description data structures......thanks
+ Stefan for sending a good list of your required data structures. Any comments?
+ END
#jemxadr> To SB: yes, I had a long chat with IB this week. END
<Peter:#jemxadr> Comments to data structures:
<sb:#jemxadr> Yes, I strongly dislike the word FAKE End
<sb:#jemxadr> Also, I had a discussion with Stephane about the gap routine.
<Peter:#jemxadr> JMXi-MASK-MOD: I assume the hole geometry, mask orientation etc
+ are supposed to be in keywords (=attributes in DALspeak)? END
<sb:#jemxadr> He said there could be gaps returned that were not from missing pa
+ckets. I don't quite understand that END
<Peter:#jemxadr> Still JMXi-MASK-MOD: AFAIK the holes partially shielded by the 
+support structure have been decided to be closed. END
<larsson:#jemxadr> To Peter: Yes. END
<larsson:#jemxadr> To Peter again: Partly shielded holes: OK it simplifies thing
+s. END
<sb:#jemxadr> Sorry, I think I got started on another doc from Stephane END
<Peter:#jemxadr> JMXi-COLL-MOD: What is this supposed to hold? END
*** smaisala <~smaisala@taurus.astro.helsinki.fi> joined channel #jemxadr
<smaisala:#jemxadr> hi there! Sorry I am late .( end
<larsson:#jemxadr> JMXi-COLL-MOD: A description of the shadowing due to the coll
+imator. END
#jemxadr> Yes, what does this hold in your current SW, NJW? END
<Peter:#jemxadr> "description of the shadowing" is still vague to me - sorry END
#jemxadr> Won't this go in MASK-MOD, as partially covered holes, and also turn u
+p in the angular transmission description? END
#jemxadr> Aren't we in danger of correcting for the collimator twice? END
<larsson:#jemxadr> Shadowing: If a trajectory from an event position towards a s
+ource intersects
<larsson:#jemxadr> the collimator. END
<Peter:#jemxadr> To SL: So far so good, but what precisley are you storing in th
+e structure? END
<njw:#jemxadr> Sorry for being absent for a while - a visitor came.
<larsson:#jemxadr> Sorry Peter. Right now I am not storing anything. 
<larsson:#jemxadr> I have not yet included this in my software!! END
<njw:#jemxadr> The shadowing of the collimator is a table of throughput as a fun
+ction of off-axis angle
<njw:#jemxadr> this table must be repeated for a series of azimuth angles becaus
+e of the square shape of collimator tunnels END
<Peter:#jemxadr> So this would be fine for you as well Stefan? END
<larsson:#jemxadr> To NJW: I also need the positional dependence over the detect
+or. END
<njw:#jemxadr> To Stefan: OK, I can supply that. END
<larsson:#jemxadr> Fine END
<njw:#jemxadr> I have a structure for the instrument description in mind where t
+he main entrance
<njw:#jemxadr> is a grouping table pointing to the various data elements holding
<njw:#jemxadr> keyword(attribute) information and/or tables. In this way the
<njw:#jemxadr> way to find information will be one file and one element name END
<larsson:#jemxadr> Sounds like a good idea to me NJ. END
<Peter:#jemxadr> Sounds good to me. Have you discussed this with Stephane? END
<njw:#jemxadr> No not yet END
<Peter:#jemxadr> OK, I'll ask him, if there is anything to consider with this ap
+proach. END
<Peter:#jemxadr> Btw, looking at JMXi-DETE-MOD, which seems to contain several t
+hings:
<Peter:#jemxadr> please do all remember that an individual ISDC data structure
<Peter:#jemxadr> corresponds to a _single_ FITS extension. I.e. as soon as you h
+ave
<Peter:#jemxadr> multiple tables, arrays, etc, you also need multiple structures
+. END
<njw:#jemxadr> Yes, Peter. I'm aware of that, but I think it is possible. END
<Peter:#jemxadr> I assumed you understand this but want to make sure everybody k
+eeps this in mind. END
<larsson:#jemxadr> The mix of things in JMXi-DETE-MOD e.g. are mainly stored as 
+keywords. END
<Peter:#jemxadr> What about the Energy boundaries? Whould we just leave them as 
+separate entity? END
<larsson:#jemxadr> Right Peter. But NJ dont think they are needed so maybe they 
+will drop out. END
<njw:#jemxadr> Stefan: what kind of energy boundaries are you talking about ? EN
+D
<allan:#jemxadr> (I have to leave for a few minutes) END
<larsson:#jemxadr> Energy boundaries for data channels. END
<larsson:#jemxadr> So they will be needed I think. END
<njw:#jemxadr> I think that such boundaries should be defined elsewhere since th
+ey are not intrinsic values END
#jemxadr> The energy boundaries of the channels will be written by me and are st
+ored in -EDBS-MOD END
<larsson:#jemxadr> OK I see the point. END
<larsson:#jemxadr> (I will be happy with your -EDBS-MOD CAO) END
<Peter:#jemxadr> To CAO: if you generate them with your ISSW they should be call
+ed -CAL and not -MOD, right? END
#jemxadr> No, the PI channels will be determined beforehand, during pre-flight c
+alibration,
#jemxadr> or maybe just by chatting with astronomers and IT people to see what d
+istribution of channels will be most suitable
#jemxadr> for the instrument's energy range.
<Peter:#jemxadr> And why do you write them then? END
<Peter:#jemxadr> There seems to be something I'm missing here ... END
<njw:#jemxadr> But the definition of the PI channels can change now and then dur
+ing the mission lifetime ?? END
#jemxadr> Then I do the corrections on the energy data by binning the event appr
+opriately following the table and the current energy/channel relationship deter
+mined by the calibration spectra. Hence this is a MOD file. END
<Peter:#jemxadr> Sorry, I'm still confused. What I had envisaged is the followin
+g:
#jemxadr> Because I'll determine what the model will be, after due discussion wi
+th people, and there is a chance that these channels could change if the the te
+lemetry binning of the energy is changed by uploading a different binning table
+to the
#jemxadr> DPE END
<Peter:#jemxadr> - You have a MOD file which 'just exists'. Naturally it can lat
+er be updated, replaced by a new version etc. 
#jemxadr> We want to ensure that there's the same energy coverage for the PI cha
+nnels as for the data/telemetry channels. END
<Peter:#jemxadr> - You do the gain calculation to calculate the channel->energy 
+relationship, this will lead to the "gain history" DS
#jemxadr> Perhaps it's more appropriate then for PreProcessing to determine the 
+PI channels, based on the DPE binning table that's being used for a given SciWi
+n. END
<Peter:#jemxadr> - In JCorrection you apply the -MOD file and the gain history t
+o calculate the appropriate PI values for individual events. END
<Peter:#jemxadr> Rather ICA (Intsrument Configuration Analysis). Btw, ist it cle
+ar how ISDC gets informed about the DPE table changes? END
<Peter:#jemxadr> And if this feature is '
#jemxadr> To Peter: it's not clear how ANYONE gets hold of the DPE binning table
+ :-)
#jemxadr> At the moment providing Ib with a bottle of whisky seems the best way.
+....END
<Peter:#jemxadr> 'volatil' then the corresponding DS shouldn't be called -MOD IM
+HO. 
<Peter:#jemxadr> Seems I have something more to discuss with various people. END
<Peter:#jemxadr> Should I just try and call Ib directly? END
<sb:#jemxadr> the binning table can be obtained from a memory dump, I am sure EN
+D
#jemxadr> All I know at the moment, and this is where it gets even more complica
+ted:
<sb:#jemxadr> ... and it will NOT be changed often END
<sb:#jemxadr> Yes, don't expect to do this automatically END
#jemxadr> there will be one permanent binning table in the DFEE (Ib's domain) to
+ bin the calibration spectra so that they can be passed on to the DPE as pure H
+K data
<Peter:#jemxadr> OK. Back to the DPE table. ISDC _absolutely_ needs a procedure 
+on how this will be updated.
<Peter:#jemxadr> There is no problem, if this is done only from time to time,
#jemxadr> and there will be another uploadable binning table in the DPE which wi
+ll be used to bin science data. This one can in theory change, though it should
+ happen as seldom as possible.
<Peter:#jemxadr> to organize it by having the memory dump checked by DSRi and a 
+new ...-MOD DS delivered to us.
<Peter:#jemxadr> The real and _very important_ question is: what _is_ the expect
+ed frequency for these changes? Can we/should we do somethin automatic to detec
+t them (SB says no)? END
<sb:#jemxadr> I guess the basline will be to adjust the table in orbit, but befo
+re the science phase END
#jemxadr> In theory users can see this binning change is possible in the user's 
+manual, but they'll be strongly discouraged from using this option....
<sb:#jemxadr> if something unexpected happens with the detector it may be change
+d
<sb:#jemxadr> otherwise it should stay (forever) END
#jemxadr> and anyway changing the binning to cover a smaller energy range may no
+t produce any energy advantages since the binning already borders on the limit 
+of the instrument resolution END
<Peter:#jemxadr> OK. So the baseline is - this is a -MOD data structure, updated
+ if need be, but not changed frequently at whim.
<Peter:#jemxadr> It has to be delivered by DSRI. END
#jemxadr> That's why I'd assumed it was my responsibility....maybe my assumption
+ was wrong? END
<Peter:#jemxadr> Sorry, probably I misunderstood something there. 
<Peter:#jemxadr> Were you saying that you would send us updated versions every n
+ow and then,
<allan:#jemxadr> (I am back - for a couple of minutes.)  May I add a bit on the 
+energy issue? END
<Peter:#jemxadr> or were you thinking of generatingit as part of your ISSW deliv
+ery? END
#jemxadr> Soren and I are still not sure if there should be 64 PI channels, or 1
+28 channels to cut down on loss of information during rebinning from PHA to PI.
+ END
<allan:#jemxadr> I am sure S
<allan:#jemxadr> of the channels , which should not be altered. There is, howeve
+r,
<allan:#jemxadr> the possibility of doing so, and since ESAs policy is to
#jemxadr> My ISSW will be reading the DFEE and DPE binning tables (two separate 
+tables), so I'm in the best possition to decide IF an new PI arrangement is req
+uired (that could be a big if) END
<allan:#jemxadr> describe ALL possiblities in the UM, there MAY be users
<allan:#jemxadr> who want their own energy channel -binning.  But they are 
<allan:#jemxadr> recommended not to do so, also because there then will be diffe
+rent
<sb:#jemxadr> I think I want an off-line disc with peter on the 64/128 issue END
<allan:#jemxadr> tables between calibration and science data.  
<allan:#jemxadr> We are not quite finished with the discussion here, and if you 
<allan:#jemxadr> start in GEneva, S
<allan:#jemxadr> AND
<allan:#jemxadr> (Sorry, I used the dansih OE in Soeren, which has caused some
<allan:#jemxadr> tranmission problems, I now realise. END
<sb:#jemxadr> Are you serious about letting the general user change the binning?
+? that is crazy END
<allan:#jemxadr> The point is, that since the option exists, it must be describe
+d in the uM,
<allan:#jemxadr> and thus people can request it. My advice to Ib and NL was, tha
+t 
<allan:#jemxadr> users should not even see the option, but it is claimed
<allan:#jemxadr> not to be possible to hide it from the users.  We are looking
<allan:#jemxadr> into that. END
#jemxadr> I would welcome the posssibility to work with two *unchangeable* binni
+ng tables, and one PI channel description provided by ISDC.... but I suspect th
+at might not be the way things will function. END
<allan:#jemxadr> The baseline is even, that the two tables are identical. END
<allan:#jemxadr> I have to leave for two other meetings - sorry to break out of
<allan:#jemxadr> this interesting issue - can we make an AI to resolve it and ge
+t it 
<allan:#jemxadr> described before 2 weeks? END
<Peter:#jemxadr> Sounds good to me. END
#jemxadr> I'll make and AI on me, SB, NL, Allan and Peter to resolve this matter
+ for sure within a couple of weeks. Is that okay? END
<Peter:#jemxadr> OK with me. END
#jemxadr> The binning issue covers all my personal questions about instrument mo
+del DS - what about everyone elses questions? END
<Peter:#jemxadr> A final one on Stefan's:
<Peter:#jemxadr> TRANSMISSION PARAMETERS - would we rather have a single table w
+ith one column energy and N others for the various materials,or multiple tables
+? END
<smaisala:#jemxadr> I have some problems about AUXL-TCOR-HIS and AUXL-ORBI-HIS d
+atastrures. Is there any definition about those? END
<smaisala:#jemxadr> sorry strures=structures END
<larsson:#jemxadr> To Peter: I cant see why not one. END
<njw:#jemxadr> To Peter: I think that individual tables may be easier to maintai
+n in the long run
<njw:#jemxadr> in particular if special absorption edges require a local dense e
+nergy grid END
<Peter:#jemxadr> To Sami: have you looked at the ISDC data structures web site?
<Peter:#jemxadr> http://isdc.unige.ch/doc/tec/add/add-w/data/data2html.cgi?add-w
++AUXL
<smaisala:#jemxadr> To Peter: Yes The names are there, but pages are empty. END
<Peter:#jemxadr> To NJW: good point. END
<Peter:#jemxadr> To Sami: not for me ... we'll clear this up offline. END
<smaisala:#jemxadr> Ok
<Peter:#jemxadr> Sami: what's your phone number? END
#jemxadr> I think there's a problem with the CGI scripts used to transfer DALfil
+es to webpages....I've complained about this in the April monthly report END
<smaisala:#jemxadr> To Peter: +358 9 19122907
<Peter:#jemxadr> I don't think it's with the scripts per se, rather with some da
+tarights - but that's just an idea. END
<Peter:#jemxadr> I'll look into it. For me all descriptions appear nicely. END
<Peter:#jemxadr> Could some of you others try to look at the page I've just
<Peter:#jemxadr> pointed to? END
<larsson:#jemxadr> Its white from Stockholm toooo. END
<Peter:#jemxadr> OK, I'll kick up some dust around here ... END
<Peter:#jemxadr> What about DSRI? END
<njw:#jemxadr> Nothing on that particular page: ... data/data2html.cgi?add-w+AUX
+L END
#jemxadr> I spent a whole DAY printing out the new jemx Data Structures here...t
+he pages simply wouldn't print without being saved to file, one page at a time,
+ first! END
<Peter:#jemxadr> OK, OK, I'll take my nice smile and a big stick to our system p
+eople. END
<smaisala:#jemxadr> Sounds good to me :) END
#jemxadr> Thanks, Peter! Now back to the data structures. What about this thing 
+with the fake events....I agree with SB that it's not the best
#jemxadr> name in the world for them, but is there anything better, more descrip
+tive, and wasn't it the IT that came up with the name in the first place, and  
+if we decide to change it, will they use the new name? END
#jemxadr> Hello, is there anyone out there? END
<sb:#jemxadr> if it needs to be short GREY is a better word than FAKE END
<sb:#jemxadr> I assume the use of fake to be slang, used without considering dow
+nstream users END
#jemxadr> I prefer GREY too END
<larsson:#jemxadr> (Yhats GREYT!) END
<Peter:#jemxadr> Fine with me END
#jemxadr> Good - let's start indoctinating the IT now Soren END
<smaisala:#jemxadr> Ok END
<sb:#jemxadr> So who writes the official request for the change? END
<Peter:#jemxadr> You - you started it :-) END
#jemxadr> I agree ;-) END
<sb:#jemxadr> well I am not really SDAST, so cannot speak officially END
<larsson:#jemxadr> You write we speak. END
<Peter:#jemxadr> You can always pass it via Allan ... END
#jemxadr> I can show you the SCREW system, if you like. Or you could ask Tim Loc
+k while you're at ISDC END
<Peter:#jemxadr> Yes, just do it today. END
<sb:#jemxadr> sounds sort of interesting. I will ask END
#jemxadr> Next on the agenda: finding a chat time to discuss the DAL3JEMX routin
+es newly provided by Stephane. When can you all be available in the first half 
+of next week? I want everyone to have time to look
#jemxadr> at these before we start nitpicking. END
<Peter:#jemxadr> How about Wednesday morning? END
<smaisala:#jemxadr> Wednesday is fine END
<larsson:#jemxadr> No not Wedn. for me . END
#jemxadr> I can't do Wednesday moring, that's when allan wants the observational
+ analysis meeting. END
<Peter:#jemxadr> Tuesday: mornig or afternoon? END
#jemxadr> I can't do Thursday morning either.END
<Peter:#jemxadr> How about the afternoon? END
#jemxadr> Tuesday morning looks good for me. END
<larsson:#jemxadr> Tuesday morning is ok with me. END
#jemxadr> Tuesday afternoon is okay too. END
<njw:#jemxadr> Tuesday morning is OK for me END
<larsson:#jemxadr> Afternoon: OK except for 15.00-15.45 END
#jemxadr> What about tuesday 13.00 danish universal time? END
#jemxadr> Or Tuesday 9.00 DUT? END
<Peter:#jemxadr> Both would work for me. END
<larsson:#jemxadr> Tu 13.00 DKUT is OK. (or 9.00) END
<njw:#jemxadr> DUT = Danish Universal Time ?? END
#jemxadr> What about everyone else: Peter, Sami, Soren? END
<Peter:#jemxadr> As I said: Both would work for me. END
<smaisala:#jemxadr> Both times are ok . So which one ??
<larsson:#jemxadr> Lets go for 13.00 if both are OK. END
#jemxadr> Let's go with 9.30 DUT, I thinks that's 10.30 Stockholm time. See you 
+all there. END
<njw:#jemxadr> OK with Tuesday 13.00 END
<larsson:#jemxadr> CA : Depends on your definition of DUT?
<Peter:#jemxadr> So what was the final agreement 9:30 or 13:00 ???? END
#jemxadr> OK so Tuesday 13.00 it is Copenhagen time. 14.00 stockholm time. END
#jemxadr> Final time is 13.00 Danish time, I think. END
#jemxadr> I've just typed it into my calender so it can't be changed now.END
<larsson:#jemxadr> OK (just 13.00 in Copenhag = 13.00 Stockholm) END
#jemxadr> The rest of the things on the agenda will have to wait till next week 
+-
<njw:#jemxadr> I'll login Tuesday 13.00 Danish time END
#jemxadr> it was a pretty packed agenda. END
#jemxadr> So, Any Other Business anyone? END
<smaisala:#jemxadr> Is that all folks ??
<Peter:#jemxadr> Nothing urgent, I guess. END
#jemxadr> Have a good weekend, and be sure to read Stephane's pages on DAL3jemx 
+before we meet again. END
<Peter:#jemxadr> So, 'see' you on Tuesday. Please don't hesitate to send me some
+ questions before. END
<njw:#jemxadr> Nice Weekend including this afternoon - bye END
<larsson:#jemxadr> Have a nice weekend all of you. END
<smaisala:#jemxadr> Have nice weekend! Bye !! :-) END
#jemxadr> I'm afraid I'll be far too busy coding to get round to it before Tuesd
+ay morning END
*** Signoff: njw ()
*** Signoff: smaisala ()
#jemxadr> Goodbye y'all END
*** Signoff: larsson ()
*** Error: Closing Link: oxborrow[~oxborrow@130.226.216.181] () 
*** IRC session log ended at Fri May  7 11:48:23 1999.
