RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly
According to the UniData documentation (UniData UniBasic Commands Reference (BASR.pdf), Appendix B), @SYSTEM.RETURN.CODE is supposed to be the number of items in the select list. This is for all the various SELECT commands, (SELECT, SSELECT, NSELECT, QSELECT), not just BSELECT. Using the example below, @SYSTEM.RETURN.CODE should be 60, just like SYSTEM(11). It should not be 20, which is the number of records scanned/queried. If other selects worked that way, then @SYSTEM.RETURN code for any SELECT would return the number or records in the file, or the number of items in an active list before the command was executed. For example, if there were 100 Customers, 20 of which were in Ohio, the SELECT CUSTOMER WITH STATE = OH would select 20 records with @SYSTEM.RETURN.CODE = 100 and SYSTEM(11) = 20. [re: OFF TOPIC ASIDE] That is our typical structure also, but there are times where we do multiple selects and that is where BSELECT bit us. Something like this: EXECUTE \BSELECT PO.HEADER WITH DATE EQ 6/27 DIRECT.INVOICES\ IF @SYSTEM.RETURN.CODE GT 0 THEN EXECUTE \BSELECT AP.TO.PO.XREF WITH VENDOR EQ 12345 PURCH.AGENT\ If there were PO.HEADER records that met the selection criterion but DIRECT.INVOICES were null for all, there would be no active list after the first BSELECT. Unfortunately, @SYSTEM.RETURN.CODE will not be 0, so the second BSELECT will execute but act against the whole file instead of a limited list, which is not the intended action. [/re: OFF TOPIC ASIDE] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 9:52 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly Dean Armbruster wrote on 26 Jun 2007 16:14:21 -0400 ... This is about BSELECT ... @SYSTEM.RETURN.CODE is not supposed to be the number of *records* selected. It is supposed to be the number of items in the select list. I would suggest that, in this case, the documentation is incorrect (or at least unclear), not the return code. Why? Because BSELECT allows you to select more than one attribute. From the help: Unlike the SELECT command, which retrieves only record IDs, BSELECT builds a list of the attributes you name in the UniQuery statement. Typically, this command is used to get record ID's stored in one file (e.g., BSELECT ORDER.HEADER LINE.KEY), but it can also be used to get a SET of fields. For example, BSELECT CUSTOMER WITH STATE = OH NAME PHONE FAX In this case, I would get a list with (typically) three entries for each of my Customers in Ohio: Name, Phone and Fax, in repeating order. If I have 20 customers in Ohio would expect @SYSTEM.RETURN.CODE to return 20 (the number of items/records selected), and I would expect SYSTEM(11) would have the total number of items in my list (i.e., 60). However, if any of the fields were multi-valued, I would get ALL of those values in my list, just as if I had used a BY-EXP in a sort. Watch out! @SYSTEM.RETURN.CODE for BSELECT is not what the documentation says it is. Your list may not have the number of entries indicated. Your list may even be empty even though @SYSTEM.RETURN.CODE is greater than zero. Can you support this last statement? In every test I ran, @SYSTEM.RETURN.CODE was the number of records selected, and @SYSTEM(11) was the total number of items. Of course, I tend to BSELECT FILE WITH ATTR ATTR... --Tom Pellitieri Century Equipment [OFF TOPIC ASIDE] For what it's worth, I was taught to check SYSTEM(11) for the number of items returned by an EXECUTE statement, although typically I don't check it at all. My usual processing loop uses: CTR = 0 EXECUTE \SELECT ...\ LOOP WHILE READNEXT ID DO CTR += 1 ... REPEAT So CTR has my processed count, and if there isn't anything to process, the loop exits immediately. [/OFF TOPIC ASIDE] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly
Dean Armbruster wrote on 26 Jun 2007 16:14:21 -0400 ... This is about BSELECT ... @SYSTEM.RETURN.CODE is not supposed to be the number of *records* selected. It is supposed to be the number of items in the select list. I would suggest that, in this case, the documentation is incorrect (or at least unclear), not the return code. Why? Because BSELECT allows you to select more than one attribute. From the help: Unlike the SELECT command, which retrieves only record IDs, BSELECT builds a list of the attributes you name in the UniQuery statement. Typically, this command is used to get record ID's stored in one file (e.g., BSELECT ORDER.HEADER LINE.KEY), but it can also be used to get a SET of fields. For example, BSELECT CUSTOMER WITH STATE = OH NAME PHONE FAX In this case, I would get a list with (typically) three entries for each of my Customers in Ohio: Name, Phone and Fax, in repeating order. If I have 20 customers in Ohio would expect @SYSTEM.RETURN.CODE to return 20 (the number of items/records selected), and I would expect SYSTEM(11) would have the total number of items in my list (i.e., 60). However, if any of the fields were multi-valued, I would get ALL of those values in my list, just as if I had used a BY-EXP in a sort. Watch out! @SYSTEM.RETURN.CODE for BSELECT is not what the documentation says it is. Your list may not have the number of entries indicated. Your list may even be empty even though @SYSTEM.RETURN.CODE is greater than zero. Can you support this last statement? In every test I ran, @SYSTEM.RETURN.CODE was the number of records selected, and @SYSTEM(11) was the total number of items. Of course, I tend to BSELECT FILE WITH ATTR ATTR... --Tom Pellitieri Century Equipment [OFF TOPIC ASIDE] For what it's worth, I was taught to check SYSTEM(11) for the number of items returned by an EXECUTE statement, although typically I don't check it at all. My usual processing loop uses: CTR = 0 EXECUTE \SELECT ...\ LOOP WHILE READNEXT ID DO CTR += 1 ... REPEAT So CTR has my processed count, and if there isn't anything to process, the loop exits immediately. [/OFF TOPIC ASIDE] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly
Does the same thing happen when you use SELECT filename SAVING [UNIQUE] field NO.NULLS? I'm not on Unidata so I can't try it. Universe doesn't have the BSELECT command. @SYSTEM.RETURN.CODE only returns 0 on a select so we use @SELECTED which does return the full amount in the select list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 4:20 PM To: u2-users@listserver.u2ug.org Subject: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly My apologies for the poor job I did posting this. I sent it before I had completed the subscribe procedures. I blame it on my vacation. :-) Because of my mistake, I didn't get the replies. I had to get them from the list archive. Here are my replies to the replies: To Dave Davis, who said, If you were curious about the number of customers queried couldn't you just do a SELECT CUSTOMER first? I agree. Or, if you had done a previous select to whittle down the list, you'd already know how many records would be queried for the BSELECT. To David A. Green, who said, SYSTEM(11) returns number of items in the active select list. I think we should leave the @SYSTEM.RETURN.CODE as the number of records selected. @SYSTEM.RETURN.CODE is NOT the number of records selected. That is the problem. It is the number of records queried/polled, not the number of items returned in the select list. Those numbers will not be the same for a multivalued attribute or if the attribute is null and UDT.OPTION 59 is ON. Try this and see if you feel the same way about @SYSTEM.RETURN.CODE: EXECUTE 'UDT.OPTIONS 59 ON' CMD1 = 'BSELECT CUSTOMER WITH @ID GE 200 TAPES_RENTED' CRT CMD1 EXECUTE CMD1 IF @SYSTEM.RETURN.CODE GT 0 THEN CMD2 = 'DELETE TAPES' CRT ; CRT CMD2 EXECUTE CMD2 END SYSTEM(11) is our workaround. But it is a pain because: A) It is non-standard, i.e. not necessary for other SELECTs. B) It is not what the documentation says. BASR.pdf states that @SYSTEM.RETURN.CODE will contain the number of items in the select list. C) If the program reports errors, it must first check @SYSTEM.RETURN.CODE, and if okay then check SYSTEM(11). -Original Message- From: Moderator [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 6:15 PM To: u2-users@listserver.u2ug.org; Dean Armbruster - 0018 HQ Subject: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly REPOSTED FOR NON-MEMBER ADDRESS: [EMAIL PROTECTED] I'd looking for feedback on @SYSTEM.RETURN.CODE as returned from BSELECT of a multivalue attribute. Run the following basic code in the UniData demo account: CMD = 'BSELECT CUSTOMER TAPES_RENTED' CRT CMD EXECUTE CMD CRT '@SYSTEM.RETURN.CODE = ':@SYSTEM.RETURN.CODE CLEARSELECT When I run it, I get: BSELECT CUSTOMER TAPES_RENTED 36 records selected to list 0. @SYSTEM.RETURN.CODE = 29 Note that 29 is the number of records in CUSTOMER; 36 is then number of items in the returned active select list. The questions: Is there any way a program could depend on @SYSTEM.RETURN.CODE being incorrect some of the time? Would anyone want @SYSTEM.RETURN.CODE to be the number records polled and not number of items in the returned list, even if the number of items returned is 0? IBM case #423086*USA UniData 6.1.18 HP-UX 11.11 ECLTYPE P UDT.OPTIONS 59 ON Dean Armbruster System Analyst Wolseley North American Division * 12500 Jefferson Avenue * Newport News * VA * 23602-4314 T: +1(757) 989-2839 * F: +1(757)989-2801 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly
What are you trying to say here? You don't make sense (sorry). Not knowing UD, I have to be careful here, but if I'm selecting BY.EXP a multi-value field, I would NOT expect the number of records selected to be the same as the number of items in the select list. I'm getting the impression that @SYSTEM.RETURN.CODE *IS* the number of records selected. Thing is, you're asking it to count records multiple times if the same record appears multiple times in the select list. Let's say we have 10 records, half of them with two items in an MV field, and the rest with just one. Am I correct in thinking that, if you do a SELECT BY.EXP, the @SYSTEM.RETURN.CODE is 10, the number of *records* selected, while SYSTEM(11) is 15, the number of *items* in the select list? Hope this clarifies things :-) Cheers, Wol -Original Message- From: Jerry Banker [mailto:[EMAIL PROTECTED] Sent: 26 June 2007 14:24 To: u2-users@listserver.u2ug.org Subject: RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly To David A. Green, who said, SYSTEM(11) returns number of items in the active select list. I think we should leave the @SYSTEM.RETURN.CODE as the number of records selected. @SYSTEM.RETURN.CODE is NOT the number of records selected. That is the problem. It is the number of records queried/polled, not the number of items returned in the select list. Those numbers will not be the same for a multivalued attribute or if the attribute is null and UDT.OPTION 59 is ON. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly
SELECT with the SAVING keyword, with or without NO.NULLS, returned the correct value in @SYSTEM.RETURN.CODE, in my tests. I don't know or have Universe, so I could be wrong, but it appears you have an implied BSELECT, as demonstrated with the SAVING keyword. A BSELECT is, as quoted from the UniData UniQuery doc: BSELECT filename ['record_IDs'][selection_criteria] attribute [attribute...] The UniQuery BSELECT command retrieves data from a file into an active select list. Unlike the SELECT command, which retrieves only record IDs, BSELECT builds a list of the attributes you name in the UniQuery statement. You must name at least one attribute in the statement. In UniData, you can also do an implied BSELECT by following the same syntax as BSELECT in a SELECT command. UniData does not have @SELECTED. @SYSTEM.RETURN.CODE is normally an error code (if negative) or the number of items in the select list (if non-negative) for any executed UniQuery commands dealing with select lists. It is misbehaving for BSELECT. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Banker Sent: Tuesday, June 26, 2007 9:24 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly Does the same thing happen when you use SELECT filename SAVING [UNIQUE] field NO.NULLS? I'm not on Unidata so I can't try it. Universe doesn't have the BSELECT command. @SYSTEM.RETURN.CODE only returns 0 on a select so we use @SELECTED which does return the full amount in the select list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 4:20 PM To: u2-users@listserver.u2ug.org Subject: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly My apologies for the poor job I did posting this. I sent it before I had completed the subscribe procedures. I blame it on my vacation. :-) Because of my mistake, I didn't get the replies. I had to get them from the list archive. Here are my replies to the replies: To Dave Davis, who said, If you were curious about the number of customers queried couldn't you just do a SELECT CUSTOMER first? I agree. Or, if you had done a previous select to whittle down the list, you'd already know how many records would be queried for the BSELECT. To David A. Green, who said, SYSTEM(11) returns number of items in the active select list. I think we should leave the @SYSTEM.RETURN.CODE as the number of records selected. @SYSTEM.RETURN.CODE is NOT the number of records selected. That is the problem. It is the number of records queried/polled, not the number of items returned in the select list. Those numbers will not be the same for a multivalued attribute or if the attribute is null and UDT.OPTION 59 is ON. Try this and see if you feel the same way about @SYSTEM.RETURN.CODE: EXECUTE 'UDT.OPTIONS 59 ON' CMD1 = 'BSELECT CUSTOMER WITH @ID GE 200 TAPES_RENTED' CRT CMD1 EXECUTE CMD1 IF @SYSTEM.RETURN.CODE GT 0 THEN CMD2 = 'DELETE TAPES' CRT ; CRT CMD2 EXECUTE CMD2 END SYSTEM(11) is our workaround. But it is a pain because: A) It is non-standard, i.e. not necessary for other SELECTs. B) It is not what the documentation says. BASR.pdf states that @SYSTEM.RETURN.CODE will contain the number of items in the select list. C) If the program reports errors, it must first check @SYSTEM.RETURN.CODE, and if okay then check SYSTEM(11). --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly
The @SYSTEM.RETURN.CODE you describe is the same as it was on PI which also didn't have an @SELECTED. At least I don't remember one. Of course they didn't have a BSELECT either. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 26, 2007 2:34 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly SELECT with the SAVING keyword, with or without NO.NULLS, returned the correct value in @SYSTEM.RETURN.CODE, in my tests. I don't know or have Universe, so I could be wrong, but it appears you have an implied BSELECT, as demonstrated with the SAVING keyword. A BSELECT is, as quoted from the UniData UniQuery doc: BSELECT filename ['record_IDs'][selection_criteria] attribute [attribute...] The UniQuery BSELECT command retrieves data from a file into an active select list. Unlike the SELECT command, which retrieves only record IDs, BSELECT builds a list of the attributes you name in the UniQuery statement. You must name at least one attribute in the statement. In UniData, you can also do an implied BSELECT by following the same syntax as BSELECT in a SELECT command. UniData does not have @SELECTED. @SYSTEM.RETURN.CODE is normally an error code (if negative) or the number of items in the select list (if non-negative) for any executed UniQuery commands dealing with select lists. It is misbehaving for BSELECT. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Banker Sent: Tuesday, June 26, 2007 9:24 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly Does the same thing happen when you use SELECT filename SAVING [UNIQUE] field NO.NULLS? I'm not on Unidata so I can't try it. Universe doesn't have the BSELECT command. @SYSTEM.RETURN.CODE only returns 0 on a select so we use @SELECTED which does return the full amount in the select list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 4:20 PM To: u2-users@listserver.u2ug.org Subject: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly My apologies for the poor job I did posting this. I sent it before I had completed the subscribe procedures. I blame it on my vacation. :-) Because of my mistake, I didn't get the replies. I had to get them from the list archive. Here are my replies to the replies: To Dave Davis, who said, If you were curious about the number of customers queried couldn't you just do a SELECT CUSTOMER first? I agree. Or, if you had done a previous select to whittle down the list, you'd already know how many records would be queried for the BSELECT. To David A. Green, who said, SYSTEM(11) returns number of items in the active select list. I think we should leave the @SYSTEM.RETURN.CODE as the number of records selected. @SYSTEM.RETURN.CODE is NOT the number of records selected. That is the problem. It is the number of records queried/polled, not the number of items returned in the select list. Those numbers will not be the same for a multivalued attribute or if the attribute is null and UDT.OPTION 59 is ON. Try this and see if you feel the same way about @SYSTEM.RETURN.CODE: EXECUTE 'UDT.OPTIONS 59 ON' CMD1 = 'BSELECT CUSTOMER WITH @ID GE 200 TAPES_RENTED' CRT CMD1 EXECUTE CMD1 IF @SYSTEM.RETURN.CODE GT 0 THEN CMD2 = 'DELETE TAPES' CRT ; CRT CMD2 EXECUTE CMD2 END SYSTEM(11) is our workaround. But it is a pain because: A) It is non-standard, i.e. not necessary for other SELECTs. B) It is not what the documentation says. BASR.pdf states that @SYSTEM.RETURN.CODE will contain the number of items in the select list. C) If the program reports errors, it must first check @SYSTEM.RETURN.CODE, and if okay then check SYSTEM(11). --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly
BY.EXP does not factor in. This is about BSELECT, regardless of BY.EXP use. @SYSTEM.RETURN.CODE is not supposed to be the number of *records* selected. It is supposed to be the number of items in the select list. From the UniData UniBasic Commands Reference (BASR.pdf), Appendix B: ECL @SYSTEM.RETURN.CODE Values The following table describes the possible @SYSTEM.RETURN.CODE values for various ECL commands. Command Success Return Value - - BSELECT The number of items in the select list. What I'm saying: Watch out! @SYSTEM.RETURN.CODE for BSELECT is not what the documentation says it is. Your list may not have the number of entries indicated. Your list may even be empty even though @SYSTEM.RETURN.CODE is greater than zero. IBM is reluctant to change this behavior for fear that some application somewhere may be relying on @SYSTEM.RETURN.CODE being incorrect. How an application can rely on something that is never always correct nor always incorrect is beyond me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Youngman Sent: Tuesday, June 26, 2007 10:12 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly What are you trying to say here? You don't make sense (sorry). Not knowing UD, I have to be careful here, but if I'm selecting BY.EXP a multi-value field, I would NOT expect the number of records selected to be the same as the number of items in the select list. I'm getting the impression that @SYSTEM.RETURN.CODE *IS* the number of records selected. Thing is, you're asking it to count records multiple times if the same record appears multiple times in the select list. Let's say we have 10 records, half of them with two items in an MV field, and the rest with just one. Am I correct in thinking that, if you do a SELECT BY.EXP, the @SYSTEM.RETURN.CODE is 10, the number of *records* selected, while SYSTEM(11) is 15, the number of *items* in the select list? Hope this clarifies things :-) Cheers, Wol -Original Message- From: Jerry Banker [mailto:[EMAIL PROTECTED] Sent: 26 June 2007 14:24 To: u2-users@listserver.u2ug.org Subject: RE: [U2] RE: [UD] BSELECT @SYSTEM.RETURN.CODE anomaly To David A. Green, who said, SYSTEM(11) returns number of items in the active select list. I think we should leave the @SYSTEM.RETURN.CODE as the number of records selected. @SYSTEM.RETURN.CODE is NOT the number of records selected. That is the problem. It is the number of records queried/polled, not the number of items returned in the select list. Those numbers will not be the same for a multivalued attribute or if the attribute is null and UDT.OPTION 59 is ON. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
