RE: [U2] Remove Scenario
Mark Johnson wrote: Here's a doozy. Mark, the fundamental problem is that the original code wasn't designed for the application that it's being asked to do now. That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore because it's such a bad idea. That code was written for small companies and when they get larger it falls apart as you see. It's like generating invoice numbers like this: INV.NUM = (OLD.NUM+1)R%4 Anyone remember day 10,000? While it's a good exercise to understand the underlying MV mechanisms, I think the real solution to this problem is not to try to bully a bad architecture, but to re-write it for its current environment. We can process 50,000 elements with 15 attributes, but should we do so? Only if absolutely required, which isn't the case here. If nothing else, you need to separate open invoices from closed invoices in that single attribute in the Customer record. Get the closed invoices out of the record and only hold the open ones. The best way to solve this however, is to store invoice keys in a key file, not all in a single record. In real life you're going to have a hard time telling your new formerly orphaned client that some of their TPH code needs to be re-written rather than just optimized to run faster. Been there, done that. But if you can re-write it so that the end-users get virtually zero delay when processing cash receipts they'll thank you for it. BTW, the same code can probably be applied to disbursements if your payable invoice ID's are stored in your Vendor records like that too. BTW, if you have a client with 50,000 invoices for a single client then I'd guess they won't choke too hard on some real coding vs funky patches to a bad schema. If they have 50,000 _open_ invoices for a single client then I'd further guess that they have a serious problem with their accounting practices, unless they're a one line item per S/O shop, and you might might want to check to make sure they aren't having similar problems paying their vendors, if you know what I mean. ;) Not much help, sorry. T --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [Maybe spam] RE: [U2] Remove Scenario
Rubbish,sorry Tony but that's what I think. You say experienced developers and big companies don't use EQU INVNO.TABLE TO CUST(40). I beg to differ. What do you call experienced? does 20 years count??? and what do you call a big company??? we only have two boxes running universe, two HP boxes, one with 32 processors and four logical machines, with over 5k users. We define all our files this way. Our user base is growing all the time as the company grows and our apps just keep on working. Les. -Original Message- From: Tony Gravagno [mailto:[EMAIL PROTECTED] Sent: 12 August 2005 07:23 To: u2-users@listserver.u2ug.org Subject: [Maybe spam] RE: [U2] Remove Scenario Mark Johnson wrote: Here's a doozy. Mark, the fundamental problem is that the original code wasn't designed for the application that it's being asked to do now. That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore because it's such a bad idea. That code was written for small companies and when they get larger it falls apart as you see. It's like generating invoice numbers like this: INV.NUM = (OLD.NUM+1)R%4 Anyone remember day 10,000? This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [Maybe spam] RE: [U2] Remove Scenario
I wasn't clear about that at all, sorry. What I meant was that experienced developers don't put a table of 50,000 invoice numbers into a single attribute in the customer master file, or even reserve one atb for open invoices and another one for closed, especially when either one of those atb's can expend beyond a couple thousand values. Equating a name to a dimensioned array element is absolutely standard and IMO preferred practice - sorry if that was confused. Tony Les Hewkin wrote: Rubbish,sorry Tony but that's what I think. You say experienced developers and big companies don't use EQU INVNO.TABLE TO CUST(40). I beg to differ. What do you call experienced? does 20 years count??? and what do you call a big company??? we only have two boxes running universe, two HP boxes, one with 32 processors and four logical machines, with over 5k users. We define all our files this way. Our user base is growing all the time as the company grows and our apps just keep on working. Les. -Original Message- From: Tony Gravagno That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Remove Scenario
Tony had a point in that redesign would probably give better performance, but here are some thoughts that may be helpful in the short term. 1) Using a multi-dimensioned array would be a little faster: IF BAL # 0 THEN MV=MV+1 BIG(MV,1)=ID BIG(MV,2)=SOMETHING ELSE etc. 2) In regard to an opposite of REMOVE, there really isn't a function but rather a technique. Create a large buffer and use substring assignment, e.g. BUFFER = SPACE(99) BUFPTR = 0 LOOP VAR = SOMETHING L = LEN(VAR) BUFFER[1+BUFPTR, L] = VAR; * substring assignment BUFPTR += L LATHER RINSE REPEAT I've used code like this when building large strings and it's very fast. If you get near the end of the buffer, you can always double its size. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Friday, August 12, 2005 12:26 AM To: u2-users@listserver.u2ug.org Subject: [U2] Remove Scenario Here's a doozy. Thanks for the previous suggestion of using REMOVE instead of the extractions. That's working very well. New problem. One client's application is written in The Programmer's Helper (TPH) which MATREADS and has EQUATES assigning variables like INVNO.TABLE TO CUST(40) etc. The program is written with INVNO.TABLE1,X style extracts everywhere. There are probably 15 mv'd fields with the suffix TABLE and their mv counters are in sync. Prior to using REMOVE (it had an issue on D3), I MATREAD in a BIG(30) array which breezed through the high item count of 155,000 records.(REMOVE took 8 seconds, BIG took around 12 and took over 9 minutes). Here's the rub. This is a Cash Reciept application where the BIG array is one customer's invoices. The load-in process jogs through the BIG array and for those items with a non-zero balance, it creates these 15 TABLE variables. Trouble is, if there's 155,000 total records for this 1 customer, 100,000 may have a balance of zero leaving 50,000 to be handled in the application. So while REMOVE is a great way to extract from BIG as a dynamic array and MATREAD is great for extracting from a DIM array, what would be the best way to build these 15 separately named TABLE variables. The original program (sans REMOVE) looked like this: C=DCOUNT(BIG,CHAR(254)) FOR I=1 TO C ID=BIGI READV BAL FROM ARFILE, ID, 10 THEN IF BAL # 0 THEN INV.TABLE1,-1=ID AAA.TABLE1,-1=SOMETHING ELSE BBB.TABLE1,-1=SOMETHING ELSE CCC.TABLE1,-1=SOMETHING ELSE MMM.TABLE1,-1=SOMETHING ELSE END END NEXT I So while REMOVE is a great extractor for these 150,000 fields, what is a great inserter for these 15 TABLE variables. In essence, the BAL # 0 is 50,000 records. I tried MV=MV+1 INV.TABLE1,MV=ID etc and got a minor improvement. I tried INV.TABLE:[EMAIL PROTECTED]:SOMETHING ELSE etc and got a slightly better improvement. In either case, you could see the progressive (exponential) delay as it performs these 50,000 (x 15) TABLE actions. I tried using my DIM BIG(30) where the dim element number was the insertable MV and I used the dynamic array concept on each dimensioned array element. Thus: MV=0 ; L=0 LOOP REMOVE ID FROM XREF AT L SETTING D READV BAL FROM ARFILE, ID, 10 THEN IF BAL # 0 THEN MV=MV+1 BIG(MV)1=ID BIG(MV)2=SOMETHING ELSE BIG(MV)3=SOMETHING ELSE BIG(MV)15=SOMETHING ELSE END END UNTIL D=0 DO ; REPEAT and it took only 8 seconds. Cool. So now I have a dimensioned BIG array with 50,000 elements each having 15 attributes. Because the infidel TABLE variables are scattered throughout this generated 1,500 line program, I don't want to search and replace them all with their BIG(MV)12 equivilents unless I really have to. Eventually, I have to take these mv'd TABLE variables and writev (sic) them onto the data file. MATBUILD doesn't seem to work with 2 dimensioned dimensioned arrays nor with elements containing attributes or values. It only likes the elements being simple variables. If this were a report program I would kick it off on a phantom and be done with it. Since it's a user oriented Cash Receipts program, the user literally waits 5-9 minutes while a single customer 'loads'. Of course, the larger more important customers are handled more frequently, thus more headaches. So the question is whether there is an INSERT or append function with the magic of REMOVE. Thanks for any insights. Mark Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: Re[4]: [U2] Connection Problems with Ud6
No arguments there. I just thought (like Robert's reply) that you need to see where the problem actually lies. If it's something with the windows firewall preventing the connection or it's XP media edition not letting the DB server work. Can you load another O/S on the laptop (maybe inside of VMWare)? HP is usually pretty good at having recovery CD's so you can get the laptop back to 'how you got it.' Colin Alfke Calgary, AB -Original Message- From: David Tod Sigafoos colin, Thursday, August 11, 2005, 1:01:24 PM, you wrote: catc With just UniData installed can you use UDT to connect - that will catc take telnet out of the equation. true .. but the problem is that connectivity with u6 other requires telnet and even more importantly RPC .. Neither of which 'work' though the services say they are running -- DSig David Tod Sigafoos --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [Maybe spam] RE: [U2] Remove Scenario
Tony, Thank you for clearing up the issue of using EQUATES. I was ready to pile on you along with Les Hewkin. We use EQUATES and live by what they describe. I have learned never to trust DICTS. I always value your responses, since you where the head guy at Pick Systems RD. Keep writing to this list. thanks. At 02:34 AM 8/12/2005 -0700, you wrote: I wasn't clear about that at all, sorry. What I meant was that experienced developers don't put a table of 50,000 invoice numbers into a single attribute in the customer master file, or even reserve one atb for open invoices and another one for closed, especially when either one of those atb's can expend beyond a couple thousand values. Equating a name to a dimensioned array element is absolutely standard and IMO preferred practice - sorry if that was confused. Tony Les Hewkin wrote: Rubbish,sorry Tony but that's what I think. You say experienced developers and big companies don't use EQU INVNO.TABLE TO CUST(40). I beg to differ. What do you call experienced? does 20 years count??? and what do you call a big company??? we only have two boxes running universe, two HP boxes, one with 32 processors and four logical machines, with over 5k users. We define all our files this way. Our user base is growing all the time as the company grows and our apps just keep on working. Les. -Original Message- From: Tony Gravagno That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] How to find user ID by the USER No. returned by STATUS() function
Hi All, If a record is locked by a program and another program tries to obtain a update lock on the same record then the STATUS() function returns the user number. How can I map this user number to the user id? e.g. A record xyz of ABC123 file is locked by user id 'appsadm'. Now when anyone tries to obtain the lock on the record xyz of ABC123 file then the STATUS() function returns user number: '1230'. How can I obtain the user id of the user (i.e. appsadm) corresponding to the User number? Or how can I obtain the User id without even obtaining the user number? Regards, Pankaj Gupta CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re[6]: [U2] Connection Problems with Ud6
colin, Friday, August 12, 2005, 5:43:48 AM, you wrote: catc No arguments there. I just thought (like Robert's reply) that you need catc to see where the problem actually lies. If it's something with the catc windows firewall preventing the connection or it's XP media catc edition not catc letting the DB server work. catc Can you load another O/S on the laptop (maybe inside of VMWare)? HP is catc usually pretty good at having recovery CD's so you can get the laptop catc back to 'how you got it.' snip I will probably try that when I get back to the office next week. It is just such a PITA sigh .. but then if it was all simple we would be out of jobs G thanks -- DSig ` David Tod Sigafoos ( O O ) ___oOOo__( )__oOOo___ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re[2]: [U2] Connection Problems with Ud6 and UV10
Robert, Friday, August 12, 2005, 1:07:04 AM, you wrote: RP What problem are we trying to fix at the moment? snip This has become 'a' problem. So many tries .. no hits and who knows who is on base So, when i get back to the office on monday I will re-install windows on the laptop and attempt installation with fresh install. As for the problems (and they persist) 1) I can not connect through the Intercall api as it returns with RPC not running. 2) I can not connect through telnet (even after changing ports) The Telnet screen comes up and blinking cursor BUT if I hit return the cursor drops a line and blinks there. 3) UniAdmin would not connect. RPC problem again 4) I could connect through 'Dynamic Connect' i think it was called. It went to the DEMO system so I know the DB is working fine So there you are .. the basic symptoms .. original and persistent. Thanks -- DSig ` David Tod Sigafoos ( O O ) ___oOOo__( )__oOOo___ ...our behavior matters more than the beliefs that we profess. Elizabeth Deutsch Earle --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Remove Scenario
Ray, Excellent point, as always, about field- vs value-level -1 difference. One question: Since each X-1 = ... adds to the size of memory allocated for the variable X, every so often X runs out of room and there has to be some sort of linking or remapping. (Recall we're talking about very large strings building up to 50,000 fields (was values).) So would it make sense to preallocate the space, then do substring assignments, and finally trim it: X = SPACE( 100 ) ;* reserve a million bytes of memory PTR = 1 FOR I = 1 TO 5 GOSUB get.string.to.append X[ PTR, LEN( STRING.TO.APPEND ) ] = STRING.TO.APPEND PTR+= LEN( STRING.TO.APPEND ) NEXT I X = TRIMB( X ) (of course ones should check to see if PTR is approaching the end and append another million bytes, etc.) Thanks, CDS From: Ray Wurlod UniVerse answer, but I think it's OK in UniData too. The -1 notation with angle brackets is good, but is improved by using it at the field level. Then it's a simple string append, and rather faster. So, build the multi-valued fields by this method, then apply a LOWER function as part of building the TABLE variables or the dynamic array that you will WRITE. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: Re[2]: [U2] Connection Problems with Ud6 and UV10
Looking at your list Dynamic Connect working almost certainly means that you are connecting using telnet - unless you connected serially... Which sort of makes me wonder about the other aspects as to which telnet client you are using which is not working... I tend to agree that a fresh install may allow you to make substantial progress but I would also suggest that you try breaking down the elements more as I suspect there is one key element which is causing the problem. My view is that the seeming confusion Windows Firewall has about whether it is up or down is where you should focus your attention... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Tod Sigafoos Sent: 12 August 2005 15:50 To: Robert Paterson Subject: Re[2]: [U2] Connection Problems with Ud6 and UV10 Robert, Friday, August 12, 2005, 1:07:04 AM, you wrote: RP What problem are we trying to fix at the moment? snip This has become 'a' problem. So many tries .. no hits and who knows who is on base So, when i get back to the office on monday I will re-install windows on the laptop and attempt installation with fresh install. As for the problems (and they persist) 1) I can not connect through the Intercall api as it returns with RPC not running. 2) I can not connect through telnet (even after changing ports) The Telnet screen comes up and blinking cursor BUT if I hit return the cursor drops a line and blinks there. 3) UniAdmin would not connect. RPC problem again 4) I could connect through 'Dynamic Connect' i think it was called. It went to the DEMO system so I know the DB is working fine So there you are .. the basic symptoms .. original and persistent. Thanks -- DSig ` David Tod Sigafoos ( O O ) ___oOOo__( )__oOOo___ ...our behavior matters more than the beliefs that we profess. Elizabeth Deutsch Earle --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] How to find user ID by the USER No. returned by STATUS() function
What I have done is to put a program in the LOGIN and USER.EXIT that enters/deletes all information about the user in a 'USER' file. We also have a sort of control file that lists terminals and their attributes, locations, phone extension, where that terminal is etc.. When we get a record lock, we read the USER file (key is USERNO) from that get the TTY number and read the TTY.CONTROL. Then we format a nice user friendly message stating something like 'Customer Record 12345 is being locked by Anthony Dzikiewicz at extension 123'. Believe it or not, some users will still call me and read the message on the screen because they don't know what to do. Anyway, that's one way to get it done. Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pankaj Gupta04 Sent: Friday, August 12, 2005 10:14 AM To: u2-users@listserver.u2ug.org Subject: [U2] How to find user ID by the USER No. returned by STATUS() function Hi All, If a record is locked by a program and another program tries to obtain a update lock on the same record then the STATUS() function returns the user number. How can I map this user number to the user id? e.g. A record xyz of ABC123 file is locked by user id 'appsadm'. Now when anyone tries to obtain the lock on the record xyz of ABC123 file then the STATUS() function returns user number: '1230'. How can I obtain the user id of the user (i.e. appsadm) corresponding to the User number? Or how can I obtain the User id without even obtaining the user number? Regards, Pankaj Gupta CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] How to find user ID by the USER No. returned by STATUS() function
Try this, works on Unidata: USER.LOGIN = GETUSERNAME(STATUS()) Charlie Rubeor Unix/Database Admin The Wiremold Company 800.338.1315 x3498 860.523.3690 fax --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] How to find user ID by the USER No. returned by STATUS() function
0017: EXECUTE 'LIST.READU' CAPTURING REPLY
0018: REPLY = TRIM(REPLY)
0019: CONVERT ' ' TO @VM IN REPLY
0020: DEL REPLY1 ; DEL REPLY1 ; DEL REPLY1
0021: CONVERT @FM TO @VM IN REPLY
0022: LOCATE RECORD.KEY IN REPLY1,1 SETTING X THEN
0023: LOCK.ERR = FILE.NAME:' record ':RECORD.KEY
0024: LOCK.ERR := ' locked by ':REPLY1,X-1
0025: LOCK.ERR := ' (':REPLY1,X-5:')'
0026: END ELSE
0027: LOCK.ERR = FILE.NAME:' ':RECORD.KEY:' ':' unknown lock'
0028: END
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Pankaj Gupta04
Sent: 12 August 2005 15:14
To: u2-users@listserver.u2ug.org
Subject: [U2] How to find user ID by the USER No. returned by STATUS()
function
Hi All,
If a record is locked by a program and another program tries to obtain a
update lock on the same record then the STATUS() function returns the
user number. How can I map this user number to the user id?
e.g. A record xyz of ABC123 file is locked by user id 'appsadm'. Now
when anyone tries to obtain the lock on the record xyz of ABC123
file then the STATUS() function returns user number: '1230'. How can I
obtain the user id of the user (i.e. appsadm) corresponding to the User
number? Or how can I obtain the User id without even obtaining the user
number?
Regards,
Pankaj Gupta
CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are
not to copy, disclose, or distribute this e-mail or its contents to any other
person and any such actions are unlawful. This e-mail may contain viruses.
Infosys has taken every reasonable precaution to minimize this risk, but is
not liable for any damage you may sustain as a result of any virus in this
e-mail. You should carry out your own virus checks before opening the e-mail
or attachment. Infosys reserves the right to monitor and review the content of
all messages sent to or from this e-mail address. Messages sent to or from
this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] How to find user ID by the USER No. returned by STATUS() function
0017: EXECUTE 'LIST.READU' CAPTURING REPLY
OrEXECUTE 'LIST.READU USER ':STATUS() CAPTURING REPLY
or even EXEUCTE 'LIST.READU INTERNAL USER ':STATUS() CAPTURING
REPLY
If INTERNAL keyword is used, login id is probably REPLY2,8.
(This, for UV.)
0018: REPLY = TRIM(REPLY)
0019: CONVERT ' ' TO @VM IN REPLY
0020: DEL REPLY1 ; DEL REPLY1 ; DEL REPLY1
0021: CONVERT @FM TO @VM IN REPLY
0022: LOCATE RECORD.KEY IN REPLY1,1 SETTING X THEN
0023: LOCK.ERR = FILE.NAME:' record ':RECORD.KEY
0024: LOCK.ERR := ' locked by ':REPLY1,X-1
0025: LOCK.ERR := ' (':REPLY1,X-5:')'
0026: END ELSE
0027: LOCK.ERR = FILE.NAME:' ':RECORD.KEY:' ':' unknown lock'
0028: END
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] How to find user ID by the USER No. returned by STATUS() function
Bob;
Instead of the execute and trim/convert you can use REPLY = GETREADU()
(at least in UniData).
Colin Alfke
Calgary, AB
-Original Message-
From: Bob Witney
0017: EXECUTE 'LIST.READU' CAPTURING REPLY
0018: REPLY = TRIM(REPLY)
0019: CONVERT ' ' TO @VM IN REPLY
0020: DEL REPLY1 ; DEL REPLY1 ; DEL REPLY1
0021: CONVERT @FM TO @VM IN REPLY
0022: LOCATE RECORD.KEY IN REPLY1,1 SETTING X THEN
0023: LOCK.ERR = FILE.NAME:' record ':RECORD.KEY
0024: LOCK.ERR := ' locked by ':REPLY1,X-1
0025: LOCK.ERR := ' (':REPLY1,X-5:')'
0026: END ELSE
0027: LOCK.ERR = FILE.NAME:' ':RECORD.KEY:' ':' unknown lock'
0028: END
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [Maybe spam] RE: [U2] Remove Scenario
In a message dated 8/12/2005 6:00:10 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Thank you for clearing up the issue of using EQUATES. I was ready to pile on you along with Les Hewkin. We use EQUATES and live by what they describe. I have learned never to trust DICTS. The only problem being (or at least last time I checked) was that RAID doesn't understand EQUATES. So you're walking through the code and see CUST.ADDRESS = '' and you type */CUST.ADDRESS and it says whatever something like variable not found or something I forget. So is there a downside to using a construct like A.CUST.ADDRESS = 40 CUST.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Remove Scenario
In a message dated 8/12/2005 8:11:51 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: every so often X runs out of room and there has to be some sort of linking or remapping. (Recall we're talking about very large strings building up to 50,000 fields (was values).) So would it make sense to preallocate the space, then do substring assignments, and finally trim it: X = SPACE( 100 ) ;* reserve a million bytes of memory I learned something !! No it's true I swear. I did know that at first string variables are assigned rather small areas to muck about in. And I knew that as they grew or shrank, these areas were reassigned or cleaned-up. I actually fell upon this knowledge quite by accident when I was writing a Decompiler and a Workspace Analyzer system. I think the string space originally is just 8 bytes and then gets expanded to 50 then 150... something like that. At least this was on an ADDS system. At any rate, it never occurred to me to pre-allocate space. This certainly would mean that the variable doesnt have to be garbage-collected, at least until the program is done. Also the idea of using sub-string assignment [], instead of -1 should be faster, since this would allow a JMP instead of a SCAN. You'd have to keep track of a PTR for EACH array cell however, not just one for the whole array, since each cell would have a different LEN. I believe, in this or a prior thread, it was mentioned that LEN Is actually a very fast operation, since the length is stored at the head of each string as a hiddle variable. So perhaps you could try just using LEN instead of maintaining a Pointer for each cell ? Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Remove Scenario
Interesting. I'll try the TABLE variables on the attribute level and then use CONVERT 254 to 253. D3 may not support LOWER. I'm going to suspect that the improvement may be there but minor. It still has to count 1,250,025,000 things (times 15) which is the gathering effect of 50,000 participants. - Original Message - From: Ray Wurlod [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 1:11 AM Subject: Re: [U2] Remove Scenario UniVerse answer, but I think it's OK in UniData too. The -1 notation with angle brackets is good, but is improved by using it at the field level. Then it's a simple string append, and rather faster. So, build the multi-valued fields by this method, then apply a LOWER function as part of building the TABLE variables or the dynamic array that you will WRITE. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Remove Scenario
If that's the case then 254's should work faster than 253's. I didn't know that the internals treated them any differently. I'll post my discoveries when I visit that client again (Wed Aug 17). Thanks. - Original Message - From: Mitchell, Stewart [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 1:04 AM Subject: RE: [U2] Remove Scenario Hi Mark, I seem to remember something about an internal point that is maintained for field marks @AM and not value markers @VM. I believe you will get some improvement by trying INV.TABLE:[EMAIL PROTECTED]:SOMETHING ELSE Regards, Stewart -Original Message- From: Mark Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, 12 August 2005 13:56 To: u2-users@listserver.u2ug.org Subject: [U2] Remove Scenario Here's a doozy. Thanks for the previous suggestion of using REMOVE instead of the extractions. That's working very well. New problem. One client's application is written in The Programmer's Helper (TPH) which MATREADS and has EQUATES assigning variables like INVNO.TABLE TO CUST(40) etc. The program is written with INVNO.TABLE1,X style extracts everywhere. There are probably 15 mv'd fields with the suffix TABLE and their mv counters are in sync. Prior to using REMOVE (it had an issue on D3), I MATREAD in a BIG(30) array which breezed through the high item count of 155,000 records.(REMOVE took 8 seconds, BIG took around 12 and took over 9 minutes). Here's the rub. This is a Cash Reciept application where the BIG array is one customer's invoices. The load-in process jogs through the BIG array and for those items with a non-zero balance, it creates these 15 TABLE variables. Trouble is, if there's 155,000 total records for this 1 customer, 100,000 may have a balance of zero leaving 50,000 to be handled in the application. So while REMOVE is a great way to extract from BIG as a dynamic array and MATREAD is great for extracting from a DIM array, what would be the best way to build these 15 separately named TABLE variables. The original program (sans REMOVE) looked like this: C=DCOUNT(BIG,CHAR(254)) FOR I=1 TO C ID=BIGI READV BAL FROM ARFILE, ID, 10 THEN IF BAL # 0 THEN INV.TABLE1,-1=ID AAA.TABLE1,-1=SOMETHING ELSE BBB.TABLE1,-1=SOMETHING ELSE CCC.TABLE1,-1=SOMETHING ELSE MMM.TABLE1,-1=SOMETHING ELSE END END NEXT I So while REMOVE is a great extractor for these 150,000 fields, what is a great inserter for these 15 TABLE variables. In essence, the BAL # 0 is 50,000 records. I tried MV=MV+1 INV.TABLE1,MV=ID etc and got a minor improvement. I tried INV.TABLE:[EMAIL PROTECTED]:SOMETHING ELSE etc and got a slightly better improvement. In either case, you could see the progressive (exponential) delay as it performs these 50,000 (x 15) TABLE actions. I tried using my DIM BIG(30) where the dim element number was the insertable MV and I used the dynamic array concept on each dimensioned array element. Thus: MV=0 ; L=0 LOOP REMOVE ID FROM XREF AT L SETTING D READV BAL FROM ARFILE, ID, 10 THEN IF BAL # 0 THEN MV=MV+1 BIG(MV)1=ID BIG(MV)2=SOMETHING ELSE BIG(MV)3=SOMETHING ELSE BIG(MV)15=SOMETHING ELSE END END UNTIL D=0 DO ; REPEAT and it took only 8 seconds. Cool. So now I have a dimensioned BIG array with 50,000 elements each having 15 attributes. Because the infidel TABLE variables are scattered throughout this generated 1,500 line program, I don't want to search and replace them all with their BIG(MV)12 equivilents unless I really have to. Eventually, I have to take these mv'd TABLE variables and writev (sic) them onto the data file. MATBUILD doesn't seem to work with 2 dimensioned dimensioned arrays nor with elements containing attributes or values. It only likes the elements being simple variables. If this were a report program I would kick it off on a phantom and be done with it. Since it's a user oriented Cash Receipts program, the user literally waits 5-9 minutes while a single customer 'loads'. Of course, the larger more important customers are handled more frequently, thus more headaches. So the question is whether there is an INSERT or append function with the magic of REMOVE. Thanks for any insights. Mark Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ** This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete the original message and all copies. We do
Re: [U2] Remove Scenario
I tried that although the proportional fonts in emails sort of hid that in my original post. I think it was my second example labeled slight improvement. If you're indicating to improve my MV counter then I doubt that's where the issue lies. The real bottleneck is truly the string of TABLE multi-values that will, in essence, have 50,000 values. Thanks. - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 1:33 AM Subject: Re: [U2] Remove Scenario One thought. It seems I remember that using VAR += 1 is significantly faster than VAR = VAR + 1. It's not much, but maybe it will help. Karl quote who=Mark Johnson Here's a doozy. Thanks for the previous suggestion of using REMOVE instead of the extractions. That's working very well. New problem. One client's application is written in The Programmer's Helper (TPH) which MATREADS and has EQUATES assigning variables like INVNO.TABLE TO CUST(40) etc. The program is written with INVNO.TABLE1,X style extracts everywhere. There are probably 15 mv'd fields with the suffix TABLE and their mv counters are in sync. Prior to using REMOVE (it had an issue on D3), I MATREAD in a BIG(30) array which breezed through the high item count of 155,000 records.(REMOVE took 8 seconds, BIG took around 12 and took over 9 minutes). Here's the rub. This is a Cash Reciept application where the BIG array is one customer's invoices. The load-in process jogs through the BIG array and for those items with a non-zero balance, it creates these 15 TABLE variables. Trouble is, if there's 155,000 total records for this 1 customer, 100,000 may have a balance of zero leaving 50,000 to be handled in the application. So while REMOVE is a great way to extract from BIG as a dynamic array and MATREAD is great for extracting from a DIM array, what would be the best way to build these 15 separately named TABLE variables. The original program (sans REMOVE) looked like this: C=DCOUNT(BIG,CHAR(254)) FOR I=1 TO C ID=BIGI READV BAL FROM ARFILE, ID, 10 THEN IF BAL # 0 THEN INV.TABLE1,-1=ID AAA.TABLE1,-1=SOMETHING ELSE BBB.TABLE1,-1=SOMETHING ELSE CCC.TABLE1,-1=SOMETHING ELSE MMM.TABLE1,-1=SOMETHING ELSE END END NEXT I So while REMOVE is a great extractor for these 150,000 fields, what is a great inserter for these 15 TABLE variables. In essence, the BAL # 0 is 50,000 records. I tried MV=MV+1 INV.TABLE1,MV=ID etc and got a minor improvement. I tried INV.TABLE:[EMAIL PROTECTED]:SOMETHING ELSE etc and got a slightly better improvement. In either case, you could see the progressive (exponential) delay as it performs these 50,000 (x 15) TABLE actions. I tried using my DIM BIG(30) where the dim element number was the insertable MV and I used the dynamic array concept on each dimensioned array element. Thus: MV=0 ; L=0 LOOP REMOVE ID FROM XREF AT L SETTING D READV BAL FROM ARFILE, ID, 10 THEN IF BAL # 0 THEN MV=MV+1 BIG(MV)1=ID BIG(MV)2=SOMETHING ELSE BIG(MV)3=SOMETHING ELSE BIG(MV)15=SOMETHING ELSE END END UNTIL D=0 DO ; REPEAT and it took only 8 seconds. Cool. So now I have a dimensioned BIG array with 50,000 elements each having 15 attributes. Because the infidel TABLE variables are scattered throughout this generated 1,500 line program, I don't want to search and replace them all with their BIG(MV)12 equivilents unless I really have to. Eventually, I have to take these mv'd TABLE variables and writev (sic) them onto the data file. MATBUILD doesn't seem to work with 2 dimensioned dimensioned arrays nor with elements containing attributes or values. It only likes the elements being simple variables. If this were a report program I would kick it off on a phantom and be done with it. Since it's a user oriented Cash Receipts program, the user literally waits 5-9 minutes while a single customer 'loads'. Of course, the larger more important customers are handled more frequently, thus more headaches. So the question is whether there is an INSERT or append function with the magic of REMOVE. Thanks for any insights. Mark Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- Karl L. Pearson Director of IT, ATS Industrial Supply Direct: 801-978-4429 Toll-free: 800-789-9300 1,29 Fax: 801-972-3888 http://www.atsindustrial.com [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit
Re: [U2] Remove Scenario
Actually Tony (Gravagno) you are hitting the target very closely. This TPH application has hundreds of programs in the application and the original designer, who's still here, endorses using it for existing and new work. I buck the trend as I'm not up to speed like he is on TPH but it's sort of the home court advantage. While TPH is a 4GL (please no flames or deviations here), it does allow for beaucoups of hand code or external subroutines. I wrote one last week called GET.AR.BAL that incorporates the popular REMOVE statement to jog through this mess and get the a/r balance in 8 seconds instead of 8 minutes. So I am inserting this whenever the a/r balance is desired. I can replace this Cash Reciepts program with hand-written code in around 1 day. I have to sell this concept or bury it in my other work. Plus I have to survey the users to see how it really affects them. Their top busiest customers have 150,000 - 90,000 - 40,000 - 20,000 and 9,000 invoices respectively. Their most important customers are the top 2 guys. And yes, they are billing on the sale order lines instead of the complete sales order. Can't change that as each line to the customer is a complete 'order' and my guy bunches up all the orders on a master delivery order (300-800 per day) but the customer can pay or challenge any one of these line-level orders. Unless a MV technique shows up that is the opposite of REMOVE I will follow my BIG(X)1 example. I like to solve inherited problems at the program level instead of trying to re-engineer the data files and make sure I get to all of the programs. It's only a cash receipts program for pete's sake. (I'll do the same for the a/r inquiry program). For those who care, the daily invoicing does not append to this xref file at that time. There is an overnight process that clears the xref and rebuilds it for the next day. It's not likely that they will apply cash to an invoice billed minutes earlier. Plus, the REMOVE is behaving properly for extracting the 50,000 from the pool of 150,000. It's the building of these TABLE variables inside the program that's the current issue. I solved this very issue with my original employer in 1983 by switching from EXTRACTs to using a combination of DIM and Dynamic array like I've shown with BIG(X)1. Back then a microdata only had room for 1,500 variables so you could not DIM BIG(1501). Now-a-days these limits are relegated to Jurrasic Pick. BTW, their A/P is on Quickbooks as from my observation, the original programmer wasn't that good at accounting and they decided to not invest his time using TPH (or any code) for A/P on MV. And, yes they pay promptly. Thanks Mark Johnson - Original Message - From: Tony Gravagno [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 2:22 AM Subject: RE: [U2] Remove Scenario Mark Johnson wrote: Here's a doozy. Mark, the fundamental problem is that the original code wasn't designed for the application that it's being asked to do now. That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore because it's such a bad idea. That code was written for small companies and when they get larger it falls apart as you see. It's like generating invoice numbers like this: INV.NUM = (OLD.NUM+1)R%4 Anyone remember day 10,000? While it's a good exercise to understand the underlying MV mechanisms, I think the real solution to this problem is not to try to bully a bad architecture, but to re-write it for its current environment. We can process 50,000 elements with 15 attributes, but should we do so? Only if absolutely required, which isn't the case here. If nothing else, you need to separate open invoices from closed invoices in that single attribute in the Customer record. Get the closed invoices out of the record and only hold the open ones. The best way to solve this however, is to store invoice keys in a key file, not all in a single record. In real life you're going to have a hard time telling your new formerly orphaned client that some of their TPH code needs to be re-written rather than just optimized to run faster. Been there, done that. But if you can re-write it so that the end-users get virtually zero delay when processing cash receipts they'll thank you for it. BTW, the same code can probably be applied to disbursements if your payable invoice ID's are stored in your Vendor records like that too. BTW, if you have a client with 50,000 invoices for a single client then I'd guess they won't choke too hard on some real coding vs funky patches to a bad schema. If they have 50,000 _open_ invoices for a single client then I'd further guess that they have a serious problem with their accounting practices, unless they're a one line item per S/O shop, and you might might want to check to make sure they aren't having similar problems paying their vendors, if you know what I mean.
Re: [Maybe spam] RE: [U2] Remove Scenario
I agree here. If I had the luxury of writing a complete new application, I would borrow from my Primac experience and use INCLUDE FILE.DEFS CUSTOMER which contains OPEN CUSTOMER TO F.CUSTOMER ELSE STOP (sic) DIM CUST.REC(100) EQUATE CUST.NAMETOCUST.REC(1) etc which virtually forces a uniform nomenclature for the opening of the file (named commons not withstanding), the read-in REC and consistent field names throughout the application. While many of my clients have bits and pieces of these concepts, it's still a scattered mess of crap when it's not application-wide. Primac was so advanced that they didn't wait for MV to come out with the INCLUDE concept. They wrote their own with a pre-compiler that assembled the code. Pretty impressive for 1982. I choose not to use these methods as since my clients (except those with Primac) already have so many half-baked disciplines, what's one more. And while it could be argued that I'm only adding to the fire, I am the current cook in the kitchen. I see so much mis-guided code in my travels that I feel pretty good with my own rather direct form of coding. One mis-use of these Equates was on the per-program level and the application had this throughout their programs: EQUATE CUSTNAME TO CUST.REC(1) EQUATE CUST.NAME TO CUSTOMER(1) EQUATE CNAME TO C(1) EQUATE CUSTNAME TO DATA.CUSTOMER(1) EQUATE CUSTOMER.NAME TO CUSTOMER.REC(1) etc I can't recall now but there were 17 different expressions for the first attribute in the customer file throughout all the programs. Thus, the local use of these equates is just as bad as not using them. Given that there are many ways to abbreviate CUSTOMER NAME, it's hard to remember which gets used when. That's my 2 cent son local equates. Global equates are more preferred. Mark Johnson - Original Message - From: Les Hewkin [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 4:40 AM Subject: RE: [Maybe spam] RE: [U2] Remove Scenario Rubbish,sorry Tony but that's what I think. You say experienced developers and big companies don't use EQU INVNO.TABLE TO CUST(40). I beg to differ. What do you call experienced? does 20 years count??? and what do you call a big company??? we only have two boxes running universe, two HP boxes, one with 32 processors and four logical machines, with over 5k users. We define all our files this way. Our user base is growing all the time as the company grows and our apps just keep on working. Les. -Original Message- From: Tony Gravagno [mailto:[EMAIL PROTECTED] Sent: 12 August 2005 07:23 To: u2-users@listserver.u2ug.org Subject: [Maybe spam] RE: [U2] Remove Scenario Mark Johnson wrote: Here's a doozy. Mark, the fundamental problem is that the original code wasn't designed for the application that it's being asked to do now. That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore because it's such a bad idea. That code was written for small companies and when they get larger it falls apart as you see. It's like generating invoice numbers like this: INV.NUM = (OLD.NUM+1)R%4 Anyone remember day 10,000? This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Remove Scenario
I'm going to try this as well next wed. Thanks. - Original Message - From: Rex Gozar [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 8:31 AM Subject: RE: [U2] Remove Scenario Tony had a point in that redesign would probably give better performance, but here are some thoughts that may be helpful in the short term. 1) Using a multi-dimensioned array would be a little faster: IF BAL # 0 THEN MV=MV+1 BIG(MV,1)=ID BIG(MV,2)=SOMETHING ELSE etc. 2) In regard to an opposite of REMOVE, there really isn't a function but rather a technique. Create a large buffer and use substring assignment, e.g. BUFFER = SPACE(99) BUFPTR = 0 LOOP VAR = SOMETHING L = LEN(VAR) BUFFER[1+BUFPTR, L] = VAR; * substring assignment BUFPTR += L LATHER RINSE REPEAT I've used code like this when building large strings and it's very fast. If you get near the end of the buffer, you can always double its size. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Friday, August 12, 2005 12:26 AM To: u2-users@listserver.u2ug.org Subject: [U2] Remove Scenario Here's a doozy. Thanks for the previous suggestion of using REMOVE instead of the extractions. That's working very well. New problem. One client's application is written in The Programmer's Helper (TPH) which MATREADS and has EQUATES assigning variables like INVNO.TABLE TO CUST(40) etc. The program is written with INVNO.TABLE1,X style extracts everywhere. There are probably 15 mv'd fields with the suffix TABLE and their mv counters are in sync. Prior to using REMOVE (it had an issue on D3), I MATREAD in a BIG(30) array which breezed through the high item count of 155,000 records.(REMOVE took 8 seconds, BIG took around 12 and took over 9 minutes). Here's the rub. This is a Cash Reciept application where the BIG array is one customer's invoices. The load-in process jogs through the BIG array and for those items with a non-zero balance, it creates these 15 TABLE variables. Trouble is, if there's 155,000 total records for this 1 customer, 100,000 may have a balance of zero leaving 50,000 to be handled in the application. So while REMOVE is a great way to extract from BIG as a dynamic array and MATREAD is great for extracting from a DIM array, what would be the best way to build these 15 separately named TABLE variables. The original program (sans REMOVE) looked like this: C=DCOUNT(BIG,CHAR(254)) FOR I=1 TO C ID=BIGI READV BAL FROM ARFILE, ID, 10 THEN IF BAL # 0 THEN INV.TABLE1,-1=ID AAA.TABLE1,-1=SOMETHING ELSE BBB.TABLE1,-1=SOMETHING ELSE CCC.TABLE1,-1=SOMETHING ELSE MMM.TABLE1,-1=SOMETHING ELSE END END NEXT I So while REMOVE is a great extractor for these 150,000 fields, what is a great inserter for these 15 TABLE variables. In essence, the BAL # 0 is 50,000 records. I tried MV=MV+1 INV.TABLE1,MV=ID etc and got a minor improvement. I tried INV.TABLE:[EMAIL PROTECTED]:SOMETHING ELSE etc and got a slightly better improvement. In either case, you could see the progressive (exponential) delay as it performs these 50,000 (x 15) TABLE actions. I tried using my DIM BIG(30) where the dim element number was the insertable MV and I used the dynamic array concept on each dimensioned array element. Thus: MV=0 ; L=0 LOOP REMOVE ID FROM XREF AT L SETTING D READV BAL FROM ARFILE, ID, 10 THEN IF BAL # 0 THEN MV=MV+1 BIG(MV)1=ID BIG(MV)2=SOMETHING ELSE BIG(MV)3=SOMETHING ELSE BIG(MV)15=SOMETHING ELSE END END UNTIL D=0 DO ; REPEAT and it took only 8 seconds. Cool. So now I have a dimensioned BIG array with 50,000 elements each having 15 attributes. Because the infidel TABLE variables are scattered throughout this generated 1,500 line program, I don't want to search and replace them all with their BIG(MV)12 equivilents unless I really have to. Eventually, I have to take these mv'd TABLE variables and writev (sic) them onto the data file. MATBUILD doesn't seem to work with 2 dimensioned dimensioned arrays nor with elements containing attributes or values. It only likes the elements being simple variables. If this were a report program I would kick it off on a phantom and be done with it. Since it's a user oriented Cash Receipts program, the user literally waits 5-9 minutes while a single customer 'loads'. Of course, the larger more important customers are handled more frequently, thus more headaches. So the question is whether there is an INSERT or append function with the
Re: [Maybe spam] RE: [U2] Remove Scenario
I'll add another localized comment from my experience. My client with the 17 different expressions of CUSTOMER NAME actually had 17 versions of EQUATE CUST.NAME.ATTRIBUTE TO 1 EQUATE CUSTOMER.NAME.ATT TO 1 EQUATE CNAME.ATR TO 1 etc. So I still stand by my original belief that if these EQUATES are localized as in this example, then you are missing the point and only adding to the confusion. You cannot remember which version is in each different program without going to the top of the program to find it. Only by having these EQUATES in an application-wide INCLUDE concept can its value be realized. Otherwise, it's just another half-baked inconsistent method. My 1 cent. Mark Johnson - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 1:27 PM Subject: Re: [Maybe spam] RE: [U2] Remove Scenario In a message dated 8/12/2005 6:00:10 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Thank you for clearing up the issue of using EQUATES. I was ready to pile on you along with Les Hewkin. We use EQUATES and live by what they describe. I have learned never to trust DICTS. The only problem being (or at least last time I checked) was that RAID doesn't understand EQUATES. So you're walking through the code and see CUST.ADDRESS = '' and you type */CUST.ADDRESS and it says whatever something like variable not found or something I forget. So is there a downside to using a construct like A.CUST.ADDRESS = 40 CUST.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [Maybe spam] RE: [U2] Remove Scenario
Sidebar. I wanted to change a 6 digit date value when re-processing a data set. The program would use today's date and I wanted to use the week prior. So I ran the program in the debugger and when I got to that line I did */DTE = 081005 of which I replaced it with 080305. and continued. When it was done, it had posted it to date 80305. Fortunately it isn't a date value just a posting reference. Thus, the debugger removed the leading zero (aka MS Excel Zip Codes). This was on D3. Is this also on UV/UD? Thanks. Mark Johnson P.S. Don't flame me for my method. Just focus on the debugger issue at hand. Thanks. - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 1:27 PM Subject: Re: [Maybe spam] RE: [U2] Remove Scenario In a message dated 8/12/2005 6:00:10 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Thank you for clearing up the issue of using EQUATES. I was ready to pile on you along with Les Hewkin. We use EQUATES and live by what they describe. I have learned never to trust DICTS. The only problem being (or at least last time I checked) was that RAID doesn't understand EQUATES. So you're walking through the code and see CUST.ADDRESS = '' and you type */CUST.ADDRESS and it says whatever something like variable not found or something I forget. So is there a downside to using a construct like A.CUST.ADDRESS = 40 CUST.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Remove Scenario
Tiny Sidebar to Tony's INV.NUM = (OLD.NUM+1)R%4 example. One client had this 4 digit limit in their invoice posting routine. The item-id was INV.NUM:INV and the [1,4] was pretty scattered throughout their application. The posting program would know the next available number (from a control table) and if the record exists (not paid) it tried the next number. At least this system purged paid invoices. Under my watch one day the girl noted that the update program was hanging. Sure enough, the posting program was cycling through all 10,000 (-) candidates for INV0001 and they were all used. Not wanting to repair the [1,4] everywhere, I used the DTX conversion and the number went from to which allowed the maximum number to be 65,536 and still be within the 4 digits. I was prepared to further improve on that by using 0-9 then A-Z if necessary. They never got over 20,000 open items. 0-Z for 4 digits is 1,679,616 invoices. My 1 cent. Mark Johnson - Original Message - From: Tony Gravagno [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 2:22 AM Subject: RE: [U2] Remove Scenario Mark Johnson wrote: Here's a doozy. Mark, the fundamental problem is that the original code wasn't designed for the application that it's being asked to do now. That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore because it's such a bad idea. That code was written for small companies and when they get larger it falls apart as you see. It's like generating invoice numbers like this: INV.NUM = (OLD.NUM+1)R%4 Anyone remember day 10,000? While it's a good exercise to understand the underlying MV mechanisms, I think the real solution to this problem is not to try to bully a bad architecture, but to re-write it for its current environment. We can process 50,000 elements with 15 attributes, but should we do so? Only if absolutely required, which isn't the case here. If nothing else, you need to separate open invoices from closed invoices in that single attribute in the Customer record. Get the closed invoices out of the record and only hold the open ones. The best way to solve this however, is to store invoice keys in a key file, not all in a single record. In real life you're going to have a hard time telling your new formerly orphaned client that some of their TPH code needs to be re-written rather than just optimized to run faster. Been there, done that. But if you can re-write it so that the end-users get virtually zero delay when processing cash receipts they'll thank you for it. BTW, the same code can probably be applied to disbursements if your payable invoice ID's are stored in your Vendor records like that too. BTW, if you have a client with 50,000 invoices for a single client then I'd guess they won't choke too hard on some real coding vs funky patches to a bad schema. If they have 50,000 _open_ invoices for a single client then I'd further guess that they have a serious problem with their accounting practices, unless they're a one line item per S/O shop, and you might might want to check to make sure they aren't having similar problems paying their vendors, if you know what I mean. ;) Not much help, sorry. T --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [Maybe spam] RE: [U2] Remove Scenario
I am on MasterPack. Whenever I 'deliver' a modification with a dictionary on it from one system to another, that process actually re-builds the equate includes for any new dictionary item I may have added. So yup, got lots of these, but not something I or any recent programmer before me did intentionally. -Original Message- From: Mark Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, August 12, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject:Re: [Maybe spam] RE: [U2] Remove Scenario I'll add another localized comment from my experience. My client with the 17 different expressions of CUSTOMER NAME actually had 17 versions of EQUATE CUST.NAME.ATTRIBUTE TO 1 EQUATE CUSTOMER.NAME.ATT TO 1 EQUATE CNAME.ATR TO 1 etc. So I still stand by my original belief that if these EQUATES are localized as in this example, then you are missing the point and only adding to the confusion. You cannot remember which version is in each different program without going to the top of the program to find it. Only by having these EQUATES in an application-wide INCLUDE concept can its value be realized. Otherwise, it's just another half-baked inconsistent method. My 1 cent. Mark Johnson - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 1:27 PM Subject: Re: [Maybe spam] RE: [U2] Remove Scenario In a message dated 8/12/2005 6:00:10 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Thank you for clearing up the issue of using EQUATES. I was ready to pile on you along with Les Hewkin. We use EQUATES and live by what they describe. I have learned never to trust DICTS. The only problem being (or at least last time I checked) was that RAID doesn't understand EQUATES. So you're walking through the code and see CUST.ADDRESS = '' and you type */CUST.ADDRESS and it says whatever something like variable not found or something I forget. So is there a downside to using a construct like A.CUST.ADDRESS = 40 CUST.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [Maybe spam] RE: [U2] Remove Scenario
Interesting. Especially since I have the distinct pleasure of sharing a cubicle wall with one of the original Primac developers. And while the cpylibs work as $INCLUDEs now, we still use cpylib from force of habit. -- Dave Walker 8..7 4(()) -::- -::-8.74 .74(()) ((88.74 ..74 -::- ((88.74 * Peace -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Friday, August 12, 2005 2:22 PM To: u2-users@listserver.u2ug.org Subject: Re: [Maybe spam] RE: [U2] Remove Scenario I agree here. If I had the luxury of writing a complete new application, I would borrow from my Primac experience and use INCLUDE FILE.DEFS CUSTOMER which contains OPEN CUSTOMER TO F.CUSTOMER ELSE STOP (sic) DIM CUST.REC(100) EQUATE CUST.NAMETOCUST.REC(1) etc which virtually forces a uniform nomenclature for the opening of the file (named commons not withstanding), the read-in REC and consistent field names throughout the application. While many of my clients have bits and pieces of these concepts, it's still a scattered mess of crap when it's not application-wide. Primac was so advanced that they didn't wait for MV to come out with the INCLUDE concept. They wrote their own with a pre-compiler that assembled the code. Pretty impressive for 1982. I choose not to use these methods as since my clients (except those with Primac) already have so many half-baked disciplines, what's one more. And while it could be argued that I'm only adding to the fire, I am the current cook in the kitchen. I see so much mis-guided code in my travels that I feel pretty good with my own rather direct form of coding. One mis-use of these Equates was on the per-program level and the application had this throughout their programs: EQUATE CUSTNAME TO CUST.REC(1) EQUATE CUST.NAME TO CUSTOMER(1) EQUATE CNAME TO C(1) EQUATE CUSTNAME TO DATA.CUSTOMER(1) EQUATE CUSTOMER.NAME TO CUSTOMER.REC(1) etc I can't recall now but there were 17 different expressions for the first attribute in the customer file throughout all the programs. Thus, the local use of these equates is just as bad as not using them. Given that there are many ways to abbreviate CUSTOMER NAME, it's hard to remember which gets used when. That's my 2 cent son local equates. Global equates are more preferred. Mark Johnson - Original Message - From: Les Hewkin [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 4:40 AM Subject: RE: [Maybe spam] RE: [U2] Remove Scenario Rubbish,sorry Tony but that's what I think. You say experienced developers and big companies don't use EQU INVNO.TABLE TO CUST(40). I beg to differ. What do you call experienced? does 20 years count??? and what do you call a big company??? we only have two boxes running universe, two HP boxes, one with 32 processors and four logical machines, with over 5k users. We define all our files this way. Our user base is growing all the time as the company grows and our apps just keep on working. Les. -Original Message- From: Tony Gravagno [mailto:[EMAIL PROTECTED] Sent: 12 August 2005 07:23 To: u2-users@listserver.u2ug.org Subject: [Maybe spam] RE: [U2] Remove Scenario Mark Johnson wrote: Here's a doozy. Mark, the fundamental problem is that the original code wasn't designed for the application that it's being asked to do now. That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore because it's such a bad idea. That code was written for small companies and when they get larger it falls apart as you see. It's like generating invoice numbers like this: INV.NUM = (OLD.NUM+1)R%4 Anyone remember day 10,000? This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe
RE: [U2] Remove Scenario
(I forgot to add delimiters to the X array being built) My original question about memory allocation and overhead while incrementally appending, increasing string length still stands. note 2 changed lines below: From: Stevenson, Charles X = SPACE( 100 ) ;* reserve a million bytes of memory PTR = 1 FOR I = 1 TO 5 GOSUB get.string.to.append X[ PTR, LEN( STRING.TO.APPEND ) ] = STRING.TO.APPEND fix:X[ PTR, LEN( STRING.TO.APPEND ) ] = STRING.TO.APPEND: @AM == PTR+= LEN( STRING.TO.APPEND ) fix:PTR+= LEN( STRING.TO.APPEND ) + 1 = NEXT I X = TRIMB( X ) but now you have trailing attribute mark to deal with... Close enough for an example. You get the idea. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Remove Scenario
Peter Gonzalez wrote: Tony, Thank you for clearing up the issue of using EQUATES. I was ready to pile on you along with Les Hewkin. We use EQUATES and live by what they describe. I have learned never to trust DICTS. Wiping my forehead from the sweat. This medium easily allows for such misundertandings. I'll try to be more careful about how I word commentary in the wee-morning hours. I always value your responses, since you where the head guy at Pick Systems RD. Keep writing to this list. thanks. Thank you very much. About Pick Systems, I should clarify that I was not in their RD/Engineering area, I was a support guy for a while and then QA Manager for a couple years, but I was always working directly with Engineering. Prior to PS I was doing some assembly work and I worked with most other MV variants for about 13 years before that. I wouldn't insult Engineering-class people by making anyone think I know these products at their level. I also served as Corporate Technical Account Manager, the technical arm of Sales, and after the change to Raining Data I served as DBMS Product Manager, where I later got cut by the big RDpurge of 2001. These days I tend to comment more on the business aspects of MV, especially with U2 where I'm only qualified to discuss a few technical details based on occasional usage and research. To justify my existence here I've assembled a team of great people to provide U2 services, so if I say we can do something with U2, you can be sure it means I understand the architecture but that we as a team can do the task. Regards, Tony Nebula Research and Development TG@ removethisNebula-RnD .com At 02:34 AM 8/12/2005 -0700, you wrote: I wasn't clear about that at all, sorry. What I meant was that experienced developers don't put a table of 50,000 invoice numbers into a single attribute in the customer master file, or even reserve one atb for open invoices and another one for closed, especially when either one of those atb's can expend beyond a couple thousand values. Equating a name to a dimensioned array element is absolutely standard and IMO preferred practice - sorry if that was confused. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] UniRPC Connection Network Requirements
Catching up on messagesbeen a busy week Whenever I've had problems with this in the past, and it could not be fixed by either their admin or on my side, I've always had to drop back and punt and use a PC Anywhere solution. This way, I'm using an extra PC at their building and the connections are inside their firewall, and everything *just* works. Many of my clients have been unwilling to purchase PC Anywhere, and I just became of a freeware solution called Ultra VNC which does the same thing as PC Anywhere. *I am not plugging them and this is not an add, since it is free and I have no affiliation with them whatsoever* http://www.uvnc.com/ hth! Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Simon Lewington Sent: Wednesday, August 10, 2005 10:59 To: u2-users@listserver.u2ug.org Subject: [U2] [UD] UniRPC Connection Network Requirements Does anyone know what I would need open on a VPN connection to use UniRPC over it? I've got a VPN connection (Check Point VPN-1 Secure Client if that's relevant) to a Unidata 6.1.9 server over which I am unable to use UniAdmin - I get an error dialog Title=RPC Connection Error... Message=No RPC Connection active.. I have a remote desktop connection to this server, and can run UniAdmin from the server desktop connecting to the server, so the UniRPC service is running fine. I can get the same error trying to connect from UniAdmin on my PC to a UD server on my network via a tcp/ip proxy listening on port 31438 - the proxy log shows a little bit of traffic: 10/08/2005 18:42:23 Connection Opened 10/08/2005 18:42:23 From Local l.. 10/08/2005 18:42:23 From Local udadmin60... 10/08/2005 18:42:24 From Remote l....v 10/08/2005 18:42:24 Connection Closed The VPN connection is a customer's, so I can't really experiment with it - I'd like to go straight in with an 'I need xxx' kind of thing. I don't actually want to use UniAdmin if the answer is specific to that - I'm wanting to use UniOleDB which I believe also uses UniRPC. Thanks in advance Simon --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [Maybe spam] RE: [U2] Remove Scenario
I don't specifically recall the guy's name but it's from India or Pakistan or some hindu country. It's not Chandru Murthi though. Thank him for me for making that part of my client's system more consistent than the other half. It's a hybrid of Primac for A/R, G/L, A/P P/O with RESULTS running the Inventory, Order Entry, Sales Analysis. The Primac Job Costing Module is held in a very high regard and my client sorely misses it when they converted to Great Pains and got a rather childish replacement from GP. Thanks. P.S What's that stuff after your name. Looks like a foreign phone number or some computer graphics :) - Original Message - From: Dave Walker [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 3:03 PM Subject: RE: [Maybe spam] RE: [U2] Remove Scenario Interesting. Especially since I have the distinct pleasure of sharing a cubicle wall with one of the original Primac developers. And while the cpylibs work as $INCLUDEs now, we still use cpylib from force of habit. -- Dave Walker 8..7 4(()) -::- -::-8.74 .74(()) ((88.74 ..74 -::- ((88.74 * Peace -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Friday, August 12, 2005 2:22 PM To: u2-users@listserver.u2ug.org Subject: Re: [Maybe spam] RE: [U2] Remove Scenario I agree here. If I had the luxury of writing a complete new application, I would borrow from my Primac experience and use INCLUDE FILE.DEFS CUSTOMER which contains OPEN CUSTOMER TO F.CUSTOMER ELSE STOP (sic) DIM CUST.REC(100) EQUATE CUST.NAMETOCUST.REC(1) etc which virtually forces a uniform nomenclature for the opening of the file (named commons not withstanding), the read-in REC and consistent field names throughout the application. While many of my clients have bits and pieces of these concepts, it's still a scattered mess of crap when it's not application-wide. Primac was so advanced that they didn't wait for MV to come out with the INCLUDE concept. They wrote their own with a pre-compiler that assembled the code. Pretty impressive for 1982. I choose not to use these methods as since my clients (except those with Primac) already have so many half-baked disciplines, what's one more. And while it could be argued that I'm only adding to the fire, I am the current cook in the kitchen. I see so much mis-guided code in my travels that I feel pretty good with my own rather direct form of coding. One mis-use of these Equates was on the per-program level and the application had this throughout their programs: EQUATE CUSTNAME TO CUST.REC(1) EQUATE CUST.NAME TO CUSTOMER(1) EQUATE CNAME TO C(1) EQUATE CUSTNAME TO DATA.CUSTOMER(1) EQUATE CUSTOMER.NAME TO CUSTOMER.REC(1) etc I can't recall now but there were 17 different expressions for the first attribute in the customer file throughout all the programs. Thus, the local use of these equates is just as bad as not using them. Given that there are many ways to abbreviate CUSTOMER NAME, it's hard to remember which gets used when. That's my 2 cent son local equates. Global equates are more preferred. Mark Johnson - Original Message - From: Les Hewkin [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 4:40 AM Subject: RE: [Maybe spam] RE: [U2] Remove Scenario Rubbish,sorry Tony but that's what I think. You say experienced developers and big companies don't use EQU INVNO.TABLE TO CUST(40). I beg to differ. What do you call experienced? does 20 years count??? and what do you call a big company??? we only have two boxes running universe, two HP boxes, one with 32 processors and four logical machines, with over 5k users. We define all our files this way. Our user base is growing all the time as the company grows and our apps just keep on working. Les. -Original Message- From: Tony Gravagno [mailto:[EMAIL PROTECTED] Sent: 12 August 2005 07:23 To: u2-users@listserver.u2ug.org Subject: [Maybe spam] RE: [U2] Remove Scenario Mark Johnson wrote: Here's a doozy. Mark, the fundamental problem is that the original code wasn't designed for the application that it's being asked to do now. That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore because it's such a bad idea. That code was written for small companies and when they get larger it falls apart as you see. It's like generating invoice numbers like this: INV.NUM = (OLD.NUM+1)R%4 Anyone remember day 10,000? This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this
Re: [U2] Remove Scenario
I thought about that and I'm going to incorporate the delimiter at the beginning of each element after using the first. Thanks. Mark - Original Message - From: Stevenson, Charles [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 3:12 PM Subject: RE: [U2] Remove Scenario (I forgot to add delimiters to the X array being built) My original question about memory allocation and overhead while incrementally appending, increasing string length still stands. note 2 changed lines below: From: Stevenson, Charles X = SPACE( 100 ) ;* reserve a million bytes of memory PTR = 1 FOR I = 1 TO 5 GOSUB get.string.to.append X[ PTR, LEN( STRING.TO.APPEND ) ] = STRING.TO.APPEND fix:X[ PTR, LEN( STRING.TO.APPEND ) ] = STRING.TO.APPEND: @AM == PTR+= LEN( STRING.TO.APPEND ) fix:PTR+= LEN( STRING.TO.APPEND ) + 1 = NEXT I X = TRIMB( X ) but now you have trailing attribute mark to deal with... Close enough for an example. You get the idea. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: Re[4]: [U2] Connection Problems with Ud6 and UV10 - unmentioned
Dave: I've found numerous instances where clients, and friends, install AV software that includes firewall software and we have to make sure ___BOTH___ are turned off. To turn off Windows try: Control Panel Security Center then at the bottom under Manage Security Settings: click on Windows Firewall. Make sure the darned thing if Off (not recommended). Next, open your Anti-virus software and look for some kind of Security Settings and make sure that darned software firewall is turned off. Once we get through the collosal pile of s#$% then maybe we can find out what the real problem is. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Tod Sigafoos Sent: Thursday, August 11, 2005 5:31 PM To: Ken Wallis Subject: Re[4]: [U2] Connection Problems with Ud6 and UV10 - unmentioned Ken, Thursday, August 11, 2005, 4:56:18 PM, you wrote: I have turned off as many services as I could and that didn't help. I can only conclude that there is SOMETHING running on this box that keeps UV RPC from working. KW Windows Firewall? Yes .. BUT if you bring up the security screen it says Firewall on. Drill down to the setting and it says it is off .. I am not getting the ' your computer is not protected ' from windows with makes me think SOMETHING is still working to block actual work .. -- DSig ` David Tod Sigafoos ( O O ) ___oOOo__( )__oOOo___ Should any political party attempt to abolish social security, unemployment insurance, and eliminate labor laws and farm programs, you would not hear of that party again in our political history. There is a tiny splinter group, of course, that believes you can do these things. Among them are a few Texas oil millionaires, and an occasional politician or business man from other areas. Their number is negligible and they are stupid. --President Dwight D. Eisenhower, 1954 (source: Eisenhower Presidential Papers, Document #1147; November 8, 1954 The Papers of Dwight David Eisenhower, Volume XV - The Presidency: The Middle Way Part VI: Crises Abroad, Party Problems at Home; September 1954 to December 1954,) Chapter 13: A new phase of political experience --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Remove Scenario
You'd hate Manage-2000. Their DICT.BUILD creates a MFG.LAYOUTS file which creates two INCLUDES for each file. All the dict items are prefixed with the file name, and then the rest of the dict item is at the end. And the standard at which all programmers are forced, er...*encouraged* to use mandate these includes for each file. So everything is like: IF CM.Credit_Limit ARH.Dollars_Outstanding THEN blablabla Makes is a real PITA to work with sometimes. Especially when you have everything memorized by the attr#, and now you have to remember sometimes very similar names for fairly different dict items. And the same for the DEBUG, you'll get a symbol not found and then have to put in CM.RECXX so it really forces you to have to remember or keep a cheat sheet handy when debugging. fwiwAllen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Friday, August 12, 2005 16:32 To: u2-users@listserver.u2ug.org Subject: Re: [Maybe spam] RE: [U2] Remove Scenario I'll go out on a limb here and make a conclusive opinion. I don't like EQUATES inside of a program. That doesn't mean I don't like EQUATES. I just don't like them as some form of higher programming when they are in a program. I do like them in a consistent manner and the way to make them consistent is in an INCLUDE. Thus have a SETUP include that has all of the housekeeping crap like EQUATE TRUE TO 1, FALSE TO 0 EQUATE AM TO CHAR254, 253, 252 ETC PROMPT EQUATE BELL TO CHAR(8) blah, blah, blah. and then have your file-defining EQUATES in their own single INCLUDE. Thus the filehandle, DIM size and all of the things you are trying to normalize are consistent. Like before, I've seen too many scattered examples of half-baked ideas of EQUATES that really don't impress me much. Sometimes I see one or two EQUATES like EQUATE CUSTNAME TO 1 EQUATE PRODDESC TO 6 and they're used properly but in the same program you see: PRINT CUSTRECCUSTNAMEL#30: :CUSTREC49D2/ C'mon. Either all or none at all. That begs the question. EQUATE the attribute number for a dynamic array (compiler replacement) or EQUATE the field for a dimensioned array, (alias concept). I've seen many examples of both but I think they lean more towards the DIM variety. And the survey says... Thanks. - Original Message - From: Marilyn Hilb [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 2:48 PM Subject: RE: [Maybe spam] RE: [U2] Remove Scenario I am on MasterPack. Whenever I 'deliver' a modification with a dictionary on it from one system to another, that process actually re-builds the equate includes for any new dictionary item I may have added. So yup, got lots of these, but not something I or any recent programmer before me did intentionally. -Original Message- From: Mark Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, August 12, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [Maybe spam] RE: [U2] Remove Scenario I'll add another localized comment from my experience. My client with the 17 different expressions of CUSTOMER NAME actually had 17 versions of EQUATE CUST.NAME.ATTRIBUTE TO 1 EQUATE CUSTOMER.NAME.ATT TO 1 EQUATE CNAME.ATR TO 1 etc. So I still stand by my original belief that if these EQUATES are localized as in this example, then you are missing the point and only adding to the confusion. You cannot remember which version is in each different program without going to the top of the program to find it. Only by having these EQUATES in an application-wide INCLUDE concept can its value be realized. Otherwise, it's just another half-baked inconsistent method. My 1 cent. Mark Johnson - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 1:27 PM Subject: Re: [Maybe spam] RE: [U2] Remove Scenario In a message dated 8/12/2005 6:00:10 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Thank you for clearing up the issue of using EQUATES. I was ready to pile on you along with Les Hewkin. We use EQUATES and live by what they describe. I have learned never to trust DICTS. The only problem being (or at least last time I checked) was that RAID doesn't understand EQUATES. So you're walking through the code and see CUST.ADDRESS = '' and you type */CUST.ADDRESS and it says whatever something like variable not found or something I forget. So is there a downside to using a construct like A.CUST.ADDRESS = 40 CUST.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit
Re: [U2] How to find user ID by the USER No. returned by STATUS() function
Pankaj Gupta04 wrote: Hi All, If a record is locked by a program and another program tries to obtain a update lock on the same record then the STATUS() function returns the user number. How can I map this user number to the user id? e.g. A record xyz of ABC123 file is locked by user id 'appsadm'. Now when anyone tries to obtain the lock on the record xyz of ABC123 file then the STATUS() function returns user number: '1230'. How can I obtain the user id of the user (i.e. appsadm) corresponding to the User number? Or how can I obtain the User id without even obtaining the user number? We call a subroutine that captures and parses the output of LIST.READU: Active Record Locks: Device Inode Netnode Userno Lmode Pid Login Id Item-ID. 23048847630 14 24 RU 22386 LFK 81020517 We match the record ID attempting to be read to the record ID column of the LIST.READU output and report that user's login ID. We don't bother trying to match the user number because it would be extremely rare in our environment for different users to have the same ID locked at the same time in two different files. If a user's accessing a customer's information, for example, they will most likely have that customer's record locked in all files that contain customer records. If this isn't true for your environment you might want to match the user no. instead of the record ID in the LIST.READU output. -John -- John Hester System Network Administrator Momentum Group Inc. (949) 833-8886 x623 http://memosamples.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [Maybe spam] RE: [U2] Remove Scenario
Mark: I've said this before many times. Use equates when you later want to alter one or another side of an equality. For example: EQUATE APFILE.BALDUE TO APFILE.REC(2) but don't use an EQUATE to simply assign a value. For example: EQUATE BELL$ TO CHAR(9) If you want to assign a variable simply: BELL$ = CHAR(9) This solves a lot of confusion. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson Sent: Friday, August 12, 2005 4:32 PM To: u2-users@listserver.u2ug.org Subject: Re: [Maybe spam] RE: [U2] Remove Scenario I'll go out on a limb here and make a conclusive opinion. I don't like EQUATES inside of a program. That doesn't mean I don't like EQUATES. I just don't like them as some form of higher programming when they are in a program. I do like them in a consistent manner and the way to make them consistent is in an INCLUDE. Thus have a SETUP include that has all of the housekeeping crap like EQUATE TRUE TO 1, FALSE TO 0 EQUATE AM TO CHAR254, 253, 252 ETC PROMPT EQUATE BELL TO CHAR(8) blah, blah, blah. and then have your file-defining EQUATES in their own single INCLUDE. Thus the filehandle, DIM size and all of the things you are trying to normalize are consistent. Like before, I've seen too many scattered examples of half-baked ideas of EQUATES that really don't impress me much. Sometimes I see one or two EQUATES like EQUATE CUSTNAME TO 1 EQUATE PRODDESC TO 6 and they're used properly but in the same program you see: PRINT CUSTRECCUSTNAMEL#30: :CUSTREC49D2/ C'mon. Either all or none at all. That begs the question. EQUATE the attribute number for a dynamic array (compiler replacement) or EQUATE the field for a dimensioned array, (alias concept). I've seen many examples of both but I think they lean more towards the DIM variety. And the survey says... Thanks. - Original Message - From: Marilyn Hilb [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 2:48 PM Subject: RE: [Maybe spam] RE: [U2] Remove Scenario I am on MasterPack. Whenever I 'deliver' a modification with a dictionary on it from one system to another, that process actually re-builds the equate includes for any new dictionary item I may have added. So yup, got lots of these, but not something I or any recent programmer before me did intentionally. -Original Message- From: Mark Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, August 12, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [Maybe spam] RE: [U2] Remove Scenario I'll add another localized comment from my experience. My client with the 17 different expressions of CUSTOMER NAME actually had 17 versions of EQUATE CUST.NAME.ATTRIBUTE TO 1 EQUATE CUSTOMER.NAME.ATT TO 1 EQUATE CNAME.ATR TO 1 etc. So I still stand by my original belief that if these EQUATES are localized as in this example, then you are missing the point and only adding to the confusion. You cannot remember which version is in each different program without going to the top of the program to find it. Only by having these EQUATES in an application-wide INCLUDE concept can its value be realized. Otherwise, it's just another half-baked inconsistent method. My 1 cent. Mark Johnson - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 1:27 PM Subject: Re: [Maybe spam] RE: [U2] Remove Scenario In a message dated 8/12/2005 6:00:10 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Thank you for clearing up the issue of using EQUATES. I was ready to pile on you along with Les Hewkin. We use EQUATES and live by what they describe. I have learned never to trust DICTS. The only problem being (or at least last time I checked) was that RAID doesn't understand EQUATES. So you're walking through the code and see CUST.ADDRESS = '' and you type */CUST.ADDRESS and it says whatever something like variable not found or something I forget. So is there a downside to using a construct like A.CUST.ADDRESS = 40 CUST.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [Maybe spam] RE: [U2] Remove Scenario
Goo'day, Will At 13:27 12/08/05 -0400, you wrote: In a message dated 8/12/2005 6:00:10 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Thank you for clearing up the issue of using EQUATES. I was ready to pile on you along with Les Hewkin. We use EQUATES and live by what they describe. I have learned never to trust DICTS. The only problem being (or at least last time I checked) was that RAID doesn't understand EQUATES. So you're walking through the code and see CUST.ADDRESS = '' and you type */CUST.ADDRESS and it says whatever something like variable not found or something I forget. Ah yes, but If you're walking through and you see a CUSTdotwhatever you *know* - or at least you *should* know, if you're at *that* level - that CUSTdotwhatever is, the CUSTomer record and whatever refers to a particular field. Ergo: In RAID, CUST(field)/ gives the required response.. No downsides just another* way.. So is there a downside to using a construct like A.CUST.ADDRESS = 40 CUST.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 12/08/05 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 12/08/05 Regards, Bruce Nichol Talon Computer Services ALBURYNSW 2640 Australia http://www.taloncs.com.au Tel: +61 (0)411149636 Fax: +61 (0)260232119 If it ain't broke, fix it till it is! -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 12/08/05 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Remove Scenario
This touches on the downside of the naming styles for variables. It seems like these alias's are an attempt to be like other databases which have no percieved numerical elements, rather TABLENAMEDOTFIELDNAME as the only way to get at the data. In MV you get the best of both worlds. If you have SALES.JAN and SALES.FEB etc as alias's, you can still FOR...NEXT 1-12 to clear them. Your Manage-2000 concept brings forth another question. A data file of 40 fields may have 100 or more dictionary items referencing to those 40 real fields. Does Manage-2000 take coorelative-style dict items into consideration and make them useful in a program or it knows to skip those. If it does then I'd be interested to see how that works. I've tried many ways to include dict items in data/basic programs and all seem tricky at best. It appears that trying to process 002, 007 or 008 correlatives inside of a program is just a different interpeter. And that's beyond my scope to write a dict item interpeter. About the only way that I've been able to use the complete collection of dict items in a program is to create a single record, single field English sentence and CAPTURE the answer (minus the headings and other peripheral stuff). I have a utility for this that I localize per platform and works for both regular and multi-valued fields. It's a little funky on MvBase though. Thanks. Mark Johnson - Original Message - From: Allen E. Elwood [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 7:58 PM Subject: RE: [U2] Remove Scenario You'd hate Manage-2000. Their DICT.BUILD creates a MFG.LAYOUTS file which creates two INCLUDES for each file. All the dict items are prefixed with the file name, and then the rest of the dict item is at the end. And the standard at which all programmers are forced, er...*encouraged* to use mandate these includes for each file. So everything is like: IF CM.Credit_Limit ARH.Dollars_Outstanding THEN blablabla Makes is a real PITA to work with sometimes. Especially when you have everything memorized by the attr#, and now you have to remember sometimes very similar names for fairly different dict items. And the same for the DEBUG, you'll get a symbol not found and then have to put in CM.RECXX so it really forces you to have to remember or keep a cheat sheet handy when debugging. fwiwAllen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Friday, August 12, 2005 16:32 To: u2-users@listserver.u2ug.org Subject: Re: [Maybe spam] RE: [U2] Remove Scenario I'll go out on a limb here and make a conclusive opinion. I don't like EQUATES inside of a program. That doesn't mean I don't like EQUATES. I just don't like them as some form of higher programming when they are in a program. I do like them in a consistent manner and the way to make them consistent is in an INCLUDE. Thus have a SETUP include that has all of the housekeeping crap like EQUATE TRUE TO 1, FALSE TO 0 EQUATE AM TO CHAR254, 253, 252 ETC PROMPT EQUATE BELL TO CHAR(8) blah, blah, blah. and then have your file-defining EQUATES in their own single INCLUDE. Thus the filehandle, DIM size and all of the things you are trying to normalize are consistent. Like before, I've seen too many scattered examples of half-baked ideas of EQUATES that really don't impress me much. Sometimes I see one or two EQUATES like EQUATE CUSTNAME TO 1 EQUATE PRODDESC TO 6 and they're used properly but in the same program you see: PRINT CUSTRECCUSTNAMEL#30: :CUSTREC49D2/ C'mon. Either all or none at all. That begs the question. EQUATE the attribute number for a dynamic array (compiler replacement) or EQUATE the field for a dimensioned array, (alias concept). I've seen many examples of both but I think they lean more towards the DIM variety. And the survey says... Thanks. - Original Message - From: Marilyn Hilb [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 2:48 PM Subject: RE: [Maybe spam] RE: [U2] Remove Scenario I am on MasterPack. Whenever I 'deliver' a modification with a dictionary on it from one system to another, that process actually re-builds the equate includes for any new dictionary item I may have added. So yup, got lots of these, but not something I or any recent programmer before me did intentionally. -Original Message- From: Mark Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, August 12, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [Maybe spam] RE: [U2] Remove Scenario I'll add another localized comment from my experience. My client with the 17 different expressions of CUSTOMER NAME actually had 17 versions of EQUATE CUST.NAME.ATTRIBUTE TO 1 EQUATE CUSTOMER.NAME.ATT TO 1 EQUATE CNAME.ATR TO 1 etc. So I still stand by my original belief that if these EQUATES are localized as in
Re: [Maybe spam] RE: [U2] Remove Scenario
Not for nothin' but I believe there's more to the variable assignment version of an equate than you've expressed. In essence, there are 2 kinds of EQUATES. The first style, sometimes known as an alias, is like your EQUATE APFILE.BALDUE TO APFILE.REC(2) and you can manage the contents of the second field in the A/P record either using the left portion of the TO or the right. The second style is more on the compiler level and not a simple variable assignment. EQUATE TRUE TO 1 causes the compiler to replace the expression TRUE inside the source code with the literal value '1'. Then it compiles. This is different than TRUE=1 which occurs at run-time. Quite frankly I really, really don't think the assignment version matters with today's processors. This theory has been around since Jurrasic Pick and may have made more of a difference back then. Today, saving 5-10 cpu cycles per second is drop-dead useless regardless of how many users there are. Even on a 500 user system, that's 5,000 savings against 2,800,000,000. Hardly noticable. Only the lunatic fringe or purely academic can support that argument. I think the EQUATE TRUE TO 1 comes from a taught programming discipline from a long time ago and, like many learned things, isn't bad so it doesn't need replacing. But I don't think it's necessary. EQUATE CUSTNAME TO 1 falls into the same assignment category. This borders more on documenting the program than programming in it. Technically speaking, you're wasting time with an equate like this as many times the programmer will use PRINT CUSTREC1 and the pre-compiler would have wasted those few precious cycles replacing the text CUSTNAME with the digit 1. Thus the argument should be had for the human programmer's effeciency and not the program's. Before the flames come, I'm not endorsing bad coding. But to have EQUATE CUST.AR.BAL TO 49 at the top (or buried in an INCLUDE) and trying to debug (or read) a program with a problem in that area means more work for me. Considering that the editor is purely numeric, if field 49 is screwed up somehow and I have a program filled with indirect references, I have to print out that roadmap to see the reference. Plus there is a good chance (except for Manage-2000 I guess) that the outside dict names don't always (or can't) be used for internal variable names. There's a dozen ways to express CUSTOMER NAME and only one way to express '1'. I remember a senior programmer in 1978 printing out the map of the compiled program and trying to insure that a FOR...NEXT loop fell within the boundaries of a single object code frame. That's inconcievable today. BTW, I don't subscribe to EQUATEing variables (nor alias's for that matter) as my client's code is far too scattered to introduce this level of overhead. My INCLUDE SETUP is all equal signs and I don't use File Defining INCLUDES unless the entire (or virtually entire) application is that way (Primac). Thus I guess I am a keeper of the standard manual coding styles. One other thing. I know where the $ in BELL$ came from but tell me why you use it. I've seen it before in SAS but never have used it in any MV programming except if previously used. Just interested, that all. Mark Johnson - Original Message - From: Bill_H [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 12, 2005 8:35 PM Subject: RE: [Maybe spam] RE: [U2] Remove Scenario Mark: I've said this before many times. Use equates when you later want to alter one or another side of an equality. For example: EQUATE APFILE.BALDUE TO APFILE.REC(2) but don't use an EQUATE to simply assign a value. For example: EQUATE BELL$ TO CHAR(9) If you want to assign a variable simply: BELL$ = CHAR(9) This solves a lot of confusion. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson Sent: Friday, August 12, 2005 4:32 PM To: u2-users@listserver.u2ug.org Subject: Re: [Maybe spam] RE: [U2] Remove Scenario I'll go out on a limb here and make a conclusive opinion. I don't like EQUATES inside of a program. That doesn't mean I don't like EQUATES. I just don't like them as some form of higher programming when they are in a program. I do like them in a consistent manner and the way to make them consistent is in an INCLUDE. Thus have a SETUP include that has all of the housekeeping crap like EQUATE TRUE TO 1, FALSE TO 0 EQUATE AM TO CHAR254, 253, 252 ETC PROMPT EQUATE BELL TO CHAR(8) blah, blah, blah. and then have your file-defining EQUATES in their own single INCLUDE. Thus the filehandle, DIM size and all of the things you are trying to normalize are consistent. Like before, I've seen too many scattered examples of half-baked ideas of EQUATES that really don't impress me much. Sometimes I see one or two EQUATES like EQUATE CUSTNAME TO 1 EQUATE PRODDESC TO 6 and they're used properly but in the same program you see:
