Re: [UV] Problem reactivating select list
Thanks to everyone for all the suggestions. Turns out the solution was relatively simple. I just needed to use PERFORM ED instead of EXECUTE ED to make ED run in the wrapper program's workspace. This is in PICK flavor. Seems like I once knew the difference between EXECUTE and PERFORM in PICK flavor, but I forgot. Reading through all the posts jogged my memory. To answer some of the questions as to why I chose this particular route: I prefer to never copy and modify the system utilities themselves because I'm then relegated to that version of the tool and miss out on any fixes/enhancements in later UV releases. There's also the possibility that the current version won't work correctly in later releases. I'd rather not have the ongoing maintenance and overhead of adding triggers to every file in the database (and can't in UV 9.6 anyway). Also one of the main benefits of the audit trail is capturing changes to BPs and procs that reside in type 19 files. As to the issue of people finding loopholes in ED to get around the auditing, that's not really a big concern. We have good people here and this is more of a tool to assist them rather than being big brother. If someone has to quickly fix some data on the fly and they fail to document it, now they have automatic documentation to fall back on. Thanks, John -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
Triggers would be nice, but the'd have to work on type19 files. Modifying ED is simple, but you might want to wrap other verbs, so generalized wrapper pgm is good. Protect the vanilla versions of ED, DELETE, UPDATE.RECORD, REVISE as 'remote-controlled' R-items that will only execute if executed by wrapper. In wrapper, just capture/save the active select list, then reuse it 3 times: (1st) to capture the before version of all records, (2nd) to do ED, UPDATE.RECORD, REVISE, DELETE, or whatever else you are wrapping, then (3rd) to compare the before & after versions. How to capture & reactiveate the list is up to you, but I guess that's the root of the question, isn't it? The flavors handle list variables differently: getlist, savelist, formlist, passlist, etc. $OPTIONS IDEAL makes pgm conform to documentation. Pick flavor is poorly documented (in my exalted opinion). There is a config option for PERFORM & EXECUTE. The following silly example uses methods that do essentially what you need, (uv 10.0, pick flavor account): >CT CDS.BP HESTER HESTER 0001 $OPTIONS -VAR.SELECT ;* (I like ideal behavior, not Pick) 0002 READLIST LIST FROM 0 ELSE LIST = something from command line? 0003 FORMLIST LIST TO 0 0004 DATA 'Y' 0005 PERFORM 'COPYI FROM VOC TO VOCLIB' 0006 FORMLIST LIST TO 0 0007 PERFORM 'ED VOC' 0008 LOOP 0009 REMOVE ID FROM LIST SETTING MORE 0010 CRT ID, 'compare old to new...' 0011 WHILE MORE 0012 REPEAT 0013END > >SELECT VOC SAMPLE 10 record(s) selected to SELECT list #0. >>NSELECT VOCLIB 10 record(s) selected to SELECT list #0. >>RUN CDS.BP HESTER You have an active SELECT list. Do you wish to copy the records previously SELECTed? The first record ID = "HASH.TEST". Enter Y or N: 10 records copied. SELECTed record name = "HASH.TEST". 8 lines long. : 1 0001: V : A X 0001: V X : FI "HASH.TEST" filed in file "VOC". SELECTed record name = "QUIT.KEY". 2 lines long. : 1 0001: X : A 0001: X X : FI "QUIT.KEY" filed in file "VOC". SELECTed record name = "CLEAR.LOCKS". 4 lines long. : X HASH.TEST compare old to new... QUIT.KEY compare old to new... CLEAR.LOCKS compare old to new... >=compare old to new... DIVX compare old to new... = compare old to new... MENU.DOC compare old to new... >2UP VOC VOCLIB HASH.TEST QUIT.KEY CLEAR.LOCKS /home_app/cds3389612:19:42pm 27 Apr 2004 Pg . 1 File: VOC VOCLIB Rec: HASH.TEST HASH.TEST ---1: V X # V 0002: hash.test | hash.test 0003: E | E 0004: GSP | GSP 0005: | 0006: | 0007: P}N | P}N 0008: LPTR}NOPAGE | LPTR}NOPAGE 1 difference(s) __ Rec: QUIT.KEY QUIT.KEY ---1: X X # X 0002: ACLQ | ACLQ 1 difference(s) __ Rec: CLEAR.LOCKS CLEAR.LOCKS 0001: V | V 0002: CLEAR.LOCKS | CLEAR.LOCKS 0003: I | I 0004: G | G 0 difference(s) > >.L RELLEVEL RELLEVEL 001 X 002 10.0.16 003 PICK 004 PICK.FORMAT 005 10.0.16 -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list[Scanned]
We've used alternate indexes to do trigger type processing since 1990. In our case, we do it to handle two situations: 1. Track the records that have changed to handle secondary key updates for files where the secondary data isn't really in the file. We have a master person file for our police application. Rather than select the persons with a specific name and then look for the crime records for that person, we keep the person names in an attribute in the crime report records. Note, we did efficiency analysis on PI rev 7 to determine which made the most sense. I'm not sure if it would make as much sense now but it was significantly faster back then to handle it this way. 2. Track the records that have changed to handle updates of other databases. We have GIS applications that use other databases. These databases are updated at night from our main Universe system based on what records have changed during the day. My late co-worker, Rob Fisher, and I used stuff from several sources including Gyle Iverson and Lee Leitner to flesh out this idea. We even wrote our own paper on it way back in 1991. Georgia Pritchett City of Salinas > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Hona, David S > Sent: Monday, April 26, 2004 11:04 PM > To: 'U2 Users Discussion List' > Subject: RE: [UV] Problem reactivating select list[Scanned] > > > Triggers have more overhead associated with them: > - you have install the trigger in all your hashed files/tables > IIRC, you can't have triggers on non-hashed file types. > Regards, > David > -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
John, Why write a wrapper? ED is a scrudgy BASIC program - (uv Account BP ED.B). You could just modify that. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hester Sent: 26 April 2004 22:22 To: U2 Users Discussion List Subject: [UV] Problem reactivating select list I wrote a wrapper for the ED command last week to keep an audit trail of any changes made to files outside our applications. I'm just writing a before and after version of an edited record to a temp file and comparing afterwards. All seemed fine until one of my coworkers informed me he could no longer use "X" to drop back to TCL after editing from a select list. This was due to the fact that I was processing the select list in the wrapper program and just executing ED once for each record. For "X" to work as it used to, I need to write out all the selected records at the beginning, let ED process the select list, then go back through the list again for comparison. Here's the problem: No matter what I do, I can't get ED to recognize an active select list that is activated within the wrapper program. I use "READLIST ITEMS" at the beginning to get the list of items to write to the temp file, then "SELECTN ITEMS TO 0" prior to executing ED. I also tried writing the list to &SAVEDLISTS& and executing "GET.LIST ":TEMP.LIST prior to executing ED, but got the same result. These two test programs illustrate the problem: BP TEST.READLIST 0001: READLIST ITEMS ELSE ITEMS = '' 0002: PRINT 'CONTENTS OF ITEMS=':ITEMS 0003: SELECTN ITEMS TO 0 0004: EXECUTE 'RUN BP TEST.READLIST2' 0005: LOOP 0006: READNEXT ITEM ELSE EXIT 0007: PRINT 'READNEXT ITEM=':ITEM 0008: REPEAT 0009: END BP TEST.READLIST2 0001: READLIST ITEMS ELSE ITEMS = '' 0002: PRINT 'CONTENTS OF ITEMS=':ITEMS 0003: END Output: >SELECT BP SAMPLE 10 10 record(s) selected to SELECT list #0. >>RUN BP TEST.READLIST CONTENTS OF ITEMS=1 2 3 4 5 DD FF MCT1 T2 CONTENTS OF ITEMS= READNEXT ITEM=1 READNEXT ITEM=2 READNEXT ITEM=3 READNEXT ITEM=4 READNEXT ITEM=5 READNEXT ITEM=DD READNEXT ITEM=FF READNEXT ITEM=MC READNEXT ITEM=T1 READNEXT ITEM=T2 Clearly the select list is activated by SELECTN because the subsequent READNEXT works, but the executed program can't see an active select list. Is there any way around this? I'd hate to have to make a modified copy of the UV ED command, but that's the only alternative I see at this point. TIA, John -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users This email was checked by MessageLabs SkyScan before entering Microgen. This email was checked on leaving Microgen for viruses, similar malicious code and inappropriate content by MessageLabs SkyScan. DISCLAIMER This email and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information. In the event of any technical difficulty with this email, please contact the sender or [EMAIL PROTECTED] Microgen Information Management Solutions http://www.microgen.co.uk -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
It appears that ED is aware of an active select list 0, even when it is not using it. Interesting behavior - is this a bug or feature? Well, in INFORMATION flavour accounts - at least! In INFORMATION flavour, when you 'X' out, this appears to kill the active select list 0. Hence, upon the next invocation of READNEXT, this will take the ELSE clause, resulting in the termination of the loop. As Adrian pointed out, UV account flavour does change the behavior of some functions/statements. So this could be how it works in INFORMATION and PI/Open accounts. Hence, you can use "N", "Q" and "X" out, at least in INFORMATION flavour, with this code fragment... loop readnext KEY then execute "ED filename ":KEY else exit repeat If the above doesn't work for you, try adding the following (note it may have adverse effects on other EXECUTEs in your code) compiler option at the top of your code. $OPTIONS EXEC.EQ.PERF Regards, David [EMAIL PROTECTED] wrote: > > John what is wrong with this approach > loop >readnext id else done = true > until done do >list<-1> = id > repeat > select list to mylist > loop >readnext id else done = true > until done do >execute "ed ":file:" ":id > repeat > > then before, after, between the two loops you can do whatever you wanted to do > Will That's close to what I did originally. The problem is that ED needs to think that it is reading from a select list for the "X" command to work. If I process the select list outside of ED, ED thinks it is working against a single item and the only way you can exit the middle of a list is with . -John -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
Hi John, I think the problem you are seeing is a result of the EXECUTE command being executed in a separate shell or workspace. It can't see your select list. There are a couple of ways around this, use the PASSLIST keyword in the EXECUTE command (that is for ideal flavour, your mileage may vary according to your own flavour. It is all documented in the manual 8-)) or use a SAVE-LIST and then use the DATA statement to stack a GET-LIST command before you execute your ED statement. Regards David Logan Database Administrator HP Managed Services 139 Frome Street, Adelaide 5000 Australia +61 8 8408 4273 - Work +61 417 268 665 - Mobile +61 8 8408 4259 - Fax -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, 27 April 2004 11:29 AM To: [EMAIL PROTECTED] Subject: RE: [UV] Problem reactivating select list Other things to consider: 1. What happens if someone uses XEQ within ED to edit another record. 2. What about people using UPDATE.RECORD 3. And what about REVISE (ENTRO/MODIFY) There are many different ways to get around audit trails if people want to. AdrianW -Original Message- From: John Hester [mailto:[EMAIL PROTECTED] Sent: Tuesday, 27 April 2004 05:22 To: U2 Users Discussion List Subject: [UV] Problem reactivating select list I wrote a wrapper for the ED command last week to keep an audit trail of any changes made to files outside our applications. I'm just writing a before and after version of an edited record to a temp file and comparing afterwards. All seemed fine until one of my coworkers informed me he could no longer use "X" to drop back to TCL after editing from a select list. This was due to the fact that I was processing the select list in the wrapper program and just executing ED once for each record. For "X" to work as it used to, I need to write out all the selected records at the beginning, let ED process the select list, then go back through the list again for comparison. Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
Triggers have more overhead associated with them: - you have install the trigger in all your hashed files/tables IIRC, you can't have triggers on non-hashed file types. Regards, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ray Wurlod Sent: Tuesday, April 27, 2004 3:40 PM To: U2 Users Discussion List Subject: RE: [UV] Problem reactivating select list Have you thought of using trigger subroutines to keep the audit trail? Much easier, and the before- and after-records and keys are available for you right there in the arguments. :D -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
Have you thought of using trigger subroutines to keep the audit trail? Much easier, and the before- and after-records and keys are available for you right there in the arguments. :D -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
Why not write a little paragraph that does the select, then ED, which you execute ? Ross Ferris Stamina Software Visage – an Evolution in Software Development >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of John Hester >Sent: Tuesday, 27 April 2004 9:12 AM >To: U2 Users Discussion List >Subject: Re: [UV] Problem reactivating select list > >[EMAIL PROTECTED] wrote: > >> >> John what is wrong with this approach >> loop >>readnext id else done = true >> until done do >>list<-1> = id >> repeat >> select list to mylist >> loop >>readnext id else done = true >> until done do >>execute "ed ":file:" ":id >> repeat >> >> then before, after, between the two loops you can do whatever you wanted >to do >> Will > >That's close to what I did originally. The problem is that ED needs to >think that it is reading from a select list for the "X" command to work. > If I process the select list outside of ED, ED thinks it is working >against a single item and the only way you can exit the middle of a list >is with . > >-John > >-- >u2-users mailing list >[EMAIL PROTECTED] >http://www.oliver.com/mailman/listinfo/u2-users > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.667 / Virus Database: 429 - Release Date: 23/04/2004 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.667 / Virus Database: 429 - Release Date: 23/04/2004 -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] Problem reactivating select list
You're not wrong. Triggers on files came in at rev 10. -- Regards, Clif On Apr 26, 2004, at 18:21, John Hester wrote: Correct me if I'm wrong, but on UV 9.6 I think I'd have to convert every UV file to a SQL table to be able to use a trigger. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] Problem reactivating select list
You might try this. I am not on a system right now, so I can't test this until later. -- Regards, Clif ~~~ W. Clifton Oliver, CCP CLIFTON OLIVER & ASSOCIATES Tel: +1 619 460 5678Web: www.oliver.com ~~~ saveList = "" loop while readnext recordId saveList<-1> = recordId repeat open "&SAVEDLISTS&" to slFile else abortm "Cannot open &SAVEDLISTS&" tempId = ("temp" : @userno) write saveList on slFile, tempId close slFile execute ("GET.LIST " : tempId) execute ("ED " : yourFileName) On Apr 26, 2004, at 18:11, John Hester wrote: [EMAIL PROTECTED] wrote: John what is wrong with this approach loop readnext id else done = true until done do list<-1> = id repeat select list to mylist loop readnext id else done = true until done do execute "ed ":file:" ":id repeat then before, after, between the two loops you can do whatever you wanted to do Will That's close to what I did originally. The problem is that ED needs to think that it is reading from a select list for the "X" command to work. If I process the select list outside of ED, ED thinks it is working against a single item and the only way you can exit the middle of a list is with . -John -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
Other things to consider: 1. What happens if someone uses XEQ within ED to edit another record. 2. What about people using UPDATE.RECORD 3. And what about REVISE (ENTRO/MODIFY) There are many different ways to get around audit trails if people want to. AdrianW -Original Message- From: John Hester [mailto:[EMAIL PROTECTED] Sent: Tuesday, 27 April 2004 05:22 To: U2 Users Discussion List Subject: [UV] Problem reactivating select list I wrote a wrapper for the ED command last week to keep an audit trail of any changes made to files outside our applications. I'm just writing a before and after version of an edited record to a temp file and comparing afterwards. All seemed fine until one of my coworkers informed me he could no longer use "X" to drop back to TCL after editing from a select list. This was due to the fact that I was processing the select list in the wrapper program and just executing ED once for each record. For "X" to work as it used to, I need to write out all the selected records at the beginning, let ED process the select list, then go back through the list again for comparison. Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
We don't have this type of problem using PI/Open flavour - something to do with EXECUTE being run in a different process space under other flavours. Have a look at the PASSLIST keyword that can be used with EXECUTE. Something like: READLIST ID.LIST ELSE STOP EXECUTE "ED filename " PASSLIST ID.LIST AdrianW -Original Message- From: John Hester [mailto:[EMAIL PROTECTED] Sent: Tuesday, 27 April 2004 05:22 To: U2 Users Discussion List Subject: [UV] Problem reactivating select list I wrote a wrapper for the ED command last week to keep an audit trail of any changes made to files outside our applications. I'm just writing a before and after version of an edited record to a temp file and comparing afterwards. All seemed fine until one of my coworkers informed me he could no longer use "X" to drop back to TCL after editing from a select list. This was due to the fact that I was processing the select list in the wrapper program and just executing ED once for each record. For "X" to work as it used to, I need to write out all the selected records at the beginning, let ED process the select list, then go back through the list again for comparison. Here's the problem: No matter what I do, I can't get ED to recognize an active select list that is activated within the wrapper program. I use "READLIST ITEMS" at the beginning to get the list of items to write to the temp file, then "SELECTN ITEMS TO 0" prior to executing ED. I also tried writing the list to &SAVEDLISTS& and executing "GET.LIST ":TEMP.LIST prior to executing ED, but got the same result. These two test programs illustrate the problem: BP TEST.READLIST 0001: READLIST ITEMS ELSE ITEMS = '' 0002: PRINT 'CONTENTS OF ITEMS=':ITEMS 0003: SELECTN ITEMS TO 0 0004: EXECUTE 'RUN BP TEST.READLIST2' 0005: LOOP 0006: READNEXT ITEM ELSE EXIT 0007: PRINT 'READNEXT ITEM=':ITEM 0008: REPEAT 0009: END BP TEST.READLIST2 0001: READLIST ITEMS ELSE ITEMS = '' 0002: PRINT 'CONTENTS OF ITEMS=':ITEMS 0003: END Output: >SELECT BP SAMPLE 10 10 record(s) selected to SELECT list #0. >>RUN BP TEST.READLIST CONTENTS OF ITEMS=1 2 3 4 5 DD FF MCT1 T2 CONTENTS OF ITEMS= READNEXT ITEM=1 READNEXT ITEM=2 READNEXT ITEM=3 READNEXT ITEM=4 READNEXT ITEM=5 READNEXT ITEM=DD READNEXT ITEM=FF READNEXT ITEM=MC READNEXT ITEM=T1 READNEXT ITEM=T2 Clearly the select list is activated by SELECTN because the subsequent READNEXT works, but the executed program can't see an active select list. Is there any way around this? I'd hate to have to make a modified copy of the UV ED command, but that's the only alternative I see at this point. TIA, John -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
Humm...got me there...don't know when they added the ability to create Triggers on Non-SQL tables? > Correct me if I'm wrong, but on UV 9.6 I think I'd have to > convert every > UV file to a SQL table to be able to use a trigger. > __ This e-mail, including any attachments, may contain information that is protected by law as privileged and confidential, and is transmitted for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying or retention of this e-mail or the information contained herein is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by telephone or reply e-mail, and permanently delete this e-mail from your computer system. Thank you. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] Problem reactivating select list
Mark Eastwood wrote: Have you looked at "Triggers" ? I wrote a wrapper for the ED command last week to keep an audit trail of any changes made to files outside our applications. I'm just writing a before and after version of an edited record to a temp file and comparing afterwards. Correct me if I'm wrong, but on UV 9.6 I think I'd have to convert every UV file to a SQL table to be able to use a trigger. -John -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] Problem reactivating select list
[EMAIL PROTECTED] wrote: John what is wrong with this approach loop readnext id else done = true until done do list<-1> = id repeat select list to mylist loop readnext id else done = true until done do execute "ed ":file:" ":id repeat then before, after, between the two loops you can do whatever you wanted to do Will That's close to what I did originally. The problem is that ED needs to think that it is reading from a select list for the "X" command to work. If I process the select list outside of ED, ED thinks it is working against a single item and the only way you can exit the middle of a list is with . -John -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] Problem reactivating select list
In a message dated 4/26/2004 5:22:07 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: > I wrote a wrapper for the ED command last week to keep an audit trail of > any changes made to files outside our applications. I'm just writing a > before and after version of an edited record to a temp file and > comparing afterwards. All seemed fine until one of my coworkers > informed me he could no longer use "X" to drop back to TCL after editing > from a select list. This was due to the fact that I was processing the > select list in the wrapper program and just executing ED once for each > record. For "X" to work as it used to, I need to write out all the > selected records at the beginning, let ED process the select list, then > go back through the list again for comparison. > > Here's the problem: > No matter what I do, I can't get ED to recognize an active select list > that is activated within the wrapper program. I use "READLIST ITEMS" at > the beginning to get the list of items to write to the temp file, then > "SELECTN ITEMS TO 0" prior to executing ED. I also tried writing the > list to &SAVEDLISTS& and executing "GET.LIST ":TEMP.LIST prior to > executing ED, but got the same result. These two test > programs > illustrate the problem: John what is wrong with this approach loop readnext id else done = true until done do list<-1> = id repeat select list to mylist loop readnext id else done = true until done do execute "ed ":file:" ":id repeat then before, after, between the two loops you can do whatever you wanted to do Will -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Problem reactivating select list
Have you looked at "Triggers" ? > > I wrote a wrapper for the ED command last week to keep an > audit trail of > any changes made to files outside our applications. I'm just > writing a > before and after version of an edited record to a temp file and > comparing afterwards. > __ This e-mail, including any attachments, may contain information that is protected by law as privileged and confidential, and is transmitted for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying or retention of this e-mail or the information contained herein is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by telephone or reply e-mail, and permanently delete this e-mail from your computer system. Thank you. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users