Re: [U2] Backspace sends break signal in UV
Thanks for the replies everyone. Yup. I know I can set my tty settings via PTERM. I really should have worded my question differently: What causes my system to switch tty settings simply by logging from the UV account to my development account? I'm old enough to remember that break is a condition not an actual character. Uhhh... just *barely* old enough. :) I actually wrote a Wyse 50 emulator and modem dialer a long time ago. Did it in x86 assembly language too for some reason. (Grandpa - what's a modem? ) Anyway - Here's a screen dump of the settings and the change. It starts by changing to my development account, showing the settings, logto the UV account and show the settings, then doing LOGTO back to my dev account and showing the settings there. There's nothing in the LOGIN paragraph that appears to be altering the settings. I'm using KDE Konsole as the emulator which sends a term type of xterm. rlittle@mustang:/usr/uvuser$ uv UniVerse Command Language 11.1 Copyright Rocket Software, Inc. 1985-2011. All rights reserved. uvuser logged on: Mon Apr 30 06:15:34 2012 :PTERM DISPLAY MODEEMULATE CC INTR= ^C QUIT= ^\ SUSP= OFF DSUSP = OFF SWITCH = OFF ERASE = DEL WERASE = OFF KILL= ^U LNEXT = OFF REPRINT = OFF EOF = ^D EOL = ^@ EOL2= ^@ FLUSH = OFF START = ^Q STOP= ^S LCONT = ^_ FMC = ^^ VMC = ^] SMC = ^\ TMC = ^T SQLNULL = ^N INPUTCTLON CARRIER RECEIVE -HANGUP -LOCAL CASE-UCIN -UCOUT -XCASE -INVERT CRMODE -INLCR -IGNCR ICRNL ONLCR -OCRNL -ONOCR -ONLRET -CRONLY DELAY BS0 CR0 FF0 LF0 VT0 TAB0 -FILL ECHOECHO ERASE=BSB KILL=LF CTRL -LF HANDSHAKE XON -ANY TANDEM -DTR OUTPUT POST -TILDE -BG CS -EXPAND PROTOCOLLINE=0 BAUD=38400 DATA=8 STOP=1 NONE DISABLE -STRIP SIGNALS ENABLE FLUSH BREAK=NULL :SH rlittle@mustang:/usr/uvuser$ stty -a speed 38400 baud; rows 38; columns 109; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke rlittle@mustang:/usr/uvuser$ exit :LOGTO UV UniVerse System Administration PackageAccounts Recovery Spoolersh Mem Import Devices :PTERM DISPLAY MODEEMULATE CC INTR= ^C QUIT= ^\ SUSP= OFF DSUSP = OFF SWITCH = OFF ERASE = DEL WERASE = OFF KILL= ^U LNEXT = OFF REPRINT = OFF EOF = ^D EOL = ^@ EOL2= ^@ FLUSH = OFF START = ^Q STOP= ^S LCONT = ^_ FMC = ^^ VMC = ^] SMC = ^\ TMC = ^T SQLNULL = ^N INPUTCTLON CARRIER RECEIVE -HANGUP -LOCAL CASE-UCIN -UCOUT -XCASE -INVERT CRMODE -INLCR -IGNCR ICRNL ONLCR -OCRNL -ONOCR -ONLRET -CRONLY DELAY BS0 CR0 FF0 LF0 VT0 TAB0 -FILL ECHOECHO ERASE=BSB KILL=LF CTRL -LF HANDSHAKE XON -ANY TANDEM -DTR OUTPUT POST -TILDE -BG CS -EXPAND PROTOCOLLINE=0 BAUD=38400 DATA=8 STOP=1 NONE DISABLE -STRIP SIGNALS ENABLE FLUSH BREAK=NULL :SH rlittle@mustang:/usr/uv$ stty -a speed 38400 baud; rows 38; columns 109; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke rlittle@mustang:/usr/uv$ exit :LOGTO UVUSER -----##-###-#####-- --##-####--##--######-####- --##--##--######-##---##--####- --##-##--##--##--##--##--##---####- ----######----#-##- --##--##-##--##--##--##-######- --##---##-######-##--##---####-
Re: [U2] Backspace sends break signal in UV
We use the following in our /etc/profile if [ -x /usr/bin/id ]; then USER=`id -un` LOGNAME=$USER MAIL=/var/spool/mail/$USER stty erase ^H(not just carat and H, but control V then control H) TERM=vt100 fi -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bob Rasmussen Sent: Sunday, April 29, 2012 9:57 AM To: U2 Users List Subject: Re: [U2] Backspace sends break signal in UV Here's some background that might help: The backspace key on a keyboard can be configured (in most terminal emulators) to send either ctrl-H (hex-08) or DEL (hex-7F). On the Linux system, the 'stty' command displays and configures how certain keys are recognized. For instance, on my Linux system, at the shell, if I enter stty -a (where the -a is for all), I get: ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Backspace sends break signal in UV
I don't think I'm fully understanding your problem, but, I did notice this piece in your post... There's nothing in the LOGIN paragraph that appears to be altering the settings. I'm using KDE Konsole as the emulator which sends a term type of xterm. I have never had luck with xterm emulation for any MV system (be it QM, Universe, etc.) You are probably better off setting your KDE konsole session to vt100 and sorting it out from there. Don't quote me on this, but, I don't believe most MV systems have a proper term definition for xterm. Just a thought, as I have had similar pains in the past... On Mon, Apr 30, 2012 at 7:11 AM, Bob Little b...@marketamerica.com wrote: Thanks for the replies everyone. Yup. I know I can set my tty settings via PTERM. I really should have worded my question differently: What causes my system to switch tty settings simply by logging from the UV account to my development account? I'm old enough to remember that break is a condition not an actual character. Uhhh... just *barely* old enough. :) I actually wrote a Wyse 50 emulator and modem dialer a long time ago. Did it in x86 assembly language too for some reason. (Grandpa - what's a modem? ) Anyway - Here's a screen dump of the settings and the change. It starts by changing to my development account, showing the settings, logto the UV account and show the settings, then doing LOGTO back to my dev account and showing the settings there. There's nothing in the LOGIN paragraph that appears to be altering the settings. I'm using KDE Konsole as the emulator which sends a term type of xterm. rlittle@mustang:/usr/uvuser$ uv UniVerse Command Language 11.1 Copyright Rocket Software, Inc. 1985-2011. All rights reserved. uvuser logged on: Mon Apr 30 06:15:34 2012 :PTERM DISPLAY MODEEMULATE CC INTR= ^C QUIT= ^\ SUSP= OFF DSUSP = OFF SWITCH = OFF ERASE = DEL WERASE = OFF KILL= ^U LNEXT = OFF REPRINT = OFF EOF = ^D EOL = ^@ EOL2= ^@ FLUSH = OFF START = ^Q STOP= ^S LCONT = ^_ FMC = ^^ VMC = ^] SMC = ^\ TMC = ^T SQLNULL = ^N INPUTCTLON CARRIER RECEIVE -HANGUP -LOCAL CASE-UCIN -UCOUT -XCASE -INVERT CRMODE -INLCR -IGNCR ICRNL ONLCR -OCRNL -ONOCR -ONLRET -CRONLY DELAY BS0 CR0 FF0 LF0 VT0 TAB0 -FILL ECHOECHO ERASE=BSB KILL=LF CTRL -LF HANDSHAKE XON -ANY TANDEM -DTR OUTPUT POST -TILDE -BG CS -EXPAND PROTOCOLLINE=0 BAUD=38400 DATA=8 STOP=1 NONE DISABLE -STRIP SIGNALS ENABLE FLUSH BREAK=NULL :SH rlittle@mustang:/usr/uvuser$ stty -a speed 38400 baud; rows 38; columns 109; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke rlittle@mustang:/usr/uvuser$ exit :LOGTO UV UniVerse System Administration PackageAccounts Recovery Spoolersh Mem Import Devices :PTERM DISPLAY MODEEMULATE CC INTR= ^C QUIT= ^\ SUSP= OFF DSUSP = OFF SWITCH = OFF ERASE = DEL WERASE = OFF KILL= ^U LNEXT = OFF REPRINT = OFF EOF = ^D EOL = ^@ EOL2= ^@ FLUSH = OFF START = ^Q STOP= ^S LCONT = ^_ FMC = ^^ VMC = ^] SMC = ^\ TMC = ^T SQLNULL = ^N INPUTCTLON CARRIER RECEIVE -HANGUP -LOCAL CASE-UCIN -UCOUT -XCASE -INVERT CRMODE -INLCR -IGNCR ICRNL ONLCR -OCRNL -ONOCR -ONLRET -CRONLY DELAY BS0 CR0 FF0 LF0 VT0 TAB0 -FILL ECHOECHO ERASE=BSB KILL=LF CTRL -LF HANDSHAKE XON -ANY TANDEM -DTR OUTPUT POST -TILDE -BG CS -EXPAND PROTOCOLLINE=0 BAUD=38400 DATA=8 STOP=1 NONE DISABLE -STRIP SIGNALS ENABLE FLUSH BREAK=NULL :SH rlittle@mustang:/usr/uv$ stty -a speed 38400 baud; rows 38; columns 109; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
Re: [U2] Backspace sends break signal in UV
Hi John, I used to run on Jbase/AIX and used xterm. Of course I had to fix the AIX terminfo definition because it was in such sad shape. Regards, Charlie Noah On 04-30-2012 9:26 AM, John Thompson wrote: I don't think I'm fully understanding your problem, but, I did notice this piece in your post... There's nothing in the LOGIN paragraph that appears to be altering the settings. I'm using KDE Konsole as the emulator which sends a term type of xterm. I have never had luck with xterm emulation for any MV system (be it QM, Universe, etc.) You are probably better off setting your KDE konsole session to vt100 and sorting it out from there. Don't quote me on this, but, I don't believe most MV systems have a proper term definition for xterm. Just a thought, as I have had similar pains in the past... On Mon, Apr 30, 2012 at 7:11 AM, Bob Littleb...@marketamerica.com wrote: Thanks for the replies everyone. Yup. I know I can set my tty settings via PTERM. I really should have worded my question differently: What causes my system to switch tty settings simply by logging from the UV account to my development account? I'm old enough to remember that break is a condition not an actual character. Uhhh... just *barely* old enough. :) I actually wrote a Wyse 50 emulator and modem dialer a long time ago. Did it in x86 assembly language too for some reason. (Grandpa - what's a modem? ) Anyway - Here's a screen dump of the settings and the change. It starts by changing to my development account, showing the settings, logto the UV account and show the settings, then doing LOGTO back to my dev account and showing the settings there. There's nothing in the LOGIN paragraph that appears to be altering the settings. I'm using KDE Konsole as the emulator which sends a term type of xterm. rlittle@mustang:/usr/uvuser$ uv UniVerse Command Language 11.1 Copyright Rocket Software, Inc. 1985-2011. All rights reserved. uvuser logged on: Mon Apr 30 06:15:34 2012 :PTERM DISPLAY MODEEMULATE CC INTR= ^C QUIT= ^\ SUSP= OFF DSUSP = OFF SWITCH = OFF ERASE = DEL WERASE = OFF KILL= ^U LNEXT = OFF REPRINT = OFF EOF = ^D EOL = ^@ EOL2= ^@ FLUSH = OFF START = ^Q STOP= ^S LCONT = ^_ FMC = ^^ VMC = ^] SMC = ^\ TMC = ^T SQLNULL = ^N INPUTCTLON CARRIER RECEIVE -HANGUP -LOCAL CASE-UCIN -UCOUT -XCASE -INVERT CRMODE -INLCR -IGNCR ICRNL ONLCR -OCRNL -ONOCR -ONLRET -CRONLY DELAY BS0 CR0 FF0 LF0 VT0 TAB0 -FILL ECHOECHO ERASE=BSB KILL=LF CTRL -LF HANDSHAKE XON -ANY TANDEM -DTR OUTPUT POST -TILDE -BG CS -EXPAND PROTOCOLLINE=0 BAUD=38400 DATA=8 STOP=1 NONE DISABLE -STRIP SIGNALS ENABLE FLUSH BREAK=NULL :SH rlittle@mustang:/usr/uvuser$ stty -a speed 38400 baud; rows 38; columns 109; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol =undef; eol2 =undef; swtch =undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke rlittle@mustang:/usr/uvuser$ exit :LOGTO UV UniVerse System Administration PackageAccounts Recovery Spoolersh Mem Import Devices :PTERM DISPLAY MODEEMULATE CC INTR= ^C QUIT= ^\ SUSP= OFF DSUSP = OFF SWITCH = OFF ERASE = DEL WERASE = OFF KILL= ^U LNEXT = OFF REPRINT = OFF EOF = ^D EOL = ^@ EOL2= ^@ FLUSH = OFF START = ^Q STOP= ^S LCONT = ^_ FMC = ^^ VMC = ^] SMC = ^\ TMC = ^T SQLNULL = ^N INPUTCTLON CARRIER RECEIVE -HANGUP -LOCAL CASE-UCIN -UCOUT -XCASE -INVERT CRMODE -INLCR -IGNCR ICRNL ONLCR -OCRNL -ONOCR -ONLRET -CRONLY DELAY BS0 CR0 FF0 LF0 VT0 TAB0 -FILL ECHOECHO ERASE=BSB KILL=LF CTRL -LF HANDSHAKE XON -ANY TANDEM -DTR OUTPUT POST -TILDE -BG CS -EXPAND PROTOCOLLINE=0 BAUD=38400 DATA=8 STOP=1 NONE DISABLE -STRIP SIGNALS ENABLE FLUSH BREAK=NULL :SH rlittle@mustang:/usr/uv$ stty -a speed 38400 baud; rows 38; columns 109; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol =undef; eol2 =undef; swtch =undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl
[U2] User ID of a LOCKED record
I am trying to notify a user of a locked record so they can ask the person locking that record to GET OUT. Is there a simple way to retrieve the user ID given the port number in a BASIC program? The only method I have found is to call !GET.USERS and then loop through the USER.INFO param comparing port numbers until I find the user and pull their user ID from there. Thanks in advance. Andy Krause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] User ID of a LOCKED record
John, this might not help Andy, but instead of parsing LIST.READU I would just use GETREADU() in UniData UniBasic. David A. Green (480) 813-1725 DAG Consulting -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R. Sent: Monday, April 30, 2012 1:56 PM To: 'U2 Users List' Subject: Re: [U2] User ID of a LOCKED record LIST.READU It is not pretty (at least in UniData) because of the truncation of columns, but it should be a start. John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Andy Krause Sent: Monday, April 30, 2012 4:55 PM To: U2 Users List Subject: [U2] User ID of a LOCKED record I am trying to notify a user of a locked record so they can ask the person locking that record to GET OUT. Is there a simple way to retrieve the user ID given the port number in a BASIC program? The only method I have found is to call !GET.USERS and then loop through the USER.INFO param comparing port numbers until I find the user and pull their user ID from there. Thanks in advance. Andy Krause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] User ID of a LOCKED record
Andy, On a UniData system, try the LIST.QUEUE command - it shows you who is holding the lock and who is waiting for it. Susan Lynch F. W. Davison Company, Inc. - Original Message - From: Andy Krause akra...@rammutual.com To: U2 Users List u2-users@listserver.u2ug.org Sent: 04/30/2012 4:54 PM Subject: [U2] User ID of a LOCKED record I am trying to notify a user of a locked record so they can ask the person locking that record to GET OUT. Is there a simple way to retrieve the user ID given the port number in a BASIC program? The only method I have found is to call !GET.USERS and then loop through the USER.INFO param comparing port numbers until I find the user and pull their user ID from there. Thanks in advance. Andy Krause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] User ID of a LOCKED record
The documentation at HELP LIST.READU states that the login id is returned in the displayed table. However on my Universe 10 on Windows, it is *not* returned. So at LOGIN time, the *port to user* correspondence is set, and then for any port, you can lookup what user is on that port. I don't know why the documentation says it's there, when in fact it's not there. It's been that way for umpteen years. -Original Message- From: Andy Krause akra...@rammutual.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 2:05 pm Subject: [U2] User ID of a LOCKED record I am trying to notify a user of a locked record so they can ask the erson locking that record to GET OUT. Is there a simple way to retrieve the user ID given the port number in a ASIC program? The only method I have found is to call !GET.USERS and hen loop through the USER.INFO param comparing port numbers until I ind the user and pull their user ID from there. Thanks in advance. Andy Krause ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] User ID of a LOCKED record
In the LOCKED clause of your READU/MATREADU statement, STATUS() will contain the UID of the user locking the record. The GETREADU() function will return a dynamic array of all record locks held by the system, similar to the LIST.READU TCL command. e.g.: :LIST.READU UNO UNBR UID UNAME TTY FILENAME INBR DNBR RECORD_ID M TIME DATE 1 21776 200 larry ttyp0 /u/MA.IN 23074 299 187740 X 14:28:47 Apr 30 GETREADU() returns: 1}21776}200}larryh}ttyp0}/u/MA.INFO/CUST.MST}23074}299}187740}X}14:30:58}Apr 30 2012 STATUS() in the LOCKED clause of a READU would return the UID, which is 200 (the 3rd element in the array, i.e. arrayx,3). You could loop through the array to find an entry where the UID matches your STATUS() value, and the RECORD_ID (arrayx,9) matches the key you're trying to read. You could also check the file name (arrayx,6) for good measure. Once you've found the right line, arrayx,4 contains the user name, and arrayx,5 contains the tty they're logged in on (which may be less than helpful in a telnet/ssh environment). Larry Hiscock Western Computer Services -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Andy Krause Sent: Monday, April 30, 2012 1:55 PM To: U2 Users List Subject: [U2] User ID of a LOCKED record I am trying to notify a user of a locked record so they can ask the person locking that record to GET OUT. Is there a simple way to retrieve the user ID given the port number in a BASIC program? The only method I have found is to call !GET.USERS and then loop through the USER.INFO param comparing port numbers until I find the user and pull their user ID from there. Thanks in advance. Andy Krause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] User ID of a LOCKED record
In addition to the UniBasic functions mentioned, you can use the DETAIL keyword on UniData LIST.READU and LIST.QUEUE commands to get full details (no column truncation) Wally Terhune Technical Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: u2.rocketsoftware.com -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R. Sent: Monday, April 30, 2012 2:56 PM To: 'U2 Users List' Subject: Re: [U2] User ID of a LOCKED record LIST.READU It is not pretty (at least in UniData) because of the truncation of columns, but it should be a start. John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Andy Krause Sent: Monday, April 30, 2012 4:55 PM To: U2 Users List Subject: [U2] User ID of a LOCKED record I am trying to notify a user of a locked record so they can ask the person locking that record to GET OUT. Is there a simple way to retrieve the user ID given the port number in a BASIC program? The only method I have found is to call !GET.USERS and then loop through the USER.INFO param comparing port numbers until I find the user and pull their user ID from there. Thanks in advance. Andy Krause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] User ID of a LOCKED record
Again, the PORT and PID options, although in the online HELP do not work on Universe 10 on Windows, for the PORT.STATUS verb -Original Message- From: Holt, Jake jh...@samsill.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 3:12 pm Subject: Re: [U2] User ID of a LOCKED record If you can isolate the port number from list.readu you can pass it into ORT.STATUS and retrieve the name that way as well. -Original Message- rom: u2-users-boun...@listserver.u2ug.org mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Andy Krause ent: Monday, April 30, 2012 3:55 PM o: U2 Users List ubject: [U2] User ID of a LOCKED record I am trying to notify a user of a locked record so they can ask the erson locking that record to GET OUT. Is there a simple way to retrieve the user ID given the port number in a ASIC program? The only method I have found is to call !GET.USERS and hen loop through the USER.INFO param comparing port numbers until I ind the user and pull their user ID from there. Thanks in advance. Andy Krause ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] User ID of a LOCKED record
You get bit by aborting programs and system crashes. -Original Message- From: Bill Brutzman bi...@hkmetalcraft.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 3:21 pm Subject: Re: [U2] User ID of a LOCKED record Consider... Invoking the lock by calling a sub. In the sub, do the lock... but also save to new FILE... the pertinent info... user_id, program, file, date, time, etc. hen the lock is released, have another companion sub to delete the record from he FILE. --Bill -Original Message- rom: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] n Behalf Of Andy Krause ent: Monday, April 30, 2012 4:55 PM o: U2 Users List ubject: [U2] User ID of a LOCKED record I am trying to notify a user of a locked record so they can ask the person ocking that record to GET OUT. Is there a simple way to retrieve the user ID given the port number in a BASIC rogram? The only method I have found is to call !GET.USERS and then loop hrough the USER.INFO param comparing port numbers until I find the user and ull their user ID from there. Thanks in advance. Andy Krause ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] User ID of a LOCKED record
On Universe: LIST.READU -EVERY - INTERNAL Gives details without truncation for capturing in basic. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] User ID of a LOCKED record
Also, on UV 11.1.1 the user name portion is broken. We had to work around it (by reading our own PID to USER table), but I understand a subsequent release addressed the issue. LIST.READU -INTERNAL Broken output: 11009371^677913942^0^2000^1^RU^ ^ ^333719*1^ 1606438775^34480532^0^5224^15^RU^ ^ ^270784^ 1718299426^1218558262^0^3692^15^RU^ ^ ^30742^ Original output: 814621824^1688564731^0^6896^82^RU^6896^DOMAIN\Joe.User^ZLIST.READUEX^ What they meant to say is that the USERNAME is not reported. Pid is there on 11.1.1. - - - - - - - - - - - - Problems Fixed in UniVerse Release 11.1.5 (Build 5757) UNV-5010UniVerse -- Beginning at UniVerse 11.1.1, the pid number of the UniVerse process holding a lock was no longer displayed in the LIST.READU output. This problem as been fixed. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Monday, April 30, 2012 4:28 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] User ID of a LOCKED record LIST.READU -INTERNAL you don't need the EVERY to see record locks but how wild that -INTERNAL gives you the USER NAME ! And the regular LIST.READU does not (even though the documentation says it will) _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] READU vs READ
If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Remove the line that after each read says xxx record written Terminal I/O is 100 times more expensive than reading and writing -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2-Users U2-Users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 5:32 pm Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, ill a program run significantly faster if I just WRITE it back without ocking it first? I'm updating about 700,000 records and it's just aking TOO long. I DO understand the risks of other users changing the record's content uring so let's not go down that road. I'm interested in the SPEED ialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Understood about the screen I/O ... def not an issue here. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Monday, April 30, 2012 8:40 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ Remove the line that after each read says xxx record written Terminal I/O is 100 times more expensive than reading and writing -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2-Users U2-Users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 5:32 pm Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, ill a program run significantly faster if I just WRITE it back without ocking it first? I'm updating about 700,000 records and it's just aking TOO long. I DO understand the risks of other users changing the record's content uring so let's not go down that road. I'm interested in the SPEED ialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
It'd be interesting to do a FILE.UGAGE ON, run the program, look at the stats, then do FILE.USAGE OFF. Another thing to look at is LIST.READU EVERY while the program is running. If there appears to be an issue there, increase the lock table sizing parameters in uvconfig. Troy is correct in asking about the select method; no sense in processing the same data multiple times, so that's the first thing to eliminate. The second is file sizing. If you have to follow dozens of links to read write for each record, that consumes a ton of resources. You'll see that in the FILE.USAGE report, or you could just look at ANALYZE.FILE to see if the file is poorly sized. From: troy.b...@nordsonasymtek.com To: u2-users@listserver.u2ug.org Date: Mon, 30 Apr 2012 20:47:59 -0400 Subject: Re: [U2] READU vs READ Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 8:48 PM To: U2 Users List Subject: Re: [U2] READU vs READ Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Good point... For progress indications, I tend to do the following on the mass updates: N.COUNT += 1 IF REM(COUNT, 1000) ELSE CRT +: -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Monday, April 30, 2012 5:40 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ Remove the line that after each read says xxx record written Terminal I/O is 100 times more expensive than reading and writing _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
That is WAY too long. Are your files sized correctly? READ vs READU should not be a resource pig like you are seeing. A little, sure, but not THAT much. Something else is in the mix. John Israel Sent from my iPhone On Apr 30, 2012, at 9:01 PM, Dave Laansma dlaan...@hubbardsupply.com wrote: Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 8:48 PM To: U2 Users List Subject: Re: [U2] READU vs READ Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Dave, I tend to cringe when I hear sizable records and updating MV fields. These are red flags. If you don't have the luxury of reconstructing the database then make sure you are using the right UniBasic tools like REMOVE and not FOR...NEXT. David A. Green (480) 813-1725 DAG Consulting -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 8:48 PM To: U2 Users List Subject: Re: [U2] READU vs READ Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
On 4/30/2012 9:12 PM, Buss, Troy (Contractor, Logitek Systems) wrote: We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. Same here - two years ago we moved from Solaris with dedicated RAID with hardware controller to virtualized RedHat and no hardware RAID, yet improved disk I/O by factor of 2 or more. Ditto on CPU... -- Jeff Butera Hampshire College jbut...@hampshire.edu 413-559-5556 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
By Sizable, are you talking 10k, 50k, 100k, larger? The Seperation would become a huge factor, then. Mark Baldridge wrote some great stuff about Sep in The Hitchhiker's Guide to the UniVerse series a few years back. You wouldn't happen to be on AIX, would you? If so, as root, you could do a truss -pdf pid to see every system call made by the process, along with a time stamp telling you the time delta between each system call. Date: Mon, 30 Apr 2012 21:01:07 -0400 From: dlaan...@hubbardsupply.com To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 8:48 PM To: U2 Users List Subject: Re: [U2] READU vs READ Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
(Saw other responses come in as I was writing this - oh well, this might help someone else...) From: Dave Laansma If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. I don't know what you meant by SPEED dialog but if WJ is right and you're displaying an item count as you run through records, then he is also right that that IO will destroy performance. Try this as related experiment: Loop to display the numbers 1 through 1 million. Watch it stream on your terminal emulator. Now run it again, minimize the emulator, then re-normalize it. I believe you will find that while the output was hidden it streamed through most or all of the output. Same thing happens if you're doing a copy or delete and tapping your fingers as you wait for the IDs to stream by - a watched kettle takes longer to boil... :) About READU vs READ... You're doing a READU just because you're doing a WRITE? Nah, if you don't care about contentions don't bother to ReadU. You're reading and updating lock tables and semaphors with READU and that's huge performance hit. Here's another experiment: When you're copying or restoring items, use the appropriate option to overlay items, even if you know the target file is empty. Why? Because Copy needs to do a Read first to see if it needs to warn you about an existing item. If you tell it to overlay it will just do the Write (sure, there's a lower level read there anyway but less code is executed). Combining these... if you use a Copy (Pick flavor, don't recall options otherwise) with both overlay and ID suppress, it avoids a ton of internal DBMS code, so it goes a lot faster than a no-option copy. I haven't benched those scenarios for years. If anyone does the tests, please let us know if this is valid or not, and your DBMS/flavors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Add to the mix indexes and triggers. They can both add to the time needed to update just one record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Tuesday, 1 May 2012 11:12 AM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1EE0zigg55/70gcZxRJUITQXy3UHcVFYT/0.002 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
It's a dynamic file. FILE-STAT shows no overflow. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 9:12 PM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
No indexes and no triggers. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Monday, April 30, 2012 9:22 PM To: U2 Users List Subject: Re: [U2] READU vs READ Add to the mix indexes and triggers. They can both add to the time needed to update just one record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Tuesday, 1 May 2012 11:12 AM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1EE0zigg55/70gcZxRJUITQXy3UHcVFYT/ 0.002 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
why not post the relevant code you are using to do the field updates perhaps we can see some inefficiency in the way you're grabbing and updating fields you said the records were sizeable and that raises my eyebrow (just one) -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 6:38 pm Subject: Re: [U2] READU vs READ No indexes and no triggers. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Monday, April 30, 2012 9:22 PM To: U2 Users List Subject: Re: [U2] READU vs READ Add to the mix indexes and triggers. They can both add to the time needed to update just one record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Tuesday, 1 May 2012 11:12 AM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1EE0zigg55/70gcZxRJUITQXy3UHcVFYT/ 0.002 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
I learned terminal I/O problems last millennium. Unfortunately I wrote neither the code nor did I design the files. I just want to speed the silly thing up. It also appears that each record is getting several MVs added, so each record is effectively getting larger with each WRITE ... yea ... :-/ ... it must have seemed like a good idea at the time. (My apologies for whining) Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Monday, April 30, 2012 9:22 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ (Saw other responses come in as I was writing this - oh well, this might help someone else...) From: Dave Laansma If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. I don't know what you meant by SPEED dialog but if WJ is right and you're displaying an item count as you run through records, then he is also right that that IO will destroy performance. Try this as related experiment: Loop to display the numbers 1 through 1 million. Watch it stream on your terminal emulator. Now run it again, minimize the emulator, then re-normalize it. I believe you will find that while the output was hidden it streamed through most or all of the output. Same thing happens if you're doing a copy or delete and tapping your fingers as you wait for the IDs to stream by - a watched kettle takes longer to boil... :) About READU vs READ... You're doing a READU just because you're doing a WRITE? Nah, if you don't care about contentions don't bother to ReadU. You're reading and updating lock tables and semaphors with READU and that's huge performance hit. Here's another experiment: When you're copying or restoring items, use the appropriate option to overlay items, even if you know the target file is empty. Why? Because Copy needs to do a Read first to see if it needs to warn you about an existing item. If you tell it to overlay it will just do the Write (sure, there's a lower level read there anyway but less code is executed). Combining these... if you use a Copy (Pick flavor, don't recall options otherwise) with both overlay and ID suppress, it avoids a ton of internal DBMS code, so it goes a lot faster than a no-option copy. I haven't benched those scenarios for years. If anyone does the tests, please let us know if this is valid or not, and your DBMS/flavors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Oh ... you're good ... I ALMOST pasted it ... I know better that to put even FICTITIOUS code on this board ... unless I'm just trying to rile things up about the OS. |-) I do appreciate all of the input. Thank y'all for the info. I'll see what I can do. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Monday, April 30, 2012 9:47 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ why not post the relevant code you are using to do the field updates perhaps we can see some inefficiency in the way you're grabbing and updating fields you said the records were sizeable and that raises my eyebrow (just one) -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 6:38 pm Subject: Re: [U2] READU vs READ No indexes and no triggers. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Monday, April 30, 2012 9:22 PM To: U2 Users List Subject: Re: [U2] READU vs READ Add to the mix indexes and triggers. They can both add to the time needed to update just one record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Tuesday, 1 May 2012 11:12 AM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1EE0zigg55/70gcZxRJUITQXy3UHcVFYT/ 0.002 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org
Re: [U2] READU vs READ
Well, that'll affect performance somewhat. If you're splitting on a high percentage of writes, that's a lot of expensive overhead. You also (unless someone changed it in the past couple of years) have to lock the header of the file when you do a split. But at least you're not following overflow chains out into West Jibip. The disks/file systems you're writing to aren't more than 85% full? Attaching new disk pages to the dynamic file as it grows can be a bottleneck in that scenario... Date: Mon, 30 Apr 2012 21:35:47 -0400 From: dlaan...@hubbardsupply.com To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ It's a dynamic file. FILE-STAT shows no overflow. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 9:12 PM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
You can put earrings on a pig, but it only makes the pig unhappy -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 8:09 pm Subject: Re: [U2] READU vs READ I learned terminal I/O problems last millennium. Unfortunately I wrote neither the code nor did I design the files. I just want to speed the silly thing up. It also appears that each record is getting several MVs added, so each record is effectively getting larger with each WRITE ... yea ... :-/ ... it must have seemed like a good idea at the time. (My apologies for whining) Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Monday, April 30, 2012 9:22 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ (Saw other responses come in as I was writing this - oh well, this might help someone else...) From: Dave Laansma If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. I don't know what you meant by SPEED dialog but if WJ is right and you're displaying an item count as you run through records, then he is also right that that IO will destroy performance. Try this as related experiment: Loop to display the numbers 1 through 1 million. Watch it stream on your terminal emulator. Now run it again, minimize the emulator, then re-normalize it. I believe you will find that while the output was hidden it streamed through most or all of the output. Same thing happens if you're doing a copy or delete and tapping your fingers as you wait for the IDs to stream by - a watched kettle takes longer to boil... :) About READU vs READ... You're doing a READU just because you're doing a WRITE? Nah, if you don't care about contentions don't bother to ReadU. You're reading and updating lock tables and semaphors with READU and that's huge performance hit. Here's another experiment: When you're copying or restoring items, use the appropriate option to overlay items, even if you know the target file is empty. Why? Because Copy needs to do a Read first to see if it needs to warn you about an existing item. If you tell it to overlay it will just do the Write (sure, there's a lower level read there anyway but less code is executed). Combining these... if you use a Copy (Pick flavor, don't recall options otherwise) with both overlay and ID suppress, it avoids a ton of internal DBMS code, so it goes a lot faster than a no-option copy. I haven't benched those scenarios for years. If anyone does the tests, please let us know if this is valid or not, and your DBMS/flavors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
