I'm on a client's site today trying to get a working ODBC connection to a
Unidata server running 7.1.19. The connection works fine for one request,
then from that point on we get either error 81001 or 81002 for about 5
minutes and then it begins to work again. Has anyone else experienced this
I'm having some problems getting the internal barcode to print on an okidata
320 turbo:
Sending to an aux printer:
PRINT CHAR(18):
PRINTTEST
PRINT
PRINT
CHAR(27):CHAR(16):CHAR(65):CHAR(8):CHAR(2):CHAR(0):CHAR(1):CHAR(1):CHAR(2):C
HAR(2):CHAR(3):CHAR(1):
PRINT
I will be out of the office starting 23/03/2013 and will not return until
22/04/2013.
I will respond to your message when I return. If urgent please phone the
helpdesk on 0038696 or from your handset and choose options 3 and1
First Capital Connect Limited. Registered in England Wales
Please forgive the response to my own post. The problem appears to be the
log files that are being created by the UniRPC daemon. The users have a
mix of umask settings and this is leaving log files around (millions of
'em) that aren't overwritable due to umask settings. Clearing the log
files
Bill, thanks for the post, I will check this location for debugging purposes.
But it doesn't help my issue of having Redback send back an error message that
makes more sense when the UniBasic program aborts.
David A. Green
(480) 813-1725
DAG Consulting
-Original Message-
From:
David:
Sorry I can't help you on the Redback issue, but you'd be surprised what
shows up in the UO logs. Also, do you have a UOLOGIN subroutine? In
UD this subroutine always runs when a connection is made through UO.
I've been known to cause myself trouble there.
Bill
Untitled Page
As I look at the book, your codes are exactly right. Perhaps the char(10)
is getting post-translated from linefeed to return-linefeed. I suggest you
try a 9-digit code for comparison.
On Mon, 25 Mar 2013, Nancy Fisher wrote:
I'm having some problems getting the internal barcode to print on
I forget exactly how I solved a similar problem sending control codes to
a printer like that but it had something to do with an automatic reset
code being automatically sent between an initialization string and the
actual data. I think the way I figured it out was by changing the port
of the
Could it be a problem that doing a print vs a print on is changing the CHAR(16)?
Can you set your printer to go into hex dump mode, to see what you actually
receiving on the printer end.
Also, if your running unix, you could also tee off the printer driver output to
a /tmp file and check that
Wait, nevermind, with aux printing, you can't do print on
Sorry,
George
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen
Sent: Monday, March 25, 2013 2:05 PM
To: U2 Users List
Subject: Re: [U2]
Hi Geniuses.
At a few of my customer sites I've seen people have these little hand-built
utilities that help them identify the file/location of the source of a
globally cataloged item.
I could really use a handy little device like that - on both platforms,
Universe and Unidata. Does anyone -
General response...
This is why I love PrintWizard:
PRINT \barcode src=1234567890 style=code39\
Done!
Really. Look below. Now look above. Now think about which code you'd
rather maintain, or pay someone else to maintain, every time you get a
new printer.
Jus' sayin'...
I do not sell PrintWizard
My first thought is it's *throwing away* the middle of the data stream and you
get the ending at times when it's over its hiccup.
Try modding your routine below to wait one second between each character :)
Hey it's worth a shot!
-Original Message-
From: George Gallen
I have this built into my VIEW routine which allows inter-call jumping
but I don't have it as a sep program
Just be aware that you *have* to read the opcode in BLOCK form (READBLK)
because it *can* have embedded char 255's which will truncate any string read.
Nice huh?
So you have to step the
To be more clear. The path of the source code, is embedded at the tail of the
opcode in the GLOBAL.CATDIR item for that catalogued routine name. If you can
retrieve that path you can then parse it and compare it to what you know or
think you know about where your code is stored from the
Thank you!
From: Wjhonson [mailto:wjhon...@aol.com]
Sent: Monday, March 25, 2013 4:29 PM
To: u2-users@listserver.u2ug.org; sjos...@sjplus.com
Subject: Re: [U2] Cataloged programs // finding
To be more clear. The path of the source code, is embedded at the tail of
the opcode in the
On 25/03/2013 16:47, Kevin King wrote:
Please forgive the response to my own post. The problem appears to be the
log files that are being created by the UniRPC daemon. The users have a
mix of umask settings and this is leaving log files around (millions of
'em) that aren't overwritable due to
In UniData, there's a CTLGTB file (not directory) with dictionary items
and a catalog item with a format like:
4 Dev (0)- AE CTLGTB *
606 record(s) selected.
1 Top of MVNET.DICTWRITE in CTLGTB, 4 lines, 47 characters.
*--: p
001: S
002: 3
003: E:\MVNET\MVNET.BP MVNET.DICTWRITE
004: admin
18 matches
Mail list logo
