RE: [U2] UniData PROC tip: DB command
Baker Hughes wrote The man (person) who writes a PROC interpreter/conversion utility that can take a PROC and turn it into either Basic, or a PAragraph, will have a product to sell... I tried really really really hard to do this a few years ago. The code got more and more complicated until I threw in the towel. Then I realised that it was easier to write a PROC interpreter in BASIC, and that I could re-use the code I had, but that it would be much, much simpler and clearer. Although I never finished it, Martin Phillips took it on from there and did the hard work so that QM had a PROC interpreter. We all know what grinding out that last 20% is like! I was as pleased as punch that I could contribute something to QM because it's such a good product, and the support has always been exceptional. The code (at the stage I got it to) is the programs RUNPROC and CALLPROC in http://www.geocities.com/pickfalla/programs.html. If you have an _extremely_ wet week end (our last few have been atrocious) it might be something to look at. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] CAPTURING TOXML
Following on from Mike Henderson's post... Maybe the best idea is to use GETXMLSUB itself as your subroutine call. It handles the case where the XMLExecute function returns a fail status, but a subsequent XMLGetError function doesn't have an error code by assigning a new error code of 80120 and an errmsg of "query/sql syntax error". It has 6 arguments documented in the code as follows - 006: * argument count 6 007: * 008: * input 1 CMD the LIST/SELECT command used to generate xml doc 009: * input 2 options: any dynamic array like string to store options for the TOXML 010: * command 011: * output 3 XMLSTR, result xml document 012: * output 4 XSDSTR, result xsd schema 013: * output 5 RTNCODE. 014: * output errmsg if RTNCODE <> 0 Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Multiple columns from a LIST statement?
Using LIST.LABEL (on a Universe system) EVAL can create a dummy column
mergeing
two columns and you can replicate column headings using the page heading
as below.
LIST.LABEL TRANSACTION EVAL
"FMT(@ID,'L#15'):FMT(OCONV(TRAN.AMOUNT,'MD2$,'),'R#15')" ID-SUPP
HEADING "ID Amount ID
Amount"
Answer the prompt like this,
COUNT, ROWS, SKIP, INDENT, SIZE, SPACE {,C} ?2,1,0,0,30,2
and here is the output
ID Amount ID Amount
183046|11645|19 $2.49 28282|14248|147 $-0.34
99305|12650|116$201.58 16308|13753|169 $84.77
11495|14099|141$-23.14 2143|13275|16 $162.17
21782|14617|506$164.09 21782|14617|749$213.35
33661|12995|103 $23.21 92635|13095|635 $2.49
Note that TRAN.AMOUNT already had an output conversion, but I had to put
one inside the EVAL statement.
Regards, Keith
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] execute code/proc question HELP!!!!!!!!
Assume one has PROGRAM in USUAL.BP. Write NEW.PROGRAM in DOUGS.BP with this at the beginning. 001 SUBROUTINE PROGRAM(V1,V2,V3...) 002 * 003 IF @LOGNAME NE "DOUG" THEN 004CALL ORIG.PROGRAM(V1,V2,V3...) 005RETURN 006 END 007 * continue with the new program At TCL do these commands CATALOG USUAL.BP ORIG.PROGRAM PROGRAM CATALOG DOUGS.BP PROGRAM NEW.PROGRAM The calling program(s) need no changes and when testing is finished, copy the new version of PROGRAM to USUAL.BP, delete lines 3-6 above, then compile and catalog it. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Scared to recompile
Using VLIST to compare old and new programs is a good idea. You're probably OK on 10.1, but if you want to do this in future, be aware that VLIST may crash on UV 10.2 when used on older programs. If this happens, change the 8th character from 000 to 016. VLIST may then work, although the code and object probably will get out of synch. Another option is to strip off the header on both strings - I think 80 characters may be enough. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Universe XML is not to standard
Michael Rajkowski wrote "First, capturing the XML to a hold file is not the way to get an XML file." Someone really ought to put this into the documentation! Retrieve manual page 6-17 specifically states "Note: UniVerse does not store the XML document unless you execute the COMO ON statement prior to executing the RetrieVe statement. If you execute COMO ON, the XML document is stored in the &COMO& file. You can also direct the output to the &HOLD& file using SETPTR, or the printer using LPTR." XMLEXECUTE does what I want, true; but why doesn't the recommended, documented, simple-to-implement method work properly too? Then there's the UTF-8 vs iso8859-1 issue that Stuart Boydell identified - another *gotcha* waiting for us. Just tidy things up... there's no benefit to IBM in acting like stRaining Data. Regards, Keith (I really should turn the grumpy_old_%^$_mode off) Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Universe XML is not to standard
The software I am supporting has a user screen which builds and saves enquiry statements (English/Access/Recall). I recently created another screen to allow users to use the defined statement/report to output XML to the &HOLD& file and to transfer the results to their PC. All well and good, but then I found that Excel wouldn't pick up the results properly. The reason for this is that the XML output is not quite to the standard. For example, the command >LIST VOC 'VOC' F1 F2 TOXML gives the result -- -- While the command >LIST VOC 'VOC' F1 F2 TOXML HEADING "WAHOO 'D'" gives the result -- WAHOO 08 May 2008 -- It's not absolutely clear from the W3C standard itself, but it is very clear from the examples given with it; that the output must start with the string " <-- report heading follows WAHOO 08 May 2008 --> -- Does anyone else agree with me? Ought IBM change this? What do you think? Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] blank lines in code / mixed case
On Mon, 10 Mar 2008, Jerry Banker wrote...
> If you ever want a scare then go through the programs in the Universe
BP
> file. Some are upper case program lines with mixed case comments and
> prompts, the way I prefer it, some are all lower case, some are mixed
> case, and some are a mixture of all types. In the latter it appears
that
> whomever was programming at the time picked their preferred case. So
it
> appears not only we mere mortals have a problem deciding what standard
> to use.
If you REALLY want a scare go and look in Universe BP at "RETURN TO"
usage.
In PHELP it even mixes case use!
("return to end.program" and "return to RETRY.SORT.BOX")
Regards, Keith
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE:[U2] Change Prompt
In Universe, the following program (called PATH) will do this. To use it, just put PATH in the LOGIN command. PATH CLEAR puts things back to how they were. PATH FULL gives the full path name at the input prompt. == PATH program v SENTENCE = UPCASE(@SENTENCE) THIS = '' ; THAT = 1 BEGIN CASE CASE INDEX(SENTENCE,'CLEAR',1) ; THAT = 0 CASE INDEX(SENTENCE,'FULL',1) ; THIS = @PATH:'>' CASE 1 ; THIS = FIELD(@PATH,'/',DCOUNT(@PATH,'/')):'>' END CASE IF THIS NE '' THEN THIS<2> = THIS<1>:'>' THIS<3> = '+' END ASSIGN THIS TO SYSTEM(4002) ASSIGN THAT TO SYSTEM(4001) == PATH program ^ This version is for a UNIX system, you may have to change the '/' to '\' on Windows SYSTEM(91) = 0 on UNIX SYSTEM(91) = 1 on Windows Regards, Keith P.S. A great benefit of this is that you can then edit the command stack using the arrow keys. You have to use backspace to delete, though. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] CSV output
These might be useful. To save typing, I decided to use Q for QUOTE, C for COMMA and T for TAB. And since I thought it likely that I would use QUOTE COMMA QUOTE (or "Q C Q") a lot, I also set up D (for DELIMITER) as below. Also q and d which use double quotes. Top of "D" in "VOC", 20 lines, 108 characters. 001: I 002: "','" 003: 004: ',' 005: 3L 006: S I should point out that it's been my practice to remove the "Q" and "P" commands because otherwise I stumble over them. Usually just after a big session in the editor, when my mind is in that problem-focused state where it takes a while to realise just what the heck happened. Maybe it's something in our setup, but I have ITEM.ID in DICT.DICT and get an '"ITEM.ID" not found' error if I try and use it in a query. There is the same error if I try and use D/CODE (which is in DICT.PICK) in a query. Quite apart from that, on our system these files are read-only; so what I do is put the items in DICT VOC, compile them by using them in a query, and then copy them to VOC so they are available for every file. It's not really worth anything - speed of machines these days, etc. etc. - but using CHAR(9) results in slightly longer compiled code. I really do need to get a life, don't I? Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Deep and long indentations vs multiple exit points
Dave Barret gave this code as an example: GOSUB OPERATION.1 IF (NOT(ERROR)) THEN GOSUB OPERATION.2 IF (NOT(ERROR)) THEN GOSUB OPERATION.3 IF (NOT(ERROR)) THEN GOSUB OPEARTION.4 END END END What about this version? GOSUB OPERATION.1 IF ERROR ELSE GOSUB OPERATION.2 IF ERROR ELSE GOSUB OPERATION.4 IF ERROR ELSE GOSUB OPERATION.5 or, more acceptably: GOSUB OPERATION.1 IF GOOD THEN GOSUB OPERATION.2 IF GOOD THEN GOSUB OPERATION.4 IF GOOD THEN GOSUB OPERATION.5 Which I personally find far more readable than the indented code. Regards, Keith "De gustibus non est disputandum" Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Can I get some advice on triggers?
A big Thank You to everyone for the information. In the end it was straightforward, but I stumbled on a couple of the steps. Maybe this will help others Firstly, I wanted the code to be locally, not globally, cataloged. Our CATALOG verb has "PICK.FORMAT" rather than "INFORMATION.FORMAT" on line 6, so it took me a little while to realise I needed a new CATALOGI verb. Secondly (and this is the bit where _knowing_ the system manual is wrong helped) the actual command line I wanted was CREATE TRIGGER ADDRESS.TRIGGER BEFORE INSERT OR UPDATE ON PERSON FOR EACH ROW CALLING "ADDRTRIGGER"; I eventually put in two VOC items, CTRIG for the above, and DTRIG which is DROP TRIGGER PERSON ADDRESS.TRIGGER; The code is simplicity itself 008: * See if the address and post code are the same 009: SAME = @TRUE 010: IF NEWREC<5> NE OLDREC<5> THEN SAME = @FALSE 011: IF NEWREC<8> NE OLDREC<8> THEN SAME = @FALSE 012: IF SAME THEN RETURN 013: 014: * Update the date on the file 015: NEWREC<34> = DATE() 016: 017: RETURN The idea is to pass only changed addresses out to a third party at intervals to get checked. Thanks again for the help, Regards, Keith. PS. I thought the FROM in "COPY FROM file ..." was a pain, but the requirement to put "FOR EACH ROW CALLING"? Even if they plan to extend the command usage in the future, couldn't they make the wild assumption that, if we don't say *anything* restricting the rows, we actually mean "FOR EACH ROW"? From the people who gave us OVERWRITING, I guess. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Practice?
Thanks for putting up the right link, Thomas. (dammit, I must measure BEFORE cutting... measure BEFORE cutting... hit self) To answer Ed's questions, 1. "nap 5" sleeps for 5 milliseconds. It may not be necessary, so you could comment it out and see how that goes. If you do get comm. delay that causes a problem and don't have nap, try a time-wasting loop - not a "sleep" command. I tried "sleep" years ago and it is frustrating. A nap of up to 100 milliseconds is almost unnoticeable in practice. 2. KEYIN() on Universe seems to be exactly the same as IN() on UniData. Regards, Keith PS Here's a silly program showing NAP 001: Crt "Bang!": 002: For I = 10 To @CrtWide-20 003: Crt '.': 004: Nap 10 005: Next 006: Crt "Ouch!" --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [UV] Can I get some advice on triggers?
Hi, I'm hoping someone can give me some help on triggers. I want to put a trigger on a file to datestamp address changes. The system manual (25119270.pdf) says that triggers aer set up by the command CREATE TRIGGER trigger.name [BEFORE|AFTER|UPDATE] But when I try that I get an SQL prompt. We don't use SQL at all - is there some way of setting up triggers without it? Is there another manual I should look at? Thanks, Keith. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Practice?
Craig Bennett pointerd out that TEST = '\AF1\CK1\CK2\H\LHC\MP\NU1\NU2\TK1\TK2\' IF INDEX(TEST,'\':F200.SCHEME.CODE:'\',1) THEN THAT = @FALSE *can* generate a false positive if F200.SCHEME.CODE contains an embedded slash. In this case it can't, because the F200.SCHEME.CODE is validated on entry against a list of codes (whew!) The super long string I started with is from a program to decide whether or not to show something on a printout. I suppose I could quibble and say it is actually a true positive... but no, Craig got me proper. My bad. However, this brings up a good practice thing to note. The seperator must not be 'enterable'. So that makes INPUT a bad idea. If you want to try out an alternative, I just put http://www.pickwiki.com/cgi-bin/wiki.pl?action=edit&id=GetKey up on the wiki. My problem was that the Asus eeePC does not seem to be a proper xterm, so I reproduced most of the functionality of QM's keycode() input. === Looking back, I feel I may have defended the INDEX function more than I wanted. My own code generally looks like this ENDWORDS = 'IF\OPEN\OPENSEQ\READNEXT\READ\READU\READV\READVU\' ENDWORDS = ENDWORDS:'MATREAD\MATREADU\LOCATE' CONVERT '\' TO AM IN ENDWORDS and I use the classic form LOCATE(WORD,ENDWORDS;POSN) THEN Regards, Keith PS: The extra line is solely to prevent wrapping on an eighty-column terminal. I value my concept of readability above efficiency. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Practice?
Hi Mark, Just a couple of points. First, the value of F200.SCHEME.CODE of CK *cannot* trigger a false positive. TEST = '\AF1\CK1\CK2\H\LHC\MP\NU1\NU2\TK1\TK2\' IF INDEX(TEST,'\':F200.SCHEME.CODE:'\',1) THEN THAT = @FALSE is fairly bulletproof because of the backslashes around both the string and the substring. Second, I wasn't concerned about LOCATE adding a cycle or two. It's just that one has to provide the SETTING variable which is then ignored. INDEX involves a string, a substring, and a start count - there's virtually nothing redundant. Using LOCATE involves a string, a substring, the position found as well as (possibly) a start position and a search sequence; so it can be regarded as a more complex function. Also, one can choose from three forms of LOCATE - Pick, Ideal/Reality, or Information. Then, to avoid the long setup string, one has to use CONVERT (or SWAP or CHANGE). Regards, Keith PS Good surname - mine's Norwegian in origin... great grandad jumped ship in Auckland. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Good Practice?
Neil suggested using LOCATE rather than INDEX in my example. I'm not sure I agree that would be any less complex as far as the code is concerned. INDEX and LOCATE are both 'complex' compared with the IF statement, and since LOCATE needs its SETTING variable, it's arguably the more complex statement. There are three different forms of LOCATE, so that can cause problems. Lastly, the variable TEST has to be set up with attribute marks either by multiple lines or by the very long line below; which, I have to say, I don't find very readable at all. TEST = 'AF1':@AM:'CK1':@AM:'CK2':@AM:'GS1':@AM:'H':@AM:'JM':@AM:'LHC':@AM:'MP': @AM:'MP3':@AM:'NU1':@AM:'NU2':@AM:'TK1':@AM:'TK2' There may be a slight speed benefit in restricting the scan by using 'AL'; but this is not material (or possibly even detectable?) in strings of this length. There is also an ongoing maintenance risk because the next programmer might not notice the codes were sorted, and may just add a new one to the end of the string. Regards, Keith. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] RE: (U2) Dictionary Help
Al DeWitt had a need for a utility to search the dictionaries. I had to write one a little while ago - to look for SB+ stuff, as it happens. PROGRAM FIND.DICT * This program searches the data dictionary section * of every file in the VOC for a string CRT 'INPUT STRING ': INPUT THAT IF THAT = '' THEN STOP OPEN 'VOC' TO VOC ELSE STOP 201,'VOC' EXECUTE 'SSELECT VOC WITH TYPE EQ "F"' IDLIST = '' LOOP WHILE READNEXT ID DO IDLIST<-1> = ID REPEAT XXNO = DCOUNT(IDLIST,@AM) FOR XX = 1 TO XXNO ID = IDLIST OPEN 'DICT',ID TO TEST ELSE CONTINUE SELECT TEST LOOP WHILE READNEXT DID DO READ REC FROM TEST,DID ELSE CONTINUE IF INDEX(REC,THAT,1) THEN CRT ID,DID REPEAT NEXT XX Might be useful, but I know if you could say it was efficient... Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Good Practice?
Here's an example of how I rewrote some code. Old version 284: * IF F200.SCHEME.CODE = "CK1" OR F200.SCHEME.CODE = "CK2" OR F200.SCHEME.CODE = "NU1" OR F200.SCHEME.CODE = "NU2" OR F200.SCHEME.CODE = "TK1" OR F200.SCHEME.CODE = "TK2" OR F200.SCHEME.CODE = "GS1" OR F200.SCHEME.CODE = "JM" OR F200.SCHEME.CODE = "MP3" OR F200.SCHEME.CODE = "LHC" OR F200.CALC.CODE = "H" OR F500.S91.ANNUITY.SEQ + 0 >= 2 OR F500.S48.ANNUITY.SEQ + 0 >= 2 OR F200.SCHEME.CODE = "AF1" OR F200.SCHEME.CODE = "MP" THEN; *002 285: IF F200.SCHEME.CODE = "CK1" OR F200.SCHEME.CODE = "CK2" OR F200.SCHEME.CODE = "NU1" OR F200.SCHEME.CODE = "NU2" OR F200.SCHEME.CODE = "TK1" OR F200.SCHEME.CODE = "TK2" OR F200.SCHEME.CODE = "LHC" OR F200.CALC.CODE = "H" OR F500.S91.ANNUITY.SEQ + 0 >= 2 OR F500.S48.ANNUITY.SEQ + 0 >= 2 OR F200.SCHEME.CODE = "MP" OR F200.SCHEME.CODE = "AF1" THEN ; *002*003 New version 261: THAT = @TRUE 262: *TEST = '\AF1\CK1\CK2\GS1\H\JM\LHC\MP\MP3\NU1\NU2\TK1\TK2\' 263: TEST = '\AF1\CK1\CK2\H\LHC\MP\NU1\NU2\TK1\TK2\' 264: IF INDEX(TEST,'\':F200.SCHEME.CODE:'\',1) THEN THAT = @FALSE 265: 266: IF F500.S91.ANNUITY.SEQ + 0 GE 2 THEN THAT = @FALSE 267: IF F500.S48.ANNUITY.SEQ + 0 GE 2 THEN THAT = @FALSE I think the new version is easier to maintain (well I would say that), but the code itself is more complex; which is rather interesting. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE:[U2] UD - SYSTEM(14)
Hi Bill, There is a vague memory at the back of my mind that SYSTEM(14) could be problematical. Would it work in your circumstance to change the last line to use the "INPUT ..., -1" mechanism? EG * UNTIL NOT(SYSTEM(14)) DO REPEAT ; ** UD version INPUT ANYTHING.THERE,-1 WHILE ANYTHING.THERE DO REPEAT Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Conversion code for week number
Wol wrote >INT (DAY / 365.25) > >will always give the correct number of years since day 0. The following shows that is not strictly true because of the centennial non-leap year. Test Program 001: ZZ = 0 002: FOR XX = 1 TO 5 003: Y1 = 1968 + INT((XX-1)/365.25) 004: Y2 = OCONV(XX,'DY') 005: IF Y1 NE Y2 THEN 006:ZZ += 1 007:CRT ZZ,XX,OCONV(XX,'D') 008: END 009: NEXT XX Results 1 48579 01 JAN 2101 2 48944 01 JAN 2102 3 49309 01 JAN 2103 4 49674 01 JAN 2104 I vaguely remember a comment a long time ago (maybe in c.d.p?) that the date was chosen _because_ it was a leap year that started on a Sunday and that this helped in converting dates from other IBM formats for the GIRLS/GIM project. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [BB] U2 Enhancement Request - WRITE
It's always annoyed me that WRITE permissions were not handled better. Even under R83, one could set up a file with a user able to read, but not write to it (file definition attributes 5 and 6, I think?). If a WRITE was encountered and the permission was not correct, the program would just crash horribly. As an application programmer who tried to put out solid, error-free code, this really ticked me off. Any program I wrote that updated a file could be made to crash by a change to an external definition. GAAHHH!!! This is probably the reason why Pick's read/write security mechanism never seemed to be used, even though it was very flexible. >From my point of view, I want one of the following (although I wouldn't turn my nose up at both) - 1. The write fails nicely and I can catch it in code. 2. I have a REALLY easy way of finding out if the write will fail before I even try the write. Fiddling about with the STATUS and then trying to figure out if this user is owner, or in the group, or whatever is VERY trying. Especially since a user can be in more than one group (On this UNIX box, anyway). It seems to me this should have been addressed years ago - wasn't the Spectrum Manfacturers' thing a waste of space? IBM, holding 2 big cards at the multivalue game, ought to be taking a lead on this, but they'll probably leave it to Martin Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [UV] VLIST failure - some detail of another program
Just to give an update - it may help someone else one day. Gyle gave me enough of a clue to get along with. It _was_ the machine type, so all that was required was to change the eighth character from ^000 to ^016. Then VLIST did not fall over. The source and output did get out of step, but there was no core dump and the jump addresses displayed correctly. For my small program, this is adequate. Thank you Gyle. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [UV] VLIST failure - some detail of another program
I don't know if there's any interest in this, but I have found a very short program where the old compiled version causes a problem with VLIST. Here are the details The old compiler version was 9.3.1.2, the new one 10.2.0.0 001: $OPTIONS -F L ;*WR631 002: * 003: *** TITLE: Time conversion routine. 004: * 005: * Written by Wilfred D'Mello, 02-August-1993 006: * 007: PRINT 008: PRINT "Time conversion routine. Press RETURN to return to TCL" 009: PRINT "You may enter time in 24 hour format eg: 18:30:26 " 010: PRINT " OR " 011: PRINT "In 12 hour format with AM/PM appended eg: 6:30:26PM" 012: PRINT 013: LOOP 014: PRINT "Enter Time to convert ": 015: INPUT ITIME 016: UNTIL ITIME = '' DO 017: ITIME = OCONV(ITIME,"MTS") 018: ITIME = ICONV(ITIME,"MTS") 019: PRINT @(40):"ICONV()=":ITIME: 020: PRINT @(60):"OCONV()=":OCONV(ITIME,"MTS") 021: PRINT 022: REPEAT 023:END When I used VLIST, the line numbering gets out of kilter at the LOOP - all the source prints, then the if fell over like this 00023:END 00258 0001C : 12E print "Enter Time to convert " 00259 00022 : 0B9 input 0 16 => ITIME 00260 0002A : 10C nop 00260 0002C : 06E eq ITIME "" => $R0 00260 00034 : 2E0 testtw $R0 00084: 00261 0003C : 112 oconv ITIME "MTS" => ITIME 00262 00044 : 0AC iconv ITIME "MTS" => ITIME 00263 0004C : 04A cursor 40 -1 => $R0 00263 00054 : 12E print $R0 "ICONV()=" ITIME 00264 0005E : 04A cursor 60 -1 => $R0 00264 00066 : 112 oconv ITIME "MTS" => $R1 00264 0006E : 130 printcrlf $R0 "OCONV()=" $R1 00265 00078 : 126 pcrlf 00266 0007A : 10C nop 00266 0007C : 0C2 jump 0: 00267 00084 : 01C calculate Abnormal termination of UniVerse. Fault type is 11. Layer type is Unknown. Program "/usr/ibm/uv/bin/vlist" core dumped. [SIGSEGV] segmentation violation Interestingly, I don't get the core dump if the source is missing - but the last two lines don't make any sense to me. 00266 0007C : 0C2 jump 0: 00267 00084 : 01C calculate [365] => [49] The VLIST output from a newly compiled program ends like this 00022: REPEAT 00022 0007A : 10C nop 00022 0007C : 0C2 jump 0001C: 00023:END 00023 00084 : 190 stop So it looks like there's some problem with the way it works out the jump address. I compared the object code and the only changes are in the header and a couple of extra char(0)s at the end of the program. If the logic is unchanged, why does the addressing go wrong? OLD NEW 3 147 162 <--- EG old version has char(147) as third character, new is char(162) 4 18 0 Aha! DTX 147 = 93 18 = 12 -> 9.3.1.2 DTX 162 = A2 0 = 0 -> 10.2.0.0 8 0 16 29 0 255 30 0 9 31 0 8 32 0 216 51 0 42 52 0 72 73 0 70 74 0 85 75 0 18 76 0 15 657 255 0 <--- New one is two characters longer 658 255 0 I'm off until Monday morning, so I won't be able to give any further details before then. It's definitely a puzzle, and possibly a bug. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Union Query
This is an interesting idea. Maybe it could be handled in a way that is
similar to distributed files, if the file meets a few criteria.
Firstly, it would have to have the "M" flag on line 4 in the VOC.
Secondly, it would have to have a structure like SYS.HELP where
/usr/ibm/uv/SYS.HELP is a directory containing the 'part' files
BASIC.HELP
BCI.HELP
CONV.HELP
PICK.HELP
SQL.HELP
SYS.HELP
Thirdly, the individual files would have to have the same dictionaries.
Strictly speaking, this is not necessary as we refer to the whole lot
via the 'enclosing' directory and VOC item (SYS.HELP in the example).
Given that, then treat it much like a standard distributed file - IF the
user has the keyword "SPANNING". The keyword allows the user to
restrict the individual 'part' files used ("SPANNING ALL" means to use
the lot, of course), and also indicates that the default ID to be
returned should be something like BASIC.HELP*DIMENSION or
SYS.HELP*BLOCK.TERM.
The character to use between the ID parts would be defined in the VOC
(obviously not everyone would want an asterisk). Maybe it should
require M* (or M| or M^, etc) on line 4 to do this - the simple lone M
meaning it won't work this way. That allows people who don't want to
use this feature to basically ignore it - the only change they would
actually see is an extra keyword in the VOC.
It seems to me this would be readily achievable in Universe, as it
already handles distributed files. UD should implement distributed
files too. I think UV implemented them to get around the 2GB size
limit, but they are really useful for managing historical data - even if
you're nowhere near any limit.
Regards, Keith
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE:[U2] A couple of questions about the PE version
Dave Taylor described in simple terms how to set up Dynamic connect on the PC; but Outlook decided that Digest #1647 should go to the junk folder, and I've only just read it. I'll try the technique out this weekend. Thanks very much, Dave. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[no subject]
Leroy wrote >Are you able to copy the object from your live system to your dev system to see if VLIST aborts there? Because of the big upgrade in SB+ and the fact we were also upgrading Universe, we upgraded the test system first to see what problems it would bring. Actually we built a temporary system on a loan machine first, upgraded THAT, then upgraded the development/test machine, then upgraded the production machine. Thanks for the thought, though. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] RE: (UV) - Is VLIST in version 10.2 fragile?
Hi Leroy, Thanks for your comments. I figured it might be a problem with opcode changes. My problem is that I'm not certain that the source code we have is correct. To recapitulate - * We have old object in production. * We have no source code in production * We have source code in development. * The development object is different because it was compiled more recently (and from a different directory) * Any given development source program is very unlikely to be the same as production *sigh*. This is the situation where one most wants VLIST to work! I would have preferred to just scan the VLIST output but I guess I'll just have to work it out by code analysis. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] (UV) - Is VLIST in version 10.2 fragile?
Hi there,
We have just upgraded both Universe and System Builder, going from UV
10.1.8 to 10.2.0 and from SB+ 3.4 to 5.4.
Because the SB+ common block changed slightly, I had to recompile all
programs that referenced it. However, I have discovered that not all
the source code was on the production system. I wanted to verify that
the development code was valid, but VLIST did not work properly.
When I try VLIST, it seems to get the testfw jump wrong on line 22 (or
24 in the development version). From then on it gets stranger and
stranger until it falls over. It looks like it gets out of step
somehow.
I realise it's not something anyone on the list can help with, but has
anyone else noticed VLIST is more fragile in UV version 10.2?
The development version of the source code and the VLIST from production
are below. Don't bother criticising it - you can't be more scathing
than me because I've had more practise.
Regards (and thanks), Keith
001: $OPTIONS -F ;*WR631
002: SUBROUTINE LWPINP.INTERVAL.SEQ
003:
**
004: * Description of subroutine
005: * Used for documentation purposes (including auto
documentation)
006:
**
007: *
008: $INCLUDE DMSKELCODE COMMON
009: EQU AM TO CHAR(254), VM TO CHAR(253)
010: *
011: *PARAM(3) = 0
012: ORIG.REC = 0
013: INTERVAL.SEQ = WORK<3>
014: LWOP.INTERVAL = 0
015: LWOP.INTERVAL.FILE = ''
016: OPEN.OK = @FALSE
017: CALL PAN.FILE.HANDLE ('LWOP.INTERVAL', LWOP.INTERVAL,
LWOP.INTERVAL.FILE, OPEN.OK)
018: IF NOT(OPEN.OK) THEN
019: CALL SB.DISP (3, 'Can not open the file
LWOP.INTERVAL')
020: RTN.FLAG = 1
021: END
022: FOUND = @TRUE
023: BEGIN CASE
024: CASE INTERVAL.SEQ = ''
025: KEY = WORK<1>: '|': WORK<2>: '|'
026: SEQ = 1
027: LOOP
028:READV DUMMY FROM LWOP.INTERVAL.FILE, KEY:
SEQ, 1 ELSE FOUND = @FALSE
029: WHILE FOUND DO
030:SEQ += 1
031: REPEAT
032: KEY = KEY: SEQ
033: WORK<3> = SEQ
034: * PARAM(3) = 1
035: ORIG.REC = 1
036: CASE INTERVAL.SEQ = 'L'
037: KEY = WORK<1>: '|': WORK<2>: '|'
038: SEQ = 1
039: LOOP
040:READV DUMMY FROM LWOP.INTERVAL.FILE, KEY:
SEQ, 1 ELSE FOUND= @FALSE
041: WHILE FOUND DO
042:SEQ += 1
043: REPEAT
044: KEY = KEY: SEQ - 1
045: WORK<3> = SEQ - 1
046: CASE 1
047: KEY = WORK<1>: '|': WORK<2>: '|': WORK<3>
048: READV DUMMY FROM LWOP.INTERVAL.FILE, KEY, 1
ELSE FOUND = @FALSE
049: IF NOT(FOUND) THEN
050:CALL SB.DISP (3, KEY: ' not on the LWOP
INTERVAL file')
051:RTN.FLAG = 1
052: END
053: END CASE
054:
055: RETURN
>VLIST SFPROGS LWPINP.INTERVAL.SEQ
Subroutine "SFPROGS.O/LWPINP.INTERVA/L.SEQ"
Compiler Version: 8.3.3.1
Object Level: 5
Machine Type: 10
Local Variables : 12
Subroutine args : 0
Unnamed Common : 0
Named Common Seg: 1
Object Size : 540
Source lines: 52
Object Date Time:
00011 0 : 060 dyn_extractWORK 3 0 0 => INTERVAL.SEQ
00012 C : 0F8 move 0 => LWOP.INTERVAL
00013 00012 : 0F8 move "" => LWOP.INTERVAL.FILE
00014 00018 : 0F8 move 0 => OPEN.OK
00015 0001E : 0F8 move "LWOP.INTERVAL" => _T
00015 00024 : 01E call "PAN.FILE.HANDLE" _T LWOP.INTERVAL
LWOP.INTERVAL.FILE OPEN.OK
00020 0005C : 0F8 move 1 => FOUND
00022 00062 : 06E eq INTERVAL.SEQ "" => $R0
00022 0006A : 2DE testfw $R0 0:
00023 00074 : 0F4 mmatstore [97] => WORK
00023 0007A : 018 braces 0 0 => $R0
00023 00082 : 060 dyn_extractWORK 2 0 0 => $R1
00023 0008E : 104 multi_cat $R0 "|" $R1 "|" => KEY
00024 0009C : 0F8 move 1 => SEQ
00026 000A2 : 03A concat KEY SEQ => $R0
00026 000AA : 272 reapv LWOP.INTERVAL.FILE $R0 1 => DUMMY
00026 000B4 : 0C8 jumpt 000BE:
00026 000BC : 0F8 move 0 => FOUND
00027 000C2 : 2DE testfw FOUND 0:
00028 000CC : 0D8 lockelse OPEN.OK
00028 000D0 : 009 and1 SEQ => [195]
00029 000D8 : 000 abort
00029 000DA : 000 abort
00029 000DC : 0A0 ge [59] KEY => SEQ
00030 000E4 : 00D atan[101] => WORK
00030 000EA : 010 bi
RE:[U2] A couple of questions about the PE version
Anthony - Not *nix where I am prepared to give it a go, but Windows where I lose stuff and become short-tempered. Dave - Thanks - that's just what I want to do. It's just the mechanics of "telnet to itself" that confuses me. I never like fiddling with Windows because I seem to have an ability to damage stuff. Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] A couple of questions about the PE version
As I recall, neither U2 console understands screen addressing - which means you can't run most of the applications I've written from the console. To my mind this means that someone can't just run U2 'out of the box' and get a thing that works. They will have to connect to a terminal emulator or set up some interface. Whatever that is, it may have the potential to fail or to confuse. I know it _is_ possible to have a console that allows screen addressing, because the QM one does. Does anyone know why the U2 console(s) cannot do simple green screen applications? What is the easiest, simplest way to set up a terminal session with the Personal Edition on a standalone PC? I'd like to do it on my home one. Regards, Keith P.S. Decrepitude means I can only follow simple instructions that assume neither knowledge nor sense. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] 2 questions, one on STATUS and the other on STEAL-FILE
Jeff Fitzgerald wrote > Could you give us an example of that -- I don't seem to be able to get it to work: I remember in the past being able to use the form "SET.INDEX FAST.STATS TO ./I_FAST.STATS". However, now one has to use the key word "RELATIVE.PATH" like this "SET.INDEX FAST.STATS TO RELATIVE.PATH" The key word is within the program only - it is not in the VOC, and this usage is undocumented. (!) The program will prompt you to show what it would use (./I_FAST.STATS) and ask if this is OK. I really like the idea of using relative addressing for indexes, but I do wish this was documented properly. Using the word RELATIVE.PATH to implement the capability is noted in the program header (line 17) as being GTAR E7818 dated 05/08/05, but it appears the actual capability was provided by E1752 of 07/12/03 (line 19). As I say, I remember using a relative path reference some time ago... possibly before 2001. Regards, Keith P.S. Can someone come up with a humorous acronym for the archetypal nit-picking documentation-nagging grumpy old bug^H^H^Hprogrammer? Just wondering. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] 2 questions, one on STATUS and the other on STEAL-FILE
Hi there, There is a utility program at http://www.pickwiki.com/cgi-bin/wiki.pl?FileStatus to show the file STATUS stuff in a usable manner. You may also be interested in FILEINFO stuff which is at http://www.pickwiki.com/cgi-bin/wiki.pl?FileInfo Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] 2 questions, one on STATUS and the other on STEAL-FILE
Brian Leach wrote >1. Before you take a copy of the file in Explorer, check whether it has any indexes. > >If a file has secondary indexing, UniVerse holds the absolute path to the index in the file header. You must use SET.INDEX to either change or remove that path on the history file, otherwise your history file will update your live index .. not a smart move. > You can use the SET.INDEX command to make the path a relative one like this SET.INDEX FILENAME TO RELATIVE.PATH Which is something I have only just discovered by inspecting the source code for SET.INDEX - it's not in the user reference manual at all! Regards, Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
