Re: [U2] too many values in sort
You can try saving your list of keys you want to sort and use Unix's sort program on that savedlist. Use the port number on your saved list to make sure it is unique. - Original Message From: Kevin King precisonl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, October 25, 2010 11:54:25 AM Subject: [U2] too many values in sort Unidata 6.1.15 on AIX. The following command: SSELECT SHOPPING.LIST BY.EXP PROD.NUM Yields the message too many values in sort. There is one record in this file with 36,457 product numbers but would that break the BY.EXP? If so, is there a config parameter somewhere that could be tweaked to make this work? -Kevin http://www.PrecisOnline.com ___ 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] too many values in sort
AFAIK SSELECT BY.EXP returns a select list with the record ID and the position in the multivalued attribute. At least on ADDS Mentor it did. I didn't use it for decades because I haven't had any need for such a list, and I haven't tried it on UD yet. So I don't think anything short of a Basic program will be able to solve your problem if there is a restriction on number of values in any one record. Try some smaller records, save the list and have a look at the data. Then you could run a program to generate the same array and write it to the SAVEDLIST file. Ugly but it might actually do the job. Mecki On 26/10/2010 12:22, Jacques G. wrote: You can try saving your list of keys you want to sort and use Unix's sort program on that savedlist. Use the port number on your saved list to make sure it is unique. - Original Message From: Kevin King precisonl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, October 25, 2010 11:54:25 AM Subject: [U2] too many values in sort Unidata 6.1.15 on AIX. The following command: SSELECT SHOPPING.LIST BY.EXP PROD.NUM Yields the message too many values in sort. There is one record in this file with 36,457 product numbers but would that break the BY.EXP? If so, is there a config parameter somewhere that could be tweaked to make this work? -Kevin http://www.PrecisOnline.com ___ 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] Building XML using the UV XDOM API functions
I'll have to disagree with you on this one Tony. As a vendor yourself you would of course think this way. As an end user of the product we would like it all to come from one source. This is the reason that Microsoft has got such a jump on everyone else, they will provide you with all of the tools as well as the database. I'm talking about the harsh reality of things, at one time if you went IBM you went all the way, now it's Microsoft. Companies don't want to deal with several vendors they want one. Jerry Banker -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Monday, October 25, 2010 11:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Building XML using the UV XDOM API functions Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. 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] Building XML using the UV XDOM API functions
Let's be careful we're lobbing grenades at the right enemy. As I see things the conflict here isn't choosing vendor supplied solutions vs. open source, the problem is the vendor doing a poor job of making something that is usable and truly useful. There is a time and place for both vendor supplied and open source solutions. As Jerry has stated some customers prefer to have one vendor for everything. For other customers, having one vendor for everything is a level of captive dependence they would rather avoid. One size certainly does not fit all. But all that aside, vendors need to put more attention into their products to make them useful and usable rather than simply another tick on a marketing checklist. Having XML support or whatever doesn't mean jack squat if it's so convoluted and unstable and poorly documented so as to be about worthless without heroics. This is where vendors could learn a great deal from the open source movement; open source technologies, though having no clear vendor or support often do a much better job of making things that are useful, usable, AND understandable. Once vendors return to a commitment to excellence over a commitment to marketing things may change. Until then, as solution providers the best we can do is keep all of our options open and when there are no options, to create new ones. -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
On 10/26/2010 1:46 PM, Kevin King wrote: But all that aside, vendors need to put more attention into their products to make them useful and usable rather than simply another tick on a marketing checklist. This conversation is reminding me of a recent blog post I read. http://blog.garlicsim.org/post/1388741380/thinking-of-your-software-as-a-butler-is-difficult-but ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] PC setup for to use ODBC
A question for those who have done it- I want to set up ODBC access on user PCs to Universe files for several of my users. The Universe side is all set up. This, of course, requires the ODBC driver be installed on the user's PC when creating the ODBC data source. I have this driver on my personal PC from some time ago, gotten from the very large IBM download that includes UniDK, UniAdmin, and much more. Of course that download from IBM is no longer available. Anybody have simple steps to get the needed driver all loaded on a PC so that the Universe driver is available for setup? I know - this is the lowest form of communication to the Universe files, but I want to give users the option. It's a perception thing mostly, if they see ODBC they think good things. Thanks- Harold D. Oaks Sr. Analyst/Programmer Office of the Budget and Information Systems Clark County, Washington ph: (360) 397-6121 x4132 fax: (360) 397-2342 This e-mail and related attachments and any response may be subject to public disclosure under state law. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
Brilliant article! Thanks for sharing. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] PC setup for to use ODBC
We currently have it set up. But there some things you watch out for like file names and dictionary entries with embedded periods. Email me offline at wgbuffing...@hydro.mb.ca and I'll send you our documentation for the setup. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Oaks, Harold Sent: Tuesday, October 26, 2010 1:22 PM To: U2 Users List Subject: [U2] PC setup for to use ODBC A question for those who have done it- I want to set up ODBC access on user PCs to Universe files for several of my users. The Universe side is all set up. This, of course, requires the ODBC driver be installed on the user's PC when creating the ODBC data source. I have this driver on my personal PC from some time ago, gotten from the very large IBM download that includes UniDK, UniAdmin, and much more. Of course that download from IBM is no longer available. Anybody have simple steps to get the needed driver all loaded on a PC so that the Universe driver is available for setup? I know - this is the lowest form of communication to the Universe files, but I want to give users the option. It's a perception thing mostly, if they see ODBC they think good things. Thanks- Harold D. Oaks Sr. Analyst/Programmer Office of the Budget and Information Systems Clark County, Washington ph: (360) 397-6121 x4132 fax: (360) 397-2342 This e-mail and related attachments and any response may be subject to public disclosure under state law. ___ 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] Building XML using the UV XDOM API functions
Right Jerry! As a VAR I have to support XDOM API. It took me hours to figure out how to do it. Because the API was poorly documented and any examples I found made no sense at all. When I got my code running the client could not use it because the version of Universe did not work with XDOM even though it was released with it. The key is tools. How many are still using AE or ED? How many think they are real productive using Notepad, EditPlus, AccuTerm's Editor, VI, wIntegrate's Editor, or whatever? The answer is most of you are using tools from the 80's and have no idea how productive you can be with new tools. I've been selling the equivalent of Visual Studio for U2 that runs on the Eclipse platform. I don't have to FTP and code from server to workstation. I can compile and format code with a click of a button. I can see subroutine code and includes just by hitting a single button. I have built an Universe and Unidata Editor, Dictionary Editor, Resize tool, Web Developer, Object Editor, U2 program and data installer, and ability to synchronize with version control. Our team built this wonderful Windows Explorer equivalent to copy files from account to account that saves me hours and hours when I have to have data to do testing on my machine or the client's test account. Maybe it is the Not Invented Here syndrome. See http://u2logic.blogspot.com/. Regards, Doug www.u2logic.com/tools.html -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jpb-u2ug Sent: Tuesday, October 26, 2010 10:48 AM To: 'U2 Users List' Subject: Re: [U2] Building XML using the UV XDOM API functions I'll have to disagree with you on this one Tony. As a vendor yourself you would of course think this way. As an end user of the product we would like it all to come from one source. This is the reason that Microsoft has got such a jump on everyone else, they will provide you with all of the tools as well as the database. I'm talking about the harsh reality of things, at one time if you went IBM you went all the way, now it's Microsoft. Companies don't want to deal with several vendors they want one. Jerry Banker ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] INPUTIF statement in Universe
In a message dated 10/26/2010 11:58:58 AM Pacific Daylight Time, eric.rosenzw...@petco.com writes: In testing, it's the INPUTIF statement that's utilizing the CPU, not the timer calculation. Is there a better, less CPU intensive way to do this? Thanks in advance. INPUTIF checks the type-ahead buffer every time slice. You're getting so many slices that your CPU is consumed with this one task of checking the type-ahead buffer. It's frenetic, a CPU on crystal meth. In the old days, we would say Release Timeslices RQM. Today you can solve that issue as well, by adding a Sleep for a 1 second. On systems that allow sleeping for periods less than a second, you only really need to add a sleep for a tenth of a second, to see your CPU suddenly quiesce. Will Johnson ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] INPUTIF statement in Universe
Hi Eric, We get around this by using an optimistic locking strategy if and only if there must be user input between the original record read and final record write. Depending on the usage of your system, this might prove to be a better solution? Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Eric Rosenzweig Sent: Wednesday, 27 October 2010 5:58 AM To: U2 Users List Subject: [U2] INPUTIF statement in Universe We are on an IBM AIX 5.3 box with 32 CPU and 32GB of memory running Universe 10.2.4 As we've increased our user count I'm noticing several applications that use the INPUTIF statement coming to the top of CPU usage. We have users that go into a product record, lock it, and then leave their desk or go onto something else leaving the lock and therefore keeping other people out of updating that record. We use the INPUTIF with a timer loop to gracefully exit the program and release the record if there hasn't been activity in 10 minutes. In testing, it's the INPUTIF statement that's utilizing the CPU, not the timer calculation. Is there a better, less CPU intensive way to do this? Thanks in advance. Here's the code we currently employ: OK = 0 ; START.DT = DATE() ; START.TM = TIME(); TIME.OUT = 900 LOOP INPUTIF PSN THEN OK = @TRUE ELSE OK = ((DATE()-START.DT)*86400)+TIME()-START.TM TIME.OUT IF OK THEN IF EDIT.FLG THEN PSN = '' ELSE PSN = 'Q' END END UNTIL OK DO REPEAT Eric Rosenzweig eri...@petco.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ### The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files with the permission of IMB. ### ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] INPUTIF statement in Universe {Unclassified}
I.E., add the line with NAP in it. You may want to try different NAP intervals to work out the best balance between snappy user response and CPU usage. OK = 0 ; START.DT = DATE() ; START.TM = TIME(); TIME.OUT = 900 LOOP INPUTIF PSN THEN OK = @TRUE ELSE NAP 100 ; Doze 100 milliseconds = 1/10 sec OK = ((DATE()-START.DT)*86400)+TIME()-START.TM TIME.OUT IF OK THEN IF EDIT.FLG THEN PSN = '' ELSE PSN = 'Q' END END UNTIL OK DO REPEAT __ -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of fft2...@aol.com Sent: Wednesday, 27 October 2010 10:14 a.m. To: u2-users@listserver.u2ug.org Subject: Re: [U2] INPUTIF statement in Universe In a message dated 10/26/2010 11:58:58 AM Pacific Daylight Time, eric.rosenzw...@petco.com writes: In testing, it's the INPUTIF statement that's utilizing the CPU, not the timer calculation. Is there a better, less CPU intensive way to do this? Thanks in advance. INPUTIF checks the type-ahead buffer every time slice. You're getting so many slices that your CPU is consumed with this one task of checking the type-ahead buffer. It's frenetic, a CPU on crystal meth. In the old days, we would say Release Timeslices RQM. Today you can solve that issue as well, by adding a Sleep for a 1 second. On systems that allow sleeping for periods less than a second, you only really need to add a sleep for a tenth of a second, to see your CPU suddenly quiesce. Will Johnson ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] INPUTIF statement in Universe {Unclassified}
Experienced a similar thing a while back and decided to use NAP as well. Even
went as far as changing the NAP depending on how long the period of inactivity
has been.
Sample code:
LASTTIME = TIME()
FOUND.CMD = @FALSE
LOOP
UNTIL FOUND.CMD DO
ELAPSED = TIME() - LASTTIME
GOSUB SET.NAP.TIME
IF TIME() - LASTTIME GT QUIT.TIME THEN STOP (or exit or whatever is
best for you)
INPUTIF TCL.CMD THEN FOUND.CMD = @TRUE ELSE NAP NAPTIME
REPEAT
*
SET.NAP.TIME:
*
* Minimise looping by NAPing before doing the next INPUTIF check.
* Set NAP time as an increasing amount depending on the period of
* inactivity
BEGIN CASE
CASE ELAPSED LT 60
NAPTIME = 100 ; * Up to 1 min, pause for 0.1 seconds
CASE ELAPSED LT 300
NAPTIME = 200 ; * Up to 5 mins, pause for 0.2 seconds
CASE ELAPSED LT 600
NAPTIME = 500 ; * Up to 10 mins, pause for 0.5 seconds
CASE ELAPSED LT 900
NAPTIME = 1000 ; * Up to 15 mins, pause for 1 second
CASE 1
NAPTIME = 2000 ; * More than 15 mins, pause for 2 seconds
END CASE
RETURN
Brendon
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of HENDERSON MIKE, MR
Sent: Wednesday, 27 October 2010 8:31 AM
To: U2 Users List
Subject: Re: [U2] INPUTIF statement in Universe {Unclassified}
I.E., add the line with NAP in it.
You may want to try different NAP intervals to work out the best balance
between snappy user response and CPU usage.
OK = 0 ; START.DT = DATE() ; START.TM = TIME(); TIME.OUT = 900 LOOP
INPUTIF PSN THEN OK = @TRUE ELSE
NAP 100 ; Doze 100 milliseconds = 1/10 sec
OK = ((DATE()-START.DT)*86400)+TIME()-START.TM TIME.OUT
IF OK THEN
IF EDIT.FLG THEN PSN = '' ELSE PSN = 'Q'
END
END
UNTIL OK DO
REPEAT
__
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of fft2...@aol.com
Sent: Wednesday, 27 October 2010 10:14 a.m.
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] INPUTIF statement in Universe
In a message dated 10/26/2010 11:58:58 AM Pacific Daylight Time,
eric.rosenzw...@petco.com writes:
In testing, it's the INPUTIF statement that's utilizing the CPU, not
the
timer calculation.
Is there a better, less CPU intensive way to do this?
Thanks in advance.
INPUTIF checks the type-ahead buffer every time slice. You're getting
so
many slices that your CPU is consumed with this one task of checking the
type-ahead buffer. It's frenetic, a CPU on crystal meth.
In the old days, we would say Release Timeslices RQM. Today you can
solve
that issue as well, by adding a Sleep for a 1 second. On systems that
allow
sleeping for periods less than a second, you only really need to add a
sleep for a tenth of a second, to see your CPU suddenly quiesce.
Will Johnson
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or
distribute this message or the information in it.
If you have received this message in error, please Email or telephone
the sender immediately.
___
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] Building XML using the UV XDOM API functions
I actually like the XML handling built into UV. I have always been a believer in using the intrinsic facilities of the database where possible to maximise the performance of the process being automated. The XDOM API is a good example of this, and is a good fit for our requirements. My biggest issue is with the poor state of the documentation. It does not allow me to easily obtain a good level of competency, which I think is needed to feel like I can be productive with a tool, and to feel that the tool is worth using. Once I got past the documentation and did a lot of testing, and raising cases with Rocket Software (the guys here in Australia should now know their XDOM backwards!), I have a much clearer understanding of what is possible and what the limitations are. Which is why I created the blog and started adding entries for various aspects of the XDOM that were not obvious from the documentation. I just hope it helps others get a handle on the XDOM API a bit quicker than I did. It might also allow others to better evaluate the XDOM API as a valid toolset, rather than discount it out of hand due to FUD, or marketing pressures. Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Tuesday, 26 October 2010 3:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Building XML using the UV XDOM API functions Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. T ___ 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/1AYrw4K3L1/76hLrBplQLdEzGQ20K2ljp/0 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] Building XML using the UV XDOM API functions
Compared to something like lxml it seems rather clumsy and unmaintained. On 10/26/10, Gregor Scott gregor.sc...@pentanasolutions.com wrote: I actually like the XML handling built into UV. I have always been a believer in using the intrinsic facilities of the database where possible to maximise the performance of the process being automated. The XDOM API is a good example of this, and is a good fit for our requirements. My biggest issue is with the poor state of the documentation. It does not allow me to easily obtain a good level of competency, which I think is needed to feel like I can be productive with a tool, and to feel that the tool is worth using. Once I got past the documentation and did a lot of testing, and raising cases with Rocket Software (the guys here in Australia should now know their XDOM backwards!), I have a much clearer understanding of what is possible and what the limitations are. Which is why I created the blog and started adding entries for various aspects of the XDOM that were not obvious from the documentation. I just hope it helps others get a handle on the XDOM API a bit quicker than I did. It might also allow others to better evaluate the XDOM API as a valid toolset, rather than discount it out of hand due to FUD, or marketing pressures. Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Tuesday, 26 October 2010 3:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Building XML using the UV XDOM API functions Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. T ___ 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/1AYrw4K3L1/76hLrBplQLdEzGQ20K2ljp/0 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 -- Sent from my mobile device ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
Hi Gregor Thanks for sharing your useful experiences and your blog. I found the same issue with U2 MQSeries API documentation too. Although, I guess when you are using such complex API's - it helps first to understand the underlying technology and concepts. Be it MQSeries or XML, etc. Otherwise, it is a case of learning or mis-learning two things at once. I find nearly all documentation from vendors have issues. Be they specialists in a particular field of a jack-of-trades multi-national software corporation. :) Your mileage will varyas it vary in respect with your own competency and the fact one size can never fit all skills/knowledge (etc)...be it tools or documentation or vendors or consultants! ;-) I do see value in investing some time/effort in the potential value that third-party tools and consultants can provide. Should budget, time and capabilities dictate such a requirement. Alas, we rarely have enough the later attributes... Cheers, David -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Wednesday, 27 October 2010 10:30 AM To: U2 Users List Subject: Re: [U2] Building XML using the UV XDOM API functions I actually like the XML handling built into UV. I have always been a believer in using the intrinsic facilities of the database where possible to maximise the performance of the process being automated. The XDOM API is a good example of this, and is a good fit for our requirements. My biggest issue is with the poor state of the documentation. It does not allow me to easily obtain a good level of competency, which I think is needed to feel like I can be productive with a tool, and to feel that the tool is worth using. Once I got past the documentation and did a lot of testing, and raising cases with Rocket Software (the guys here in Australia should now know their XDOM backwards!), I have a much clearer understanding of what is possible and what the limitations are. Which is why I created the blog and started adding entries for various aspects of the XDOM that were not obvious from the documentation. I just hope it helps others get a handle on the XDOM API a bit quicker than I did. It might also allow others to better evaluate the XDOM API as a valid toolset, rather than discount it out of hand due to FUD, or marketing pressures. Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Tuesday, 26 October 2010 3:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Building XML using the UV XDOM API functions Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. T ** IMPORTANT MESSAGE * This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ** ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
It was definitely 'mapped' into our world. There are steps in the API that logically would never be used 'standalone', but as the underlying process broke the functions out as the underlying API did -- for example -- the PrepareXML must be followed by OpenXML -- why show that to us developers?!? We should have received a PrepareAndOpen function call instead. I mean, I will never do a PrepareXML that is not immediately followed by an OpenXML. It was a literal implementation of the underlying requirements without any thought to the 'target user'. Anyway, that kind of design ugliness was what said 'checkbox item' over 'well thought out' or 'implemented for real users' to me. I voiced this the first time I went through the process -- my point was that all parts of the systems handles that kind of 'allocation of memory' without it having to be explicitly executed. The XML add-on is the most C like stuff ever presented to us to use in BASIC! g So I'm in the camp that I like that it is built in to UniData, but it really was a cheesy (and maybe even inconsiderate) job on the design and implementation That was my take anyway! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Tuesday, October 26, 2010 6:36 PM To: U2 Users List Subject: Re: [U2] Building XML using the UV XDOM API functions Compared to something like lxml it seems rather clumsy and unmaintained. On 10/26/10, Gregor Scott gregor.sc...@pentanasolutions.com wrote: I actually like the XML handling built into UV. I have always been a believer in using the intrinsic facilities of the database where possible to maximise the performance of the process being automated. The XDOM API is a good example of this, and is a good fit for our requirements. My biggest issue is with the poor state of the documentation. It does not allow me to easily obtain a good level of competency, which I think is needed to feel like I can be productive with a tool, and to feel that the tool is worth using. Once I got past the documentation and did a lot of testing, and raising cases with Rocket Software (the guys here in Australia should now know their XDOM backwards!), I have a much clearer understanding of what is possible and what the limitations are. Which is why I created the blog and started adding entries for various aspects of the XDOM that were not obvious from the documentation. I just hope it helps others get a handle on the XDOM API a bit quicker than I did. It might also allow others to better evaluate the XDOM API as a valid toolset, rather than discount it out of hand due to FUD, or marketing pressures. Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Tuesday, 26 October 2010 3:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Building XML using the UV XDOM API functions Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. T ___ 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/1AYrw4K3L1/76hLrBplQLdEzGQ20K2ljp/0 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 -- Sent from my mobile device ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list
