Issue with UUDECODE with large size OBX-5

This topic has 8 replies, 5 voices, and was last updated 11 years, 3 months ago by Robert Milfajt.

Creator

Topic
September 12, 2013 at 1:34 pm #53815
Chris Adams
Participant
Hey Clovertechers!

We are having an issue with getting over MUSE waveforms through Cloverleaf WHEN they hit a certain size. In our test environment (which produces OBX-5 data that is about 90k large) our TCL code works fine, the waveform comes in, we UUDECODE it then BASE64 encode it to send over to our Webblob.

However our PROD MUSE produces waveform data that hits between 180k-200k and we are failing to get these through the TCL. Debugging this the issue is the UUDECODE- data is fine right before the UUDECODE line but we end up with null data once the UUDECODE is run.

I know the data itself is valid since I can take it and run it through a similar TCL proc locally using Komodo but for whatever reason we can’t get the same code to work on Cloverleaf.

Does anyone have any ideas? Maybe a max string size we are running into? Thanks!
Creator

Topic

Viewing 7 reply threads

Author

Replies
- September 13, 2013 at 8:17 pm #79032
  Russ Ross
  Participant
  I first wondered like you about a size limit when I read this.
  
  I really don’t know if that is the issue, so how about doing some testing to see if that might be the problem.
  
  Try starting with a very small string size, and if that works, keep increasng the size until it breaks again.
  
  Russ Ross
  RussRoss318@gmail.com
- September 13, 2013 at 9:02 pm #79033
  Jim Kosloskey
  Participant
  have you tried running the prod data in your Test environment?
  
  If it works there then it is something related to your environment.
  
  If it also fails there, have you tried using hcitcl and just encoding/decoding, etc. a large string?
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- September 17, 2013 at 5:45 pm #79034
  Chris Adams
  Participant
  Hey all,
  
  Thanks for the replies! I’m trying to come up with a decent way to test this- the trick I’m having currently is I can’t just mock up a string to a certain size, it would fail the uudecode.
  
  I’m going to try and mock up some uuencoded messages when I get some free time to mess around.
  
  My other thought on this would be to have our pre-xlate proc call to a specific UUENCODE execuable instead of using the uuencode.tcl functionality, but I’m still brainstorming this.
  
  Another thought actually would be trying to replace the uuencode.tcl with a more updated verison- just ideas I have floating in my head that I haven’t been able to test yet.
- September 26, 2013 at 4:44 pm #79035
  Bob Moriarty
  Participant
  5.8.4 on AIX 6.1
  
  We handle 200KB+ uuencoded Muse content without problem.
  
  A TPS Inbound Data proc extracts the uuencoded content from the ZPD segment, regsubs the “\X0D\\X0A\” strings to “n”, converts the HL7 escape sequences (that’s actually a little tricky) and then execs uudecode.
  
  I can send you the code if you’re interested.
- September 26, 2013 at 4:53 pm #79036
  Bob Moriarty
  Participant
  5.8.4 on AIX 6.1
  
  We handle 200KB+ uuencoded Muse content without problem.
  
  A TPS Inbound Data proc extracts the uuencoded content from the ZPD segment, regsubs the “\X0D\\X0A\” strings to “n”, converts the HL7 escape sequences (that’s actually a little tricky) and then execs uudecode.
  
  I can send you the code if you’re interested.
- September 26, 2013 at 11:58 pm #79037
  Robert Milfajt
  Participant
  We had to do the same thing with PaceArt PDFs to Epic. We tried to send directly to Epic Interconnect, but ended up routing through Cloverleaf to run the TCL to get rid of the same characters.
  
  Robert Milfajt
  Northwestern Medicine
  Chicago, IL
- September 27, 2013 at 2:55 pm #79038
  Chris Adams
  Participant
  Hey all!
  
  I’ll certainly take a look at any code you have available! Given where this is failing (on the UUDECODE line) I have a feeling it’s not an issue in the TCL at this point, since the UUDECODE pretty much has to be done with the UUENCODE:UUDECODE line, but examples are always good!
  
  It almost feels like we are hitting some environmental issue, but I have no idea where else to check at this point!
  
  Thanks!
- September 30, 2013 at 3:06 pm #79039
  Robert Milfajt
  Participant
  Chris, you have to take the source data and run it through this TCL prior to decoding. At least that was my experience with PaceArt. Here is the TCL proc we have hung in an Xlate for:
  
  Code: COPY 1(0).1(%g1).1(%g2).OBX.#5.[4] -> 1(0).1(%g1).1(%g2).OBX.#5(0).[4]
  
  Tcl fragment:
  
  Code: regsub -all — {\X0A\} $xlateInVals “” xlateOutVals
  
  Apparently PaceArt was putting this character in amidst the rest of the encoded PDF and just removing the X0A from within the encoded PDF was all we needed. We tested by taking a copy of the encoded data from message, running through as TCL script which pulled out this field, decoded it, and wrote it to an AIX file. We then FTPed the file to a workstation with PDF extenstion and opened it. It didn’t work with the X0A in it, but worked fine after we stripped it out.
  
  Hope this helps,
  
  Robert Milfajt
  Northwestern Medicine
  Chicago, IL
Author

Replies

Viewing 7 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.