Re: [U2] 2 GIG Limit
UniData has a 2 gig limit on hashed files. What is the exact limit? Is it really 2,147,483,648 (2**32)or is 2 gig a loose term. What is the true threat level? Is it truly 2**31, or is it something else? We will need to do something soon, but how soon is what I am trying to determine. The problem occurs within a few bytes of 2**31, depending on the block size and a few other things. Actually, it's the write that causes the block offset to go over 2**31. Be aware that, if you're anywhere close to 2 GB, you may be closer to going over the top than you realize. If you have a nice, sequential key, it's quite possible that the file size could double rather quickly as all of the groups go into overflow in rapid fashion. Once you go over, writes will begin to fail, and data loss is imminent. When I see a file approaching 1 GB, I start thinking about converting it to dynamic. When it's at about 1.5 GB, I consider it time to convert it at the next available opportunity. If you're at the point that you're worried about the difference between 2*10**9 and 2**31, I suggest that you're close enough to warrant action rather soon. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Linux / file create default permissions
You could try the UniVerse command “UMASK 000”. Works exactly like the Unix version. Put it in the UV.LOGIN or the account LOGIN macro and everyone will get the settings applied. While this answers the original question, the original question itself begs another question: Are you sure you want to create all files as 777? True, this will ensure that nobody will hit access problems. But do you really want database files created as accessible to anybody with access to the system? And should they be set as executable? Fully open files are a huge red flag for system auditors. There may be times when it's justifiable to create a file as 777, but creating ALL files as 777 is - IMHO - opening yourself up for a huge cleanup problem later. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] default sort order
Hmm, That is one of the things I tried. just by @id is fine for me, howver, it is not doing it. I'll look again tomorrow. Are you running with ECLTYPE P? Try it with ECLTYPE U. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Inter-Process Control...
We have two phantom processes. The first phantom needs to wait for an event to occur with the second phantom. I realize that I could have the first phantom loop, check, then sleep. However, I'd like to avoid wasting resources. Back on the Prime, I could use semaphores, to control this flow and this was clean, and simple. Has anyone come across a means of having a phantom wait on something, so it only wakes up when it needs to perform its function? If you use the LOCK command (e.g.: LOCK 17) you're using semaphores. Does that suit your needs? If you're on UniData, you may want to take a look at PAUSE and WAKE. It gives you a way for a process to go to sleep, allowing another process to wake it up. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2][UD] Index for @ID (IBM documentation)
It's not going to speed everything up, just certain select statements. And quite honestly, it's going to speed up certain select statements that are not really kosher. For example, if your application is full of select statements like SELECT FILE WITH @ID = ABCDEF, then you should probably re-write the statement to something like SELECT FILE ABCDEF. What about this? SELECT FILE WITH @ID LIKE ABCDEF... or, in Pick style SELECT FILE EQ 'ABCDEF]' Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group 717-545-6403 tsnyd...@us.ibm.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Tab characters in output
While I'm at it, it would also be nice to dump list/sort output into an array. Not exactly what you're asking for, but you may get some help from the TO DELIM UniQuery keywords to create flat, delimited files that can be read in by your program or by Excel and other applications. I use it all the time and it works great. It's one of those features that's been out there almost forever ,but most folks aren't quite aware of its usefulness. Make sure you read up on UDT.OPTIONS 91 before playing around with it. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Tab characters in output
UDT.OPTIONS 91 always seemed backwards to me. If you're using the LIST syntax you would expect things in converted form - not the other way around. It's easy enough to create dicts (or even list statements) without conv codes. I agree that it seems backwards. My guess is that, when TO DELIM was implemented, it output it as raw, which is pretty much useless for most implementations. So formatted output was added. But, rather than change the default behavior (and possibly screwing up anybody that had built anything around the old behavior), UDT.OPTIONS 91 was added. As we all know, changing behavior (even bad behavior) often causes more problems that it solves - not to mention much wailing and gnashing of teeth. ;-) Like I said, I'm just guessing. But if you look at a lot of the UDT.OPTIONS, they seem backwards; I suspect it's all for the same reason. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Compile overwrite
Does anyone know what causes the system to stop and ask for an overwrite when you try to compile a program? It looks like the program was previously compiled by somebody else, who became the owner of the object file. While you have permission to write to the directory, allowing you to add or delete files, you're about to delete a file that's owned by somebody else, and it's confirming that's what you want to do. To avoid this, you could have your login ID added to the same group as the primary group other person, so you could both compile programs without getting the error. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Guaranteed unique sequential keys
D3 has a 'System-Wide' Unique ID generator in their SYSTEM() selectiosn... U2 does not. Darn it. Ah, but nothing's free. To ensure uniqueness, there needs to be some sort of negotiation. Years ago I worked on a Sequoia system running Pick O/A. We were happy to see SYSTEM(19), which provided a unique ID. We used it in some processes that were used by many users and discovered that performance suffered dramatically. After talking with the system engineers, we discovered that there was a semaphore that negotiated the requests to ensure that exactly one user was served at a time, then assigned the unique ID to that user. The problem was that, if you have dozens of users requesting an ID simultaneously, you have a bottleneck. Because we didn't care what the ID contained, we did something similar to what others here have suggested - a combination of port, date and time the program started, and a counter unique to the process. Performance system-wide improved dramatically and immediately. If it's important to have an ID that guarantees that you can sort the file in the order the transactions occurred, the READU scenario is probably the best. You could probably work out something with linked C routines and/or a socket server, but there will still be a bottleneck if there are many simultaneous requests. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unidata Time in Milliseconds?
SYSTEM(9) is milliseconds since the start of the program Careful - that's accumulated CPU time, not wall-clock time. It can be very helpful in identifying which parts of a program are processor hogs. But it's not useful in telling the time. As reported by others, SYSTEM(12) is the right tool for that job. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD] Cleaning out _PH_
Have a _PH_ that is just full of crud and I cannot think of a convenient way to automate the 'cleanup' from within UniData I usually do this with scripting at the O/S level, but you could do it with UniBasic. It would go something like this: 1) Open _PH_ with a normal OPEN statement 2) Use FILEINFO(filename, 2) to determine the path to _PH_ 3) Loop through with READNEXT 4) Construct the full path using the path to _PH_ and the ID returned by READNEXT 5) Use the DIR function to determine the date (and optionally, time) the file was updated 6) Delete, archive or whatever, based on the date Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Over-coming EDitor shortcomings
This is shifting into a less technical zone, so I am going to ask you to move it to community. Also, *Please, Please, Please* remember to trim quotes when responding. Apparently people are filtering out messages from the moderator, because this topic won't die and people insist on including the entire posting history with each message. Maybe if it comes from somebody besides the moderator they'll see it. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Over-coming EDitor shortcomings
From what I can see this is technical discussion about interfacing with U2. OK - granted. But what about over-quoting? People are reminded about this on a regular basis, and sometimes a special mention is made, as in this case. Still they continue to include the entire history. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Internal Cache in Unidata
Can anyone speak factually about internal cache in Unidata? I would be looking more at the operating system than UniData when it comes to results like this. With the amount of memory available on today's systems, it's likely that major portions (if not all) of the file(s) are remaining in O/S cache. So for second and subsequent queries you're pulling from memory instead of disk. If you really want to get a fair estimation of one query method versus another, you really should reboot between each invocation. OK - that's generally not practical, so you probably want to perform each query twice, ignoring the first one each time. That won't give you an indication of how things will perform in real life, but it will give you some sort of idea of how one method compares to another. It's interesting to note that your second of three queries changes drastically during the second invocation while the others remain the same. Without knowing anything about your files or the dictionary items involved, I'm going to guess that XCDD.DIV involves one or more file translates. The records in the file(s) being referenced are being cached during the first invocation and available in memory the second time around. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse and Shadow copy on Windows 2003
The only way to guarantee business level data integrity in non-transactional applications is to force all users off the system briefly while you do steps 1 - 3. That's a good point. However, it's important to have a controlled way to do so. I've had people think they were safe to just log everybody off. Of course, there's no way to ensure you're not doing *that* in the middle of a transaction. ;-) Much worse, I've even had people with good intentions of getting everybody off of the system so they could have stable backups. How did they do it? With stopud -f or by doing a kill -9 on each user. Either one could create a mess at least as bad as backing up hot, since processes are not terminated cleanly. Actually, the mess could be worse with the unconditional kill methods, since they could result in corruption of the live database files, while backing up hot only impacts the backup copy. And if you do that while running RFS, head for the hills. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UV basic assignment error ?
As far as I can tell, UD doesn't have a BASIC runtime-error log. Oops - haphazard reading on my part. You're correct, of course. I actually get a lot of good information from the UniData logs that do exist, but then those are things that pertain more to what I normally do. And, as you pointed out, you shouldn't be making programming errors, anyway. ;-) OK - administering self-imposed cyber-spanking... Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UV basic assignment error ?
Too bad UD doesn't feel the same way. :-( I'm not sure what this references, but UniData does have a series of log files. They're text files ($UDTBIN/*.log and $UDTBIN/*.errlog), and the information doesn't scroll away if you don't catch the entries quickly enough. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Getting current SETPTR values
Is there a way to get the values reported by SETPTR, especially the destination without parsing the results of the ECL command? If you're on UniData, take a look at the UniBasic GETPU() and GETPTR() functions. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD 7.1] [Solaris 9]
I 'd like to copy 10 files from our production server to our test server. The problem is that NFA doesn't allow me to use the ECL command COPY I've seen NFA users write their own copy utilities in UniBasic. It really isn't any less efficient than the COPY command, since your bottleneck will be on the network more than anything you're doing on the hosts. I envision a cataloged program called something like NFA.COPY that can take the same command-line parameters as the standard COPY command. Naturally, you could work off of saved lists, and all of that good stuff. We are also implementing RFS so we can't use unix copy. And you're right about recoverable files under RFS - please don't copy them at the UNIX level! :-) Actually, I'm not a fan of using O/S commands to copy database files unless it's done in a very controlled fashion. And even then... Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Tracking Disk Writes - AIX, Unidata
I have a client who is experiencing something rather strange. Every few seconds, and not with any particularly regularity, topas will report a spike in disk writes, maxing out one or more disks to 100% utilization. CPU utilization, on the other hand, remains nominal or only slightly elevated. When this happens, the world stands still - literally - as user screens freeze up until several seconds after the disks have gone back to normal load. It may be tied to the syncd daemon, depending on how frequently every few seconds is. Try fiddling with the maxrandwrt parameter of the ioo command. I've seen this work miracles with intermittent spikes like you're describing. (I've also seen it make no difference at all, depending on the circumstances.) The default behavior of AIX provides improved overall system performance, but sometimes interactive processes suffer. By using the write-behind buffer with maxrandwrt, you even things out and reduce the spiky performance. Anyway, check out the man page for ioo and search for maxrandwrt for more information. This would probably be the easiest thing to try first. If it doesn't provide relief, you may want to play around with filemon, as suggested by somebody else. It will show you the busiest files on the system, but requires tinkering with quite a few command-line parameters to get useful results. Of course, AIX and UniData tuning can be quite complex, and the problems could be due to any number of factors. If no relief is in sight, you may need to get some assistance from somebody with experience with this type of tuning. [Oops - I forgot to enable the shameless plug alert.] Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Conversion code for week number
I know you said don't tell me it's the base date, but the date 1/1/68 was chosen for a reason - it means divide by 365.25 actually gives the right answer... Anybody that relies on that in code is bound to get a nasty surprise. There are dates for which that doesn't work. Try it with July 7, 2006. Today's date is 14437, a year ago was 14072. The difference is 365. Divide that by 365.25 and you get less than one year. The argument could be made that you could round it after the division, but that will throw other dates off. The bottom line is that this is not a safe way to accurately calculate an age - it's *almost* always right, but when that's not good enough, it shouldn't be used. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UD Backups - DBPAUSE for UniVerse?
For any Backup solution that uses the Microsoft VSS Snapshot functionality, or an Advanced Open File Manager option, would it be safe to say that for UD applications, they should issue the DBPAUSE command, grab a snapshot, then DBRESUME - *for each Backup requested*, to ensure optimal consistency of the Backup's integrity? Since others have responded with the information about suspending updates on UV, I'll focus on this question about using snapshots. The answer for both UDT and UV is yes, for each backup requested you should suspend updates, create the snapshot, resume updates, and then back up from the snapshot. This gives you safe backups that are consistent as of a point in time. Note, however, that if your application doesn't have transaction processing semantics in place, the backup may be transactionally inconsistent. In other words, if you don't tell the database where the logical transactions begin and end, it's possible that only some files in a transaction will have been committed as of the time of the backup. Of course, you would have the same issue even if you logged off all users to perform the backup, and the pause-snapshot-resume scenario is much more appealing than doing that or (worst of all) backing up the database while hot. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Unidata Dynamic files
What I don't understand is why you'd want a split load of something like 20 in any circumstance. Perhaps it's my misunderstanding of split load, but I take it to mean that when a group reaches 20% full, it will split it into two different groups. For KEYONLY dynamic files, the split and merge load factors refer to how full the group is of keys, not keys plus data. It's possible to fill a block with keys and not get any data in the primary block. In those cases you can use smaller factors to force the data into the same blocks as the keys. You may want to go even lower - maybe 10/5. If you're using a KEYDATA dynamic file, the factors are based on the size of keys plus data. Try it as a KEYONLY file with small factors and see if you get better results. Of course, I'm dealing with a headache of a dynamic file that just isn't happy. In short, it's got about 33,000,000 records, each in under 512 in size with purely integer keys... When I copy records from the original to the new dynamic file and get somewhere around 20,000,000 records, it start creating ovr segments lie crazy. I end up with 4 dat segments and 5 ovr segments. How close to 512 is the average record size? You may be close enough that two records won't fit into the primary block. Have you tried a larger block size? For fun, you may want to create a small version of the file as static, copy in a reasonable number of records, and see what guide recommends for the modulo and block size. While those won't necessarily translate to dynamics, the exercise may give you some ideas. Besides, you may get better performance with a larger block size (maybe 4 KB), depending on how your disks are set up. On the other hand, don't go too large arbitrarily, especially if you're running with RFS. All that being said, the block size *probably* wouldn't be creating the overflow - it should be forcing splits, but it's something to consider. If you haven't already, take a look at the GROUP.STAT output for the file. Since you have sequential keys, the records should be spread pretty evenly among the groups - if not, something else may be going on. Also look at the number of bytes per group to see if it's fairly consistent. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Tony Jones/WA/QBE/Insurance is out of the office.
Please unsubscribe Mr. Jones as looking forward to 5 months of 'out of the office' auto-replies is a highly annoying consideration. I will be out of the office starting 04/07/2007 and will not return until 09/07/2007. July 4 through July 9 is five months? :-) Clearly, he's using European-style (or should I just say non-American) dates. This was brought home to me once when I was in Europe and bought a prepackaged sandwich. I looked at the sell-by date when I was about halfway through and for a moment thought it had gone bad months before. Then I remembered to flip the month and day and realized that I didn't need to head for the WC and stick my finger down my throat. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UD Backups - DBPAUSE for UniVerse? [not-secure]
I thought DBPAUSE allowed running processes to finish but would hold new processes . That's not much of a pause when you think that a process could be running for hours before the system is truly paused. Fortunately, that's not true. Only pending writes are processed, not entire programs. Committed transactions are processed, uncommitted transactions are temporarily rolled back. Processes that attempt new updates after dbpause is issued will appear to be hung. As soon as dbresume is issued, they pick up at the update. Processes performing read operations continue along their merry way. As a rule, control returns from dbpause to its invoking process in a few seconds, although it could be a bit longer if there are many pending updates or if it takes a long time for the disk subsystem to catch up. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [AD] [U2] Basic developments reverse engineering tool ?
One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Wow - that's just plan mean! There may have been a thought that it was a way to avoid hard-coding file names in case they ever changed (though that would be a weak argument), but then they're hard-coded in the PROC, so I can't see any benefit at all, other than obfuscation. The person that created it must have had a future grudge against whoever came along to maintain the code. Take my job from me, did you? I'll teach you a lesson. :-) Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UD Backups
...I was hoping someone would have experience with a high-speed backup product that would backup open files for U2. Since our application has a module that uses ASP.NET we really don't want to shut down the dbms for very long (this is more important than backuping up open files and not having a pristine backup). It's pretty common to use an extra mirrored copy or a flash copy to provide backups of a quiescent database without suspending processing. It goes like this: 1) Pause updates with dbpause 2) Split off the copy, which will now be as of a point in time 3) Resume updates with dbresume 4) Back up from the quiescent, split copy, using the backup utility of your choice 5) Resync, snap back or do whatever is necessary to get the copy back up to date The duration of the pause will depend on many factors, but it's usually pretty quick - generally measured in seconds rather than minutes. And of course the exact commands to perform steps 2 and 5 will vary based on your operating system, disk storage facilities, high availability options, etc., etc. If your application uses transaction processing semantics, the transactions will be consistent within the backup, thanks to the dbpause. And you won't have to worry about files being backed up while groups are being updated, since they're not being accessed by the production users, who are happily going about their business, regardless of how long the actual backup takes. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] _PH_ ID
Is there a way for a phantom to know the _PH_ item that it's output is being redirected to? On UniData it's SYSTEM(48). Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] New UV system
Seems to me a move to Linux would be better since they are probably more familiar with a nix system. The spoolers are completely different. I agree with what Jerry said. In addition to his points, consider that changing the operating system means that you have to worry about any application code that launches operating system commands. You'll have to locate and change those. Maybe you'll be lucky, but it's a rare application that doesn't shell out to do something. Also, although UniVerse is rather forgiving about VOC pointers that use forward slashes rather than backward slashes, you'll have to be careful about making sure everything is installed on your Windows drive exactly the way it's installed on SCO, with paths relative to the current drive. And don't forget to check for application code that constructs file paths. Maybe there aren't any, but you need to be certain. There may be good reasons for switching to Windows, but it's not a decision that should be taken lightly. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UD: Login users
[EMAIL PROTECTED] wrote on 01/25/2007 11:26:28 AM: You can try the net user command (windows command use !net ... To run). Note I have only used it for users to update their own password so not sure how well it will work to create new users (access permissions to do it). I used NET USER to set up all users for a new system. I had a customer who was migrating from UNIX to Windows [much as it pained me to take part in such a thing ;-) ]. I moved the /etc/passwd file from UNIX and wrote a BASIC program to read it in and generate new users on Windows. Naturally, I couldn't interpret the passwords from UNIX. We just plugged the new passwords and forced the users to change them upon first login. The command was: net user user_id new_password /add /fullname user_name where userid and user_name came from the passwd file. You will need to have administrator access to perform this, for the obvious security reasons. You can type net user /help at the DOS prompt for more information. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UD: Login users
The /fullname switch causes me error messages on XP-Pro (SP2), but the rest works perfectly. Did you wrap the name in quotes? I had problems until I did that. I did it on Windows 2003, so maybe it's a difference on XP. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] re: Integration of UniVerse with Microsoft Team System 2005 {Unclassified}
[EMAIL PROTECTED] wrote on 01/17/2007 12:32:19 PM: True for CONV, FMT, COL.HDG, but (for UV) you need write permissions on the dictionary to to use EVAL. How about UniData? This is not true for UniData. You can use EVAL without having write access to the dictionary. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Calculate age from date of birth
[EMAIL PROTECTED] wrote on 01/16/2007 07:36:53 PM: Okay, to be truly accurate - divide by 365.25. (3 * 365) + 366 = 1461 total days in a four year span including a leap year. 1461 / 4 = 365.25. Actually, this isn't 100% accurate. There are quite a few dates for which this will generate an age that is off by one year. I created a demonstration program a long time ago to prove this, because we had a program that was using this logic. It never seemed quite right to me, and it is right *almost* every time. Calculating ages as of January 16, 2007 for all dates in the last ten years will show incorrect ages for January 16 of the following years: 1997, 1998, 2001, 2002, 2005, and 2006. For example, January 16, 2006 shows as zero years old (365/365.25 is less than 1). My preferred method of calculating age is to extract the month, day, and year of both dates and calculate the age as the difference between the years. Then, if the target MMYY is less than the birth MMYY, subtract one from the age. In other words, pretty much the way you would do it in your head - or at least the way I do it in my head. ;-) This also handles all leap-year rules, including those funky 100- and 400-year ones, which are not accommodated by simply dividing by 365.25. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Calculate age from date of birth
OOPS!!! I need to correct what I just posted. In the following statement: Then, if the target MMYY is less than the birth MMYY, subtract one from the age. both of those references should say MMDD instead of MMYY. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] Basic Program Scheduling Priority
I recall reading some blurb somewhere that although RQM is still supported by the universe compiler it is in effect a NOP and doesn't actually do anything on any platform. Not true. On UniData, the documentation for RQM includes the following: RQM is a synonym for the SLEEP function. For more information, see SLEEP. If you check TIME() or SYSTEM(12) before and after an RQM statement, you'll see that, without any parameters, RQM will generate a SLEEP 1. Although not documented as such for UniVerse, this will act the same way. Years back, I was working on Sequoia Pick O/A and was looking into a program that was suddenly taking a long time. I came across a bunch of RQM statements and talked to the programmer who was working on the program to see what they were all about. He said that they forced a screen flush so a record counter would be up to date. I slapped together a small test program and demonstrated that this was actually doing a one-second sleep, which was happening pretty frequently. (Well, yes, it did flush the screen, too.) I replaced all of the RQMs in the program with CRT CHAR(0):, which forced a screen flush on O/A, and the program sped up drastically. So anyway, this shouldn't be treated as a NOP. If you come across something like this in a program, get rid of it, unless the desired effect is actually to sleep for a second. I can't speak to other platforms, but for Pick O/A, UniData, and UniVerse, that's what you'll get. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2]UniData and Multithreading for udtsort.exe on Windows Server 2003
[EMAIL PROTECTED] wrote on 01/04/2007 08:54:01 PM: One way you COULD boost CPU usage to 50% would be to upgrade to a dual 3.8Ghz system . but I'm guessing that isn't an option Of course, that assumes that you _want_ to allow a single process to consume half of your entire CPU capacity. That would also apply to UniBasic programs that sit in tight loops, such as badly-written keystroke input routines and READU...LOCKED processing, not to mention the classic problems with manipulating large dynamic arrays. I recently worked with a customer with exactly this scenario. They were running on a dual-core system. A keyboard input routine went into a loop that simply checked whether a keystroke was pending; if not, it just went back to the top of the loop and kept looping unthrottled until something was available. It was chewing up half of their CPU capacity. When that program was running on more than one PID at a time - well there wasn't much actual work getting done on the system. Splitting up the total processor capacity among multiple units is not necessarily a bad thing. Having a small number of very fast processors allows CPU hogs to take over the system quite easily. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] ANSI Not Supported
[EMAIL PROTECTED] wrote on 10/30/2006 10:17:53 AM: How do I configure UniVerse on HP-UX (11i v2) so to not get this error message TERMINAL TYPE 'ansi' NOT SUPPORTED. THE SUPPORTED TERMINAL TYPES ARE VIEWPOINT AND VT100. Are you sure the message is coming from UniVerse itself? I suspect this is coming from the application, which may only support those two terminal types. By default, UniVerse will support many more terminal types than those two. Try logging into the UV account, or anyplace that doesn't run through the application code - I suspect you won't have any problems at all with ansi. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Have you ever seen this?
[EMAIL PROTECTED] wrote on 10/24/2006 10:51:23 AM: Don't forget to look for: cat /dev/null /path/to/filename While we're at it, you don't even need anything to the left of the redirection sign. The following is a complete and valid statement for creating a new, empty file, or for replacing an existing file with an empty one: /path/to/filename Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Slow ascii output
Mark Johnson wrote on 10/21/2006 09:43:13 PM: Keep in mind that 16MB for 32 users is 250 times the memory available circa late 1970s' with the Microdata Royale series. There's something to be said for programming on an older system that gives you respect for todays horsepower. I agree 100%. In the late 70s I was working at a Savings and Loan with seven branch offices. There were several teller terminals and one or two VDTs at each branch. We ran with a grand total of 256 KB (not MB - KB) of memory - and that was after the upgrade from 128 KB. [Hey, it seemed like a lot because my TRS-80 only had 4 KB ;-)] You learned to be very efficient. And we couldn't make any programming mistakes. Our online program took all night to compile. We kept a few KB of memory set aside in the program so we could patch in hex code and branch in and out of the main program. At the end of the online day we rebooted the system with different memory parameters for nightly batch processing. Ah, the good old days... Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM RM
Adrian Merrall wrote on 10/17/2006 06:44:40 PM: But won't this only work if your data fits into the modulo that matches your page size? If your data is lumpy and doesn't nicely fit into the page size/file modulo selected you get level 1overflow and more disk IO. Good point. And in case anybody is still thinking of setting up files with modulo 1 to improve performance, remember that UniVerse will associate all records in that file with a single lock semaphore, creating a potential bottleneck on the lock table. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 09/03/2006 01:11:43 AM: Anyone can create an example of extremes to invalidate any suggestion. I didn't really see one million records as being extreme. That's really not a very big file in today's world. Since many people here are working on large systems, I just wanted to give them a heads-up before they implement logic that drags down their systems. You never said this was for only small sets of records, so I felt people needed to be aware of the limitations. Many people who come here are new to the MV world, and we need to look out for them. If I were intending to process 5 million records as you would suggest, I would write a simple program to create the csv's. I create many of these as programs for their recurring use. I use download for the one-shot simple projects. The problem is that somebody could inherit the system years later, see something called DOWNLOAD, and assume it will work for their needs. Unless there are built-in warnings that say they should only process VERY small data sets with this logic, they're going to get bitten. And we all know that one-time programs often make into production. Who here has never had that happen? :-) Besides, so what if it did 5 million executes. These systems can handle it. I know the common thinking these days is that the hardware can handle anything that programmers throw at it, and that programmer time is more expensive than hardware. Therefore, programmers should just put something together that works and let the system handle it. If not, you can always buy more hardware. When programmers think that way, their employers end up bringing in people like me to make it right - not that I'm complaining. :-) With one line of BASIC code you can consume an entire CPU. If your system has four CPUs, that's 25% of the entire system's capacity! Run that program in four different sessions and you've bogged down the entire system. Yes, hardware has come down in price over the years, but nobody's giving away CPUs yet. Also, the fact is that faster, more powerful systems very often exploit inefficient coding practices, and can create some very nasty bottlenecks. Time or processor consumption wasn't an issue in the original request Again, just warning people. It's my belief that system efficiency should always be a key consideration in developing software. I acknowledge that you shouldn't agonize over every CPU cycle, but it doesn't take that much longer to consider how coding and implementation practices will impact the entire system. Unfortunately, performance is generally seen as a problem for the SAs and DBAs to solve. In the VAST majority of cases that I've come across, the best performance improvements come from cleaning up the application code. Please understand that I'm not picking on anyone here. Just trying to help people understand the consequences of the decisions they make while developing systems. When systems perform sluggishly, there's a tendency to blame that oddball Uni-whatchamacallit database. The more we all do to keep the application humming along, the better off we'll all be. And if anybody out there isn't sure how to make that happen, there are plenty of us out here that are willing to help out. [Wipes brow and steps down from soapbox] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 08/31/2006 07:03:29 PM:
The magic is to take the TCL statement, derive the filename (CUSTOMER)
and
using READNEXT, acquire each of the item id's from the SSELECT
statement.
Then I generate very tiny English statements of the form:
EXECUTE LIST FILE ID NAME ID-SUPP COL-HDR-SUPP {any other necessary
suppressors} CAPTURING X
If I'm reading this correctly, you're performing multiple executes for
each record in the file. In the example you provided, you would be
performing one execute each for NAME, CSZ, PHONE, CONTACT, and
AGED.BALANCE. If you're processing a million records, that means you'll
be performing FIVE-MILLION executes!!!
Maybe I've misunderstood what you're doing. But if not, I don't recommend
this approach. The overhead of performing that many executes is
staggering. I had a customer that had a process that was running in eight
hours, and they desperately wanted to get it down to four hours. It was
consuming an entire CPU and imposing significant I/O wait times that
impacted system-wide performance. I found where the program was spending
most of its time and CPU cycles - it was in a routine that was performing
executes to locate a value within an index and read through that. I
changed it to eliminate the executes and use intrinsic basic functions
instead - nothing else was changed. It went down to twenty minutes - much
better than they had hoped for. CPU and disk consumption became
insignificant. Executes are a wonderful thing, but they are very
expensive operations when performed many times. By adding the capturing
clause, you're adding even more overhead.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 08/30/2006 08:59:24 PM:
It sounds to like what you want is the TRANS() BASIC function.
This works in UniVerse - Don't know about UniData.
In UniData you can use CALCULATE() or the curly braces {} like you're used
to. The documentation for both formats is in the manual under CALCULATE.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Select with Multiple Indices Not Working
[EMAIL PROTECTED] wrote on 08/29/2006 09:53:33 AM: When we execute at TCL SELECT ORDERS WITH CUST.NO = '12345' AND WITH INV.DATE = '12/14/05' no items are selected. Try it with double quotes instead of single quotes. It may be taking those values as primary keys. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Getting information on udt processes
[EMAIL PROTECTED] wrote on 08/02/2006 01:57:45 PM: Rather than just kill the process, is there some way to get a stack trace from it? I'd love to find out what subroutine it's running. Try PORT.STATUS PID 9 CALL.STACK. It reports the call stack, including the current line number for all executed programs and external subroutines. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] part files
[Posted on behalf of Wally Terhune, who is experiencing email problems] David W wrote: UniData does not have the 'part' files like UniVerse UniData does not have UV distributed files, but it does support MULTIFILEs with single shared dictionary and multiple parts :CREATE.FILE MULTIFILE PURCHASE_ORDERS 11,1 Create DIR type file PURCHASE_ORDERS. Create file D_PURCHASE_ORDERS, modulo/1,blocksize/1024 Hash type = 0 Added @ID, the default record for UniData to DICT PURCHASE_ORDERS. Create file PURCHASE_ORDERS/PURCHASE_ORDERS, modulo/11,blocksize/1024 Hash type = 0 Added @PURCHASE_ORDERS to DICT PURCHASE_ORDERS. : :CREATE.FILE MULTIFILE PURCHASE_ORDERS,HISTORY 11,1 Create file PURCHASE_ORDERS/HISTORY, modulo/11,blocksize/1024 Hash type = 0 Added @HISTORY to DICT PURCHASE_ORDERS. : :LIST PURCHASE_ORDERS,HISTORY LIST PURCHASE_ORDERS,HISTORY 12:51:33 Aug 01 2006 1 PURCHASE_ORDERS No records listed. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Read Error, Improper Data Type
[EMAIL PROTECTED] wrote on 07/27/2006 12:12:01 PM: I am having a problem with a straightforward read statement that is driving me crazy... snip open 'IM' to F.Item else null snip read R.Item from F.Item, This.Part else R.Item = '' Are you sure the file is being opened? I would put something on the else clause of the open to be sure. I suspect you're just falling through, and never assigning F.Item, so you don't have a file handle available for the read. Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] unix equivalent of FNAME = FIELD( PATH, '/', DCOUNT(PATH, '/' )
[EMAIL PROTECTED] wrote on 07/14/2006 04:06:46 PM: So if path is /twas/brillig/and/the/slithy/toves, then I want toves in standard out. Try something like this: filename=`basename $path` Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] unix equivalent of FNAME = FIELD( PATH, '/', DCOUNT( PATH , '/' )
[EMAIL PROTECTED] wrote on 07/14/2006 04:25:51 PM: cut -d/ -f7 That works for the example provided, but what if the next string encountered is /did/gyre/and/gimble/in/the/wabe? Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] RESIZE DYNAMIC FILES
[EMAIL PROTECTED] wrote on 06/12/2006 10:24:51 AM: Does anyone have any tech tips on how to select parameters when resizing dynamic files ? The following is from a published tech tip. It provides guidelines, but of course the nature of MV files makes it difficult to predict optimal sizing. To get the appropriate input data, run guide with the -r option to send the output to a hashed file. Point the dictionary of that file as directed, and you'll have what you need. It's important to note that this only applies to KEYONLY files. === Formula for determining base modulo, block size, SPLIT_LOAD, and MERGE_LOAD for UniData KEYONLY Dynamic Files Note that the variables used are the same as the DICT items in $UDTHOME/sys/D_UDT_GUIDE. Considerations: a) The following does not take into account the Unix disk record (frame) size so it is best to select a block size based on the number of items you?d like in a group. b) No one method will provide absolute results but these calculations will minimize level one overflow caused by a high SPLIT_LOAD value. c) Type 0 works best for most Dynamic Files but it is best to check a small sample via the GROUP.STAT command. Step 1: Determine the blocksize. (Use 4096 unless the Items per group is larger then 35 or less then 2) A) If the MAXSIZ 1K ITEMSIZE = 10 * MAXSIZ B) If 1 K MAXSIZ 3 K ITEMSIZE = 5 * MAXSIZ C) If MAXSIZ 3 K ITEMSIZE = 5 * (AVGSIZ + DEVSIZ) Once you determine the item size, use it to determine the NEWBLOCKSIZE. A) ITEMSIZE 1024; NEWBLOCKSIZE = 1024 B) 1024 ITEMSIZE 2048; NEWBLOCKSIZE = 2048 C) 2048 ITEMSIZE 4096; NEWBLOCKSIZE = 4096 D) 4096 ITEMSIZE 8192; NEWBLOCKSIZE = 8192 E) 8192 ITEMSIZE 16384; NEWBLOCKSIZE = 16384 Step 2: Determine the actual number of items per group. ITEMS_PER_GROUP = NEWBLOCKSIZE-32 / AVGSIZ Step 3: Determine the base modulo BASEMODULO = COUNT / ITEMS_PER_GROUP Step 4: Determine SPLIT_LOAD SPLIT_LOAD=INTAVGKEY + 9)*ITEMS_PER_GROUP)/NEW_BLOCKSIZE)*100)+1 If the SPLIT_LOAD is less then ten then: SPLIT_LOAD = 10 Step 5: Determine MERGE_LOAD MERGE_LOAD = SPLIT_LOAD / 2 (Rounded up) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] RESIZE DYNAMIC FILES
[EMAIL PROTECTED] wrote on 06/12/2006 12:57:03 PM: What does the guide -r option do ? We have been using the -a option. The -r option sends guide output to a hashed file. This makes it very easy to select for files that are undersized, or that have corruption. So I'll often do a CREATE.FILE DATA UDT_GUIDE 101, then edit the VOC entry of UDT_GUIDE so attribute 3 points to @UDTHOME/sys/D_UDT_GUIDE. Then I can do something like this from ECL: !guide /some_dir/some_file -na -ne -ns -r UDT_GUIDE This will create a record in UDT_GUIDE keyed as /some_dir/some_file. With that information for all of your files, you can do something like this: list UDT_GUIDE WITH STATUS LIKE ...2 (to find files with level 2 overflow) list UDT_GUIDE WITH STATUS LIKE Err... (to file files with corruption) list UDT_GUIDE MAXSIZ AVGSIZ DEVSIZ COUNT AVGKEY (to get the info for the dynamic file sizing calculations) It's SO much easier than writing code to parse through the text output of guide. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse Internal Date Blackout
[EMAIL PROTECTED] wrote on 06/09/2006 11:40:36 AM: Pointing out the obvious was very helpful, thanks. Gives me great confidence in dealing with IBM on odd issues such as this. We're dealing with report code written by a vendor (who knows what bizarre reason they had), and found the issue when the report wasn't returning expected results. We know using external dates work. We know having a dict item without the conversion works. We also know that using the bizarre scenario of an internal date against an external field works. What we don't know, and hence the question being posted, is why only this date range of 14001 - 14365 does not work. You are providing dates in external format. YYJJJ is a valid external format. Before you proclaim this as a bug in UniVerse, try it in other databases. I suspect that if you go to a legacy pick system and try this, you'll get the same results. This behavior is by design, and is in support of legacy systems. Try 10001, 18365, and other such ranges. I suspect you'll find that they behave similarly. Face it - you're supplying data that is not consistent with the intent of the dictionary item. Anything that doesn't resolve to an external date will just be passed through. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniData performance problems
[EMAIL PROTECTED] wrote on 06/07/2006 04:07:09 PM: * Resizing seems to have pretty much resolved our batch processing but hasn't helped online activity. Udtmon still shows a surprising amount over Overflow 2 activity. We're investigating, so maybe we have more work to do there. Does anyone know what a system in overflow 2 looks like to the O/S? Maybe a higher number of reads? It seems as if there is a bottleneck that noone can identify. Aside from periodic AIX read/write waits nothing shows any problems. Level 2 overflow will most likely manifest itself in terms of additional I/O requests at the O/S level. Look at the heavy hitters list in filemon. If there's a file at the top of the list, and the number of reads seems high, check sizing on that file. You say that batch processing is OK but interactive users are experiencing performance problems. Is this constant or intermittent? I wouldn't be surprised to hear that some users experience long delays while others fly through. Does the wait queue (see sar -q or topas) show high values? I would look at random write-behind and maybe high- and low-water marks for possible relief. There could be a complex combination of events - at the database and/or AIX levels - converging to create these problems. Shameless plug alert! You may want to have somebody perform a detailed health check of your system. I may just know of somebody who could help you out with this. ;-) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Backup Question
[EMAIL PROTECTED] wrote on 05/17/2006 02:04:35 PM: Seems like there should be a market for a product that can do online backups of unidata like uvbackup does for universe or the FILE-SAVE does for pick. I'm not so sure of that. Even when I'm setting up users on UniVerse, I never use uvbackup. Two reasons: 1) It's terribly slow on large databases; 2) You don't get a snapshot as of a point in time. If the backup takes four hours, one file may be backed up at midnight, while another is backed up at 4:00. Would a restore of this database be usable? It's better than nothing, but not by much. Whether on UniVerse or UniData, I strongly prefer the pause-snapshot-resume-backup method outlined by several folks here. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] D3 to U2 - how to import a FileSave tape
Bill Haskett wrote on 05/12/2006 11:46:20 AM: IBM advises that those migrating an MV system to U2 select UniVerse not UniData. UniData is not inherently multi-value aware Just curious - who within IBM supplied that information and opinion? The last time I looked, UniData seemed to have one or two features that address multi-values. ;-) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unidata Caching
Does RFS manage virtual paging - or is it just a block of memory? The RFS system buffer is a chunk of shared memory that keeps track of records read from and/or updated to recoverable files. In other words, it's maintained at the logical record level. If a requested record is found in the system buffer, no attempt is made to retrieve the record from disk. I/O to non-recoverable files goes straight to the O/S I/O routines, just as when RFS is not active. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Running a command from / via PCPERFORM
Dean Armbruster wrote on 03/13/2006 04:33:27 PM: PCPERFORM can do multiple commands. Separate them with a linefeed (char(10)). snip This is on HP-UX with the Bourne shell. I don't know about other shells, other unix, or Windows. Unfortunately, this won't work on Windows. Neither will the semicolon as proposed in a previous posting. On Windows you can use an ampersand as a line separator. Of course, if you use that same construct in UNIX you'll get totally different results (possibly amusing, possibly frightening, definitely incorrect), since anything preceding the ampersand will be launched as a background process with the rest being tossed. If you have software that needs to work on both NIX and Doze, you'll probably have to check SYSTEM(33) to see which you're running, and assign your continuation character accordingly. Hey, you'll probably be doing that anyway, to deal with forward slashes versus backslashes and some other things. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Capturing hold file numbers.
I assume this pertains to UniVerse, where you have to jump through the type of hoops outlined by the posters so far. For the sake of completeness, on UniData you can just use the GETPU() function. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] CAll Stack
Symeon Breen wrote on 02/07/2006 09:37:24 AM: Seems you can do this in universe using system but perhaps not unidata SYSTEM(49) does this for UniData. If call stack means the command-line stack history, that's in SYSTEM(52). Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Dynamic Files
James Cowell wrote on 02/01/2006 11:16:36 AM: Sorry if this is a bit thick, I'm a UV guy rather than a UD guy. But when you said I've tried changing split/merge loads from the default of 60/40 to 20/10 wouldn't that make the file much bigger? I don't know if UD works differently but in UV this would mean a new group was created every time the actual file load hit 20% so setting it to 20/10 in UV I'd expect the file to be about 5x bigger than the amount of data in it... As you suspect, there is a difference between the way UDT and UV handle this. Or more specifically, UniData offers an option not available in UniVerse. When you create or configure a dynamic file, you can instruct it to use either KEYDATA or KEYONLY determination. KEYDATA acts the same way as UniVerse in that the size of both the key and the data are used in determining whether to split or merge. If you use KEYONLY, only the size of the keys is used to make the decision. UniData stores the keys and pointers at the beginning of a group, and the records are stored at the end. If you use KEYONLY with a high split load, you could end up with only keys in the physical block, with all of the records in other blocks. A low split load with KEYONLY will cause it to keep the records more local to their corresponding keys. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Dynamic Files
[EMAIL PROTECTED] wrote on 01/31/2006 09:15:09 PM: The file STC.HIST as a dynamic file takes up 4.3Gig of disk space. It has around 944,000 records, a blocksize of 1024 but a modulo of 4,000,000+ When I convert this to a static file, I can properly size it with a modulo of around 94,000 which takes up a mere 75Meg. I've tried changing split/merge loads from the default of 60/40 to 20/10. I've tried playing with the minimum modulo. I'm clueless on dynamic files and would love any insight. For the large file in its dynamic form, is most of the space consumed by the dat* or the over* files? If the former, you may just be wasting space. If the latter, you have some file configuration issues to resolve. What does GROUP.STAT show you? Are the records distributed evenly in the groups or does it vary greatly? What do your key lengths look like? Are they large or small? Do they vary greatly from one record to the next? You may want to consider using the KEYDATA option. It doesn't usually work better than KEYONLY, but I have seen it make a huge positive difference on a small percentage of files. You might also want to play around with changing the hash type. 0 usually works best, but once in a while 1 will help you. Also, you may actually see things improve by increasing the split and merge loads. I've seen files that worked with 90/45, but that doesn't happen very often. So much depends on the characteristics of the data in the file. I recently posted the following [very verbose] information, which may give you some guidance. = COPY OF RECENT POSTING BEGINS HERE = The following is swiped from an old technical bulletin and is a good starting point. You should run guide with the -r option on the file and use its output for the variables below. However, there's nothing like getting a small sample of the records in the file - maybe 1 percent, and creating a small test file to play around with. You can play with CONFIGURE.FILE and memresize (AVOID REBUILD.FILE AT ALL COSTS) to find the best parameters, then use those, with an increased modulo to size the real file. For what it's worth, I generally find that smaller split and load numbers, such as 20/10, work better than larger ones. Of course, that varies from file to file, and there is no absolute rule. == Formula for determining base modulo, block size, SPLIT_LOAD, and MERGE_LOAD for UniData KEYONLY Dynamic Files Note that the variables used are the same as the DICT items in $UDTHOME/sys/D_UDT_GUIDE. Any calculated values which are not attributes in this dictionary appear in bold italic. Considerations: The following does not take into account the Unix disk record (frame) size so it is best to select a block size based on the number of items you?d like in a group. No one method will provide absolute results but these calculations will minimize level one overflow caused by a high SPLIT_LOAD value. Type 0 works best for most Dynamic Files but it is best to check a small sample via the GROUP.STAT command. Step 1: Determine the blocksize. (Use 4096 unless the Items per group is larger then 35 or less then 2) A) If the MAXSIZ 1K ITEMSIZE = 10 * MAXSIZ B) If 1 K MAXSIZ 3 K ITEMSIZE = 5 * MAXSIZ C) If MAXSIZ 3 K ITEMSIZE = 5 * (AVGSIZ + DEVSIZ ) Once you determine the item size, use it to determine the NEWBLOCKSIZE. A) ITEMSIZE 1024;NEWBLOCKSIZE = 1024 B) 1024 ITEMSIZE 2048; NEWBLOCKSIZE = 2048 C) 2048 ITEMSIZE 4096; NEWBLOCKSIZE = 4096 D) 4096 ITEMSIZE 8192; NEWBLOCKSIZE = 8192 8192 ITEMSIZE 16384;NEWBLOCKSIZE = 16384 Step 2: Determine the actual number of items per group. ITEMS_PER_GROUP = NEWBLOCKSIZE-32 / AVGSIZ Step 3: Determine the base modulo BASEMODULO = COUNT / ITEMS_PER_GROUP Step 4: Determine SPLIT_LOAD SPLIT_LOAD=INTAVGKEY + 9) * ITEMS_PER_GROUP ) / NEW_BLOCKSIZE)*100)+1 If the SPLIT_LOAD is less then ten then:SPLIT_LOAD = 10 Step 5: Determine MERGE_LOAD MERGE_LOAD = SPLIT_LOAD / 2 ( Rounded up ) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Difference between IBM Universe and IBM UniData
Pankaj Gupta wrote on 01/20/2006 02:00:07 AM: Can anyone tell me what are the basic differences bwtween UniVerse and Unidata? Brian Leach did a great job in his exhaustive response. For the most part, a programmer can make the transition from one environment to the other fairly easily. There are some nagging differences, and of course the right way is whichever one you're most familiar with. ;-) If your duties touch on DBA responsibilities, the differences are much more pronounced. Things are handled quite differently at the O/S level. Files are stored differently, records within files are stored differently, IPC structures are used in a totally different way, etc., etc. The tools for analyzing performance, data integrity, and process information are quite different. If you have to dig in at this level, I suggest you read the appropriate Administering UniData manual for your operating system. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Log Process ID for Phantom in UV 10
Baker Hughes wrote on 01/19/2006 12:05:40 PM: I seem to recall in UD a SYSTEM(nn) function that holds the Unix PID. I can't find the UV equivalent. It doesn't show in the docs to have one. In UniData it's @USERNO. In UniVerse you have to use a GCI call. Try the following: DECLARE GCI getpid pid = getpid() Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Freeing up AIX disk space
Sirulnick, Steve wrote on 01/16/2006 07:33:45 PM: I keep deleting files from AIX, but when I run a df -k, the amount of free space seems to be decreasing as opposed to increasing. Is there anything I can do to free up more disk space? If somebody has a file open when you delete it, the directory entry will be removed but the space will not be reclaimed until after the file is closed. The process(es) will continue to read and even update the original contents in the original location. That is consistent with what you're seeing. Unfortunately, you'll have to wait until everybody who opened the now-deleted file has closed it. If the system isn't too busy, you may be able to track something down with filemon, but that's a real shot in the dark, since the only reference available will be by device and i-node, and you probably don't know what those were and there's no way to find out anymore. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] System Migration issues
Michael Doyle wrote on 01/12/2006 12:52:14 PM: If AIX used \n as a line terminator (in keeping with standard UNIX practice,) binary vs ascii mode would not be an issue, but according to the ever-accurate wikipedia, it uses EBCDIC 0x15: http://en.wikipedia.org/wiki/Newline Since anybody can post anything into a wiki, any information contained therein should be taken with a huge grain of salt. AIX is a UNIX system, not a mainframe system, as claimed in the link. It uses ASCII, not EBCDIC. You can move text files directly between AIX and any other UNIX without problems. Besides, binary files like databases should - as pointed out by many other posters - be moved with binary mode, which means that the line terminator issue is not a factor. We need to hear back from the OP as to whether binary mode was used and what was meant by converting the files for Linux use. Then we can get closer to a solution. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Allen E. Elwood wrote on 01/04/2006 01:29:47 PM: I've always found it helpful to open the file/record in 'regular' mode first to find out if the directory entry worked or possibly to write a null record if it didn't. So, if the O/S-level file is multi-megabytes, you're reading the whole thing into memory? That could cause problems with shared memory and will certainly create a burden on the system. It also kind of defeats the purpose of using a sequential file, since you're reading the whole thing in, then opening it again and reading through the entire file a second time with READSEQ. Since you've incurred the memory and performance hit to pull the whole thing into a variable, you might as well waltz through that variable to extract the lines an attribute at a time with REMOVE or READNEXT. If you're following this practice only on small files, and only infrequently, it's probably OK, but how can you guarantee that will always be the case? Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Upgrading from Unidata 3 to Unidata 7
Darren Macdonald [EMAIL PROTECTED] wrote on 12/22/2005 04:24:08 AM: We have been running (in the dark ages) on Unidata 3.3 and 5.2 (on SGI Irix) for a number of years, and are considering moving up to Unidata 7 - ideally on a Windows machine. You've gotten some good responses about O/S-level executables - I can't think of much to add to that. You also need to think about the following: 1) Do you have any device-specific settings in SETPTR commands? If so, they may need to be evaluated for the new platform 2) If you have any tape jobs, you may need to evaluate the device settings. 3) It may be necessary run convdata on the data files. 4) Because of skipping so many releases, you should rebuild all index files rather than run convidx. 5) You should recompile and - as necessary - recatalog all programs. Hopefully your source code is in good shape. 6) VOC pointers will have to be modified to accommodate the nomenclature for the new O/S. 7) If you're using CallC or CallBasic routines, they will have to be regenerated and relinked. It may be necessary to modify the source code, depending on what is being done. 8) In addition to hard-coded PCPERFORM and EXECUTE statements, you'll have to look at those that launch processes based on constructed strings. This applies not only to the commands themselves, but to parameters that may contain paths and other O/S-specific information. 9) Be on the lookout for variable names that have become reserved words. The compiler is generally smart enough to work things out based on context, but there is a possibility of confusion. 10) There could be problems with files that are being created on the fly, since they could be based on explicit paths. This includes CREATE.FILE, OPENSEQ, OSOPEN, etc. How many concurrent users are you planning on? Be wary of placing too many on Windows - if you hit the wall you quickly run out of scalability options. You're skipping many releases and implementing a new O/S and hardware at the same time. It goes without saying that you really need to test this thoroughly before going live. If something goes wrong it may be difficult to isolate causes. You may want to seek help from somebody who has gone through it before. (Hint, hint.) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Unidata split/merge loads
[EMAIL PROTECTED] wrote on 12/12/2005 11:06:37 PM: I'm seeking some advice from others on reasonable parameters for a KEYONLY dynamic hashed file on unidata. The following is swiped from an old technical bulletin and is a good starting point. You should run guide with the -r option on the file and use its output for the variables below. However, there's nothing like getting a small sample of the records in the file - maybe 1 percent, and creating a small test file to play around with. You can play with CONFIGURE.FILE and memresize to find the best parameters, then use those, with an increased modulo to size the real file. For what it's worth, I generally find that smaller split and load numbers, such as 20/10, work better than larger ones. Of course, that varies from file to file, and there is no absolute rule. = = Formula for determining base modulo, block size, SPLIT_LOAD, and MERGE_LOAD for UniData KEYONLY Dynamic Files Note that the variables used are the same as the DICT items in $UDTHOME/sys/D_UDT_GUIDE. Any calculated values which are not attributes in this dictionary appear in bold italic. Considerations: The following does not take into account the Unix disk record (frame) size so it is best to select a block size based on the number of items you?d like in a group. No one method will provide absolute results but these calculations will minimize level one overflow caused by a high SPLIT_LOAD value. Type 0 works best for most Dynamic Files but it is best to check a small sample via the GROUP.STAT command. Step 1:Determine the blocksize. (Use 4096 unless the Items per group is larger then 35 or less then 2) A) If the MAXSIZ 1K ITEMSIZE = 10 * MAXSIZ B) If 1 K MAXSIZ 3 K ITEMSIZE = 5 * MAXSIZ C) If MAXSIZ 3 K ITEMSIZE = 5 * (AVGSIZ + DEVSIZ ) Once you determine the item size, use it to determine the NEWBLOCKSIZE. A) ITEMSIZE 1024;NEWBLOCKSIZE = 1024 B) 1024 ITEMSIZE 2048; NEWBLOCKSIZE = 2048 C) 2048 ITEMSIZE 4096; NEWBLOCKSIZE = 4096 D) 4096 ITEMSIZE 8192; NEWBLOCKSIZE = 8192 8192 ITEMSIZE 16384;NEWBLOCKSIZE = 16384 Step 2: Determine the actual number of items per group. ITEMS_PER_GROUP = NEWBLOCKSIZE-32 / AVGSIZ Step 3: Determine the base modulo BASEMODULO = COUNT / ITEMS_PER_GROUP Step 4: Determine SPLIT_LOAD SPLIT_LOAD=INTAVGKEY + 9) * ITEMS_PER_GROUP ) / NEW_BLOCKSIZE)*100)+1 If the SPLIT_LOAD is less then ten then:SPLIT_LOAD = 10 Step 5: Determine MERGE_LOAD MERGE_LOAD = SPLIT_LOAD / 2 ( Rounded up ) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deciphering Pick UniBasic statement
Caleb Ng [EMAIL PROTECTED] wrote on 12/08/2005 02:10:32 PM: IF P(2)-AR(12)=28 THEN CC=CC+1; INS 0 BEFORE AR(14)1,1; DEL AR(14)1,9; ELSE IF AR(13)=DATE() THEN CC=CC ELSE INS 1 BEFORE AR(14)1,1; DEL AR(14)1,9 OK, this is some kind of test, right? Nobody actually put that mess in production code, did they? Actually, it's unfortunately not the worst thing I've ever seen. Anyway, here's my take on it. IF P(2)-AR(12) LE 28 THEN CC = CC+1 INS 0 BEFORE AR(14)1,1 DEL AR(14)1,9 END ELSE IF AR(13) NE DATE() THEN INS 1 BEFORE AR(14)1,1 DEL AR(14)1,9 END END I changed the second compare to not equal, since the equal condition is just assigning CC to itself. The only time I've seen that do anything useful was when playing with REMOVE variables, which doesn't seem to be the case here. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] 15,200 users attained on IBM's U2 UniVerse
Symeon Breen [EMAIL PROTECTED] wrote on 11/23/2005 04:46:48 AM: Hi Tim - great info - I am always being asked how U2 performs and this is helpfull to a point. However without being critical it does not realy say much in terms of real stats ie. Number of transactions, IO read/writes, program executions etc per second/minute/day . The goal of this project was not to generate raw numbers like that. It was created to demonstrate that a particular application could perform under the projected user load. A requirement was to provide a certain number of transactions per user per hour. This was not measured in I/O operations, since that is not the measure of real-world productivity. Raw benchmarks that just generate numbers can be interesting, but do not demonstrate real-world productivity. They are always called into question because they could be tweaked to generate desired results by modifying the transactions for maximum throughput. We've all seen benchmark results and have questioned their viability. (OK - you can perform a bubble sort in 3 milliseconds, but what does that mean to my users?) This test was engineered and executed by using an actual application in a realistic environment, with realistic expectations. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] 15,200 users attained on IBM's U2 UniVerse
Stevenson, Charles [EMAIL PROTECTED] wrote on 11/22/2005 11:44:26 AM: Tim, Was transaction logging or data replication used? You're not the first person to ask that. Unfortunately these were not part of the goals of this load test. Can you share any interesting performance stats comparing w/ vs w/o TX or DR? I don't have anything formal to share. We've done some testing, but don't have anything formal. Naturally, the overhead of these products is highly dependent on the nature of the application employed. Something that does a lot of updates will have a different performance profile than something that's heavy on reads. And large record/transaction sizes will create a large amount of logging and/or replication activity as compared with something that has smaller records and/or transactions. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] 15,200 users attained on IBM's U2 UniVerse
Stevenson, Charles [EMAIL PROTECTED] wrote on 11/22/2005 12:59:53 PM: I suppose the test environment has been disassembled already, but it sure would be good to turn on logging give it a nother go. Can you keep that in mind for the future? The system has been dismantled, so there's no chance to run anything else. Unfortunately, the type of tests that are performed are dictated by the people who are paying for the time in the benchmark center. Since this is by no means cheap, it's difficult to add things that we think would be interesting. Each test took almost eight hours to prepare, execute and gather statistics, so it was difficult to squeeze in extra stuff. Now, if somebody's willing to sponsor a huge-scale test like this with TL turned on and off, I'd be thrilled to put something together... Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] 15,200 users attained on IBM's U2 UniVerse {Unclassified}
HENDERSON MIKE, MR [EMAIL PROTECTED] wrote on 11/22/2005 04:03:39 PM: An idea on the 'list price' cost of the target p590 system with 64 dual core CPUs and 124GB memory would be helpful, also information on how this was achieved, particularly as the IBM web-site says the p590 maxes out at 32 CPUs (2 'books' of 2 8-chip MCMs) ;-) Oops - miscommunication of information. The testing was done on a p595, not a p590. Steve O'Neal was asking me about the configuration yesterday and I may have told him it was a 590 - but I'm looking at the specs right now and it was definitely a 595. As far as the pricing, I think you'd have to get a quote from an IBM sales rep. I don't think these things are sitting on a shelf with price tags, ready to ship. ;-) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Redback Training?
Ralph Burton [EMAIL PROTECTED] wrote on 10/11/2005 01:30:19 PM: Any suggestions on Redback training/education? Here's a good place to start. ;-) http://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=pagecontentID=a523 Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OPEN vs TRANS
George Gallen [EMAIL PROTECTED] wrote on 10/11/2005 02:01:52 PM: Also, I don't use the OCONV() method with corelatives, I use the VAR=RAISE(TRANS(filename,itemname,-1,'x')), which is pretty self commenting, of course, that requires you to know what the TRANS() keyword does. I'm still trying to see how this is superior to a READ, which is entirely self-documenting and efficient, and doesn't require you to know about how TRANS behaves. I suspect that most programmers would have to look at the documentation or a help screen to know why you're doing a RAISE, and what the -1 and the 'x' are all about. Maybe I'm wrong about that. A line that starts out VAR= doesn't immediately say to me, here's where we're doing some I/O. If I'm searching a program for I/O statements, I'm not generally looking for something like this. There's also the overhead of doing the RAISE, which is only there to counteract the behavior of the TRANS. On small records this wouldn't be significant, but if you're processing many large records, it could make a difference. I'm not trying to be difficult here - I'm just trying to see the benefits of this alternative to a straightforward and standard approach. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OPEN vs TRANS
Allen E. Elwood [EMAIL PROTECTED] wrote on 10/07/2005 12:53:47 PM: The way I look at it, when I started programming 30 years ago systems were millions of times slower, and in another 30 years they'll be so stinking fast that coding for speed will go the way of the Suchomimus and the Iguanodon! As long as programmers think that way, their employers will continue to pay people like me big bucks to come in and make the code more efficient. ;-) Sometimes more powerful systems can make bottlenecks more prominent. Today's systems are expected to process more data in a shorter time, and to provide more functionality than in days of yore, so even minor inefficiencies are encountered over and over again. IMHO, there will always be room for efficient coding techniques. Some folks claim you have to sacrifice maintainability and readability for the sake of efficiency - I've rarely found that to be true. As long as you care about and consider both performance and maintainability as you develop code, it all just falls together. Now, as to people who want to code one line instead of two (e.g.: the topic of this thread), I say take a touch typing course so you don't mind a few extra keystrokes. (I've always been amazed watching seasoned professionals using only one finger on each hand to write programs.) I would much rather inherit a program that does its own opens and reads instead of doing translates. Sooner or later somebody will want to get a second field from the record and you'll be faced with doing two translates or changing it to the way it should have been done in the first place. Plus, the OCONV with a translate isn't nearly as obvious to the casual observer of the code. Of course, you could put in some comments to make it clear, but those keystrokes could have been spent opening the file at the top of the program. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
Mark Johnson [EMAIL PROTECTED] wrote on 10/01/2005 01:00:33 AM: Files that can't open are usually solved pretty quickly either after installing the software or making the changes. The downstream elaborate errmsgs for OPEN CUSTOMER TO F.CUSTOMER ELSE PRINT CANNOT OPEN THE CUSTOMER FILE. PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING ; STOP OPEN INVENTORY TO F.INVENTORY ELSE PRINT CANNOT OPEN THE INVENTORY FILE. PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING ; STOP or whatever the verbose message/mechanism is, is just an exercise in typing. 99.44% of the time the ELSE clause is not realized. So because it's not likely that an open will fail, it's not worth programming for? Can you guarantee that the files will never be placed on a network or external device that could fail? Or that the file could be deleted or otherwise rendered unusable? I realize that 99.44% is a reference to an old Ivory Soap ad, but imagine 56 opens out of 10,000 failing - that would certainly be worth coding for. Even if there's one chance in a million that an open will fail, that's worth coding for. I cringe when I see OPEN ... ELSE STOP 201, 'WIDGET'. (I've also even seen it with just STOP, without even referencing the file name.) That means the poor user will be placed at the command prompt with no idea of what to do. (And, noting that you advocate doing OPENs in external subroutines, that could leave transactions partially committed. Even if performance isn't a concern for you, this should be enough justification to avoid that practice.) I worked with a customer once that had just installed UniData with RFS. Everything went well through months of development and testing. Then, on the first day running live, OPEN statements started hitting their ELSE clauses. It turned out that the N_AFT parameter hadn't been set high enough. For those not familiar with RFS, suffice it to say that there wasn't enough space in a table that maintains open recoverable files, causing the opens to fail. Fortunately, that customer had some intelligence built into their open routines, which logged the problems and got the users out fairly gently. One strategy that I like is to have the ELSE clause add the file name to a list. Then after all of the opens have been attempted, see if the list is empty - if not, report on the files that couldn't be opened, log them somewhere, and get the user back to a safe point such as a menu. It may require a bit of typing, but those few keystrokes seem well worth the effort. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Programs slowing down after many iterations
Clifton Oliver [EMAIL PROTECTED] wrote on 09/01/2005 10:31:10 AM: Your named COMMON trick, especially with the second step of avoiding the file reopen is not a work-around. It is considered by most to be the correct way to code one of these subroutines. I agree with Clif - I've seen this approach make a huge difference many times. Don't consider it a work-around, but rather embrace this approach throughout the application. That being said, the original question is why this particular query became an issue all of a sudden. Although UniVerse hasn't been upgraded on this box recently, *something* has clearly changed. Maybe one of the impacted files has dramatically outgrown its configured size. Maybe somebody performed a uvregen that changed the size of the rotating file pool or something else. Maybe the user load has changed recently. Maybe a file design has been changed. Maybe something else has changed in the application environment, such as installing an application modification that is consuming disk or memory resources. Maybe there's a problem with some component of the disk subsystem. The list of possible causes is long; whatever changed may not have directly caused the problem with your query, but it may have been enough to cause a bottleneck in some system resource. What is the operating system being used? Is it possible that something changed there? Was any performance monitoring done at the O/S level while the problem was occurring? That would provide some valuable clues. Bottom line - sorry, no easy answers. ;-) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Prime number file modulos
I've definitely seen some non-prime modulos make a mess of things on platforms that allow them. UniData forces everything to a prime number, but UniVerse and some PICKs don't. If I remember rightly, Sequoia forced it to a number ending in 1, 3, 7, or 9. I remember an argument years ago - supported by Dick Pick, I believe - that said any number that is not divisible by 2 or 5 would be OK with a mod-10 hashing algorithm. I've never played with the math of it, but it sounds valid on the surface. I've seen lots of files with a modulus of 301 - apparently people think it looks kinda prime-ish - that worked as well as the actual prime of 307. But change it to 300 and it's a different story. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Timothy Snyder/Philadelphia/IBM is out of the office.
I will be out of the office starting 08/12/2005 and will not return until 08/22/2005. I will respond to your message as soon as possible. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] File name of the RECORDS which are listed in LIST.READU output
Louis Windsor [EMAIL PROTECTED] wrote on 08/06/2005 04:12:35 AM: I do the same but every time you login. The context of this is a bit blurred due to over-quoting, so I just want to make sure I understood correctly. Does the same mean going through all file references in an account and creating an entry in an i-node table for each? And does you mean every user? If so, you may want to reconsider this strategy. If you have five people logging on simultaneously, each of them is buzzing through the VOC, opening each file referenced therein, resolving the device and i-node, then constructing and writing a record in a reference table. Now, let's say you have dozens or hundreds of users logging on simultaneously - say, at the start of business in the morning. The overhead of all of the I/O (including many expensive OPEN operations) and contention for the lock table will be overwhelming. Not to mention the delay the user encounters before being able to start working. Maybe you could check a time stamp somewhere and bypass the procedure if the table has been rebuilt in the last, let's say, 10 minutes. That will still give you fairly current information, assuming somebody has logged in recently. However, if you don't have people logging in constantly throughout the day, the table could get rather stale at times. I'd be more inclined to have something that is scheduled on a regular basis. Or, since you apparently have a wrapper around LIST.READU, maybe have that wrapper check a time stamp to see how old the i-node look-up table is. If it's not very fresh, ask whether to rebuild it right before doing the native LIST.READU command. If, on the other hand, I misunderstood what you're doing, then please ignore the two previous paragraphs. ;-) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Timothy Snyder/Philadelphia/IBM is out of the office.
I will be out of the office starting 07/26/2005 and will not return until 08/01/2005. I will respond to your message as soon as possible. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
Will Johnson wrote on 07/15/2005 05:47:27 PM: someone mentioned that Remove has beenaround a long time. Not so. REMOVE was not added to the ADDS environment until perhaps around the mid 80s or so. That's only twenty years ago - a mere two decades. The paint isn't even dry on it yet. How are we supposed to keep up with this rate of change? ;-) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] SYSTEM(20)?
Check out GETPU() in the UniBasic Commands manual. That should give you what you need. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SYSTEM(20)?
David Knight wrote on 07/13/2005 08:03:10 PM: Reading the manual, the GETPU seems to return everything BUT the current print job number. Perhaps this is a wish list for the next release of UV. The OP is on UniData. I've been using GETPU() to report the currently open hold entry on each print unit since UDT release 3.3. It probably goes back farther than that. (No, we don't need anybody to crack open any dusty manuals to find out.) ;-) Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] - Determining time sequence
[EMAIL PROTECTED] wrote on 06/27/2005 09:32:35 PM: If you are on UNIX you can simply set TZ to different values before running a program which records SYSTEM(99). To expand on this, you could switch to a time zone that doesn't observe Daylight Saving Time before running the program. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Finding last day of month
Marco Manyevere [EMAIL PROTECTED] wrote on 06/02/2005 01:31:17 PM: Given a date like 20040203, I want to return the last valid date for that month and year (20040229 in this case). What is the shortest code fragment to achieve this? Ooh! A good old-fashioned programming challenge. I think the following is simpler and, because it uses half as many date conversions, will burn fewer CPU cycles than your method. INPUT ORIG.DATE YEAR = ORIG.DATE[1,4] MONTH = ORIG.DATE[5,2] MONTH += 1 IF MONTH EQ 13 THEN MONTH = 1; YEAR += 1 NEW.DATE.I = ICONV(MONTH:'/01/':YEAR, 'D') - 1 NEW.DATE = CHANGE(OCONV(NEW.DATE.I, 'DYMD'), ' ', '') CRT NEW.DATE This may need to be modified if your default date convention is not MM/DD/YY. It also assumes that the input date is in the correct format. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Finding last day of month
[EMAIL PROTECTED] wrote on 06/02/2005 09:54:59 PM: Input Date ; *format mmdd NextMonth = Oconv(Iconv(date[1,6]:'15','D') + 30,'D2') I.LastDayPreviousMonth = Iconv(NextMonth[1,2]:'01':NextMonth[5,2],'D') + 1 That's an interesting approach, but it comes at the price of an extra ICONV, which is more expensive than a simple IF statement. Granted, the difference isn't significant for a small number of invocations, but after a while it adds up. By the way, you may want to check the logic of the scrunched version. It's not giving you what you want. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Finding last day of month
[EMAIL PROTECTED] wrote on 06/02/2005 10:34:09 PM: input oDate ; *format mmdd iDate = iconv(oDate,'dymd') loop until oconv(iDate+1,'dd) = 1 do iDate += 1 repeat lastDay = oconv(iDate,'dymd') Not sure if it's worth bragging about - but mine's smaller (146 v. 161 bytes). This will chew a lot of CPU cycles if you're working on the beginning of the month. Again, it doesn't make much of a difference on a small data sample, but if you're processing millions of records, it can add up. OK, I'll get off my performance soapbox now... Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
Richard Taylor [EMAIL PROTECTED] wrote on 05/13/2005 02:05:51 PM: ... Why take a flexible, dynamic database system and force it to be fixed length. This is what you are doing using dimensioned arrays and MATREADs. The most common justification I have heard is performance and this simply doe not hold water. Have you ever compared performance between dynamic and dimensioned arrays, or are you just saying that you've never notice problems but have never tried dimensioned arrays? I've seen it make a HUGE difference in Pick, UniVerse, and UniData. If you reference many elements of a dynamic array many times, you'll burn a lot of CPU cycles just to locate the data. When you reference an element of a dimensioned array, it's stored in separate address space, and is immediately referenced. I have a standard way to avoid problems with the last attribute folding into the highest array element. Just dimension the array one element larger than the highest attribute you reference in the program. So if the highest attribute you reference is number 72, dimension the array at 73 or higher. Where I used to work, we had an automated process that created file definitions, including standard equates and the code to dimension arrays. We always created the arrays at one more than the highest attribute, and never had problems. This won't be necessary in environments where the extra attributes are placed on element zero, but it won't hurt anything, either. That way your code will be portable. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
Scott Ballinger [EMAIL PROTECTED] wrote on 05/13/2005 05:10:49 PM: In UV at least (not sure about UD) attribute processing has improved dramatically since the old days, to the point where it is essentially instant. When you're going sequentially through a dynamic array, that is true. Change your code to reference the elements randomly, and I predict you'll see a huge difference between dynamic and dimensioned. In most real-life programs, you'll see it pull something from attribute 23, then something from attribute 7, and something else from attribute 97. In my experience, it's rare that you see something neatly step through an array. I do agree with others that it depends. It depends not only on how many attributes are in the file, but how big those attributes are. Unfortunately, it's pretty common to put name and address information - usually pretty beefy and infrequently accessed stuff - at the beginning of the record, while smaller and more frequently accessed stuff is after it. That means you're parsing through the bytes comprising the names and addresses many times. I recently helped a customer with their performance problems. They had some very large records that were being referenced in a batch process. Whenever this process was run, CPU idle time went to zero and the system ground to a halt. By changing the reference to dimensioned rather than dynamic, the process sped up drastically and CPU became almost completely idle. Changing a few lines of code made a huge difference, not only to this program, but system-wide. This customer was running a recent release of UniVerse, so it had nothing to do with the parsing changes (which were added a long time ago anyway). I have many other real-life stories just like this on UniData and UniVerse. For small records where you're plucking or stuffing a few bits of information, dynamic arrays will do the job. But dimensioned arrays definitely have their place. Hardware delivers much more bang for the buck than just a few years back, but inefficiencies have a way of catching up with you. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Installing Easysoft ODBC-ODBC-Bridge on AIX
Metherall, Arthur [EMAIL PROTECTED] wrote on 05/02/2005 05:42:48 PM: When I define LIBPATH with the Easysoft libraries, for the Easysoft tests to work, UniData won't run. $ LIBPATH='$LIBPATH:/usr/local/easysoft/lib: /usr/local/easysoft/oob/client:/usr/local/easysoft/unixODBC/lib:/usr/lib:/lib' $ export LIBPATH Gut reaction without thinking it through too much - what happens if you move the single quote so that it's after the first colon? Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Timothy Snyder/Philadelphia/IBM is out of the office.
I will be out of the office starting 03/23/2005 and will not return until 03/28/2005. I will respond to your message as soon as possible. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] making 00001 our of 1
Scott wrote on 03/02/2005 04:30:09 PM: I have a need to search through our program files for any code that format a number from 1 through 9 with leading 0's. It's nasty, and I don't recommend it, but I've seen people do things like this: LOOP WHILE LEN(X) LT 5 DO X = 0 : X REPEAT Actually, this is generally done with some ugly GOTO logic, but I just couldn't make myself do that. Of course, it could be done with a FOR-NEXT loop, or any variety of ways. Good luck trying to automate a search for this sort of thing. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2][UD] Using Environmental Variables in VOC...
David Wolverton [EMAIL PROTECTED] wrote on 01/28/2005 03:30:06 PM: I want to have a VOC entry called UDT_SAVED_LOGS 001: DIR 002: $UDTBIN\saved_logs 003: D_BP Try replacing the $ in line 2 with @. This will cause it to resolve to an environment variable. You probably already have some of these in your VOC, such as _MAP_ 001: F 002: @UDTHOME/sys/_MAP_ 003: @UDTHOME/sys/D__MAP_ Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] AE on UniVerse
Morawa, Hans [EMAIL PROTECTED] wrote on 11/15/2004 07:27:37 PM: Does anyone know where I can find the AE manual. Get into AE and type HELP. That will describe several options, such as exploring individual commands, etc. You can also spool the entire help listing to the printer, but be prepared to chew up a lot of paper. Maybe just go to a hold file and browse it. Tim Snyder IBM Information Management Consulting I/T Specialist , U2 Professional Services --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] DATA Statements
Mark Johnson [EMAIL PROTECTED] wrote on 11/12/2004 09:28:03 AM: I don't dare mess with the UDT.OPTIONS on this system. It was installed before me, I just do app programming and simplistically concluded that things were set for MCD as PQN (real) procs work. Don't fear UDT.OPTIONS, embrace them. Bear in mind that you're not changing anything system-wide. You're only impacting the session that invokes them. You can do some wonderful things by flipping these bad boys on and off. Tim Snyder IBM Information Management Consulting I/T Specialist , U2 Professional Services --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] DATA Statements
George Smith [EMAIL PROTECTED] wrote on 11/12/2004 10:56:00 AM: Does that mean that if I am from the Pick background instead of prime I can set the switch and it will have no effect on the new .NET C# implementation. The docs recommend that you use the unidata settings. Not a problem. You can set UDT.OPTIONS 2 ON (also accomplished with ECLTYPE P) for your session without impacting what other users/processes are doing. There are also a ton of other options that can customize the environment to make it more like what you're used to. If there's some behavior that isn't what you're used to, check the manual on UDT.OPTIONS - there may be something there that will make you feel more warm and fuzzy. Tim Snyder IBM Information Management Consulting I/T Specialist , U2 Professional Services --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] broken up SELECTS
Adrian Matthews [EMAIL PROTECTED] wrote on 11/11/2004 10:26:48 AM: It's something I've always done over the last twenty years. The select processor in theory should apply optimisiation but I always break my statements down to reduce the working record set and to increase readability. Makes very little difference on smaller amount of records but makes a huge difference when record counts get into the millions, especially on distributed files or selects which work on a mixture of non-indexed and indexed fields. Of course, like so many things in the MV world (and life in general) this is an it depends scenario. If you're selecting based on three fields that reside in the record, the additional overhead of comparing them will be negligible compared to making a second pass through. It also depends on whether one of the criteria would be expected to reduce the working set of records significantly. If so, a second pass may be worth it. If you can reduce the working set significantly by selecting on a resident field, and save a nasty translate for a small percentage of the entire file, a two-pass approach is almost a no-brainer. But if the resident field only pares out 10% of the records, you'll be passing through 90% of the file twice, and you have to determine whether the second pass is saving work or creating more. With a particularly nasty dictionary item, it may be worth it. Tim Snyder IBM Information Management Consulting I/T Specialist , U2 Professional Services --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD] running a subroutine
Mark Johnson [EMAIL PROTECTED] wrote on 10/20/2004 08:53:46 AM: In fact, I welcome any criticisms or limitations anyone would have against establishing this PRINT command to handle everything. This is an intriguing concept, and does seem to have its uses. A couple of issues that occurred to me are: 1) This could cause problems in a multi-user environment. The %PRINT% item should probably include a port number, PID, or something else unique so you don't end up creating and compiling something, only to have it overwritten by somebody else before you execute it. Granted, that's not likely, but on a very busy system with many users, it's certainly a possibility. Of course, you'd have to clean up the generated source and the object after the EXECUTE instead of before, to avoid littering up your BP file. 2) This relies on the fact that the name of the program is also a basic command. The logic as it is precludes changing the name to anything other than PRINT. If PRINT also exists as a command or other VOC entry, you're out of luck. (You do allude to this when you say that on UniData, where PRINT is a keyword, this should be globally cataloged instead of creating a VOC entry.) On general principal, I'd prefer to name it something that's more descriptive of its purpose. I think I'd be tempted to change the name to DO.BASIC, or something like that. Then of course you'd have to change the logic so you strip out the first word of the command line that you place in TEST. This would also mean that you don't have to put a dummy argument at the beginning of the command line if you don't actually want to print anything. So, instead of PRINT ; CALL SUBROUTINENAME(VAL1, VAL2, VAL3) you could just say DO.BASIC CALL SUBROUTINENAME(VAL1, VAL2, VAL3) Thanks for sharing this interesting idea. Tim Snyder IBM Information Management Consulting I/T Specialist , U2 Professional Services --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
