Brain storm a solution to a Dos Problem created by an obsolete program.

I am currently seeking solutions to a problem that becomes a bigger problem with each passing day.
One of my clients has an old Aging DOS Point of Sale system using PC DOS 7.0, IBM  NDIS2 drivers
configured for NetBEUI  that connects to an O/S2 Warp 4 File Server.   The DOS clients in addition to
running the POS software runs a TSR called ICVerify V. 6.63.01.  The TSR is used to grab bhe amount
of the transaction from video memory, then get credit card authorization.  It does this  as client/server.
Hardware wise they have anything from a P100 with 8 meg ram to  1Ghz P3's with 64.  

The Problem:
The program does not have any option to turn off printing of the Credit Card number on the customer receipt and so it prints the entire number for all to see.  My understanding is a  Federal law (and probably state regulations  as well)  prohibits printing of this information  on the receipt. The  merchants with old systems are 'GrandFathered' until 2005  at which time  they need be in compliance with the law.

Short of finding a 'hacked' version from someone with access to the original source code to this program,
there is one thing that may work.  Normally the receipt is printed out a serial port to a 40 column serial printer at 9600 baud.  It is configured to print  2 receipts.  1  goes to the customer  and the other  to the merchant. The ICverify can be configured to just output to a file instead of a printer device.  This is a good thing.   The idea is  when this file (which has the same filename each time it is created) is present we modify the first part of the file  by using something like  SED  for DOS and remove all but the last 4 digits  of the CC#.  We then print the other part verbatum which is the merchant copy and requires the number be intact.  The file actually has 2  clean ASCII representations of both  receipts The format is pretty much the same and the credit card number line never really changes  its location on the  receipt.  Once printed, the file is either moved to an archive or deleted.

My first idea  in order to keep things  as simple as possible would be to find a 'hot-key' TSR program
compatable with the CC TSR.  The Hot key would be labled something like Print.   This activates the TSR,
which runs  our batch file which envokes SED or something else, then  sends the file to the printer via
COM1 or COM2 etc/  Since the  size is relatively small, it would not take much time to process the file and
print it.

Other ways are  to intercept the file before it goes out the comport and replace the credit card number
'on the fly'  but this is more complex and  would render the machine unstable if not done right.

There may be other ways of dealing with this problem other than telling my client to buy  a lot of black
Magic Markers  to blank out the CC #.  I'm really hitting a dead end on finding a TSR to do this and I 've yet to prove the concept is workable . Or I could be open to other ideas, provided they try to follow the KISS formula.

Who is Participating?
PAQed, with points refunded (500)

Community Support Moderator
If the printing program is using bios interrupt to print via COM port, the logical solution is to create small TSR to take over bios interrupt and modify data when printed.
_RonC_Author Commented:
Yes, I agree that intercepting the data in this manner would be
the better way, but that may be easier said than done.

There has to be some TSR that will at least support a HOT-kEY and  give execution control to a program of my choice.  Maybe I could get it working on a fundamental  level before attempting to do the harder stuff.
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

I agree with you. I always created needed tools instead of looking for them. So, my knowledge of funcy utilities is rather weak. Maybe some other expert knows about some proper utility.
Intercepting serial is really hard problem
Intercepting parallel is relatively simple
If you can redirect output to LPT you can easy capture it in your TSR and send modified output to serial

link above to such tsr with source code
hmmm...I have another idea, might work since we are dealing with ascii files.  I'm thinking you write a little code in good old basic, compile it when it works - here's the process outline:
0) ICVerify launches this little batch
1) batch file renames sourcefile to oldsource file
2) calls basic program credkill.bas

     REM Rough Basic Code
     OPEN oldsourcefile as INPUT File #1
     OPEN sourcefile as OUTPUT File #2
     TEST EOF of INPUT close program if true
     INPUT #1 readaline$
     if readaline$ contains "card" print #2 "***************"
          else print #2 readaline$

3) delete oldsourcefile
4) print sourcefile
5) end batch

(and now I'm  waiting for the amused responses :)
_RonC_Author Commented:
Yes the code to do the actual work seems to be trival doesn't it?
The problem is _HOW_ to launch this program.  To my knowledge the Credit Card
authorization program has no 'hook'  within it to run an external program, which
is the first part of the problem, with rubbing out the CC # as the 2nd part.

As far as amused responses are concerned I think your response was a very valid one,
and I thank you for it.  Now  put some thought into problem #1, so we can do the fun problem #2.

So I went and looked at the ICVerify website, since I've never used POS before.  They indicate newer versions of the software, for windows of course.  Is there no possiblity of upgrading the
client(s) to a window OS?

I'm also thinking of redirecting the data that goes to the comport to a pipe/stream terminating on another machine running a newer OS, allowing you more processing capability.....

um, wait a sec...another wild thought.  Can we put the TSR in a mode so that it exits after a transaction?  That way it could be invoked in a looping batch file as we looked at above...The TSR exits, we process the ascii files and the TSR reloads?  Better yet, do you have any command line documentation for this TSR you can share?  are there any useful command line switches?

_RonC_Author Commented:
Vadim_ti :  

     You bring up a very interesting  work-around  and this will require me to review
it carefully.  It's been years since I've done assy work, and wasn't all that good at it when I
did.  The printer in question  uses hardware flow control via DTR,DSR and CTS.  Obviously one would
want to change the  Xon/Xoff 'trigger' signals to something more sane.  Like a 'cut' code, I.E.  a code to signal the printer to cut the receipt.   In anycase, It would probably be easier to just have the Assy  search the data stream for the  magic number.  If I go this route, the new problem is the skill level  needed to  accomplish this simple task (but not necessarly so simple when writing Assy code) .  

If there was a way to hook in a  C function It might bring it closer to my skill level (assuming Gcc or some other freely available C compiler for Dos).  Otherwise, the lack of skill in this area very much complicates matters by trying to hook in C function, then a  C compiler , linking etc.

But this line of thinking is a start and I welcome it.


As I underscand,
- ICVerify starts by a hot key
- CC number is entered
- transaction authorization
- receipt printing from ICVerify

What COM port settings (IO port, baud rate, port number) are available in ICVerivy?
Is it possible to redirect printout to COM1 or COM2 file? This should print to COM port through DOS and BIOS internal services.

When receipt printing is redirected to a file, try to exit to dos, and to copy the file directly to COM port.
copy file COM1
_RonC_Author Commented:
Yes you got it right.
Additionally it can output to LPT as well.

Sending the resulting file to the printer attached to COMx is as easy as
type receipt.txt > COMx  or as you suggested COPY receipt.txt COM1
works as well.

_RonC_Author Commented:


From your earlier question, It would not be practical.
I'm talking about 70 of these DOS stations total.  Some
are running old Cyrix 200Mhz Processors and not much
memory.    A better solution would likely be  DOSEMU booting
PCDOS 7 under Linux.  as that would be the only likely candidate
of having a chance in hell on runing on  a 16 meg machine.

Some of these boxes have seen better days long gone,  So the bottom
line was I did consider this with windows and Linux but decided that
I would be violating prime directive #1 of 'KISS' or ' Keep It Simple Stupid'.
and end up causing more work for myself.  

A less intrusive method might be to utualize the server at each site have
OS/2 warp 4.  I did fail to mention these puppies have 8 port Arnet Serial
cards in them.  Using about 4-5 ports to send orders to  various serial printers
in the kitchen via a program I wrote many moons ago when we  wore rose colored
sun glasses and actually thought that O/S2 had a chance in hell of displacing

In this scenerio the OS2 machine has a directory on  the hardrive which acts like a
print input queue.  The POS program dumps orders to be printed to various  kitchen
printer devices  in this directory, and a 32 BIT OS/2 app which acts like a serial 'print
server'  happily sends  the file to  the corresponding serial port based on a deviceID
embedded in its filename.

In this schema, it would involve just some software reconfig and the running of
2 extra serial cables. But the problem is how to print the CC receipt without having to
resort to buying a new printer dedicated to the function.   Well splitting 2 serial cables
to 1 printer device would do this.  It would probably only need to have GND, and TXD
lines from the DCE end connected to the GND and RD lines on the DTE side.  With the
PC ->Printer cable having all the necessary hw signals for the flow control the DOS software
needs  in order to print. as it is doing right now.

One would simply write a REXX program that looked for  say RCPTR1.TXT or RCPTR2.TXT
(with R1,R2 being unique id's so it know where they came from)  which comes from the dos
machines and toss em into the print servers input queue renamed so they would go to the
proper com port .  

Unfortunately, this solution too is fraught with complexity and I wish to avoid that :\

One  really big possible problem would be what would happen if my electrical grounds
between the front of the store where the DOS machines are and the back of the store where
the server lives has a high potential differnece?  In this case anything over 0.5VAC.  It would
result in a ground loop and possibly wreck all sorts of havoc on the whole system.   A drunk
Simpson on a rampage comes to mind.   I could easily design  a circut to decouple or isolate
the two, which is the proper way of doing it.  But again there has to be a much simplier way to
accomplish my goal without having to resort to this.


LOL...there is a much simpler solution; budget and upgrades :)..But if you needed a simple solution you wouldn't be here....putting my thinking cap back on.
Looks like ICVerify uses DOS services to print.
It is difficult to take over DOS file services routine, but BIOS LPT, or COM services are easy prey for skilled programmer. DOS is using BIOS interrupts so interrupt routine can replace data when printed.

I wrote a polish letter emulation utility to change some polish national characters in printout stream to proper english letters and to print additional character on the english letter. The utility had to check the data stream for graphic data and stop from replacing characters in graphic printout. Now I'm thinking about printer language replace utility form Epson to PCL.

The simplest solution I've found is to start selling program from a batch. The batch can modify, and print receipt on the program exit.
The problem is, it will be necesary to exit program on each CC printout.
_RonC_Author Commented:
         Thanks for the reply. I'm afraid that shelling the program from batch would
kill them dead in the water in terms of speed.  

I can tell the program to put a 'cut' code at the end of the print out.  This signals
the printers autocuter if it has one, to  cut the receipt at the very end.

A TSR could use this cutcode as a 'trigger' that simply wakes up. checks for the
presence of a receipt file, Modifies one line  that amounts to less than 40 bytes,
and then sends the modified receipt as well as the original one  out the com port.
Before the TSR goes back to sleep, it would unlink the receipt file (delete), and go
back to sleep to and wait for the next transaction that will wake it up again.

This is the most simple way I can think of.  For one. it is not intrusive on the majority
of transactions that are not CC related, unless they have printers which use the same
cut code, but then even if they were the same so what?  The TSR would see  there were no files it needed to print and go back to sleep.

I've even pondered the possibility of hacking the eprom in the printer itself to mask
out the CC number, but quickly rejected the idea as being too nonsensical  to be
taken seriously. :)  Although, some printers can reverse the paper back to previously printed lines and then overstrike them.  I dont think the vast majority of the ones
I've seen can do this though.



long time ago i write TSR to replace one printer with another one
original printer was parallel Epson and printer to replace was serial Zebra
TSR cathed data in parallel port , do reformatting and send new data to serial port

TSR written in borland c 3.1 and masm
if you want i can send it to you to e-mail
may be you will be able to do with it something
JonShCommented: the end, I don't think we helped much :)
_RonC_Author Commented:
Well it looks as though I should close this question as being un answered.

There were several possibilities presented, but they iin themselves had hurdles
I needed to overcome.  For exampe:

(1)  Some  code required compilers or tools I did not have.

(2)  If I  did manage to snag these tools somwhere it would have required
      me to dedicate time and resources to  learn how to use these tools effectively.

(3) Most of the code needed modifications which required skills I do not immediately
     poessess.  This would have required even more allocation of time and resources which
    I do not have.  

In the end, I determined it is simply not an easy solution , and thus forced me to rethink my
solution.  I could have found a programmer to do this.  Be it very unlikely this programmer would
have the same type of Hardware and printer configurations, I would have had to send him/her this
equipment and be at the programmers mercy to get it done.  Again, not a whole lot of time to play with
considering 22 locations and a Dec 31 deadline, and not a single solution  on the horizion.

Therefore, after rethinking the issue, I  am forced to use another approach, and Ineed I will be  testing this
approach  in the field in the ext couple of days.  In my opinion the solution is LAME.   No argument there.
However in the lab, it works and works well.  I briefly mentioned it in one of my other messages but for the
curious recall a few facts:

(1). File Servers in the back of house run OS/2 warp 4.  
(2).The above servers have 8 port dumb serial cards in them that support remote 40 col kitchen printers in the kitchen.
(3).The dos clients (Registers) running the POS application  connect to this file server to run the pos program.
(4).The file server also runs the ICVERIFY MULTIUSER server which does the credit card authentication  thanks to OS/2
      great DOS emulation.

Given the above, I have written some software in  PHP CLI  that runs on  the OS/2 SERVER in its own process that handles
the ICVERIFY receipt issue. I accomplish this by telling  THE iicverify client to  output the receipt to a file instead of a printer.
The file for each ICVERIFY cleint has a unique name and outputs to a "input" QUEUE directory on the file server.  The PHP
program polls the input queue for these files.  If it finds one, it makes any necessary changes to the customer receipt and the
store copy if necessary (for things other than cc number) , we writes these changes to a new file.  The new file is written into
the POS print server's print queue directory.  The print server has well documented info on what files it looks for to print and
where to print them.  So some configuration changes to the  print server's ini file are necessary but thats it.  Once the cc receipt
files are tossed into the print servers  input queue directory, I dont worry about them anymore.  The pserver takes care of that.

There is then one last problem to deal with , and this is the LAME part of the solution.

It requires running a serial cable from the 8 port serial card on the server to each dos workstation that needs to print a credit card
receipt.  I attach the the dos workstation and the  new cable to the receipt printer via a "port splitter"   This allows the computers to
talk to the printer without contention, and  with hardware handshaking working for each computer as it should.  The port splitter is
a inline device and requires no external power.    In order to be safe, I insert an opto isolator "Coupler" between the server serial line
and the splitter.  The opto isolator will handle up to 4kv  potential difference betwen the two.  If the PD ever gets a fraction of that, I've
got bigger problems than blowing up a few computers I can tell you that.

I've managed to keep the total cost per terminal down to about $40.00 a terminal not including  having the cables run and terminated
with will run in the neighborhood of $95.00 - $140 a store.  So the max possible cost would be $140 for cabling  + 3 terminals at $40
or $260  The $40 includes the cost of the splitter and extra serial cable needted to connect the DOS PC to the splitter.

Turns out this solution may offer other bonus capabilities such as the ability to print coupon or promotional receipts etc so If It may not
be as lame as I first thought.

I will be testing a site live with this in the upcomming week.

One may ask why on earth did I choose PHP instead of using say REXX  which is included in O2/2.  The answer is because of PHP's rich  choice of functions,
and because PHP really excels in dealing with TEXTUAL data in a very robust and easy way, and because I was most familiar with PHP since it has been
years since I wrote  any real code using REXX.

I would like to thank those who did bother to respond to my questions.  

To JonSh  yes you did hlelp.  More than you know.  Rarely is information exchange not helpful.
Unless its a US presidental debate or some other sillyness.


_RonC_Author Commented:
I think if there are no rules or objections against it tojust split up the points amongst everyone who
bothered to answer at all.  This seems fair enough to me.  Is there some rule or reason I should not
do this?

OMG, RonC, that looks a lot like best pieces of some of the hacks I thought of without the stupid stuff.  I congratulate you on your creativity and sheer determination in nailing down the details to make it work.  Wow!  Kudos to you!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.