	DAL3JEMX #1: Tuesday 11th May 1999
	
Participants: Peter Kretschmar, Niel Joergen Westergaard, Carol Anne Oxborrow,
	Sami Maisala, Allan Hornstrup (listening)

Subject: New functions for the DAL#JEMX library

Action Items: None


*** IRC session log started at Tue May 11 13:03:26 1999.
#jemxadr> Hello Sami! END
H smaisala     #jemxadr 0 *real name unknown*   ~smaisala@us.astro.helsinki.fi
H oxborrow     #jemxadr 0 Carol Anne Oxborrow          ~oxborrow@tenma.dsri.dk
H njw          #jemxadr 0 Niels Joergen Westergaard       ~njw@130.226.216.177
H Peter@       #jemxadr 0 KRETSCHMAR Peter         ~pkretsch@isdcul10.unige.ch
315 apollo.dsri.dk * End of /WHO list.      
<smaisala:#jemxadr> Hi there ! END
#jemxadr> Hi Peter and NJW! END
#jemxadr> Are you all ready to chat? END
<njw:#jemxadr> Yes - start shooting END
#jemxadr> Allan will be with us soon. What about Juhani, is he coming Sami? END
<smaisala:#jemxadr> No Juhani is so busy that he is not with us. END
#jemxadr> Peter, do you want to make some general comments on behalf of Stephane and I
+SDC? END
<Peter:#jemxadr> There's nothing that immediately comes to mind.
<Peter:#jemxadr> Well, maybe just that if you are wondering why you should use a funct
+ion
<Peter:#jemxadr> then you probably simply don't need it. END
#jemxadr> We'll wait a couple of minutes longer for Stefan-from-Stockholm. END
<Peter:#jemxadr> Stephane's work is driven by various inputs plus his own ideas
<Peter:#jemxadr> and the main reason he's waiting for comments is that he'd like some
<Peter:#jemxadr> confirmation that the current ideas aren't too far off from SDAST's w
+ishes. END
<Peter:#jemxadr> Btw: Stephane has agreed to change "Fake" to "Grey" with Soren.
<Peter:#jemxadr> If you'd prefer another name, please let me know here and now. END
#jemxadr> What I've seen seems pretty  good - I'm too stupid to understand all of it j
+ust by reading a description, so I've written a list of questions to him, that I'll c
+irculate this afternoon, but otherwise, I think most of the functions do things
#jemxadr> that would be quite tricky for us to do singlehanded: for example read all t
+he packet data in a Science window. I'm still not sure I know why you'd want to do th
+is, but I'm glad someone else will have to go off and find all the packets 
#jemxadr> instead of me! Also, selecting events around the GTI's seems an nice thing t
+o do in just one function. Comments? END
<Peter:#jemxadr> Everybody too embarassed to speak??? END
*** allan <~allan@130.226.216.175> joined channel #jemxadr
H allan        #jemxadr 0 Allan Hornstrup               ~allan@130.226.216.175
H smaisala     #jemxadr 0 *real name unknown*   ~smaisala@us.astro.helsinki.fi
H oxborrow     #jemxadr 0 Carol Anne Oxborrow          ~oxborrow@tenma.dsri.dk
H njw          #jemxadr 0 Niels Joergen Westergaard       ~njw@130.226.216.177
H Peter@       #jemxadr 0 KRETSCHMAR Peter         ~pkretsch@isdcul10.unige.ch
315 apollo.dsri.dk * End of /WHO list.      
#jemxadr> I'm just phoning Stefan, to see if he wants to join in. END
<njw:#jemxadr> I have a question: All the functions need as input a pointer to a DAL d
+ata structure.
<njw:#jemxadr> Do we need to get that pointer fromm the ISSW directly or will there be
<njw:#jemxadr> a DAL3 function to help there as well ?? END
#jemxadr> I can't get through to Stefan, so we'll assume he won't be joining in. so le
+t's get specific: Comments on the List of data type definintions? END
<Peter:#jemxadr> Wait a second please
<Peter:#jemxadr> To NJW's question:
#jemxadr> Try using CommonPreparePARsStrings, NJW, that'll make a point to a complete 
+science window group for you. END
<njw:#jemxadr> Good, thanks END
<Peter:#jemxadr> The pointer can be the pointer to a Science Window Group, or any othe
+r sensible DAL element
<Peter:#jemxadr> In principle it can be a pointer to the data themselves though
<Peter:#jemxadr> for some functions this could be tricky.
<Peter:#jemxadr> You get the pointer either by using appropriate DAL functions
<Peter:#jemxadr> or by relying on Bruce's nice work and using CommonPreparePARs(String
+s) [both are functionally equal]. END
<njw:#jemxadr> Good, thanks END
<njw:#jemxadr> Good, thanks END
<njw:#jemxadr> The repetition was unintentional END
#jemxadr> If you need a sample routine using the new common routine, my delivered code
+ will be available on the forum from about Friday (God willing!)END
<Peter:#jemxadr> Another example is jcreatespecmode, which you should find from the SD
+AST developper's forum too. END
#jemxadr> Peter's delivered code is already there, so check out Bruce's super function
+. Now on to the JEMX data definitions for DAL3. I have a couple of comments (of cours
+e), what about you guys? END
#jemxadr> What I want to know is what is NOT_JEMX supposed to be used for? Who would m
+ake a call with this event type? END
<Peter:#jemxadr> I 
#jemxadr> Also, the enumerated types are not complete since there will now be *two* sp
+ectral formats. 
#jemxadr> This is official: we got an email from Gregorz on monday, that will be circu
+lated officially once everyone here at DSRI
<Peter:#jemxadr> My guess is that NOT_JEMX is rather a return ('error') code
#jemxadr> has had a chance to approve all the formats. This is the first step in
#jemxadr> the IT officially approving a `final' set of telemetry packages. END
<Peter:#jemxadr> For cases where something got mixed up (SPI and IBIS events might hav
+e the same column names. But I haven't really thought about it.
<Peter:#jemxadr> Regarding the spectrum formats - well we'll just update the types. EN
+D
#jemxadr> Thanks, Peter, but I don't see anywhere where this type of variable is retur
+ned from a function. END
<Peter:#jemxadr> Oops you're right - I somehow remember it beingreturned somewhere - c
+ould have been in a prototype of DAL3JEMX
<Peter:#jemxadr> I'll ask Stephane what he wanted with this one. END
#jemxadr> I had thought maybe it stood in for other data types in JEMX: grey filter, o
+r mode or something. END
<Peter:#jemxadr> To my best knowledge no.
#jemxadr> I hope adding *two* new event types won't be too much trouble: I really do t
+hink the IT has started to stabilize the telemetry formats: leastway they don't seem 
+to be changing as fast as they were! END
<Peter:#jemxadr> The update will happen, once we have the doucmentation formally. END
#jemxadr> Next function showAllEvents: any comments? END
<Peter:#jemxadr> Wait a minute: SPECTRUM_1 and _2 aren't _event_ types anyway ... END
<Peter:#jemxadr> So what's lacking (and Stephane is probably aware of this) are DAL3ge
+tSpectra functions.
<Peter:#jemxadr> If I remember correctly he wanted to wait for the IT to sort themselv
+es out first END
#jemxadr> So they're handled in a completely separate way, that doesn't involve having
+ their own JEMX_type? So we need spectral functions then? END
<Peter:#jemxadr> We still probably should have a similar enum type END
#jemxadr> It's probably a good idea till we publish the formats officially......END
#jemxadr> It's a good idea to wait, I mean. END
<Peter:#jemxadr> Got that one. Now back to showAllEvents ... END
#jemxadr> I think there's a couple of typo's in this description, though the funciton 
+itself seems fine.
<Peter:#jemxadr> What exactly do you mean? END
#jemxadr> Should there be a `*' before jmx_numi[4]? These are outputs right and requir
+e a pointer? Any other comments? END
<Peter:#jemxadr> isnt jmx_num[4] a pointer by this definition? (I'm just learning C)?
<Peter:#jemxadr> END
<njw:#jemxadr> To CAO: they are vectors and therefore also pointers END
#jemxadr> But if they are used as per the description i.e. jemx1_num[REST], that is a 
+single number, not a pointer to a number or to an array. Anyway, we're all agreed it 
+should be a pointer, and that's what
#jemxadr> s most important. END
<njw:#jemxadr> Four number are returned ? END
#jemxadr> Wait a moment - I think I see what he's saying now - all four numbers are pa
+ssed back in the array and then you look at each one individually. I was all mixed up
<Peter:#jemxadr> Exactly - that's the whole point. END
#jemxadr> I thought it only passed back one number at a time. Sorry. END
<Peter:#jemxadr> Don't worry - I had to ask Stephane the first time I saw this :-) END
#jemxadr> Of course, that's the way it should be done - I htought it was a bit odd jus
+t asking for one sort of event at a time! END
#jemxadr> Next function: DAL3JEMXselectEvents. Any comments? I've got a couple. END
<Peter:#jemxadr> Shoot, seems everybody else was lazier (and I clarified my questions 
+with the horse's mouth ...) END
#jemxadr> Now as I understand this one: it's all inputs. We specify the data object (s
+cience window group) event types, etc, and also the times 
#jemxadr> during which we have GTI's, but nothing comes back except the status integer
+ that's returned. Is this right? END
<Peter:#jemxadr> Yes. The whole data is stored in a temporary structure that you don't
+ need to worry about.
<Peter:#jemxadr> This temporary memory is then accessed by the get*Events functions. E
+ND
#jemxadr> So we never seen the selected events pointer or structure. Then all the mani
+pulation with getNumEvents, getEvents etc. occurs
#jemxadr> implicitly using this hidden data structure. So only one lot of selected eve
+nts can be opened at a time? END
<Peter:#jemxadr> Yes. END
<njw:#jemxadr> So selectEvents must be called in any case, even if no selection is req
+uired ? END
#jemxadr> Okay, having got that straight I'd like to move on to getNumEvents and getEv
+ents. Any comments from anyone else? I don't want to hog the limelight. END
<Peter:#jemxadr> Exactly. That's just what's happening in my example executable. END
#jemxadr> So all events can be used by using "DAL3_NO_OBT"? END
<Peter:#jemxadr> I use 0,NULL,NULL 
#jemxadr> Thanks for the tipEND
<Peter:#jemxadr> Remember you pass on _lists_ of times, so the first parameter is the 
+number of times and the others are vectors<->pointers END
#jemxadr> My next question is probably also dumber than you'd think possible, but here
+ it is: we can get the number of selected events using getNumEvents. And then we pres
+umbaly use the number passed back to calculate the transfer buffer size 
<Peter:#jemxadr> Yes. END
#jemxadr> for getting the events themselves. However, getEvents appears to pass BACK t
+he number of values as an output, rather than take it in as an input. What's going on
+ here? END
#jemxadr> Surely getEvent's numValues should have the same value as getNumEvents' num_
+events? END
<Peter:#jemxadr> In principle yes - just a second, while I ask SP ...
<Peter:#jemxadr> (He's back now) 
<njw:#jemxadr> Isn't this a case of 'no harm done' getting the same value twice ? END
<Peter:#jemxadr> It was made because it's similar to the way the lower level DAL funct
+ions work. END
#jemxadr> What if the two values are different? Exit with a nice message? END
<Peter:#jemxadr> That's what I've coded. But Stephane says this should never happen, e
+xcept if DAL has a bug. END
#jemxadr> I can imagine a situation where the numbers would be different where the num
+ber of values for a particular data type are smaller than the number of events due to
+ a change in mode. 
<Peter:#jemxadr> The point is that getEvents always returns _all_ events.
<Peter:#jemxadr> So there is no place for an input parameter here.
<Peter:#jemxadr> It could either be dropped, or left as it is - so it can be used as Y
+ASG (Yet Another SafeGuard). END
#jemxadr> Say you start off in full imaging and switch into timing mode there will be 
+fewer energy values than events. What happens here? END
<njw:#jemxadr> To CAO: that is done in selectEvents END
<Peter:#jemxadr> But here we might have a problem for some tools - you can only access
+ one type of data at once. END
#jemxadr> To NJW: What is done in selectEvents, padding? END
<njw:#jemxadr> In selectEvents you have to specify the event type END
#jemxadr> So it's still going to be fairly cumbersome to process science windows with 
+mixed modes? END
<njw:#jemxadr> Maybe that's where we should ask for more DAL3 functions END
<Peter:#jemxadr> Yes. But there is only a limited remedy for that with any kind of gen
+eric functions. END
<Peter:#jemxadr> (The yes as to CAO) END
<Peter:#jemxadr> To NJW: Maybe yes, or we should try to detail, _how_ precisely we wou
+ld need access across TM modes. END
#jemxadr> I agree wtih NJW: if we're going to have DAL3 functions specific to JEMX the
+n this is one of the areas where they could be REALLY helpful. END
<Peter:#jemxadr> Fine in principle. Again ISDC will need some detailed examples of wha
+t could be useful, before SP sets out to work on this. END
<njw:#jemxadr> Another example: what happens in a timing analysis with changing grey f
+ilter values ? END
<Peter:#jemxadr> What should happen? The binning part of the SW must take into account
+ the grey filter values
<Peter:#jemxadr> I would not place this into a DAL3 function. END
<Peter:#jemxadr> We defintely should not "invent" events somewhere ... END
<njw:#jemxadr> Alright, that was a bad example (I rather thought of removing events) E
+ND
#jemxadr> Soren also has a question about selectEvents: can you only choose one sort o
+f data column at a time?
<Peter:#jemxadr> No. You get several columns at once. Again in my executable (please d
+o have a look) I get access to several columns by telling getEvents to give me PRP. E
+ND
#jemxadr> For example if you want to get out RAWX, RAWY and PHA for full imaging event
+s, does he have to call selectEvents 3 times with colSel set to one of those three di
+fferent things each time? END
<njw:#jemxadr> The parameter rowFilter may contain references to several columns (?) E
+ND
<Peter:#jemxadr> To NJW: as far as I understand: yes
#jemxadr> Soren would like to know if the subsets of parameter columns given by the
#jemxadr> enumerated type EVTS_colsel can be altered by request?
<Peter:#jemxadr> To CAO+SB: If you look at the description of COLSE you see that
<Peter:#jemxadr> you several columns with one setting.
#jemxadr> So that we could define subsets of parameter columns that best suit our need
+s. END
#jemxadr> Yes, Peter, we've just re-read that bit! END
<Peter:#jemxadr> And yes, I don't see why this selction could not be changed. That's t
+he whole idea of having feedback. END
#jemxadr> Soren thinks that with a little more experience we might come across certain
+ particularly useful subsets END
<Peter:#jemxadr> I'm sure there is no major problem. 
<Peter:#jemxadr> But if we change this several times over, we might have compatibility
+ problems with existing software. We must look out for that. END
#jemxadr> That's great! END
#jemxadr> Flexibility: great! compatibility problems: let's look out for that. END
#jemxadr> Next, getEventsBins. Any comments from other people? END
#jemxadr> As I understand this, getEventsBins is just like getEvents, but with an addi
+tional filter criterion given by start and stop line numbers. Is this right? END
<Peter:#jemxadr> Yes. 
<Peter:#jemxadr> This just mirrors the DAL[get|put]Col[Bins] functions, which give you
+ the same choice. END
#jemxadr> So we'll determine our start and stop rows by calling to getPackets, or some
+thing like that? END
<Peter:#jemxadr> Whatever. AFAIK, one is just a wrapper around the other so Stephane f
+ound it easy
<Peter:#jemxadr> to give us the choice between getting _all_ of a column or a specific
+ subset, if required. END
<Peter:#jemxadr> Again you are not required to use one or the other. END
#jemxadr> So the row numbers provided by getPackets, for example, are the same as thos
+e used in the selected events data structure that we never get to see? END
<Peter:#jemxadr> Good question ...
<Peter:#jemxadr> No can't be, because the evnets are already selected. END
<Peter:#jemxadr> I'm not sure anybody will actually use this feature, but I'm also sur
+e it wasn't serious work for Stephane. END
<Peter:#jemxadr> How about just letting it exist and worry about possible uses later. 
+END
<Peter:#jemxadr> One (wild) example: if you had a _really_ large set of events you mig
+ht want to get a firm subset (e.g. 10000) at a time. END
#jemxadr> What I'm really asking, is that the SSC and packet row number of an event ar
+e unique identifiers of the even that follow it through its DAL lifetime. So that eve
+n if events are selected and some thrown away due to bad GTI's etc. they don't 
#jemxadr> get renumbered? END
<Peter:#jemxadr> Do you really need that? The startBin and endBin values are really ju
+st pointing to rows in a table. 
<Peter:#jemxadr> And this table is filled without empty rows. 
<Peter:#jemxadr> So your request would make for a _very_ different design which possib
+ly would also waste some of the time/memory savings. END
#jemxadr> So it's not a way of selecting particular events, rather of selecting certai
+n sized chunks of data? END
<Peter:#jemxadr> Yes. As I;ve said, there may not be much use for us, but it mirrors a
+ common DAL functionality:
<Peter:#jemxadr> Getting either a whole column, or a well defined chunk of it (helps w
+ith memory allocation at least). END
<Peter:#jemxadr> Coming from FORTRAN I've been tempted to use it. END
#jemxadr> Thanks for clearing that up: I'd imagined something quite different! So if y
+ou've got 100,000 events in your selected file and a buffer that only holds 20,000 at
+ a time, you call getEventsBins 5 times first 0to 19,999 then 20,000 to29,999 e
#jemxadr> etc. END
<Peter:#jemxadr> Yeah, that would be a possible use. END
#jemxadr> Next: closeEvents. This has to be used before selecting more events presumab
+ly. For example if I needed to access different modes in the same science window, I n
+eed to call selectEvents twice, once for each mode. END
<Peter:#jemxadr> It's also a way to get just one at once (not too efficient if you hav
+e 200,000 but still ... END
<Peter:#jemxadr> Sorry the comment was still with ...Bins END
#jemxadr> I understand... END
<Peter:#jemxadr> closeEvents: yes, that's my understanding. END
#jemxadr> If there are no more comments from anyone else I'll just plug on with the re
+st of teh functions: why can't the packet functions deal with eanything except SWG's?
+ END
<Peter:#jemxadr> Because the data only makes sense at that level. END
#jemxadr> Is that the same answer for the grey events functions? END
<Peter:#jemxadr> Good question
<Peter:#jemxadr> The answer is probably yes. Note that you should access grey filter s
+ettings with a DAL3HK function
<Peter:#jemxadr> (Or a new DAL3JEMX function if SB gets his way) END
#jemxadr> Apparently Soren and Stephane have agreed to use the word `grey'
#jemxadr> instead of `fake' so presumably all these function names will also change? E
+ND
<Peter:#jemxadr> Yes. END
<Peter:#jemxadr> Except if you fight against that :-) END
#jemxadr> Don't even suggest it _ i've got enough to do at the moment! END
#jemxadr> Finally: findEventGaps. There's some kind of inconsistency in the descriptio
+n of this one:
#jemxadr> At the start of the description function claims to find "the possible gaps
#jemxadr>  in the telemetry or *between science windows......."
<Peter:#jemxadr> Probably "between pointings" would be clearer. END
#jemxadr> but on the next page explicitly states: "Packets lost at the beginning or en
+d of a science window are not counted". Aren't these contradictory statements? END
#jemxadr> You mean that anything that drops out during a slew is forgotten about since
+ it wasn't useable science data
#jemxadr> while missing packets at either end of a science window during a pointing ar
+e counted as missing? END
<Peter:#jemxadr> LEt me try to clarify (I'm just talkin with SP):
<Peter:#jemxadr> NUM_MISS_PACK counts the number of missing packets within a ScW.
<Peter:#jemxadr> There is simply no way to tell how many might have been dropped befor
+e the first one or after the last one we have received.
<Peter:#jemxadr> If you have multiple ScWs, NUM_MISS_PACK is summed over all of them.
<Peter:#jemxadr> Stephane wrote this function mainly as a help to define a GTI based o
+n continous telemetry (so probably for Reiner Rohlfs). END
#jemxadr> So we can forget this maybe, and just stick with GRI's? END
<Peter:#jemxadr> During slews JEM-X does collect science data, as far as ISDC knows. 
#jemxadr> sorry, GTI's. I've no idea what GRI's are. END
#jemxadr> But we ruthlessly ignore the slewing data? END
<Peter:#jemxadr> Any packets sent but logically belonging to previous pointings are co
+unted as belonging to the pointings. END
<Peter:#jemxadr> To CAO: yes, and yes IMHO. END
#jemxadr> So a science window begins when you receive the frist packet, though previou
+s ones may have been lost unknown to us? END
<Peter:#jemxadr> Correction: ISSW running _before_ OSM may need this function, if it r
+equires continous input data. END
<Peter:#jemxadr> To CAO's last question: Yes, exactly. END
<Peter:#jemxadr> Actually you should probably have a critical look at my design and se
+e if I should not use this function for jcreatespecmode. END
#jemxadr> What about long(ish) intervals where the high voltage is switched off and th
+e detector
<Peter:#jemxadr> That's no science data, is it? END
#jemxadr> isn't sending any events: it this considered a break in the telemetry too? (
+Soren's question, not mine ;-) ) END
<Peter:#jemxadr> Depends, only if this happens within a pointing where it starts to se
+nd some science data and then is switched off. END
#jemxadr> That seems fair enough. I'll tell soren. END
<Peter:#jemxadr> The instrument must be in a _science TM_ mode, to have any data showi
+ng up in the input data we're looking at. END
#jemxadr> That's all my questions - thank you for being so patient. I hope we've manag
+ed to clear up any misunderstanding anyone else had.
#jemxadr> Have the rest ofyou really no questions? END
<Peter:#jemxadr> If not, you're not using DAL3JEMX yet, I guess.
#jemxadr> That's basically the thing: we're not using it, and reading the descriptions
+ just doesn't give you a feel for how it works.
<Peter:#jemxadr> Seriously, I would recommend to everyone to start writing prototype s
+oftware that uses the ISDC libraries with all bells & whistles.
<Peter:#jemxadr> That's the only way we'll get questions sorted out and missing featur
+es included soon. END
#jemxadr> But that said, I think we can approve Stephane's functions and we'll start u
+sing them as soon as I can install the library here. END
#jemxadr> Personally, there's nothing here for me to use at the moment, I'm only using
+ calibration spectra and a binning table. END
<Peter:#jemxadr> Fine. But remember he'll update (hopefully) soon with FAKE->GREY etc.
+ END
<Peter:#jemxadr> That's the unfairness of the world - your S/W is too specific to make
+ DAL3 functions worthwhile. END
#jemxadr> I know 2 hours is quite a long chat - but I hope we'll avoid lots of stupid 
+questions turning up at the help desk now! END
<njw:#jemxadr> In order to use the DAL3 routines we need some TM data to work on. How 
+do we get that ? END
<Peter:#jemxadr> I found it well invested time. END
#jemxadr> The SWG thing works just fine for me. I don't need anything else. END
<Peter:#jemxadr> To NJW: We don't have that either - ask the IT to produce some TM :-)
+ 
#jemxadr> Good question NJW! Send us some fake data, Peter. END
<Peter:#jemxadr> More seriously though, Stephane has cocked up a tiny bit of fake JEM-
+X data
<Peter:#jemxadr> that I've been using for my tests. I can pack it all into a .tar file
+ and give it to CAO. But it's _very_ limited.
<Peter:#jemxadr> This is the problem with not having a test engineer at the moment. EN
+D
<njw:#jemxadr> And do we need a full data repository here at DSRI in order to use it ?
+ END
<Peter:#jemxadr> No. I just have some local files. END
#jemxadr> Don't worry about limitedness - I'm currently working with *one* binning fil
+e and  *one* spectral file - there's hardly anything to make an SWG with! END
<Peter:#jemxadr> The grouping convention does not require any specific layout. END
<njw:#jemxadr> So your test data has the correct grouping structure END
<Peter:#jemxadr> I'll try to send you some today or tomorrow morning. Before lunch I w
+as debugging some code to create OMC fake data and I'd like to get bakc to that. 
<Peter:#jemxadr> END
#jemxadr> I'll put the ISDC files you send on /t at DSRI, and we can set up our own li
+ttle repository - just to check out the SWG functionality. END
<Peter:#jemxadr> To NJW: It has a FITS file with the group table and some more files t
+o which it points. END
<Peter:#jemxadr> Maybe all the data (unexplained) is already in the tar I sent
<Peter:#jemxadr> to CAO END
#jemxadr> I'd like to get back to JGainFitting. Thanks for a productive chat. Happy OM
+C'ing, Peter. END
<Peter:#jemxadr> Thanks, they can use some attention - I've delayed that delivery in o
+rder to finish jcreatespecmode. END
#jemxadr> When shall we three meet again? Friday morning as usual? END
<Peter:#jemxadr> I won't be in. I'll work on Thursday and take Friday off - my brother
+s are coming for a visit. END
#jemxadr> It's a partial holiday here too, so perhaps we should wait till next Friday.
+ END
#jemxadr> Have a good weekend everyone. Goodbye. END
<njw:#jemxadr> Nice weeend all of you who are still there END
*** Signoff: njw ()
<Peter:#jemxadr> OK. See you in 10 days or so. END
<smaisala:#jemxadr> Goodbye 
*** Signoff: Peter (Leaving)
*** Signoff: smaisala ()
H allan        #jemxadr 0 Allan Hornstrup               ~allan@130.226.216.175
H oxborrow     #jemxadr 0 Carol Anne Oxborrow          ~oxborrow@tenma.dsri.dk
315 apollo.dsri.dk * End of /WHO list.      
*** Error: Closing Link: oxborrow[~oxborrow@tenma.dsri.dk] () 
*** IRC session log ended at Tue May 11 15:25:33 1999.
