NO UNIX Tail and Perl type question

Lou Picciano loupicciano at
Sun Dec 18 12:45:37 EST 2011


Can you control/modify/log output from the Cloverleaf daemons: hcistatus, hcialert and lockmgr?? I'm guessing you'll get lots of useful info from them. 

Sounds like the Cloverleaf 'Gods' may not know their minions very well... Again, it's (one) of the great beauties of UNIX; that everything can be chained together. 

Lou Picciano 

----- Original Message -----
From: "Stephen Miller" <stephenmiller1958 at> 
To: "OmnisDev List - English" <omnisdev-en at> 
Sent: Sunday, December 18, 2011 1:00:54 AM 
Subject: Re: NO UNIX Tail and Perl type question 

Hi Cliff and Lou 

Ok this is the setup. Health Integration using TCP and HL7. The 
receiver Patient Administration System has a server module listening 
for messages. The message is patient data. A message broker 
(Cloverleaf) passes on a channel of messages to the Server Module. 
Cloverleaf expects the server to respond with an ACK or NACK basically 
Ok, processed with errors, Cant process this message therefore stop 
all messages for this patient or Server is having a problem - stop 
sending all messages. 

Well in this case the server has some built in processing errors and 
is not responding at all in certain circumstances. In this situation 
Cloverleaf gets a Communication error. On this basis it will stop for 
a pre-determined time and then attempt to send the message that blew 
up the server again - again the server blows up (in the interim it was 
restarted by a script that runs on a timer and if cant find the server 
running it restarts it). 

The Cloverleaf GODS here say - there is nothing we can do - well as 
always I take this as a challenge. 

The Server writes to a log file as it processes the message and as it 
checks the validity of each segment of the message. The same file is 
used per day regardless of how many times it is restarted. 

Ok so I can determine that the Server has failed and on what record 
and what segment of the record. As there are a finite number of 
segment types and the server writes before it checks the data, and 
sometimes crashes, I can pattern match on the file. For example: 

A successful message ends, together with the start of the next process write: 

MSA Segment successfully sent 

Data received at: 

A fail will read: 

Validating segment: PID 


(In a successful message the log would read: 

PID segment loaded 
Validating segment: PID 
PID segment validated) 

So if I can read using the tail I can tell that the message has 
crashed the server leading to the communication error. 

Once I cant get this on a different process, such as Perl or whatever 
then Cloverleaf can be re-programmed to 


Contact Perl (Perl does the tail and returns the data) 
If what it returns contains : 

Validating segment: PID 

If Perl doesnt return anything - and in facts gives a comm error 
itself - then Cloverleaf will know there is something seriously wrong. 
If the Message that Cloverleaf gets back is is good then it knows the 
Comms error glitch is not relevant. If however if it gets the unique 
:"Validating segment: PIDchr(13)Chr(13)" then it knows this patients 
record has to be quarantined. 

Then Cloverleaf can act according and quarantine messages for this 
patient but can continue to deliver for other Patients. 

So so much for the Unix-Cloverleaf guru's saying that it is impossible 


Stephen Miller 

On 12/17/11, CLIFFORD ILKAY <clifford_ilkay at> wrote: 
> On 12/16/2011 09:18 PM, Stephen Miller wrote: 
>> Greetings heew is an interesting problem. 
>> In my rapid learning curve on UNIX I am aware that we can have a live 
>> log file that can be read locally by other applications using the tail 
>> command. In this case I am only interested in the last few lines of 
>> the current log file. In this instance I am looking for a certain 
>> string. This string indicates that the process has failed and is in an 
>> unstable state. 
> [snip] 
> Hi Stephen, 
> Can you provide more information about this process? What does it do? 
> Other than writing "Good bye, cruel world!" to the log file and then 
> flopping over and dying, how else can you tell that the process in 
> question is contemplating hara kiri? What causes the process to fail? 
> Parsing log files and notifying you after-the-fact is certainly possible 
> and not that difficult but it might be feasible to be notified earlier 
> of developing problems. You can think of it as a long-range weather 
> forecast, "There is a 90% probability of precipitation tomorrow.", vs. 
> the weatherman telling me something I could tell just looking out the 
> window, "It's raining outside." 
> -- 
> Regards, 
> Clifford Ilkay 
> Dinamis 
> 1419-3266 Yonge St. 
> Toronto, ON 
> Canada M4N 3P6 
> <> 
> +1 416-410-3326 
> _____________________________________________________________ 
> Manage your list subscriptions at 

*Kind Regards 

Stephen Miller 

+61 (0)415 968048 

Skype: Stephen.Miller.1958 

Work Phone: 08 6213 5697 * 

*Work E-mail: Stephen.Miller at; * 
Manage your list subscriptions at 

More information about the omnisdev-en mailing list