Re: [U2] Sparse array population in Pick
Isnt this just a name value pair construct ? i do this a lot and just have 2 mv attributes 1 = name, 2 = value If you want mv data in the values then you can always LOWER it. From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of fft2...@aol.com Sent: 09 December 2010 22:10 To: u2-users@listserver.u2ug.org Subject: [U2] Sparse array population in Pick Years ago I had written a system, far predating XML, where the element-tags were unpredictable. Essentially the user was allowed to create any tags they wished, and any number of tags they wished, attached to another item. Each tag had an associated value. So far example Zip Code = 95062 You could not however predict what tags a person would use, they were all free-form and user-supplied, but you still had to store the tag with their associated value. At the time I developed two ideas for how to do this in a Pick item TAGS1052 001 Make = Chrysler 002 Model = LeBaron 003 Age = 7 years and 3 days TAGS1052 001 Make]Model]Age 002 Chrysler 003 LeBaron 004 7 years and 3 days The first model is clear. Anyone with no programming background at all, can easily understand it, and also easily edit it. It suffers from requiring more elaborate programming than the second model, as you have to parse every element. The second model is not quite as clear. You determine the attibute position of the value by locate the tag in attribute 1 and then adding 1 to it. That gives you the attribute number where the value lives. Alternately you could simply pre-fill attribute 1 with an initial null to push everything forward 1 place, then you wouldn't have to add 1 after your locate. Comments? Critiques? Nasty cat-calls and grimaces? Will Johnson ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1170 / Virus Database: 426/3305 - Release Date: 12/09/10 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] cpio: premature end of file
On 10/12/10 03:06, Boydell, Stuart wrote: This what you're looking for? http://www.mail-archive.com/u2-users@listserver.u2ug.org/msg21914.html It might not be. There's also an issue with block size, where they changed the default block size. I don't remember any create issues on SuSE but I do remember block size. I suspect that B always *used* to mean use big blocks, and upstream (followed very quickly by RH) changed it to mean use small blocks. So IBM's install instructions used the RH B for small blocks while SuSE defaulted to small blocks and thought it was being fed big blocks. It didn't like it! :-( Actually, premature end of file sounds suspiciously like that ... :-) Cheers, Wol -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of doug chanco Sent: Friday, 10 December 2010 14:05 To: U2 Users List Subject: Re: [U2] cpio: premature end of file I don't think so this the STARTUP script that comes with the personal edition of 10.3.3 and generates this error trying to install universe. I am still racking my brain and the internet but I can't seem to remember exactly what I did last time I installed universe PE and got this error but I seem to recall something about the options to cpio, sigh getting old bites dougc On 12/9/2010 9:42 PM, Perry Taylor wrote: Any chance your cpio file has exceeded the 2GB limit? Perry - Original Message - From: doug chanco [mailto:d...@chancofamily.com] Sent: Thursday, December 09, 2010 09:39 PM To: u2-users@listserver.u2ug.orgu2-users@listserver.u2ug.org Subject: [U2] cpio: premature end of file I am 95% sure this is being caused by the cpio options being different between unix/linux (in this case suse enterprise server) in the STARTUP script. What I cannot remember is which flag it is, can anyone refresh me? I am trying to install the personal edition of universe 10.3.3. on suse linux 11 enterprise server. thanks dougc ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ 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 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] cpio: premature end of file
Try adding the -H option to the cpio command when extracting the archive. Eg cpio --extract -vBdum -H odc /tmp/sb523_uv_cpio. Doug Chanco wrote: I am 95% sure this is being caused by the cpio options being different between unix/linux (in this case suse enterprise server) in the STARTUP script. What I cannot remember is which flag it is, can anyone refresh me? I am trying to install the personal edition of universe 10.3.3. on suse linux 11 enterprise server. thanks dougc ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- View this message in context: http://old.nabble.com/cpio%3A-premature-end-of-file-tp30422868p30426771.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Sparse array population in Pick
That is why I was thinking a real name-value store might be in order. As MV professionals, not every solution has to be a Pick solution. On Fri, Dec 10, 2010 at 4:10 AM, Symeon Breen syme...@gmail.com wrote: Isnt this just a name value pair construct ? i do this a lot and just have 2 mv attributes 1 = name, 2 = value If you want mv data in the values then you can always LOWER it. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Sparse array population in Pick
Consider replacing age with year or purchase date. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of fft2...@aol.com Sent: Thursday, December 09, 2010 5:10 PM To: u2-users@listserver.u2ug.org Subject: [U2] Sparse array population in Pick Years ago I had written a system, far predating XML, where the element-tags were unpredictable. Essentially the user was allowed to create any tags they wished, and any number of tags they wished, attached to another item. Each tag had an associated value. So far example Zip Code = 95062 You could not however predict what tags a person would use, they were all free-form and user-supplied, but you still had to store the tag with their associated value. At the time I developed two ideas for how to do this in a Pick item TAGS1052 001 Make = Chrysler 002 Model = LeBaron 003 Age = 7 years and 3 days TAGS1052 001 Make]Model]Age 002 Chrysler 003 LeBaron 004 7 years and 3 days The first model is clear. Anyone with no programming background at all, can easily understand it, and also easily edit it. It suffers from requiring more elaborate programming than the second model, as you have to parse every element. The second model is not quite as clear. You determine the attibute position of the value by locate the tag in attribute 1 and then adding 1 to it. That gives you the attribute number where the value lives. Alternately you could simply pre-fill attribute 1 with an initial null to push everything forward 1 place, then you wouldn't have to add 1 after your locate. Comments? Critiques? Nasty cat-calls and grimaces? Will Johnson ___ 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] Sparse array population in Pick
Yep, we do it all of time.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rob Sobers
Sent: Thursday, December 09, 2010 6:53 PM
To: U2 Users List
Subject: Re: [U2] Sparse array population in Pick
Doug,
I love JSON and use it all the time, mainly in JavaScript and Python, but
how do you propose persisting it to a U2 database? Or are you proposing
that one would persist data in the native attribute, value, sub-value format
and then de-serialize into JSON for the purpose of transporting?
-Rob
On Thu, Dec 9, 2010 at 7:41 PM, Doug dave...@hotmail.com wrote:
Read up about JSON (JavaScript Object Notation). At least JSON is
compatible with Java, JavaScript, PHP, Python, and Ruby to name a few,
see http://json.org. Your field names can be dictionaries or meta names.
Most other languages besides Unidata or Universe are not happy with
dots in the named fields so you need to replace them with some other
character like a underline. You will have to write a parser in
UniBasic but you can do in about 30 lines of code. This syntax
supports multi-values or even sub-values. Here are some simple examples:
Here is a single valued record:
[{IdCode:A,Desc:Active,ReportColor:#CC,No_AR:}]
Here is a multivalued record:
[{IdCode:178*MAINT,CustomerNo:178,G1EffectiveDate:[[10/01/20
07],[ 12/31/2010]],G1BillRate:[[0.00],[1.00]]}]
JavaScript Reference would be for the first line if it was loaded as
an object called oData as:
Single array reference:
oData[0].IdCode would be 178*MAINT
Multiple array reference:
oData[0].G1EffectiveDate[1][0] would be 12/31/2010
We use this format in our U2WebLink middleware running under UniObjects
for
Java for the Web. The data is much more compact than XML and very
readable. Most of the languages have the ability to parse this in a
single function. In JavaScript it takes around 7 to 10 milliseconds
to parse a pretty big JSON string into a JSON array.
Regards,
Doug
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Sparse array population in Pick
In a message dated 12/10/2010 6:56:38 AM Pacific Standard Time, slestak...@gmail.com writes: That is why I was thinking a real name-value store might be in order. As MV professionals, not every solution has to be a Pick solution. On Fri, Dec 10, 2010 at 4:10 AM, Symeon Breen syme...@gmail.com wrote: Isnt this just a name value pair construct ? i do this a lot and just have 2 mv attributes 1 = name, 2 = value If you want mv data in the values then you can always LOWER it. Not sure why you would lower it. You could have all the tags in attribute one and all the values in attribute 2, as multi-values. Of course if the user decides to create 800 tags, that can get pretty darn ugly to look at in the EDitor. And it's true that not every solution has to be a Pick solution, but if you have to reference it many times, from within the Pick environment, why make it external? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Sparse array population in Pick
that's what EV is for (unless you use another editor for data than AE) ;-) On 10/12/2010 18:06, fft2...@aol.com wrote: In a message dated 12/10/2010 6:56:38 AM Pacific Standard Time, slestak...@gmail.com writes: That is why I was thinking a real name-value store might be in order. As MV professionals, not every solution has to be a Pick solution. On Fri, Dec 10, 2010 at 4:10 AM, Symeon Breen syme...@gmail.com wrote: Isnt this just a name value pair construct ? i do this a lot and just have 2 mv attributes 1 = name, 2 = value If you want mv data in the values then you can always LOWER it. Not sure why you would lower it. You could have all the tags in attribute one and all the values in attribute 2, as multi-values. Of course if the user decides to create 800 tags, that can get pretty darn ugly to look at in the EDitor. And it's true that not every solution has to be a Pick solution, but if you have to reference it many times, from within the Pick environment, why make it external? ___ 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] Sparse array population in Pick
I think Symeon was saying that if the tag values are multi-valued, then lowering it makes them multi-sub-valued and won't corrupt the structure. I use this lower/raise trick for name/value pairs in 'named common' for passing parameters between processes except that I use a lower/lower (when stored) and a raise/raise (when extracted) so I can store items with attribute marks in my named pairs. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of fft2...@aol.com Sent: Friday, December 10, 2010 10:07 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Sparse array population in Pick Not sure why you would lower it. _ 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] Sparse array population in Pick
E-mail client from issue and this post never made it, so I'm forwarding my response again. Glen Batchelor IT Director/CIO/CTO All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 E-mail: webmas...@all-spec.com Web: http://www.all-spec.com Blog: http://blog.all-spec.com -Original Message- From: Glen Batchelor [mailto:webmas...@allspec.com] Sent: Friday, December 10, 2010 2:38 PM To: 'U2 Users List' Subject: RE: [U2] Sparse array population in Pick You can also store the metadata outside of the data item in another item using a standardized item naming structure. If a specific file contains the same types of data formats then you can store a global default in a locally or globally unique key. When creating new records the default layout is pulled up. This allows you more formatting and storage flexibility, IMO, but always requires two normal reads instead of one to obtain the data and metadata. In the case of a new data item, 2 reads will still be required. One to determine the item doesn't exist and a second to read the default meta so a new item can be created. CARS $$METADEFAULT 001 Make 002 Model 003 Age $$META.TAGS1052 001 Make 002 Model 003 Age 004 Comments TAGS1052 001 Chrysler 002 LeBaron 003 2558 D (2558 days) 004 This item is a non-default data test If you required multiple formats in the same data file, then that's OK. You can always store additional non-standard formats in additional $$METADEFAULT. items. would be the format number and you can store descriptions in the dictionary regarding what the various format codes are meant to be used for. Another, more compact, option is to just store the description of the metadata in attribute 001 and shift the data down one attribute. CARS $$METADEFAULT 001 Normal inventory filings for autos 002 Make 003 Model 004 Age $$METADEFAULT.0001 001 Collision inventory related filings for autos 002 Incident Date 003 Make 004 Model 005 Age 006 Insurer 007 Policy Number 008 Notes $$META.TAGS1052 001 TAGS1052 Created on 10/12/2010 by GB 002 Make 003 Model 004 Age 005 Comments TAGS1052 001 Chrysler 002 LeBaron 003 2558 D (2558 days) 004 This item is a non-default data test I could make up more sample data, but I hope that's enough to understand to structures. Regards, Glen Batchelor IT Director/CIO/CTO All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 E-mail: webmas...@all-spec.com Web: http://www.all-spec.com Blog: http://blog.all-spec.com -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: Friday, December 10, 2010 10:56 AM To: U2 Users List Subject: Re: [U2] Sparse array population in Pick Consider replacing age with year or purchase date. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of fft2...@aol.com Sent: Thursday, December 09, 2010 5:10 PM To: u2-users@listserver.u2ug.org Subject: [U2] Sparse array population in Pick Years ago I had written a system, far predating XML, where the element- tags were unpredictable. Essentially the user was allowed to create any tags they wished, and any number of tags they wished, attached to another item. Each tag had an associated value. So far example Zip Code = 95062 You could not however predict what tags a person would use, they were all free-form and user-supplied, but you still had to store the tag with their associated value. At the time I developed two ideas for how to do this in a Pick item TAGS1052 001 Make = Chrysler 002 Model = LeBaron 003 Age = 7 years and 3 days TAGS1052 001 Make]Model]Age 002 Chrysler 003 LeBaron 004 7 years and 3 days The first model is clear. Anyone with no programming background at all, can easily understand it, and also easily edit it. It suffers from requiring more elaborate programming than the second model, as you have to parse every element. The second model is not quite as clear. You determine the attibute position of the value by locate the tag in attribute 1 and then adding 1 to it. That gives you the attribute number where the value lives. Alternately you could simply pre-fill attribute 1 with an initial null to push everything forward 1 place, then you wouldn't have to add 1 after your locate. Comments? Critiques? Nasty cat-calls and grimaces? Will Johnson
