Re: [U2] How do you verify windows printer is good before fatal error by PRINTing to a bogus printer.
Not quite so easy - Remember that under Windows a printer is a combination of a driver and a device. If you link to a remote printer, it needs to install the driver locally on your server so as to access the printer correctly .. that means either it has to be a model that has previously been installed (say, if you have two equivalent HP Lasers on different machines) or the client needs to have the right drivers to publish back to you - which can give problems if they are running different versions of Windows and e.g. 64 bit vs 32 bit and you haven't loaded them all. Also, BTW, being able to access the driver doesn't mean the printer is working. Most drivers only check when they actually start printing. So any 'is this printer online or offline' messages only relate to the last thing the driver knew about and not necessarily the current state. That said, you can try the DOS NET commands. NET USE will show you what you have visible already: C:\Users\briannet use New connections will be remembered. Status Local RemoteNetwork --- Unavailable LPT1: \\tiny\text1 Microsoft Windows Network The command completed successfully. Now this is NOT showing what is actually available. C:\Users\brianNET USE \\tiny\HP Color LaserJet CP2020 Series PCL6 The command completed successfully. Now it is there: Status Local RemoteNetwork --- Unavailable LPT1: \\tiny\text1 Microsoft Windows Network OK \\tiny\HP Color LaserJet CP2020 Series PCL6 Microsoft Windows Network The command completed successfully. Brian ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Programmatic Verification of Globally Cataloged Subroutine
In particular, when using the CALL @ syntax to dynamically call something. Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ross Ferris Sent: Wednesday, January 29, 2014 10:56 PM To: U2 Users List Subject: Re: [U2] [UV] Programmatic Verification of Globally Cataloged Subroutine Knowing how many arguments a subroutine is expecting is a good way to check/confirm that the call you are about to make isn't going to blow up in your face! Ross Ferris Stamina Software Visage Better by Design! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Wednesday, January 29, 2014 10:15 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UV] Programmatic Verification of Globally Cataloged Subroutine I was just trying to think of a reason why I'd want specifically to know how many arguments the subroutine has. That is, why was this particular fact chosen as the returned status code ? -Original Message- From: Keith Johnson [DATACOM] keith.john...@datacom.co.nz To: 'u2-users@listserver.u2ug.org' u2-users@listserver.u2ug.org Sent: Tue, Jan 28, 2014 3:10 pm Subject: Re: [U2] [UV] Programmatic Verification of Globally Cataloged Subroutine Hi, LeRoy Dreyfuss said that you would have to change 52 to 12 for EXIST to work. The globally cataloged programs have an extra 40 characters put on the front, so that would cause a problem. @RECORD[1,4] is a count of the number of times the program has been used. @RECORD[5,8] is who cataloged it @RECORD[13,4] are the date and time (I think) Regards, Keith ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Programmatic Verification of Globally Cataloged Subroutine
Not sure if this is helpful or not but I write software that allows users to create their own subroutines that plug into my architecture. Users can forget to catalog or have other issues with their subroutine. So, I require the user subroutine to accept an argument called 'mode'. In my system, mode=2 means 'test mode'. If a user subroutine is called with mode set to 2, then it should set test data and when processing is complete, output the string /%%validated%%/ to standard out. In my program where I will be calling the subroutine, I reference it twice. First to validate the subroutine and second to actually call the subroutine. I use the EXECUTE/CAPTURING on the first pass using a special test executable to validate the subroutine then if I find %%validated%% in the captured output, then I mke the second pass and actually call the subroutine with CALL @. On the first pass, I EXECUTE using my validator program so that even if the subroutine fails or dies, only that execute levels is affected. i.e., you can execute a program that calls a failing subroutine and the main program that executed will carry on after the failure. I leveraged this behavior to mitigate the chance that a user subroutine would cause my main program to abort. Yes, I understand the EXECUTE is expensive but it's less expensive than me having to spend my time helping a user restart my process because one of their subroutines failed. This technique might be used in combination with the global catalog checker to provide a richer level of validation. Here are some code fragments is case anyone finds this technique useful: *The Main Program* userSubroutineName = \MY.SUBROUTINE.NAME\ * check the subroutine to make sure it is valid before calling EXECUTE \bpixmlize.validateSubroutine \:userSubroutineName CAPTURING result * check result to see if the subroutine responded cordially IF (INDEX(reuslt, \%%validated%%\, 1) THEN * yep, the subroutine is alive and well, it's okay to call it. itemId=\\ mode=1; * 1 means 'run' mode error = \\ CALL @userSubroutineName(itemId, mode, error) END ELSE * not sure what happened but subroutine is not playing nicely CRT \So sorry, but \:userSubroutineName:\ does not appear to be valid\ CRT \result=\:result END * The subroutine validator program* *bpixmlize.validateSubroutine *a executable program that will attempt to call subroutine or error if not *to be executed in a basic program with captured output. Evaluate the captured *result and it should contain the string %%validated%% otherwise it's a bad *or invalid subroutine. The prevents the caller from crashing with object not *found so that it can wrap-up normally. It's the job of the called subroutine *to output %%validated%% or something agreed by the caller in order to validate *the subroutine. Since this is executed and not called, it will fail but return *control to the calling program after failing. * -- INCLUDE bpi.xml.bp bpixmlize.common ; * to get common variables GOSUB ParseSentence GOSUB Validate GOTO Exit * -- Validate: IF subroutine.name NE \\ THEN item.id = \\; mode=2; error = \\ CALL @subroutine.name( item.id, mode, error) END RETURN * ParseSentence: pgm.id = \bpixmlize.validateSubroutine\ start = @FALSE sentence= CHANGE( @SENTENCE, SPACE(1), @AM) max.words = DCOUNT( sentence, @AM) subroutine.name = \\ FOR i = 1 to max.words BEGIN CASE CASE start BEGIN CASE CASE subroutine.name EQ \\ subroutine.name = sentence i CASE @TRUE * ignore END CASE CASE sentencei EQ pgm.id start = @TRUE CASE @TRUE * ignore END CASE NEXT i RETURN * Exit: STOP * **A sample user subroutine:* SUBROUTINE MY.SUBROUTINE.NAME(item.id, mode, error) * Copyright (c) 2013 by Blue Prairie, Inc. * All Rights Reserved * * item.idis the item ID of the main file to process * mode If caller sets mode=2, then subroutine will simply output *string '%%validated%%\ and return. This is so that the *caller can use the subroutine test program to validate that *the subroutine name is valid and callable before actually *calling it. If the subroutine sets mode to zero, the calling *program should consider this a signal that something is wrong *and it should stop processing. The caller should normally set *mode to 1 for normal processing. * error is an error code to
Re: [U2] [UV] Programmatic Verification of Globally Cataloged Subroutine
Nice technique. My first reaction was why would you want to not let a subroutine failure be catastrophic?!. I could see where it could allow data to get scrambled. Let's say an decryption routine unable to decrypt so the encrypted data gets sent back exactly the same. But then I could see where this would create resiliency with some non-critical function that could be fixed after the fact, like a cross-referencing subroutine which sets up cross-references, just to add feature. Your technique allows the failure and keeps moving forward, with hopefully an error log entry so someone could fix it. Almost like an error message from the system when you don't initialize a variable to zero, so it does that for you and gives you a nastrygram in the process, but it doesn't effect operation (in many cases). Thanks for the tip. Robert Norman ROBERT NORMAN AND ASSOCIATES 23441 Golden Springs Dr., #289, Diamond Bar, CA 91765 (951) 541-1668 i...@keyway.net mailto:i...@keyway.net http://users.keyway.net/~ice/ http://users.keyway.net/%7Eice/ Affordable computer consulting services and computer programming for UNIVERSE, UNIDATA, U2, PICK/BASIC, DATA/BASIC, UniVerseBasic, UniBasic, R/BASIC, jBC. Ask about our lowest $45 discounted rate for long-term telecommuting projects. On 1/30/2014 9:03 AM, Bruce Decker wrote: Not sure if this is helpful or not but I write software that allows users to create their own subroutines that plug into my architecture. Users can forget to catalog or have other issues with their subroutine. So, I require the user subroutine to accept an argument called 'mode'. In my system, mode=2 means 'test mode'. If a user subroutine is called with mode set to 2, then it should set test data and when processing is complete, output the string /%%validated%%/ to standard out. In my program where I will be calling the subroutine, I reference it twice. First to validate the subroutine and second to actually call the subroutine. I use the EXECUTE/CAPTURING on the first pass using a special test executable to validate the subroutine then if I find %%validated%% in the captured output, then I mke the second pass and actually call the subroutine with CALL @. On the first pass, I EXECUTE using my validator program so that even if the subroutine fails or dies, only that execute levels is affected. i.e., you can execute a program that calls a failing subroutine and the main program that executed will carry on after the failure. I leveraged this behavior to mitigate the chance that a user subroutine would cause my main program to abort. Yes, I understand the EXECUTE is expensive but it's less expensive than me having to spend my time helping a user restart my process because one of their subroutines failed. This technique might be used in combination with the global catalog checker to provide a richer level of validation. Here are some code fragments is case anyone finds this technique useful: *The Main Program* userSubroutineName = \MY.SUBROUTINE.NAME\ * check the subroutine to make sure it is valid before calling EXECUTE \bpixmlize.validateSubroutine \:userSubroutineName CAPTURING result * check result to see if the subroutine responded cordially IF (INDEX(reuslt, \%%validated%%\, 1) THEN * yep, the subroutine is alive and well, it's okay to call it. itemId=\\ mode=1; * 1 means 'run' mode error = \\ CALL @userSubroutineName(itemId, mode, error) END ELSE * not sure what happened but subroutine is not playing nicely CRT \So sorry, but \:userSubroutineName:\ does not appear to be valid\ CRT \result=\:result END * The subroutine validator program* *bpixmlize.validateSubroutine *a executable program that will attempt to call subroutine or error if not *to be executed in a basic program with captured output. Evaluate the captured *result and it should contain the string %%validated%% otherwise it's a bad *or invalid subroutine. The prevents the caller from crashing with object not *found so that it can wrap-up normally. It's the job of the called subroutine *to output %%validated%% or something agreed by the caller in order to validate *the subroutine. Since this is executed and not called, it will fail but return *control to the calling program after failing. * -- INCLUDE bpi.xml.bp bpixmlize.common ; * to get common variables GOSUB ParseSentence GOSUB Validate GOTO Exit * -- Validate: IF subroutine.name NE \\ THEN item.id = \\; mode=2; error = \\ CALL @subroutine.name( item.id, mode, error) END RETURN * ParseSentence: pgm.id = \bpixmlize.validateSubroutine\ start = @FALSE sentence= CHANGE( @SENTENCE, SPACE(1), @AM) max.words = DCOUNT(
Re: [U2] [UV] Programmatic Verification of Globally Cataloged Subroutine
Good points. My view is that it is usually not a matter of whether the failure should be catastrophic. It's usually a matter of who should be in in control of the catastrophe. If you call a object that bombs, the caller will never know why because control never returns to the caller. With this technique, if you don't get a validated response, you can certainly choose 'go on' in the main program but you chould also choose to make it a catastrophe. The point is that your main program regains control after it provokes failure and can choose what to do with the failure. As you point out, it might just log the error but it could logoff, or throw some other hissy instead of moving forward. Note that the capture variable 'result' will contain the failure message. That could be parsed to to whatever... *For example: ... * IF INDEX( result, \%%validated%%\, 1) THEN CALL userSubroutine(foo, bar...) END ELSE message = \Call to \:userSubroutine:\ failed with this error: \:result message:= \So, we aborted on port \:@USERNO:\. Sorry it didn't work out and thanks for all the fish.\ emailTo = \ad...@mydomain.com\ emailSubject = \Houston we had a problem on port\: @USERNO CALL emailAdmin( emailTo, emailSubject, message, status) CRT message GOSUB makeACatastopheOutOfIt END ... makeACatastopheOutOfIt: ABORT RETURN Bruce Decker Blue Prairie, Inc. 720.733.0459 http://www.bluepinc.com On 1/30/2014 11:03 AM, Robert wrote: Nice technique. My first reaction was why would you want to not let a subroutine failure be catastrophic?!. I could see where it could allow data to get scrambled. Let's say an decryption routine unable to decrypt so the encrypted data gets sent back exactly the same. But then I could see where this would create resiliency with some non-critical function that could be fixed after the fact, like a cross-referencing subroutine which sets up cross-references, just to add feature. Your technique allows the failure and keeps moving forward, with hopefully an error log entry so someone could fix it. Almost like an error message from the system when you don't initialize a variable to zero, so it does that for you and gives you a nastrygram in the process, but it doesn't effect operation (in many cases). Thanks for the tip. Robert Norman ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] A Descriptors and its Subroutine Issue
I'm not use to making these. I based what I was doing on another A type which also called a Subroutine. My A Type record; SB.SVCED DICT ADFILA RNS.CB.MAS 10 lines long. : 0001: A : 0002: 0 : 0003: Reason Not To Be Sent : 0004: M : 0005: : 0006: : 0007: : 0008: URNS.CB.MAS.SUB : 0009: L : 0010: 20 Bottom at line 10. I cataloged the process RNS.CB.MAS.SUB But get this error; $RNS.CB.MAS.SUB is not in the CATALOG space. [ENOENT] No such file or directory Incorrect VOC entry for $RNS.CB.MAS.SUB. Unable to load subroutine. Not seen this before. Any ideas? I know I can just make an I type, and I have done those before. I thought this might be less work in making and porting over to production. - I used to be an Optimist until I knocked over the glass. -- View this message in context: http://u2-universe-unidata.1073795.n5.nabble.com/A-Descriptors-and-its-Subroutine-Issue-tp42599.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A Descriptors and its Subroutine Issue
Did you compile the program before cataloging it? What command did you use to catalog it? I always like to take a look at the output from the CATALOG command to verify it was done properly. Robert Norman ROBERT NORMAN AND ASSOCIATES 23441 Golden Springs Dr., #289, Diamond Bar, CA 91765 (951) 541-1668 i...@keyway.net mailto:i...@keyway.net http://users.keyway.net/~ice/ http://users.keyway.net/%7Eice/ Affordable computer consulting services and computer programming for UNIVERSE, UNIDATA, U2, PICK/BASIC, DATA/BASIC, UniVerseBasic, UniBasic, R/BASIC, jBC. Ask about our lowest $45 discounted rate for long-term telecommuting projects. On 1/30/2014 12:07 PM, randyleesmith wrote: I'm not use to making these. I based what I was doing on another A type which also called a Subroutine. My A Type record; SB.SVCED DICT ADFILA RNS.CB.MAS 10 lines long. : 0001: A : 0002: 0 : 0003: Reason Not To Be Sent : 0004: M : 0005: : 0006: : 0007: : 0008: URNS.CB.MAS.SUB : 0009: L : 0010: 20 Bottom at line 10. I cataloged the process RNS.CB.MAS.SUB But get this error; $RNS.CB.MAS.SUB is not in the CATALOG space. [ENOENT] No such file or directory Incorrect VOC entry for $RNS.CB.MAS.SUB. Unable to load subroutine. Not seen this before. Any ideas? I know I can just make an I type, and I have done those before. I thought this might be less work in making and porting over to production. - I used to be an Optimist until I knocked over the glass. -- View this message in context: http://u2-universe-unidata.1073795.n5.nabble.com/A-Descriptors-and-its-Subroutine-Issue-tp42599.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A Descriptors and its Subroutine Issue
You have to catalog it, using the renaming option Otherwise the system will most likely catalog it normally, thus the error you have -Original Message- From: Robert i...@keyway.net To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Jan 30, 2014 1:06 pm Subject: Re: [U2] A Descriptors and its Subroutine Issue Did you compile the program before cataloging it? What command did you use to catalog it? I always like to take a look at the output from the CATALOG command to verify it was done properly. Robert Norman ROBERT NORMAN AND ASSOCIATES 23441 Golden Springs Dr., #289, Diamond Bar, CA 91765 (951) 541-1668 i...@keyway.net mailto:i...@keyway.net http://users.keyway.net/~ice/ http://users.keyway.net/%7Eice/ Affordable computer consulting services and computer programming for UNIVERSE, UNIDATA, U2, PICK/BASIC, DATA/BASIC, UniVerseBasic, UniBasic, R/BASIC, jBC. Ask about our lowest $45 discounted rate for long-term telecommuting projects. On 1/30/2014 12:07 PM, randyleesmith wrote: I'm not use to making these. I based what I was doing on another A type which also called a Subroutine. My A Type record; SB.SVCED DICT ADFILA RNS.CB.MAS 10 lines long. : 0001: A : 0002: 0 : 0003: Reason Not To Be Sent : 0004: M : 0005: : 0006: : 0007: : 0008: URNS.CB.MAS.SUB : 0009: L : 0010: 20 Bottom at line 10. I cataloged the process RNS.CB.MAS.SUB But get this error; $RNS.CB.MAS.SUB is not in the CATALOG space. [ENOENT] No such file or directory Incorrect VOC entry for $RNS.CB.MAS.SUB. Unable to load subroutine. Not seen this before. Any ideas? I know I can just make an I type, and I have done those before. I thought this might be less work in making and porting over to production. - I used to be an Optimist until I knocked over the glass. -- View this message in context: http://u2-universe-unidata.1073795.n5.nabble.com/A-Descriptors-and-its-Subroutine-Issue-tp42599.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A Descriptors and its Subroutine Issue
Curious why you are doing this as a user exit? iirc, there are differences between using an A and an Itype. In an itype, the subroutine is called just once for each item in the file. With an A-type, the subroutine is going to be called once for each value/subvalue in the attribute referenced by the amc on line 2 of the dictionary entry (which in this case is 0 so there will only be once value, but be careful using it on other attributes in the item) The subroutine needs to be cataloged with a $ prefix, $RNS.CB.MAS.SUB rather than just RNS.CB.MAS.SUB, and I think it needs to be cataloged globally. From the universe manual: Cataloging User Exits Once you have written and compiled the UniVerse BASIC subroutine, you must catalog the program. User exits are cataloged globally by specifying the user exit name with a dollar sign in front of it. For example, to catalog the user exit U50MB in the example shown earlier, use the CATALOG command as follows: CATALOG CATALOG NAME or LOCAL = $50MB FILENAME = APP.PROGS PROGRAM NAME = 50MB Or you can use the form: CATALOG APP.PROGS $50MB Like any other program, a user exit must be compiled before you can catalog it. See Chapter 8, “ UniVerse BASIC,” for more information about cataloging UniVerse BASIC programs. Cataloging Programs in PICK Accounts PICK and IN2 flavor accounts do not permit global cataloging; therefore you must either catalog the program in a different flavor account or create an INFORMATION flavor CATALOG entry in your PICK account. To create an INFORMATION flavor CATALOG entry, create a VOC entry which is the same as the entry for CATALOG, except that field 6 is defined as INFORMATION.FORMAT instead of PICK.FORMAT. On Jan 30, 2014, at 3:07 PM, randyleesmith randyleesm...@roadrunner.com wrote: I'm not use to making these. I based what I was doing on another A type which also called a Subroutine. My A Type record; SB.SVCED DICT ADFILA RNS.CB.MAS 10 lines long. : 0001: A : 0002: 0 : 0003: Reason Not To Be Sent : 0004: M : 0005: : 0006: : 0007: : 0008: URNS.CB.MAS.SUB : 0009: L : 0010: 20 Bottom at line 10. I cataloged the process RNS.CB.MAS.SUB But get this error; $RNS.CB.MAS.SUB is not in the CATALOG space. [ENOENT] No such file or directory Incorrect VOC entry for $RNS.CB.MAS.SUB. Unable to load subroutine. Not seen this before. Any ideas? I know I can just make an I type, and I have done those before. I thought this might be less work in making and porting over to production. - I used to be an Optimist until I knocked over the glass. -- View this message in context: http://u2-universe-unidata.1073795.n5.nabble.com/A-Descriptors-and-its-Subroutine-Issue-tp42599.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] How do you verify windows printer is good before fatal error by PRINTing to a bogus printer.
Thanks, Brian. I was heading that general direction with net view \\[printserver] Then searching for the printer I'm looking for. You're right about the drivers, but I don't think I'll get a fatal error just because the printing is garbled or printer is offline, will I? We've been getting a rash of errors in something that's been pretty stable for years, resulting in incomplete updates because the PRINT statements aborted were in the middle of the writes. On 1/30/2014 4:23 PM, Brian Leach wrote: Not quite so easy - Remember that under Windows a printer is a combination of a driver and a device. If you link to a remote printer, it needs to install the driver locally on your server so as to access the printer correctly .. that means either it has to be a model that has previously been installed (say, if you have two equivalent HP Lasers on different machines) or the client needs to have the right drivers to publish back to you - which can give problems if they are running different versions of Windows and e.g. 64 bit vs 32 bit and you haven't loaded them all. Also, BTW, being able to access the driver doesn't mean the printer is working. Most drivers only check when they actually start printing. So any 'is this printer online or offline' messages only relate to the last thing the driver knew about and not necessarily the current state. That said, you can try the DOS NET commands. NET USE will show you what you have visible already: C:\Users\briannet use New connections will be remembered. Status Local RemoteNetwork --- Unavailable LPT1: \\tiny\text1 Microsoft Windows Network The command completed successfully. Now this is NOT showing what is actually available. C:\Users\brianNET USE \\tiny\HP Color LaserJet CP2020 Series PCL6 The command completed successfully. Now it is there: Status Local RemoteNetwork --- Unavailable LPT1: \\tiny\text1 Microsoft Windows Network OK \\tiny\HP Color LaserJet CP2020 Series PCL6 Microsoft Windows Network The command completed successfully. Brian ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] How do you verify windows printer is good before fatal error by PRINTing to a bogus printer.
Thanks Anthony. Yeah, it you can find the code w/o too much trouble, I'd be interested. BTW, it's impressive how little printing this company actually does. Remember that promise of a paperless society? Maybe we're getting there. Good. I hate printers. Always have. Chuck On 1/29/2014 10:43 PM, Anthonys Lists wrote: On 28/01/2014 20:59, Charles Stevenson wrote: Anthony pretty much nailed how we're doing it. But my original question is still unanswered. I want to make sure it's a valid printer before I start printing to it. I think I problably need to do something like EXECUTE DOS /C [some-command] \\MY_PRINT_SERVER\PrinterName CAPTURING DOSMSG IF DOSMSG = [something bad] THEN . . . I was hoping someone in this august body had crossed that bridge before. We never had that problem. I had a PRINTER subroutine or suchlike that accessed a printers file with all the parameters. Any programatic (or user command line) attempt to access a printer was via my stuff, that checked this file, and set things up accordingly. So as far as eg accounts was concerned, they had the ACCOUNTS printer. Whenever anything changed, I simply changed the ACCOUNTS entry in the parameter file. Very useful, because on the odd occasion when a printer went down I just made a temporary change to the file and everything got diverted :-) If tyou're interested, let me know and I'll see if I can find the code - I know I had it but it's a long time ago ... Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Programmatic Verification of Globally Cataloged Subroutine
I'd be interested to see how ON ERROR could catch a subroutine call failure. And I'd ball-up and toss my stuff in a heartbeat. No pride here... -BD On 1/30/2014 2:52 PM, Anthonys Lists wrote: On 30/01/2014 18:35, Bruce Decker wrote: Good points. My view is that it is usually not a matter of whether the failure should be catastrophic. It's usually a matter of who should be in in control of the catastrophe. If you call a object that bombs, the caller will never know why because control never returns to the caller. Which is the whole point of the object-oriented programming feature try/catch, or even the ON ERROR statement that has been added to databasic in recent years. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A Descriptors and its Subroutine Issue
Thankyou Ed! We did not know you could call a program from a S-type dictionary! How long has it been there? We went through months of work to be able to use I-types to be able to call subroutines, and to get accurate arithmetic. Test shows arithmetic has been fixed. We talked to U2 people about it at a U2U, and were told UV doe integer arithmetic, and we had to live with it. Many (20+) years ago 1.9 + 1.9 gave 2, then it was fixed so we took the work-arounds out, then it went bad again. Do you know when it was fixed again? We do still need I-types to bring back multi-values from a Translate. Perhaps this will be attended to as well some day. We do not like I-types, as we cannot use dict fields beyond 10 for out data entry parameters, and inadvertently printing the dict item kills the session. Maybe one day we can get rid of them again. Cheers, Kate Kate Stanton Walstan Systems Ltd 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: + 64 9 360 5310 Mobile: + 64 21 400 486 Email: k...@walstan.com On 31 January 2014 10:34, Ed Clark u...@edclark.net wrote: Curious why you are doing this as a user exit? iirc, there are differences between using an A and an Itype. In an itype, the subroutine is called just once for each item in the file. With an A-type, the subroutine is going to be called once for each value/subvalue in the attribute referenced by the amc on line 2 of the dictionary entry (which in this case is 0 so there will only be once value, but be careful using it on other attributes in the item) The subroutine needs to be cataloged with a $ prefix, $RNS.CB.MAS.SUB rather than just RNS.CB.MAS.SUB, and I think it needs to be cataloged globally. From the universe manual: Cataloging User Exits Once you have written and compiled the UniVerse BASIC subroutine, you must catalog the program. User exits are cataloged globally by specifying the user exit name with a dollar sign in front of it. For example, to catalog the user exit U50MB in the example shown earlier, use the CATALOG command as follows: CATALOG CATALOG NAME or LOCAL = $50MB FILENAME = APP.PROGS PROGRAM NAME = 50MB Or you can use the form: CATALOG APP.PROGS $50MB Like any other program, a user exit must be compiled before you can catalog it. See Chapter 8, UniVerse BASIC, for more information about cataloging UniVerse BASIC programs. Cataloging Programs in PICK Accounts PICK and IN2 flavor accounts do not permit global cataloging; therefore you must either catalog the program in a different flavor account or create an INFORMATION flavor CATALOG entry in your PICK account. To create an INFORMATION flavor CATALOG entry, create a VOC entry which is the same as the entry for CATALOG, except that field 6 is defined as INFORMATION.FORMAT instead of PICK.FORMAT. On Jan 30, 2014, at 3:07 PM, randyleesmith randyleesm...@roadrunner.com wrote: I'm not use to making these. I based what I was doing on another A type which also called a Subroutine. My A Type record; SB.SVCED DICT ADFILA RNS.CB.MAS 10 lines long. : 0001: A : 0002: 0 : 0003: Reason Not To Be Sent : 0004: M : 0005: : 0006: : 0007: : 0008: URNS.CB.MAS.SUB : 0009: L : 0010: 20 Bottom at line 10. I cataloged the process RNS.CB.MAS.SUB But get this error; $RNS.CB.MAS.SUB is not in the CATALOG space. [ENOENT] No such file or directory Incorrect VOC entry for $RNS.CB.MAS.SUB. Unable to load subroutine. Not seen this before. Any ideas? I know I can just make an I type, and I have done those before. I thought this might be less work in making and porting over to production. - I used to be an Optimist until I knocked over the glass. -- View this message in context: http://u2-universe-unidata.1073795.n5.nabble.com/A-Descriptors-and-its-Subroutine-Issue-tp42599.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Programmatic Verification of Globally Cataloged Subroutine
On 30/01/14 22:44, Bruce Decker wrote: I'd be interested to see how ON ERROR could catch a subroutine call failure. And I'd ball-up and toss my stuff in a heartbeat. No pride here... -BD No, on error doesn't catch a subroutine call failure. But it was added to prevent programs bombing if a write failed or similar - basically a feature to trap something going wrong ... Cheers, Wol On 1/30/2014 2:52 PM, Anthonys Lists wrote: On 30/01/2014 18:35, Bruce Decker wrote: Good points. My view is that it is usually not a matter of whether the failure should be catastrophic. It's usually a matter of who should be in in control of the catastrophe. If you call a object that bombs, the caller will never know why because control never returns to the caller. Which is the whole point of the object-oriented programming feature try/catch, or even the ON ERROR statement that has been added to databasic in recent years. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] How do you verify windows printer is good before fatal error by PRINTing to a bogus printer.
On 30/01/2014 22:15, Charles Stevenson wrote: Thanks Anthony. Yeah, it you can find the code w/o too much trouble, I'd be interested. BTW, it's impressive how little printing this company actually does. Remember that promise of a paperless society? Maybe we're getting there. Good. I hate printers. Always have. I'll see if I can find them for you. But it'll have to wait as it's long past bed-time here :-) The company I learnt all about printers at ... when I started there they had a full-blown printing press in the basement! But by the time I left all the info was going out on CDs or over the web. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
