Re: [U2] Unidata 6.1.15 Oddity
Thank you everyone for the feedback. I had some suspicion in the back of my mind that doing an OCONV MCU on a full mv'd string was a Somewhat Bad Idea, now I know why. :-) On Thu, Nov 8, 2012 at 10:56 AM, Woodward, Bob bob_woodw...@k2sports.comwrote: Hi Kevin, Two times in my Unidata career I've had a problem like this where something doesn't work in a subroutine. My work around, both times, was to add a simple line of code at the beginning of the program. Usually just assigning a value to a new, unused, variable like JUNK=JUNK is all it would take. With it, the program would work flawlessly but if I took it back out, or commented it out, the odd behavior returned. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Wednesday, November 07, 2012 4:26 PM To: U2 Users List Subject: [U2] Unidata 6.1.15 Oddity We have a customer who has a system that was rebooted a couple days ago. Since then, and only in one certain subroutine, when doing an MCU conversion on a multivalued list, the ASCII 253 value marks are replaced with ASCII 221. Understanding that the difference between an lower and upper case A is 32 in the ASCII table (97 - 65), it seems like Unidata is treating the delimiters like normal characters. But again, this only happens in certain programs. If I extract the lines of code that exhibit this behavior into its own program, the problem does not occur. Any ideas what might be causing this and only in one subroutine? Both my test program and the real program with the problem are $BASICTYPE U. ___ 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] Unidata 6.1.15 Oddity
Were you doing an OCONVS or just an OCONV? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Friday, November 09, 2012 11:46 AM To: U2 Users List Subject: Re: [U2] Unidata 6.1.15 Oddity Thank you everyone for the feedback. I had some suspicion in the back of my mind that doing an OCONV MCU on a full mv'd string was a Somewhat Bad Idea, now I know why. :-) On Thu, Nov 8, 2012 at 10:56 AM, Woodward, Bob bob_woodw...@k2sports.comwrote: Hi Kevin, Two times in my Unidata career I've had a problem like this where something doesn't work in a subroutine. My work around, both times, was to add a simple line of code at the beginning of the program. Usually just assigning a value to a new, unused, variable like JUNK=JUNK is all it would take. With it, the program would work flawlessly but if I took it back out, or commented it out, the odd behavior returned. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Wednesday, November 07, 2012 4:26 PM To: U2 Users List Subject: [U2] Unidata 6.1.15 Oddity We have a customer who has a system that was rebooted a couple days ago. Since then, and only in one certain subroutine, when doing an MCU conversion on a multivalued list, the ASCII 253 value marks are replaced with ASCII 221. Understanding that the difference between an lower and upper case A is 32 in the ASCII table (97 - 65), it seems like Unidata is treating the delimiters like normal characters. But again, this only happens in certain programs. If I extract the lines of code that exhibit this behavior into its own program, the problem does not occur. Any ideas what might be causing this and only in one subroutine? Both my test program and the real program with the problem are $BASICTYPE U. ___ 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 Dave Davis Team Lead, RD P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]http://www.harriscomputer.com/ 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.comhttp://www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 6.1.15 Oddity
Kevin: Many releases ago on Unidata we noticed that this particular code was not working. The code would work when we had it in another program. The program would fail even when we added CRT statements around the code. So, we moved the offending code to another area of the program and the problem was no longer. It seems there was something in the area of code that was causing the compiler to work correctly. Of course we have not seen any of the problem on the current release of 7.3. Regards, Doug www.u2logic.com On Wed, Nov 7, 2012 at 5:25 PM, Kevin King ke...@precisonline.com wrote: We have a customer who has a system that was rebooted a couple days ago. Since then, and only in one certain subroutine, when doing an MCU conversion on a multivalued list, the ASCII 253 value marks are replaced with ASCII 221. Understanding that the difference between an lower and upper case A is 32 in the ASCII table (97 - 65), it seems like Unidata is treating the delimiters like normal characters. But again, this only happens in certain programs. If I extract the lines of code that exhibit this behavior into its own program, the problem does not occur. Any ideas what might be causing this and only in one subroutine? Both my test program and the real program with the problem are $BASICTYPE U. ___ 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] Unidata 6.1.15 Oddity
FWIW not just @VM. I have standard include code that does a CONVERT CHAR(222) TO @FM after doing MCU conversions on UniData. Since it just gets poked in various places I haven't checked if it is still a problem. BASICTYPE P, but no other UDT.OPTIONs strangely set .. Brian -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Averch Sent: 08 November 2012 15:11 To: U2 Users List Subject: Re: [U2] Unidata 6.1.15 Oddity Kevin: Many releases ago on Unidata we noticed that this particular code was not working. The code would work when we had it in another program. The program would fail even when we added CRT statements around the code. So, we moved the offending code to another area of the program and the problem was no longer. It seems there was something in the area of code that was causing the compiler to work correctly. Of course we have not seen any of the problem on the current release of 7.3. Regards, Doug www.u2logic.com On Wed, Nov 7, 2012 at 5:25 PM, Kevin King ke...@precisonline.com wrote: We have a customer who has a system that was rebooted a couple days ago. Since then, and only in one certain subroutine, when doing an MCU conversion on a multivalued list, the ASCII 253 value marks are replaced with ASCII 221. Understanding that the difference between an lower and upper case A is 32 in the ASCII table (97 - 65), it seems like Unidata is treating the delimiters like normal characters. But again, this only happens in certain programs. If I extract the lines of code that exhibit this behavior into its own program, the problem does not occur. Any ideas what might be causing this and only in one subroutine? Both my test program and the real program with the problem are $BASICTYPE U. ___ 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] Unidata 6.1.15 Oddity
Hi Kevin, Two times in my Unidata career I've had a problem like this where something doesn't work in a subroutine. My work around, both times, was to add a simple line of code at the beginning of the program. Usually just assigning a value to a new, unused, variable like JUNK=JUNK is all it would take. With it, the program would work flawlessly but if I took it back out, or commented it out, the odd behavior returned. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Wednesday, November 07, 2012 4:26 PM To: U2 Users List Subject: [U2] Unidata 6.1.15 Oddity We have a customer who has a system that was rebooted a couple days ago. Since then, and only in one certain subroutine, when doing an MCU conversion on a multivalued list, the ASCII 253 value marks are replaced with ASCII 221. Understanding that the difference between an lower and upper case A is 32 in the ASCII table (97 - 65), it seems like Unidata is treating the delimiters like normal characters. But again, this only happens in certain programs. If I extract the lines of code that exhibit this behavior into its own program, the problem does not occur. Any ideas what might be causing this and only in one subroutine? Both my test program and the real program with the problem are $BASICTYPE U. ___ 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] Unidata 6.1.15 Oddity
We have a customer who has a system that was rebooted a couple days ago. Since then, and only in one certain subroutine, when doing an MCU conversion on a multivalued list, the ASCII 253 value marks are replaced with ASCII 221. Understanding that the difference between an lower and upper case A is 32 in the ASCII table (97 - 65), it seems like Unidata is treating the delimiters like normal characters. But again, this only happens in certain programs. If I extract the lines of code that exhibit this behavior into its own program, the problem does not occur. Any ideas what might be causing this and only in one subroutine? Both my test program and the real program with the problem are $BASICTYPE U. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Unidata 6.1.15 Oddity
Kevin: Many releases ago on Unidata we noticed that this particular code was not working. The code would work when we had it in another program. The program would fail even when we added CRT statements around the code. So, we moved the offending code to another area of the program and the problem was no longer. It seems there was something in the area of code that was causing the compiler to work correctly. Of course we have not seen any of the problem on the current release of 7.3. Regards, Doug www.u2logic.com On Wed, Nov 7, 2012 at 5:25 PM, Kevin King ke...@precisonline.com wrote: We have a customer who has a system that was rebooted a couple days ago. Since then, and only in one certain subroutine, when doing an MCU conversion on a multivalued list, the ASCII 253 value marks are replaced with ASCII 221. Understanding that the difference between an lower and upper case A is 32 in the ASCII table (97 - 65), it seems like Unidata is treating the delimiters like normal characters. But again, this only happens in certain programs. If I extract the lines of code that exhibit this behavior into its own program, the problem does not occur. Any ideas what might be causing this and only in one subroutine? Both my test program and the real program with the problem are $BASICTYPE U. ___ 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] Unidata 6.1.15 Oddity
Kevin: You might try to re-compile the code. Ever since I went to UniData on Windows I have an occasional burp in programs. Last week one of our clients reported an index not working properly. A thorough review showed no problems. We had their IT people in and still were having problems. The index showed: ...removing indexes for ARTMASTER,ARTMASTER file... errno=13: Permission denied Delete index file 'ARTMASTER\X_ARTMASTER' failed There was absolutely no permissions problem! The solution was to simply recompile all code and the problem went away. I've had this /*very*/ occasional problem on every UD installation I've had since I moved to UD six years ago. Today, the first thing I do with clients who complain of weird things happening is to recompile the code. Sometimes two lines of code say WRITE... then WRITE... and the second write doesn't occur. Again, this is a very rare occurrence but it does happen. HTH, Bill - Original Message - *From:* ke...@precisonline.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 11/7/2012 4:25 PM *Subject:* [U2] Unidata 6.1.15 Oddity We have a customer who has a system that was rebooted a couple days ago. Since then, and only in one certain subroutine, when doing an MCU conversion on a multivalued list, the ASCII 253 value marks are replaced with ASCII 221. Understanding that the difference between an lower and upper case A is 32 in the ASCII table (97 - 65), it seems like Unidata is treating the delimiters like normal characters. But again, this only happens in certain programs. If I extract the lines of code that exhibit this behavior into its own program, the problem does not occur. Any ideas what might be causing this and only in one subroutine? Both my test program and the real program with the problem are $BASICTYPE U. ___ 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] Unidata 6.1.15 Oddity
From memory... The difference may depend on the UNIX LANG setting for different users. LANG=C may be required. You don't say what platform you are on. We may also have fixed something since 6.1.15. My memory isn't what it used to be. You can certainly scan the readmes for MCU and/or UPCASE. Wally Terhune Technical Support Engineer 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 Kevin King Sent: Wednesday, November 07, 2012 5:26 PM To: U2 Users List Subject: [U2] Unidata 6.1.15 Oddity We have a customer who has a system that was rebooted a couple days ago. Since then, and only in one certain subroutine, when doing an MCU conversion on a multivalued list, the ASCII 253 value marks are replaced with ASCII 221. Understanding that the difference between an lower and upper case A is 32 in the ASCII table (97 - 65), it seems like Unidata is treating the delimiters like normal characters. But again, this only happens in certain programs. If I extract the lines of code that exhibit this behavior into its own program, the problem does not occur. Any ideas what might be causing this and only in one subroutine? Both my test program and the real program with the problem are $BASICTYPE U. ___ 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] Unidata 6.1.15/AIX/SB+ 5.3: Pegging a CPU
I have a customer using my Download Definition tool for SB+ who is reporting a strange thing (at least to me). When he kicks off a download (which is effectively a tight optimized READNEXT loop extracting data, formatting it, and writing it via WRITESEQ) it pegs a CPU - full on 100%. Maybe I spend too much time under a rock, but I have never seen a single Unidata session peg a CPU on AIX - until now. We've run Unidata profiling to try to get a handle on the issue and nearly 70% of the time (from the profile.elapse) is being invested in the SB.EVAL.EXP subroutine being called from the tool. Of course, I have no access to the source code for SB.EVAL.EXP but I have seen where complex SB+ stacks can definitely impact the performance of the tool. Yet, in looking at the stacks that are being used, all of them in the test case are simple record extractions (i.e. R5 or R18,-1). @RECORD is loaded before the stacks are evaluated so there should be zero I/O being done in SB.EVAL.EXP and even if there was I/O, how could this one subroutine peg a CPU? -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
RE: [U2] UniData 6.1.15
Bob; In 6 you need MV and in 7 you need the name of a linking dictionary for reporting to work properly on a multi-valued field. The linking dictionary needs to be set up like: PLINE_LINK 001: PH 002: PLINE PROD-SUB PROD-COST All the dicts in 2 need to have PLINE_LINK in 7. That should get everything printing properly again. Hth Colin Alfke Calgary Canada -Original Message- From: Bob Wyatt Doing a sort from ECL/TCL, ECL Type P Have a field that is a straight D-type dictionary item, multi-valued PLINE 001: D 002: 6 003: 004: 005: 6R 006: 007: 008: VARCHAR2 009: 010: A!6!!!L!6 011: 012: }} Value Type (6) is blank on purpose for this email If I do SORT FILE WITH 26 OR WITH NO MATCH BY TYPE BY 26 BY L BY-EXP PLINE BY INV_n_ ID-SUPP BREAK-ON TYPE 'P' BREAK-ON 26 BREAK-ON L INV-DATE CUST CUST-NAME ORDER-NBR WHSE BREAK-ON PLINE TOTAL PROD-SUB TOTAL PROD-COST GRAND-TOTAL TOTALS FOR MY LITTLE SHOP CO., INC. HEADING 'C'MY LITTLE SHOP CO., INC. 'LC'NOT-SO-LITTLE MONTH-END REPORT AS OF 'D' 'L'PAGE 'PL' --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData 6.1.15
Thank you Colin for these suggestions... They certainly work better than either of the samples I sent in the request, and therefore may become a suitable work-around... I do note, though, that it repeats information that I typically hadn't seen before, such as: A 11/17/2006 123456 SOME COMPANY NA 432529VAL 04 134.90 101.17 A 11/17/2006 123456 SOME COMPANY NA 432529VAL 04 24.44 18.32 A 11/17/2006 123456 SOME COMPANY NA 432529VAL 04 37.64 28.22 A 11/17/2006 123456 SOME COMPANY NA 432529VAL 04 12.22 9.16 ** -- -- 04 209.20 156.87 In previous reports, everything prior to VAL in the example is only printed on the first line (for the first value), not for each multi-value... Am I missing something else? Thanks again! Bob Wyatt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 22, 2007 08:53 To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData 6.1.15 Bob; In 6 you need MV and in 7 you need the name of a linking dictionary for reporting to work properly on a multi-valued field. The linking dictionary needs to be set up like: PLINE_LINK 001: PH 002: PLINE PROD-SUB PROD-COST All the dicts in 2 need to have PLINE_LINK in 7. That should get everything printing properly again. Hth Colin Alfke Calgary Canada --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] UniData 6.1.15
Doing a sort from ECL/TCL, ECL Type P Have a field that is a straight D-type dictionary item, multi-valued PLINE 001: D 002: 6 003: 004: 005: 6R 006: 007: 008: VARCHAR2 009: 010: A!6!!!L!6 011: 012: }} Value Type (6) is blank on purpose for this email If I do SORT FILE WITH 26 OR WITH NO MATCH BY TYPE BY 26 BY L BY-EXP PLINE BY INV_n_ ID-SUPP BREAK-ON TYPE 'P' BREAK-ON 26 BREAK-ON L INV-DATE CUST CUST-NAME ORDER-NBR WHSE BREAK-ON PLINE TOTAL PROD-SUB TOTAL PROD-COST GRAND-TOTAL TOTALS FOR MY LITTLE SHOP CO., INC. HEADING 'C'MY LITTLE SHOP CO., INC. 'LC'NOT-SO-LITTLE MONTH-END REPORT AS OF 'D' 'L'PAGE 'PL' A 11/17/2006 123456 SOME COMPANY NA 432529VAL 04 134.90 101.17 04 24.44 18.32 04 37.64 28.22 04 12.22 9.16 ** -- -- 04 209.20 156.87 04 04 04 If I change the dictionary item field 6 to M, then the report changes to: A 11/17/2006 123456 SOME COMPANY NA 432529VAL 04 134.90 101.17 24.44 18.32 37.64 28.22 12.22 9.16 A 11/17/2006 123456 SOME COMPANY NA 432529VAL 04 134.90 101.17 24.44 18.32 37.64 28.22 12.22 9.16 A 11/17/2006 123456 SOME COMPANY NA 432529VAL 04 134.90 101.17 24.44 18.32 37.64 28.22 12.22 9.16 A 11/17/2006 123456 SOME COMPANY NA 432529VAL 04 134.90 101.17 24.44 18.32 37.64 28.22 12.22 9.16 ** -- -- 04 836.80 627.48 The total from the first display is correct, although the display is incorrect by repeating the 04 3 more times after the total In the second, it reports the same company 4 times, and each time entails all 4 multivalues I should mention this was working, and I/we have no idea what changed to break it What simple thing have I missed Bob Wyatt --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
