RE: [U2] Managing open files
Hi Colin, This is great, thank you! What it doesn't give me is information about which files are open -- know where that is, or what did you type into help to get this info? I tried whatever phrases I could think of... Susan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, December 22, 2006 9:15 AM To: u2-users@listserver.u2ug.org Cc: [EMAIL PROTECTED] Subject: RE: [U2] Managing open files If you're on a late enough version of UD have a look at SYSTEM(50). I can see it on my system as of 6.0.12 but not at 5.1.27. Here is a snippet from help system 50 The UniBasic SYSTEM(50) function returns a list of files open in UniBasic as a dynamic array. The first field is multivalued, and contains the following information: Value 1 - The maximum number of files that can be opened system-wide. Value 2 - The current number of hashed files open in UniBasic. Value 3 - The current number of dynamic hashed files open in UniBasic. Value 4 - The current number of recoverable hashed files open in UniBasic. Value 5 - The current number of sequential and OS-level files open in UniBasic. Value 6 - The current number of index files open in UniBasic. Value 7 - The current number of temporarily closed files in UniBasic. This should give you everything that you need. HTH Colin Alfke Calgary Canada -Original Message- From: Susan Joslyn Greetings group, I have a problem at a new installation of PRC on a Unidata/Windows system. There are a couple of occasions where I get an announcement that too many files are open, and my program bombs. I think it's the combination of files that the application software has open as well as the ones I have open at that moment, plus SB+. The most helpful thing for me would be some function that will tell me at any given time how many files I have open and what files they are. I can't find anything like that. I have ways that I can determine what files I have open, and SB+ keeps a list of the ones it has open. But I don't know what the limit is. I guess I'm going to have to take the known places where this is occurring (as they occur) and close all of my files that I don't need and hope it's enough. Anyone know of anything that will help me solve this problem? All advice appreciated! Cheers, Susan Joslyn p.s. I'm a digest subscriber so I'll either see responses later (which is fine, I'm in no hurry) or you can copy me directly at [EMAIL PROTECTED] if you like. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Managing open files
Hi ya'll, Actually I got this sorted out. There are some things about it I don't understand -- and I tried to open and close files to see what affect I could have and still don't understand some of it. But this program will cause a nice display of the situation, so since I typed it in I thought I'd share it back. Thanks! SUBROUTINE TEST.OPEN.FILES 5 * FILES.INFO = SYSTEM(50) * MAX.FILES = FILES.INFO1,1 HASH.OPEN = FILES.INFO1,2 DYN.OPEN = FILES.INFO1,3 RECOV.OPEN = FILES.INFO1,4 SEQ.OPEN = FILES.INFO1,5 IDX.OPEN = FILES.INFO1,6 CLS.OPEN = FILES.INFO1,7 * TOTAL.FILES=HASH.OPEN+DYN.OPEN+RECOV.OPEN+SEQ.OPEN+IDX.OPEN+CLS.OPEN * CRT @(-1): CRT Unidata SYSTEM(50) query of open files CRT CRT Maximum files that can be open :MAX.FILES CRT Total files currently open :TOTAL.FILES CRT 10 * NO.AMS = DCOUNT(FILES.INFO,AM) FOR X = 2 TO NO.AMS-1 CRT FILES.INFOX,1 L#10:FILES.INFOX,2 IF NOT(REM(X,18)) THEN CRT @(0,23):;INPUT JUNK NEXT X 999 * CRT @(0,23):Finished ;INPUT JUNK RETURN -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, December 22, 2006 9:15 AM To: u2-users@listserver.u2ug.org Cc: [EMAIL PROTECTED] Subject: RE: [U2] Managing open files If you're on a late enough version of UD have a look at SYSTEM(50). I can see it on my system as of 6.0.12 but not at 5.1.27. Here is a snippet from help system 50 The UniBasic SYSTEM(50) function returns a list of files open in UniBasic as a dynamic array. The first field is multivalued, and contains the following information: Value 1 - The maximum number of files that can be opened system-wide. Value 2 - The current number of hashed files open in UniBasic. Value 3 - The current number of dynamic hashed files open in UniBasic. Value 4 - The current number of recoverable hashed files open in UniBasic. Value 5 - The current number of sequential and OS-level files open in UniBasic. Value 6 - The current number of index files open in UniBasic. Value 7 - The current number of temporarily closed files in UniBasic. This should give you everything that you need. HTH Colin Alfke Calgary Canada -Original Message- From: Susan Joslyn Greetings group, I have a problem at a new installation of PRC on a Unidata/Windows system. There are a couple of occasions where I get an announcement that too many files are open, and my program bombs. I think it's the combination of files that the application software has open as well as the ones I have open at that moment, plus SB+. The most helpful thing for me would be some function that will tell me at any given time how many files I have open and what files they are. I can't find anything like that. I have ways that I can determine what files I have open, and SB+ keeps a list of the ones it has open. But I don't know what the limit is. I guess I'm going to have to take the known places where this is occurring (as they occur) and close all of my files that I don't need and hope it's enough. Anyone know of anything that will help me solve this problem? All advice appreciated! Cheers, Susan Joslyn p.s. I'm a digest subscriber so I'll either see responses later (which is fine, I'm in no hurry) or you can copy me directly at [EMAIL PROTECTED] if you like. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Managing open files
Greetings group, I have a problem at a new installation of PRC on a Unidata/Windows system. There are a couple of occasions where I get an announcement that too many files are open, and my program bombs. I think it's the combination of files that the application software has open as well as the ones I have open at that moment, plus SB+. The most helpful thing for me would be some function that will tell me at any given time how many files I have open and what files they are. I can't find anything like that. I have ways that I can determine what files I have open, and SB+ keeps a list of the ones it has open. But I don't know what the limit is. I guess I'm going to have to take the known places where this is occurring (as they occur) and close all of my files that I don't need and hope it's enough. Anyone know of anything that will help me solve this problem? All advice appreciated! Cheers, Susan Joslyn p.s. I'm a digest subscriber so I'll either see responses later (which is fine, I'm in no hurry) or you can copy me directly at [EMAIL PROTECTED] if you like. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Universe/NT Rel. 10.0.10: How to run a program written and compiled in one flavor in another flavor?
Dave, Brian, all, I get around the problem of the SELECT and COPY syntax differences by making a copy of the pick-flavored verbs (some platforms already have them) and I always execute COPYP and SELECTP and SSELECTP in my BASIC EXECUTE statements. Likewise you could create COPYI that is always the prime flavored even in a pick-flavored-account and then your hard-code can execute prime copy syntax -- which, granted, is easier to execute from within a basic program because its all on one command line rather than hitting return and responding to a prompt... I have to get even trickier in SB+ -- which will not officially run in Prime and Reality flavored accounts. I can't get to their source code to control the verb, so I continuously swap-out the verb in before-and-after routines. And of course I avoid using SB+ for selections when I can. But F3 lookups are so fantastic and I'm loathe to reinvent them. So I swap out the verb when I have to. Yes, it's risky -- there could be a failure by another process executing SELECT at the same moment. But -- I minimize when I use it and I've been lucky. I've proposed (for years) to IBM that SB+ create the P verbs as part of the SB-enablement of an account and then change all the source code to execute those P-verbs at all times. It's a simple fix, has no downside and then voila! SB+ runs in all flavors. But I digress. (and fantasize that if anyone else thinks this is an issue perhaps they'll put their own weight behind my request.) :) Susan -- Date: Mon, 10 Jul 2006 10:52:28 +0100 From: Brian Leach [EMAIL PROTECTED] Subject: RE: [U2] Universe/NT Rel. 10.0.10: How to run a program written and compiled in one flavor in another flavor? Dave The program flavor and $OPTIONS statement dictate the way the program is compiled: determining the specific object code generated. Which means that the BASIC code itself will run the same, regardless of the flavor of the account in which is runs. What won't work the same, of course, are flavor-dependent differences in any commands that you execute. For some commands, the simplest option is to create and execute your own synonyms by copying them from the appropriate flavor VOC. So for HUSH you might substitute the PICK flavor HUSH and call it PICK.HUSH. In a couple of places these are already provided: the COPY command has COPYI and COPYP versions in the VOC. Some aren't, e.g. CREATE.FILE has totally different syntax depending on flavor. It's the words 'any other flavor' that stand out. The main thing to catch you out is the differences in the enquiry syntax between PICK-like and INFORMATION-like flavors. Avoid using metacharacters on selections (SURNAME = SMITH]) and use LIKE instead (works across flavors), and ensure that you use double quotation marks around literals. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [UD] Simulation/performance testing tools
Greetings, Actually the mainstream desktop testing tools work remarkably well with U2 products. Especially Redback if you mean load testing your web page. There are products out there from the sublime to the ridiculous -- from shareware to very high end. How elaborate you want to be has to do with how much verification you want to be able to do. If you want to be able to script reads to the database to see if files are being updated correctly and calculations performed and so forth then get one with a powerful scripting language. If you just want to load test simulate a lot of users hitting a web-site there are loads of tools out there that will do it and it doesn't matter that it's Redback/U2 at the backend. A place to find loads of advise about software quality and testing, including reviews and links to various tools is at stickyminds.com. Cheers, Susan Joslyn Date: Tue, 6 Jun 2006 08:23:25 -0400 From: Andy Pflueger [EMAIL PROTECTED] Subject: [U2] [UD] Simulation/performance testing tools Hi, Anyone know of any good simulation/performance testing tools out there for the U2 and application server products (e.g. RedBack)? We are looking for some possible tools to try and simulate running 150-200 user processes to test the performance load of our Sun box(es). Thanks, Andy Pflueger Ivy Hill - Louisville --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Client interested in using Dynamic Connect with application software written with SBPlus
This is a subject near and dear to my heart. I have worked closely with the folks behind both Dynamic Connect and Accuterm to create usable terminal definitions when using SB+ in Character mode. Neither can be used with SB+ in SB's own GUI mode, although you can do some stuff with the GUI functionality of both programs. I don't think that makes sense in this case as you are talking about an end-user company that I can't imagine is interested in re-writing a lot of your front end. Dynamic Connect comes with a couple of special features that make it more SB+ compatible, although I've had trouble with F5 that I couldn't overcome before, too. You can get the F5 to work by use Ctrl-F and then 5 (like in DEFAULT TERM mode). But be sure to open the configuration page of Dynamic Connect and click-and-hold SB_KEYS and CONTROL_KEYS. (I'm sorry I don't remember exactly how to open that window -- someone else?) I have customers using an adds configuration, Wyse configurations and ansi/vt100/vt220 emulations. None are as perfect as I would like, but I think things go better with Wyse. Note that if you have stuff that is automatically downloading and that sort of thing, it will absolutely fail if SBClient is not at the desktop. Unless you want to rewrite it for DC's download stuff. HOWEVER you could put one copy of SBClient in, for the person who would do that sort of stuff, and the others could still use dynamic connect. I find that there are a lot of variables in the mix -- the platform, what env var is being exported by unix, all kinds of things that make a pat answer impossible, but I set the DC side to an emulation that I like, take a copy of the host side /TERM.DEFN item that I like the best and then tweak it until it is as close as it can get. I'm going to tell you -- this is my least favorite thing about SB. It's a total pain and makes me look like a dork time and time again. /end vent HTH, Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] RE: fast file transfers
Thanks to everyone for their input on my question about faster file transfers. Probably going to use a combination of your great suggestions. Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Fast file transfers
Greetings, Anyone come up with a really clever way to move a great deal of data from one machine to another (completely different Multivalue Platforms; jbase - Universe) all within the space of a weekend? We've tried some of the telnet programs that have multivalue specific file transfers ... take too long. Writing something on our own now -- but thought I'd check to see if one of you other smart guys or gals have solved this problem. Cheers and TIA, Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] SOX question
These subjects -- compliance with regulations like SOX and other
quality-focused controls are near and dear to my heart. And I have some
opinions and perhaps information about them. Hence a long-ish post. Maybe it
will help someone, somewhere.
The worst thing that happened as a result of the new SOX regulations is that
IT suckered ourselves with a double punch. First, we flat-out refused to
take a proactive part in this. We whined and whinged and wheedled and
wrangled our way out of things - developing strategies to AVOID DITCH and
DODGE the requirements -- energy and intelligence that could've been well
used in coming up with ways to BENEFIT from it. As a result the driving
force behind the compliance came from other parts of our organizations.
Battle lines were drawn. Overcompensation was rife. So -- water under the
bridge, but if your procedures are over-blown, cumbersome and
counter-productive CHANGE THEM. Nobody here is going to argue with a
straight-face that whacking away in live with no controls is BETTER, are
they? Find the sweet-spot. Push back. Make suggestions. The auditors
will buy into a lot of well thought out reasonable procedures. Not just buy
into, but jump on.
Many of my customers are small enough organizations, or small enough IT
shops anyway, that the segregation of duties was going to be a stumbling
block. But we put some controls into place to prevent a programmer from
testing their own software or from promoting their own change. And I
haven't seen any auditor balk at it. So we didn't have to add new staff, or
train somebody over in purchasing to do rollouts...we put our
checks-and-balances in place from within.
Similarly every company -- not just in our U2 world, but every company --
has a requirement to SEE a problem on live, perhaps even to FIX a problem
on live. That might be software, that might be data. We came up with
procedures and controls that accommodate and even capitalize on this -- and
which are compliant and have passed audit. When an auditor says you cant
make any changes on live you can respond with This is how we make sure it
doesn't happen casually, and here are our controls and procedures (and
audits) for when it needs to happen. Voila! Everyone is happy.
As far as going around controls --
First, this constitutes fraud and the IT staff need to understand
that. It is (and should be) a firing offense to go around the controls,
just because you know how. {I always liken this to locking your convertible.
A rag-top can be easily compromised, but nobody doubts that slashing through
someone's convertible to take their car or things in their car is a CRIME.
And honest people won't do it.) The procedures that folks are expected to
follow have to be reasonable enough that everyone can be reasonably expected
to follow them.
Most importantly: remember the purpose of the SOX legislation. It
is for the prevention and detection of financial fraud. If a control is not
completely secure ask yourself how attractive is this opportunity for
financial fraud? Analyze and put risk values on your controls. Then spend
your time and effort where the risk lives. (This exercise can actually be
quite fun -- How could I financially defraud my company from an IT
perspective?)
As an aside, the remote-VOC stuff in Universe (but sadly not
available in Unidata) can be used to really tie down some of the go around
methods described in this list over the last few days.
I'm going to get off my soapbox now, but naturally I'm going to drop in that
PRC is a software development life-cycle tool that can provide the IT
controls and procedures (the framework) to immediately and effectively meet
the requirements of SOX (and other regulatory compliance) while promoting
best practices and STREAMLINING productivity.
Susan Joslyn
SJ+ Systems Associates, Inc.
http://sjplus.com
[EMAIL PROTECTED]
(954) 796-9868
PRCR Real software configuration management for Multivalue/U2.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
[U2] Backups -- Universe
Greetings group. What are you folks using for backups these days? In terms of media and management thereof? Especially on Universe? TIA, Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
Sometimes, if a subroutine is only called during certain situations (thus, not often) and the file used by the subroutine is not used by the main program, opening the file within the subroutine that uses it makes sense to me. - From: Mark Johnson [EMAIL PROTECTED] What's the real need to have OPEN's in a sub. Isn't the main purpose of subs to allow repeated access of the same code. What's wrong with top-down coding with the OPENs, INCLUDES and other housekeeping in the beginning. I also think that any programming to accomodate the hardware limitations of the past should stay in the past. Dartmouth and other interpeted Basic languages were proven that code nearer to the top executed faster. So be it. I can't imagine that a sub anywhere in a program is any 'closer' to the top runs noticably faster. You would be hard pressed in a 60-100 user environment with everyone running their variety of apps to notice a provable difference in your program. Academic at best. I just inherited a job costing app that is a bear to debug. It 'reads' well with its graceful GOSUBs for everything but it gets out of hand. BTW, I wish the data/basic debugger would not 'step' through called subs when stepping through the main program. Just curious. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
One thing that has been over-looked in this conversation is the notion of 'lowest common denominator programming'. My software runs on all MV platforms. Therefore, whenever possible, I stick with syntax that works on all platforms. When that is not possible, I resort to calls and includes and CASE statements. Sometimes the syntax that works on ALL platforms is not the clearest, the most modern or the fastest to execute on any given platform. But so far I've not been able to justify having multiple versions of code *that are not necessary*. For example, I don't use alpha labels because they will not compile on all versions / flavors. Same with the REMOVE logic because it doesn't fly on all platforms. Both of those are handy and have benefits -- but are not worth keeping up with a separate version of the code for. Some things there is no common method -- things like the CHANGE() command, SWAP, RAISE, LOWER, CONVERT) ... I have to have a different subroutine/include/chunk to run this on each platform. Another nickel in the ante. Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
Brian, When you say pre-compiler ... tell me ... drooling ... have you written something that combs through BASIC code to highlight platform specific syntactical differences? My fantasy is to build an engine and then to build a small database of the commands (strings) as key that don't work or don't work the same on all platforms ... so that I can add to the database over time as I convert to new platforms or new features are added etc. Have you headed down that sort of road? SJ - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach Sent: Friday, September 30, 2005 8:18 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Susan, You make a good point, but the problem with that approach is that it stifles innovation and learning - though not in your case, of course :-) I have known programmers who took a 'lowest common demoninator' approach that was based on systems that were obsolete 20+ years ago, ignoring useful constructs because possibly they weren't supported on McDonnell Douglas Reality kit back when they were learning - or more likely, because their first manager told them not to use them because (s)he had heard they weren't supported 10 years earlier still. We accuse IBM of not doing enough in RD, and then refuse to use the tools they do provide for lack of compatibility (just how many UV houses out there actually USE the SQL or transactional functionality?) I would rather say, be aware of the differences and isolate them ... (In my case, I code in UniVerse as the widest feature set and use a precompiler to handle the differences) Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Are there any UniVerse / U2 Basic Language Self-Study materials?
IBM was really pushing their web-zine where they will pay for article submissions. It is probably not a ton of money, but those of you with the interest and inclination could begin a series -- with IBM buying them along the way and the collection growing in their searchable database... Gus has a lot of good info in the form or articles and series, as well -- maybe he can be persuaded to invest in breaking up the downloadable magazines into searchable articles. Likewise the Pick Users of Florida has produced tons and tons of technical articles that if piled up together would create good reference material. We don't have to reinvent the wheel -- not that a fantastic self-guided tutorial wouldn't be, well, fantastic. But baby steps, I guess. See what we have in found inventory? Two cents early on a Monday morning (so all must be forgiven), Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Universe active lists
Following up on this list question, I want to respond to the questions and suggestions. I do so appreciate each person who took a stab at it. Why would I write a program like BLEEP? Well, I wouldn't! But that was the very simplest way to illustrate the problem I was having with a far more complex suite of programs that run around the TCL editors on U2 in order to maintain source control security over a development environment (because that is what my product, PRC does (Did she really just manage to plug her product? Gadz, at least she's predictable!)). The couple of you that proposed I control the list myself, 'readnext'ing and executing the edit -- yes, there are some scenarios when I do that. But there are a couple of conditions when I want to just let go and let the editor do it's thing, directly. Why? * Because in some cases there are different functions available in an editor that knows a list is active, and when I control it one-by-one Universe doesn't know the list is active. (Best example, pre-stores.) * Because in the instances where I want to allow this to happen PRC doesn't need to be involved and strikes me as interference (and unnecessary overhead) to a routine edit. * Because it works that way just fine on the other platforms. And the suggestion that I use a different syntax to SELECT ... TO ... this would entail my having some control over the user/programmer who executed the select list (right). I can't make her type that, and I can't control what list variable she selects to. I could issue a mandate but that interferes with the mission statement of PRC -- that the programmer need not do anything differently. And, of course, they wouldn't always do it that way and so it wouldn't always work and that would be a BUG (just like I have now!) So the ideal goal was (in some specific scenarios) to be able to have my program just let go and allow the edit-from-list to carry on without interference. And just as my hero Chuck Stevenson suggested right away (and someone else mentioned it, too), using PERFORM instead of EXECUTE took care of it. Just like that. Sweet and simple. Thanks to everyone! Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Universe active lists
Greetings U2 users, I have a technical question/problem in Universe that I could sure use help with. If you type this: SELECT VOC = A] ED VOC (from a P flavored account in this case, but I'm not sure flavor has any influence on the real problem) The edit will run from the list of items in the VOC that start with A. But if you do this SELECT VOC = A] BLEEP VOC Where BLEEP is a BASIC PROGRAM that does this: SIZE = SYSTEM(11) IF SIZE # 0 THEN CRT you had a list active! EXECUTE 'ED VOC' END The executed version of ED VOC will not automatically run from the list that you selected before typing BLEEP. I guess the BASIC program has interfered with the system's memory that there was a list active. Is there a handy-dandy way for me to re-ignite the list before executing the ED VOC? I vaguely remember some stuff about PASSLIST and RTNLIST but everything I can find about that seems to work only if the BASIC program is what manufactures the list in the first place. But I'm thinking if the first thing BLEEP does is pass the active-from-tcl-list into one of the list variables, then I could re-activate it before launching 'ED'. But I'm not having any luck with this. Thanks in advance to anyone who can take time out of their busy day to help me figure this out! Susan Joslyn --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [uv]CREATE.FILE syntax for remote directories
You can do a full-path CREATE.FILE with Unidata, but not with Universe. I have been hoping that might make it to the compatibility list. I didn't know you could do a UNIX command and get a uv-typed (perhaps hashed) file -- as Martin's suggestion. What I do is create it locally by EXECUTING CREATE.FILE, then EXECUTE a UNIX 'mv' to push it to the correct location and then write down the Fpointer. Susan Joslyn SJ+ Systems Associates, Inc. -- Date: Mon, 13 Jun 2005 10:41:58 +0200 From: Manu Fernandes [EMAIL PROTECTED] Subject: [U2] [uv]CREATE.FILE syntax for remote directories Hi all, Question : Is there a way to specify a full path+filename instead a filename in the CREATE.FILE command ? To have files created into other directory like the current. Thanks for any suggestions. Manu Fernandes Infodata S.`r.l. -- Date: Mon, 13 Jun 2005 10:51:51 +0100 From: Martin Phillips [EMAIL PROTECTED] Subject: Re: [U2] [uv]CREATE.FILE syntax for remote directories Question : Is there a way to specify a full path+filename instead a filename in the CREATE.FILE command ? No but the underlying operating system level program that does the CREATE.FILE can do this. /usr/uv/bin/mkdbfile pathname type modulo separation (with the appropriate path on the mkdbfile program) It is relatively easy to wrap a bit of Basic around this and build your own CREATE.PATH verb. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Source code question
I don't have a nice clean technical answer to this. But I can share with you anecdotal information: PRC offers delivery of object or delivery of source with a trigger on the 'destination' to recompile delivered programs. No one ever believes in delivered object code across even two identical machines. We often talk about it -- but there's a (perhaps unfounded) universal mistrust that it will be correct. Movements between Realms (accounts) on the same machine, yes, people often take advantage of the ability to promote the object items. But everyone makes the same choice about moving source and recompiling on another machine! I think many of us are just as suspicious of the mechanism of moving binary object code to another machine as we are of subtle differences in that object code as it would be produced on the other machine. But -- again, I'm just running off at the mouth here because I have absolutely no technical foundation to share. Some of my customers have a clear reason not to trust moved object, some of them just have a gut feeling. But again, the final result is clear: no one believes in it. It would be interesting to hear if others believe they have clear-cut reasons for or against it! Susan Joslyn SJ+ Systems Associates, Inc. -- Date: Sat, 04 Jun 2005 18:19:29 -0400 From: Moderator [EMAIL PROTECTED] Subject: [U2] Source code question POSTED ON BEHALF A NON-MEMBER Hello guru's I've got question about source code. If I compile on 2 different machines and 2 different OS ex. HP-UX and AIX but on the same Universe versions the same source code (any basic code) did they work the same ? Maybe there are some system specific basic funcions which working different on different OS's. Conclusion : If I have source aplication ( all in UV Basic ) after migrating(compiling) on another OS there could be some changes between this two applications ex. different calculations, time representations etc.?? Regards Radoslaw -- Date: Sat, 04 Jun 2005 21:05:45 -0500 From: Larry Friedlander [EMAIL PROTECTED] Subject: RE: [U2] Source code question -- Date: Sat, 04 Jun 2005 22:40:29 -0400 From: Steven M Wagner [EMAIL PROTECTED] Subject: Re: [U2] Source code question The answer is a big fat maybe. It will depend on how different the OS's are and how tied into the OS the UV application is. I know that UV on HP-UX stored internal time as an integer and UV on WinNT includes the milliseconds. So a change from HP-UX to NT could be a major change. Different versions of Unix may not be quite as dramatic. Can you share what two different OSes you are considering? Steve Wagner At 06:19 PM 6/4/05 -0400, you wrote: POSTED ON BEHALF A NON-MEMBER Hello guru's I've got question about source code. If I compile on 2 different machines and 2 different OS ex. HP-UX and AIX but on the same Universe versions the same source code (any basic code) did they work the same ? Maybe there are some system specific basic funcions which working different on different OS's. Conclusion : If I have source aplication ( all in UV Basic ) after migrating(compiling) on another OS there could be some changes between this two applications ex. different calculations, time representations etc.?? Regards Radoslaw --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Locks, releases and STATU() (oh my)
Hello wizards, I've read what I can find on the subject, but I'm not finding what I need. As usual, anyone who knows where the info is, I would not be the least bit offended if you just point. Or if you know off-hand ... (Presently grappling with Unidata): When I hit a lock with a: READU this FROM that,ID LOCKED locked clause ELSE whatever LIST.LOCKS from TCL has always been worse than useless for me. For example at this exact moment I'm holding locks on 3 sessions, yet if I run LIST.LOCKS on a 4th session it displays ABSOLUTELY NOTHING. I don't see much on offer in the LOCKED clause, although the online help suggests that STATUS() will return the user number of the lock it ran into. Can't understand its output... I have a very short program that displays STATUS(), opens the file and displays STATUS() then does a READU against an item I purposefully have locked on another session and I display STATUS() a third time. What do you suppose its giving me, and what can I do with it? 1 STATUS = 0 -- beginning of program 2 STATUS = 1 -- after the open 3 STATUS = 197613 -- this is what it gives me after the READU against a locked item What I want to do is determine who/what has the lock, tell the user, I also want to be able to carry on under my own conditions when ud 46 flag is set which will by default allow edits to items I've locked against my own session. Which is too loose -- I want to check to make sure I'm in the exact right condition to do that and I'm not sure how I can (by seeing what is holding the lock) but ... does anyone know how to get ANY information out of a lock? Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Locks, releases and STATU() (oh my)
Awesome info and suggestion. Thanks so much! (I'll be back, looking to do the same stuff in uv if its different/gives me trouble). --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [UV] Version Control
Brian, This intrigued. ... version stamp your source code in a way that can be saved into the object code Where do you put it, what do you put there? What platform(s) have you done this on? I know we dig into the unix-level directories for their date ... (PRC checks that the object is newer than the source or it won't deliver (either/both)... and we have script/proc/macros/programs whatever that can search and display those dates from unix) ... but I'm interested in where you went with this. I think it's a good idea. Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [OT] Financial fraud (was the thread: Epicor)
Allen, This is a fantastic story. I am warning IT folks about just such a scenario ALL THE TIME. I've found that in these SOX audits the IT folk seem to think along two (deadly) lines. First, they tend to be just tell me what you want / give me a list (e.g. don't make me think) and secondly yeah, yeah, we'll make sure you can't use vi on the data wink, wink : good thing they don't know about ed! What folks don't realize about SOX is that now that an executive could be held responsible even if he didn't know (not that I think anyone on the jury believed Bernie Ebbers really didn't know (Worldcom)) those executives will be frantic to SHOW they didn't know. If they can point to a control that demonstrates a reasonable expectation that certain controls are in place (a signed off report that says data cannot be edited on live, for example) then the person who withheld certain editors from the control will actually end up being accountable. And this whole thing about exporting and importing data (soapbox is fully out and positioned center stage now): SOX is not there to PREVENT technology, flexibility, business realities! Some folks are getting so caught up that they are just lost in it. Excel is a great tool for presenting data. Users should be able to download it and play with it all day for internal decision making. But if those excel reports need to be used for consolidating multiple systems and actually reporting at an SEC level then they need controls. A control can be technological -- some reports import into read-only directories, maybe. Or a control can be human -- this report is consolidated every day, but on Thursday Sam spot checks the sales figures against the cash register reports and Sally signs off on the proofs. Or a combination ... the data is imported, the reports are created and the figures that go to the report are re-summarized, re-hashed in alternate reports that are stored on the system. [Here's an idea that has been misunderstood, too -- one company I know has an electronic report of certain activities e.mailed to an individual every day. This individual must check a box, digitally signing that he's reviewed them. He laughs and thinks everyone is stupid because he just checks the box and doesn't really review them. But what I'm trying to get him to understand is that whether or not he bothers to look, by signing off he has ACCEPTED RESPONSIBILITY for them. So if there were a problem, he'd get the 'do not pass GO, do not collect $200' card! SOX is really -- at its most bare-bones and fundamental level -- about justifying finger pointing. Think like Allen. collapsing portable soapbox that I seem to carry everywhere these days SJ Date: Wed, 16 Mar 2005 11:47:56 -0800 From: Allen E. Elwood [EMAIL PROTECTED] Subject: RE: [U2]: Epicor The system that I had setup, allowed accountants to change any field on an invoice. Believe it or not, that was the request. What they didn't know was that I kept a simple before change/change request/after change snapshot of the data along with date/time/logon as I had been warned about by a wise professor back in my school days (daze?). What I didn't know, was that they were changing the dates and invoice numbers on the invoices to make them look as if they were only 30-60 days old. This was to make the receivables look current, and therefore the company could leverage that to borrow money from Wells Fargo for purchase of more product to sell. The auditors from AA were very savvy and spotted the same invoice amount with different dates and different invoice numbers on printed aging reports kept for historical purposes. When they asked me about how that could happen, I produced the audit report. The accountants were charged with FRAUD at Wells Fargo's request and were tried and sent to jail! This was in the 80's. Way way before SOX. The first thing the accountants did was point the finger at me. That's why the auditors came to me along with the CEO with the intention of nailing me. Had I not been a paranoid programmer, I might have ended up in jail. The accountants thought I was a patsy, and got lots of time to think about that for 5 years. At the time, I worked for the accounting department. So I literally was protecting my career from my boss who was a fool of the highest magnitude and whom had drastically underestimated my abilities as a business analyst and programmer. Just because you're paranoid, doesn't mean they're NOT out to get you! --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Financial Fraud
Jeff, That one is easy. Requests for mods to the software must be documented and their justification is part of the request. Every SOX auditor I've come across has made this mandate. So in IT we have a methodology where we are responding to written requests that have been through authorization channels before coming to us. So -- without (necessarily) understanding the accounting or legal implications of the task at hand, you can verify that the request came through proper channels. Everyone has their job definition -- you don't have to have knowledge or expertise or fear outside of your realm of responsibility. BUT BOY-GOLLY make sure you are taking your own steps. If it turns out you did something that you can't point to the audit of the request and justification for WHY you did it -- well, then you may need your lawyer. Help put good procedures in place -- in the first place -- that make sense and then don't let people bypass the rules (emergencies are part of the rules, not an exception to them -- have established emergency-justification-criteria and then established emergency procedures!) whoosh-clap sound of collapsible soapbox folding up Susan Date: Thu, 17 Mar 2005 08:08:46 -0500 From: Lettau, Jeff [EMAIL PROTECTED] Subject: RE: [U2]: Epicor What if I make a change to the code in the system according to what the CFO wants and then I get implicated as being an accomplice to fraud. Can I pull my college credits where I failed accounting as being my defense? Is it getting to the point where every change to the system requires a call to a lawyer to check to see if it is ok? Jeffrey Lettau ERP Systems Manager polkaudio --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2]: Epicor
Deb, Sometimes the client actually does know best when administering their system controls Actually I couldn't agree with you more, especially about PRC Lite. It was early days and even then I didn't completely agree with the philosophy. On the more recent versions of Avante and PRC things got better. I can respond more in detail privately (I have Powerpoint presentations and stuff) or take this to the Avante newsgroup - But I wanted to state here that there are probably things that you/we can do (within PRC and procedurally) to ease your situation. I would love to hear specifically what the more open source control tools could do for you because I'm always interested in making PRC work the best for its users. I suspect that ANYTHING would be more open than PRC Lite. But I am always keen to hear ideas for improvement - or help iron out a difficult situation. For folks who have developer seats of the newer (Rel 5) PRC, there are a few things that people don't tend to do (to know about) which can have a huge impact on the amount of time it takes to install patches and releases. In your case specifically, Deb, it sounds like you are on an older release of Avante and PRC and it may be that you are caught there . Although with a little careful handling we can arrange it so that you can upgrade to a developer seat of the newer PRC without upgrading Avante. Then you could put some procedures in place that might ease things up quite a bit. I reckon there are always happy and not-so-happy customers of any product, particularly software. That is why its good to have this forum to air those. Let us hope that Epicor are watching keenly as well. Chers, Susan -Original Message- From: [EMAIL PROTECTED] [] On Behalf Of Debster Sent: Monday, March 14, 2005 10:50 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2]: Epicor Sorry Susan Your baby ain't butt ugly but no mother thinks her baby has flaws... But -- I've worked on alot of packages, and yes even extensive tier 1 packages that are well out of price points for some. Yes with Avante there are alot of bells and whistles, but ofttimes when trying to be all things to all manufacturing markets you miss the mark by being too convoluted to use effectively without customizing it to meet the individual company needs and throwing out a good portion that you paid for. Remember KISS? Sometimes simple is better, or something geared toward more specific target market, ala flavors like we are all familar with. Problems do arise with Avante and trying to administer the patches without total disruption. The location I am at was virtually shut down for more than just a day or two due to patches in the past. Even when initially bringing the system up, they were shut down due to screw ups by Epicor tech reps in regards to system set up functions. I know its your baby, but I loathe the fact that you are forced to utilize PRC. Granted my current location runs the light version along with the fact that there are few software version control systems available for the U2 market, but I have utilized more open home grown systems that provided better ease of use while providing just as much or a higher level of control and deployment functions. Sometimes the client actually does know best when administering their system controls. Even though there may be many happy as a clam Avante users, and you see those in attendance at user meetings, but what percentage does that represent of the actual number of end-users? Pissed off customers rarely attend those functions unless it's to sit at the back of the room and heckle. Someone asked for an opinion from users, and I gave it from my 15+ years in manufacturing as a resource... Sorry --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2]: Epicor
Susan steps in, ugly baby on her hip Wow -- that wasn't a very strong endorsement of Epicor as a product. And I am surprised. I go to their user meetings all over the US and Europe and I have to say that there are a lot of really, really happy Avanti, Manfact and Dataflo customers around the world.I'm sure it has flaws and bugs -- I haven't met a perfect software application yet. But many people tell me that it has flexibility and functionality for many types of manufacturing and general ERP business applications that is far beyond what else is out there in the price range. But the part of this that brought me into this foray is the bit about how difficult patch releases are. This is something that I've been very involved with at Epicor. (PRC is the tool used internally and at customer site to manage the software configuration and the patches and releases.) Now granted, they don't do exactly the way I'd like them to. But they are a big company and for some silly reason they won't let me run it! Even so, I guess if they issue bug-fix documents and patch releases too frequently I can understand feeling overwhelmed. But let's face it, its a lot of software and the fact that they are working hard to keep it current is a good thing -- isn't it? One of the hallmarks of the success of the Avanti product has been Epicor's commitment to accommodating customization. To that end they have created a system for tracking, delivering and reintegrating what can be constant change. I heard recently that the ability to stay on current releases of Avanti and customize to your hearts content is well above industry standards. Most of the time you have to choose. Now -- there are some things that Avanti customers can do on their side that will help manage the constant influx of change. Things that many companies don't bother to do until the integration effort becomes cumbersome and then they may not realize how a few simple changes in procedure in-house could have a huge impact. I would be happy to elaborate on these simple changes but won't use list bandwidth on it. But get to me privately if I can help. I couldn't help but hop in, partly in defense of Epicor. Some good folks over there working hard to provide good solutions. But its more personal, too -- you may not have realized that you called my baby ugly. :) Susan Joslyn SJ+ Systems Associates, Inc. PRC (r) Real software configuration management for U2 development. Date: Sun, 13 Mar 2005 11:48:35 -0500 From: Debster [EMAIL PROTECTED] Subject: RE: [U2]: Epicor The Avante package I am working on uses UV. They seem to have Technical Bulletins on almost a bi-weekly basis of bugs within the system. The patches are a bear to install if there is even the normal end-user amount of customization on the existing system and a nightmare if it's extensive. Most of these bugs you find fixing well before the patch arrives if it's in an area that you utilize. There appears to be little to no respect for how Epicor handles support. Trying to gestimate learning curve for an individual is hard. What shortens the timeframe is the same for any package/tool. Just how familiar are you with the outside factors such as a extensive understanding of manufacturing business process flow and if you have ever utilized SB+ before. If you are unfamiliar with either than it of course extends the learning curve. I have seen both sides of the coin with other consultants at my current contract, one had extensive expertise in SB+ and very little Basic or manufacturing. The end result in his contribution was use of SB+ tools that were not utilized anywhere else within the Avante system, spaghetti in regards to the manufacturing functions, and misuse of SB+ tools where Basic was more appropriate. [Not even the illustrious SB+ guru Kevin King did that as he passed through their doors] On the other side, yet another consultant was unable to conform to the use of SB+ when appropriate. In other words, when enhancing, by conforming to the rest of the system it creates a better flow and less problems, it also strengthens your understanding of the system. I found Avante's extensive use of SB+ tools the biggest hurdle since other systems I had used it on primarily utilized it for forms and report design leaving the majority of processes to be written more in Basic. That is not the case with Avante, there is extensive use of paragraphs. I find this more cumbersome, more system use intensive with poor use causing gross inefficiencies. If you use debugger a lot to troubleshoot as I had in the past, it becomes a nightmare. You wind up using trace and display functions instead at various points to view what is actually occurring. Making sure you don't step on yourself as you pass through multiple paragraphs, screens to basic and back to the original screen depends on file use and preserving the work files utilized. Best bet when customizing Avante is to not screw too much
[U2] [OT]- PRC Newsletter (pardon the *brief* intrustion)
Greetings. (I'll be quick -- and no replies here, please!) In cleaning up I've been a little surprised at the folks that weren't on my mailing list and should have been. The Loosely Q1 2005 edition is about to go out. If you've not been getting the PRC newsletter in the past and want it, please e.mail me. (Naturally if you get it and you don't want it, tell me!) Please reply privately to [EMAIL PROTECTED] (PRC News Source is a loosely Quarterly e.mag that covers issues of relevance to PRC users and friends.) Thanks, ducking out Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2]: Epicor
I can't stand it -- I have to correct. I know that Epicor's U2 product is Avante with an accent over the 'e'. My word processor knows to fix the spelling and include the accent-e. Whatever filters text for post changed e/accent to an 'i'. Makes me look foolish furiously defending a product if I don't know its name, doesn't it? Avante(accent). :) --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unidata acount on unix
Than you all for the response (all below). I had tried 'newacct' and it didn't fly but I think the bit about including $UDTBIN in the path was the key. At any rate, once I used a full path to newacct it seemed to do the trick. Thanks! Martin Canty: just like Windoze, only better. 'newacct' You will also need to specify a valid unix group owner. Mike Randall: It's been a while but I believe it was makeudt? Wally Terhune: same.You can also avoid the lists and prompts for owner and group by specifying eg newacct root sys Ken Wallis: Its the same ... You might need to make sure that your PATH includes $UDTBIN, and indeed that $UDTBIN is set, but once that is done, newacct user group should work. Mike Randall: So what was makeudt? Martin Canty: If I remember (in my dim distant past), it's used to compile a new UniData executable... Used if custom C routines need to be compiled into UniData. Kevin King: ...to rebuild the udt executable from object libraries. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Unidata acount on unix
This is such a fundamental question ...sorry I'm such a numbskull -- I never do this. How does one make a directory on unix into a unidata account? On windoze I just make the directory and then go to it and type 'newacct'. What does the trick on unix? Thanks a million! Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] SBClient cannot connect to SB+ on UV/AIX
David, Its usually just that you have to upgrade SB+ at the same time. The message is saying that you have to be on a newer SBClient but it just can't do math. I believe its telling you that you need to be on a newer SB+ to go with your new SBClient. You can't rarely upgrade one without the other. Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unidebugger
Chuck, Nope, forgot about that one. You're right, triggers cannot be used on directory type files. We did ask IBM for that at the U2UG meeting in Las Vegas last September. Their chief argument against them was that you can get to those directory files from outside U2 anyway. But I likened that argument to let's leave the front door wide-open because the back one won't lock. If we had triggers for all file types then we could certainly put tracking on Unidebugger, couldn't we? And that's worth something even if we have still left those program directories exposed from UNIX. Because note this -- by NOT putting in those triggers we have NOT done anything about the fact that the files can be edited from outside U2. And that protection can be worked out another way -- or the weakness documented and other mechanisms used to validate. To me the most significant argument in its favor is the fact that we want to allow this on our development machines or accounts. The live directories can be locked up tight with UNIX permissions and writes only allowed by regular software deployment using a librarian login, etc. The fact that its wide-open on the development machines is not as big an issue if we control what gets to the live machine. Something is better than nothing -- and I'll say again what I've said at least a thousand times. SOX didn't come into being to protect against the kind of folk who can make UNIX edits using vi. If anyone knows of any case anywhere, where financial fraud has occurred this way - by a legitimate employee user (not a hacker, that's a whole different conversation) then I would love to hear about it. I'm not saying it should be discounted as a possibility, just that we shouldn't spend too much time on that -- its like focusing on a crack in the pavement while the bus is screaming down on us. I hope that IBM is listening -- and if anyone agrees with me that triggers are critical in today's IT, please put your two cents in. (For all file types, with an efficiency that makes them usable.) Just full of long stories, Susan Date: Tue, 1 Feb 2005 23:34:57 -0500 From: Stevenson, Charles [EMAIL PROTECTED] Subject: RE: [U2] Unidebugger From: Susan Joslyn [snip] Gordon, I would think that you could address it with file triggers... any reason why you can't? triggers wont work on type 19 files. Programs have to be type 19 files. Can PRC work around that one? cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [AD] Unidebugger
Or there's always PRC -- manages data, software, dict -- any -- mods. Delivers a complete framework as required by SOX. Handles the software life-cycle from request to deployment with a single thread. Nearly 13 years mature and over 1000 installations. The work is already done and SJ+ makes it their full-time occupation to keep up with requirements and features so that your IT staff can get back to their real job. Only it will be easier than it was before because of the tools and information provided by PRC at the programmer level. :) Date: Wed, 2 Feb 2005 07:26:32 - From: Adrian Matthews [EMAIL PROTECTED] Subject: RE: [U2] Unidebugger We use EditPlus with SourceSafe which works well as no-one can change a program from within Universe or without unless it's been checked out first. We developed an add-in (as have others) to make the links to SourceSafe an integral part of EditPlus so checking status, checking in/out, promoting to test/pre-prod/prod is all done via a menu/single keystroke. Before we started using EditPlus we used the command line facilities of SourceSafe to link into the Universe shell. Of course, maintaining version control over dictionaries and property records is a bit trickier as SourceSafe will only work for type 1/19. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unidebugger
We're using the word 'locking' in two different ways, here. Lock as in 'read lock' is indeed done by the unidebugger. Locking as in -- calling a host subroutine to validate the available status in a source library system (such as PRC (hah! You knew I'd plug!) is something that the Unieditor (with Wintegrate, but not Dynamic Connect) can do, but the Unidebugger (presently) cannot. Everyone whine and beg and maybe they can put that in for us. In the meantime, Gordon, I would think that you could address it with file triggers... any reason why you can't? Susan From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon J Glorfield Sent: 01 February 2005 14:00 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Unidebugger Now I'm confused. You are now the second person to claim that the UniDebugger doesn't use locking when it reads/writes host Basic programs. This is definitely not the case here. We use the UniObjects connect method and it does use and honor record locks. I was hoping that someone could suggest a method utilizing triggers or something to get it to honor our check-in/check-out database. I'm not really interested in investigating alternatives to UniDebugger. I just want to explore making it work. Perhaps I need to look at the read/write permissions, as hinted at earlier, as a possible solution. Cheers, Gordon Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 02/01/2005 07:40:55 AM: The UniDebugger doesn't use locking when it reads/writes host Basic programs as this would not fit the home-grown check-in/out systems many people use. In the wIntegrate Editor we added the ability to call a custom subroutine at the usual points which give 100% control, in the same way as the service subroutine which is optionally called by the Query Builder to filter what the users sees and does. However today the UniDebugger does not support custom host subroutines. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV/Redback] How can my UV code determine the redback user
Actually, this discussion is all true as far as user-users. Business users. Web users. But Adrian is wanting to audit stuff that gets changed in development mode. And this is actually possible. And I have notes about how to do it. But I can't locate them on short notice right now. But it is in release notes for how to do the revision control stuff. There's a hook where you can put a program and one of the variables available to you is the IDE user. Let me know if you can't find it and I'll look harder. Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] SOX Compliance and Universe
First I want to sincerely thank Vance, Clif and Bill for kind words. Vance, having you, my customer speak out like that makes it all worth while. :) Naturally I do have some remarks about this stuff --I've been living and breathing these issues for over a decade now and the SOX stuff specifically in full immersion mode this past year! So I have some observations. Some are technical, some might be community. I apologize if I stray. Using Remote VOCs is a great idea, I'm so glad they are available. The thing is, that's just a 'way' to wrap a verb and you still have to write a whole framework and application around it to determine who can under what circumstances use the verb. So that's a great building block of the solution. But the solution does still have to be built. Controlling at the underneath level (with, say, UNIX permissions) is the absolute best way to go on the live machine. Having a librarian and program that has the authority to write. This is the most truly safeguarded way. It is hard to set-up initially (which files can be protected, which ones will cause a problem if they are protected), but is the tightest. In either case, two things that happen on live at every IT shop that I've ever come to know -- and this past year I must admit I was gratified to learn that its not just us folks in the U2 world -- these two things are emergency software fixes that have to happen on LIVE and 'data fixes'. That last bit -- you can make the auditor shudder. Remember in Lion King when the hyena says Mufasa and it makes the other hyena shudder and he says say it again! yeah, like that. Say data edits on live and watch in amusement as your auditors quake. Anyway, whether you're locking up at the UNIX level or with the remote VOC entries or with peanut butter, you have to have a way that allows these things to happen in such a fashion that they will pass audit. I have devised such a fashion within PRC, of course, and will be happy to elaborate but this e.mail is already going to be unbearably long ... I saw that someone else already responded to whether or not non-publicly traded companies are required to file reports under SOX and while the answer is no there are reasons why a company would want to consider a new level of control -- perhaps not as far as what SOX requires (what does SOX require? Now there's a topic) ... but at any rate: * want to go public * may want to be acquired by a public company * may want to do business with a public company * other governance initiatives (hipa, nrc, dod, etc.) * competitive advantage Now to this: Seeing this post made me wonder how other companies productivity has changed since SOX. We are going to have to hire people to do jobs that did not exist before. Programming changes that used to take less than a day usually cannot be done now in that time frame. In order to get the proper signoffs from the business, stuff sits and waits now. Our auditors are insisting that we have one person on the business side that makes sure all signoffs are done before anything goes into production. This is a topic that fascinates me. Every week smaller traded companies are 'de-listing' and 'going dark' because of SOX. (Hmm, is that what we were going for?) Then there's the ones that charged on and found that they had grossly underestimated the requirement and the cost. There is a raging debate about how much is too much and whether we have dealt the corporate world a fatal blow. In my personal opinion we had to do what we've done. I have a lot of opinions about billing and busy work and taking our eye off the ball. And I have a lot of advice for how to achieve compliance and do some good at the same time. Yes, you can. In the situation above I would very much like to ask why is that stuff sitting and waiting? Because people aren't doing their job? Is the signing off an onerous task? Could it be made easier? I believe -- I really, truly believe that this whole can of worms can be dealt with in sleek, sure measures with procedures that are streamlined, efficient AND TRANSPARENT. It takes some work up front, but if you're stalled out in a situation where progress has been hindered don't stop there. Work it through. I have loads of specific advice on that -- and I'm sure so does Clif and many others of us who specialize and obsess on these issues. But I've got one word for you: Cobit. If you haven't gotten a grip on what Cobit is I really recommend that you do. It's a little like reading Shakespeare -- might seem a little like mumbo-jumbo until you get the hang of the language, the presentation. But then it just breaks down, labels, clarifies, identifies, lists, prioritizes and organizes what may have seemed before to be a nebulous mass. Thanks for listening. Oh yeah, and buy PRC. :) Susan Joslyn SJ+ Systems Associates, Inc. Sjplus.com PRC - Real software configuration management for U2. --- u2-users
[U2] quiet list - American holiday weekend
The Americans cook and stuff them selves and argue with family on Thursday and every red-blooded American goes shopping on black Friday. :) Things will be back to normal on Monday, I'm sure. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
[U2] RE: running a subroutine [AD]
Or you could use a product such as PRC to take care of sandboxing (personal copies) and versioning and backups and tracing history and all of that sort of thing. All while automating the whole life-cycle, bringing best-practices and compliance to the party. Oops ... did I say that out loud? Predictably, Susan [SJ] Date: Wed, 20 Oct 2004 22:00:31 -0400 From: Mark Johnson [EMAIL PROTECTED] Subject: Re: [U2] [UD] running a subroutine I learned a method years ago and even had it published in Spectrum. I'll recap it here. Say you have one BP. I create another file called BP.ARCHIVE whereby I put all of the prior versions of code for any programs that I make changes to. I have a utility that I call DCOPY (stands for Dated COPY) that does 2 things. DCOPY BP UPDATE 1. Copies the current version of UPDATE to BP.ARCHIVE UPDATE_102004. It puts the date at the end. 2. Throws you into EDIT BP UPDATE as that's probably the next step anyway. If you do it more than once on a day, I append dot1, dot2 to the date suffix. Gone are the pathetic NEW, TEMP, REVISED, OLD, HOLD, SAVE, V2, V3 and other suffixes as you are really left with BP UPDATE and many items in BP.ARCHIVE that start with UPDATE and have a useful date suffix. The problem with OLD and NEW is they don't tell you when they became OLD or NEW. A similar discipline i use for temp files is to create-file PRODUCT_102004. First, its name clearly doesn't look on-line. Second, I EDIT DICT PRODUCT_102004 README and write a little reason why I created it in the first place. Often it's to protect a subset of data when making a mass change. Later, whether days, weeks or months, I can review these dated archive files and determine if I need them to backup the changes that I made. Usually I can delete them. PRODUCT.NEW or PRODUCT.SAFE doesn't tell me anything. Am I the only programmer with multiple environments (clients) that continues to follow in the footsteps of prior sloppy programmers. It appears that most on this forum are full-time programmers for a specific software company or large end user. Just curious. Thanks - - Original Message - From: Allen E. Elwood [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 9:14 PM Subject: RE: [U2] [UD] running a subroutine I just have one all purpose test program called BBB (BBBecause it's easy to remember AND type) This way when I test something, I just put in a STOP above the previous test stuff and then stick my new statements above that. This way if I ever need to go back and see if I tested a snippet of code that is close to what I need, I can just look at all the code and see. This has saved me a bunch o' hours through the years in that I never have to think of a unique name for a test program, and it becomes a historical record of programming examples that come in quite handy. I always like to have an AEE.BP file for my utilities, as well as a XXX.BP file for the clients files with the XXX being replaced with client's initials. The Manage-2000 system that I've worked a lot with has SCADS of .BP files for all the different modules and one gets used to seeing 6 pages of .BP's when listing the voc.. I agree with you that having a bunch of .bp's with upgrade and upgrade.new is WAY more than scary and just outright sloppy. I am a firm believer in the XXX.BP and OBSOLETE.BP. This way obsolete code gets deleted from the XXX.BP and put into the OBSOLETE.BP and there is no question of what it is, and yet it's a real timesaver to be able to go back to OBSOLETE.BP and resurrect a function that the client said was dead, and then half a year later wants to know what happened to the function! I always make the OBSOLETE.BP a file, instead of a directory, and that prevents anyone from compiling any of the programs in it. I use the XXX.BP as I have had clients running multiple companies with different versions of the same code (like AP.CHECK printing) for their different divisions and yet they want the names to stay the same for ease of use. It's just another safeguard when copying and installing programs that you can see you're copying the CPI version of a program into the CPI.BP file instead of just a BP file which could have been in the RED account or the CPI account. Just my couple of pennies on this subject.:) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Wednesday, October 20, 2004 17:18 To: [EMAIL PROTECTED] Subject: Re: [U2] [UD] running a subroutine True, but don't throw the baby out with the bathwater. If the program gets sophisticated enough that starts using COMMONS or INCLUDES, then write a real test program. Perhaps 90% of standard stupid test programs can be eliminated with PRINT. When I get a new client, I suggest and allow myself time to clean up BP items that I deem useless. I see BP items called TEST, TEST2, DATE, DATETEST, BOB, BOB1 etc
Re: [U2] Comparison Unidata and Universe
Of course, if you have PRC and Wintegrate (not just dynamic connect) then Unieditor can lock (and check out and track) the file you are editing. Just so you know... Date: Sun, 26 Sep 2004 15:16:46 -0400 From: Dave Walker [EMAIL PROTECTED] Subject: Re: [U2] Comparison Unidata and Universe Gordon Glorfield wrote: Now, in the 21st century, I use the UniDebugger exclusively for both coding and data fixes. The color coding of the source makes it visually pleasing. The cut and paste, drag and drop, etc. make it a great productivity increasing tool. Best of all it's free! Or at least it comes with the DB license. Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 Only problem we've found is that it doesn't lock the file that you're editing. Makes its use problematic in a multi-programmer shop. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
[U2] Avoiding automatic e.mails to the list
I worried about that, too -- I get a lot of lists. And I hated the idea of replying to spammers, too. I think the lists have logic that filters for the out-of-office or automatic replies? I assume so because we see them ONCE but not over and over again. I can't use Outlook to do it (because I take it on my laptop with me when I go) so I have to use the even more limited ISP version. It doesn't let me control who gets it. So on the occasions that I need to send one I figure its not going to kill anyone that didn't need to see it and those that did need to see it are my primary concern. But if someone wants to tell me differently I'm listening. [SJ] Date: Sun, 12 Sep 2004 23:10:15 -0700 From: Tony Gravagno [EMAIL PROTECTED] Subject: RE: [U2] How do you avoid out-of-office Outlook auto-reply to this list Oops, I posted how to avoid the messages, not how to send them. Sorry Chuck. T Stevenson, Charles wrote: (Yes, I could unsubscribe temporarily, but I prefer a more complicated solution.) Could some kind soul please post the MS Outlook (v. 2003) procedure for preventing the standard I will be out of the office... auto-reply from being sent to this list? I want everyone else to get it, but not the u2-lists. I can't figure out how to turn the feature off for particular exceptions. And we do know that I'm not the only one! -- End of U2 Users Digest V1 #244 ** u2-users-digest mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [OT] Sarbanes-Oxley
Kevin's observation is sadly true. We don't have any managers or accountants in here do we? (you may want to leave now grin) See the thing is, we're letting the auditors drive this thing. Don't get me wrong, they have to, to a certain extent. The Sarbanes-Oxley Act of 2002 (available in its entirety at Sarbanes-oxley.com) isn't really very specific about HOW the numbers are verified. Only, in a nutshell, that the CFO and CEO sign off saying I KNOW that the numbers on our financial statement are correct. Now because they can go to jail if it turns out they aren't they are in a bit of a panic. And they haven't a clue what to do about it. But they want to make sure that its CLEAR AND OBVIOUS that they've 'done diligence'. In step the auditors. Now the auditors - for the most part, let's be fair - don't know all that much about the inner workings of a large company's IT department and the mechanics and shenanigans that put that final number on the 10K. So they come up with a lot of (sometimes unnecessary) hoops for us to jump through. What can we do about it? Well, first, we have to realize that we've got this powerful, flexible environment which has nurtured a seat-of-the pants attitude. Not a bad thing, I mean we can produce amazing results on the fly. We've learned to depend on ourselves that way. But it might look a little scary to an outsider contemplating jail time. So we might have to suck it up just a little and say okay, we're going to be slowed down a bit by this. And then the next thing we do is realize that the slow-down should truly be temporary. While we work out procedures that work and get used to them its going to slow us down. But believe it or not over time the fire-fighting will slow down and we'll get time back. I promise. Then - it would be a really powerful thing if we educated ourselves a bit (see this months article in Spectrum on CobIT) and took the reins. Make sure some if this gi-hyoogic investment is going to give Us something WE want. If we come to management with a clear picture of how we can comply we can set aside some of the hoops. I have one colleague whose auditors are demanding a full table/chart of all access to all files by all programs. Hey that would be a cool thing to have. But trust me, its not required for SOX compliance. Its just the auditors trying to come up with ways that look nice and black-and-white and legitimate and . compliant. If somebody over there had proposed the - realistic steps - that needed to be taken first, this would never have happened. If someone would do a little reading and then stand up and say here's a plan the requirement in question would be scrapped in a heartbeat. This is what I do for a living. I'd love to help any of you. Either with my tools and services (hey, it is my living) or with a little advice and direction. You can't FIGHT this stuff . but remember when you were taught that if you capsized in a strong current not to swim against it but to angle toward the shore and let the current take you there? What SOX really is? A giant budget-boost for IT and a guaranteed tech-onomic recovery. And incidentally an opportunity for us to raise the bar on our software quality. Gosh, possibly even legitimize Multivalue once and for all! Ever the optimist,. Susan Joslyn PRC - Real software configuration management for U2/Multivalue http://sjplus.com Date: Thu, 5 Aug 2004 15:44:14 -0600 From: Kevin King [EMAIL PROTECTED] Subject: RE: [U2] [OT] Sarbanes-Oxley I just re-read Susan's excellent article, and it strikes me as odd that the definition of world class (reducing overhead, et al.) seems to run counter to the way folks are approaching SOA compliance. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
[U2] VOC Comparison Program
Never one to miss an opportunity, Susan swoops ... Hi Denny, PRC is, of course, a whole change-management solution. But as part of that solution is a split-screen/side-by-side editor that will compare any two items of any nature. And a utility that will comb through a whole file, as well. Then, of course, you wouldn't have mysterious differences in the VOC anymore because changes could be prevented and/or audited. And quite easily reverted. So, in case this comparison that you're doing is part of a larger initiative ... please contact us! On the other hand, you could use one of the myriad share ware diff utilities that you can find on the web. They won't work with a VOC file, but you can create two directory type files and put things you'd like to compare into there and use one of those. Susan Joslyn SJ+ Systems Associates, Inc. PRC - Complete software development life-cycle management for U2 http://Sjplus.com Date: Fri, 11 Jun 2004 08:41:21 -0500 From: Denny Watkins [EMAIL PROTECTED] Subject: [U2] VOC Comparison Program Does anyone have or know of a utility program that will compare the entries in two different VOC files in two different Universe accounts and give a report of the difference by the item in the VOC? Thanks, Denny Watkins Director Computer Services Morningside College 1501 Morningside Ave Sioux City, Ia 51106-1717 Phone: 1-712-274-5250 Email: mailto:[EMAIL PROTECTED][EMAIL PROTECTED] --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
