Re: [U2] Phone/TAPI Interface, D3/W2K
Mark, Never done it with D3, but it seems that you could look at some simple IVR software, maybe based upon rather inexpensive Dialogic cards. I'm not really sure how your operation works, is each confirmation call only made when the tech informs a ready status, or can these be batch handled at the start of the day? In both cases you could put together a daily calling list (one for each tech?) and load it into a simple VB6 application (perhaps even an existing aplication supplied with the CTI hardware). In the first case the dispatcher, upon receiving a status indicator that he/she must confirm a call could click upon the next visit for the tech's route and using a supplied protocol, have the IVR place the call, recite a predefined message and return a status (client hung up, no answer, client confirmed, busy, etc). In the second case (batch mode) the whole calling list could be processed at once, with automatic, periodic retries for the unsucessful calls). I'm in Argentina so I can't recommend specific suppliers. Regards, Marc - Original Message - From: Mark Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 24, 2004 3:04 PM Subject: [U2] Phone/TAPI Interface, D3/W2K Perhaps someone can lead me in the right direction. One of my clients, D3/W2K, dispatches 20-24 HVAC vans daily throughout our state with upwards of 100-120 calls per day. The dispatcher calls on nextel to inform the techs of their next appointment and uses a regular phone to call the customer for the upcoming visit. The question is if there's a way to interface this system (home/cell/alt phones in database) to an external phone system that could place an automated call to that customer and return a status code (ok, busy signal, no answer, answering maching) to the dispatcher so she doesn't have to have a phone handset permanently welded to her ear. Thanks in advance. Mark Johnson --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ - Original Message - From: Mark Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 24, 2004 3:04 PM Subject: [U2] Phone/TAPI Interface, D3/W2K Perhaps someone can lead me in the right direction. One of my clients, D3/W2K, dispatches 20-24 HVAC vans daily throughout our state with upwards of 100-120 calls per day. The dispatcher calls on nextel to inform the techs of their next appointment and uses a regular phone to call the customer for the upcoming visit. The question is if there's a way to interface this system (home/cell/alt phones in database) to an external phone system that could place an automated call to that customer and return a status code (ok, busy signal, no answer, answering maching) to the dispatcher so she doesn't have to have a phone handset permanently welded to her ear. Thanks in advance. Mark Johnson --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [OT] Has anyone exoerienced a HUGE increase of Spam?
The IndexInfocus archives are not indexed by search engines, when that's all there was, we were fairly anonymous. Are you sure, I recall googling and following a link to the list archives. Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branchnot taken
The suggestion made by Ray using uvbackup as a check of files is the philosophy we have adopted after experiencing this type of corruption. We run this every Saturday night over all our files and email the result reporting any likely problems. We are still discussing this one with IBM. They suggested that fixtool in UV 10.0.14 or later will find more errors than uvbackup. When (if?) we find a solution I'll post the results. IBM have suggested that the initial corruption problem which sent us this way is patched in UV 10.0.17 or later (including 10.1), but they believe that not taking the ON ERROR clause when a blink error is encountered may be a bug. Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
When (if?) we find a solution I'll post the results. IBM have suggested that the initial corruption problem which sent us this way is patched in UV 10.0.17 or later (including 10.1), but they believe that not taking the ON ERROR clause when a blink error is encountered may be a bug. I am not sure I would agree that blink errors not taking ON ERROR clauses is a defect. While inconvenient to the user to have a program stop abruptly, the error needs to be dealt with as quickly as possible or the problem will perpetuate. The abort in this case is a deliberate one, i.e. it is intended to occur and not meant to be trapped programmatically. I'll address this internally as well. Regards, LeRoy F. Dreyfuss Advanced Technical Services - U2 Technology Analyst IBM U2 Data Management Solutions Tel: 303-672-1254 Fax: 303-294-4832 Mobile: 720-341-4317 External email: [EMAIL PROTECTED] WWW: http://www.ibm.com/software/data/u2/support www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! Don't miss out on the IBM DB2 Information Management Technical Conference September 19-24, 2004 - Las Vegas, NV Craig Bennett [EMAIL PROTECTED] auTo Sent by: [EMAIL PROTECTED] [EMAIL PROTECTED] cc stserver.u2ug.org Subject Re: [U2] [UV] File corruption 07/25/2004 05:37 error, but ON ERROR branchnot PMtaken Please respond to u2-users The suggestion made by Ray using uvbackup as a check of files is the philosophy we have adopted after experiencing this type of corruption. We run this every Saturday night over all our files and email the result reporting any likely problems. We are still discussing this one with IBM. They suggested that fixtool in UV 10.0.14 or later will find more errors than uvbackup. When (if?) we find a solution I'll post the results. IBM have suggested that the initial corruption problem which sent us this way is patched in UV 10.0.17 or later (including 10.1), but they believe that not taking the ON ERROR clause when a blink error is encountered may be a bug. Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ [demime 1.01d removed an attachment of type image/gif which had a name of graycol.gif] [demime 1.01d removed an attachment of type image/gif which had a name of pic31039.gif] [demime 1.01d removed an attachment of type image/gif which had a name of ecblank.gif] --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] File corruption error, but ON ERROR branch not taken
I am not sure I would agree that blink errors not taking ON ERROR clauses is a defect. While inconvenient to the user to have a program stop abruptly, the error needs to be dealt with as quickly as possible or the problem will perpetuate. The abort in this case is a deliberate one, i.e. it is intended to occur and not meant to be trapped programmatically. I'll address this internally as well. But Leroy, the program neither aborts nor takes the ON ERROR branch, it takes the ELSE branch and continues. Craig --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] File corruption error, but ON ERROR branch not taken
Hi LeRoy Although an immediate abort is probably ideal to prevent further damage to a situation, the ON ERROR clause enables us to identify to operators and support staff the issue that caused a problem as well as deal with transactions with 3rd party database including roll backs, issues with web services and message queques. I had a scenrio, where an upgrade of UniVerse introduced a bug that caused a fatal termination of UniVerse. Not only was this difficult to debug, but the fatal did not release the UniVerse licenses. Trying to resolve the issue remotely was a nightmare. I eventually tracked down that the UniVerse bug caused a file not to be opened when it should have been. The next step then started a transaction on an unassigned file variable and caused a fatal that terminated the session without going through an on-error clause. I think an unassigned file variable could have gone to the on error clause without causing any other damage. (although the application had been tested on the new release, the bug only occurred after the programs were compiled on the new release) Programmaticaly handling fatals, although not always easy, is highly important for mission critical applications like 24x7 banking. Regards David Jordan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leroy Dreyfuss Sent: Monday, 26 July 2004 11:53 AM To: [EMAIL PROTECTED] Subject: Re: [U2] [UV] File corruption error, but ON ERROR branch not taken When (if?) we find a solution I'll post the results. IBM have suggested that the initial corruption problem which sent us this way is patched in UV 10.0.17 or later (including 10.1), but they believe that not taking the ON ERROR clause when a blink error is encountered may be a bug. I am not sure I would agree that blink errors not taking ON ERROR clauses is a defect. While inconvenient to the user to have a program stop abruptly, the error needs to be dealt with as quickly as possible or the problem will perpetuate. The abort in this case is a deliberate one, i.e. it is intended to occur and not meant to be trapped programmatically. I'll address this internally as well. Regards, LeRoy F. Dreyfuss Advanced Technical Services - U2 Technology Analyst IBM U2 Data Management Solutions Tel: 303-672-1254 Fax: 303-294-4832 Mobile: 720-341-4317 External email: [EMAIL PROTECTED] WWW: http://www.ibm.com/software/data/u2/support www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! Don't miss out on the IBM DB2 Information Management Technical Conference September 19-24, 2004 - Las Vegas, NV --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
[U2] AP/Pro Help
This is the best MV forum so I'll give it a try. I still have 4-5 clients running AP/Pro or Microdata. They'll come around eventually but they're quite content with what they have. Anyway, one UV client keeps their prior AP/Pro system and the hard drive crashed with that unfortunate 'doink' sound. Having a spare 133 MHZ P1 system, I started to rebuild it again with the Pick AP/Pro (6.1.27.pro167) diskette set. I had to boot from the floppy (#1 of 2) around 8-10 times to get the SCSI tape and Arnet boards in sync. I had to undo the write-protect tab as I guess something was being saved. Lots of X options. I wanted to lower the port count from 287 to 10 so the shutdown wouldn't take so long so I put in the same floppy again. This time the system flew past the A: drive boot and booted up regularly. I tried this 2-3 times with the same results. I know that powering up with the #1 disc in should offer the Kill/Abs/Files/eXecutable choice in addition to getting at these settings (scsi/ports/etc). Now, it appears that the #1 disc is blank or something as with it installed, it simply boots up regular pick. When I put #2 in, the system hangs at the BIOS display and needs a reboot sans floppy. I tried this in 3 other regular PC's just to see if I get the K/A/F/X prompt and they boot up to their usual W95 era screens. So the question is: Is there some form of consumable on this floppy that would disable it after a number of uses? I don't know what the disc should look like (T-READ or DOS DIR) so I can't tell. Please keep the replies limited to my question and or related to this situation. I know full well all the possible new solutions. Thanks in advance Mark Johnson --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
