Re: [U2] Logging program execution in Unidata?

You can find it in the 'Using UniData' manual under 'R Types - Remote Items'

http://docs.rocketsoftware.com/nxt/gateway.dll/RKBnew20/unidata/7.3/udtu.pdf

You can also find a slightly larger code example of a subroutine you could call via this mechanism on GitHub: https://github.com/RocketSoftware/u2-servers-lab/blob/master/UniVerse-11.2/Compiler-Defines/securitySub
It will compile on UniData (should work at least on all the 7.x series) and on UniVerse v11.2.x

Regards,
Dan

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wjhonson
Sent: Tuesday, January 07, 2014 10:20 AM
To: [email protected]
Subject: Re: [U2] Logging program execution in Unidata?


On this R-pointer point, can someone point me to the manual which describes the ability to have a security routine on these?
I can't quite figure out where that information is.

I've never heard of that ability before this thread.

Thanks.



-----Original Message-----
From: Dennis Bartlett <[email protected]>
To: U2 Users List <[email protected]>
Sent: Mon, Jan 6, 2014 10:02 pm
Subject: Re: [U2] Logging program execution in Unidata?


Ian
Perhaps your answer lies in a combo - rather than looking at the actual code you have, why not focus on what calls it: This will minimise what changes are needed.

MENU: you say you don't have code for the menu system - but you do have access to the VOC, so why not do the R pointer thing on the VOC entries of the menu stuff. A little research could get the main 'calling' routine, and maybe something like uniVerse's @PARASENTENCE might tell you what was called.

FILES USED: Files can have triggers applied that simply 'touch' a file at o/s level - file being named of file:date:time:seq:action. The resultant ls will tell you what files were read/written and when.

TCL: As for the ops staff dropping to TCL, you could write a pseudo TCL that has all the commands, but logs their use. I've seen this done successfully in situations where some staff are limited in what they can do. Most folk don't even realise they're at a pseudo level.

CRON: As for the cron items, what about R pointer'ing the PHANTOM verb (dunno if that's possible!) - then you could trap what's being launched each time. Alternatively, stepping outside of the UniData environment you could apply svn to the &PH& file, which would give you date / time evidence of calls to launch (the advantage is that it has tools designed for
analysis)

JAVA ETC: Java etc calls can be logged outside of UniData.


On 7 January 2014 12:27, McGowan, Ian <[email protected]>wrote:

> That's a good question - always get to what the user really needs, not 
> what they say they want ;-)
>
> I support a vendor supplied application.  It runs from the LOGIN 
> paragraph and provides a menu interface.  Over the years we have 
> written a lot of supporting code "around" the vendor app, so now we 
> have (at least) four ways a custom program can be run:
>
> 1) We can add user-defined menu items and they get EXECUTE'd from the 
> menu (by code I don't have access to)
> 2) Our operations people can drop to TCL and run a command directly 
> from there
> 3) We have an elaborate cron setup that ends up running "streams" on a 
> variety of schedules
> 4) We use uniobjects, and different external interfaces making calls 
> into Unidata (mostly subroutine calls from java and .net clients)
>
> As a result of an upcoming upgrade (in > 1 year), we're likely going 
> to have to touch all of the programs and make some modifications.  
> Ideally we'd cut down the number by disregarding one-off programs that 
> haven't run in ages.  We have programs last compiled in 2004, but I 
> know they run many times per day, so time-stamps don't cut it.
>
> -----Original Message-----
> From: [email protected] [mailto:
> [email protected]] On Behalf Of Charlie Noah
> Sent: Monday, January 06, 2014 5:31 PM
> To: U2 Users List
> Subject: Re: [U2] Logging program execution in Unidata?
>
> Ian,
>
> You said you didn't have a wrapper program. How do your programs get 
> executed?
>
> Charlie
>
> On 01-06-2014 7:23 PM, Baakkonen, Rodney A (Rod) 46K wrote:
> >   What we did was have a cron run every 10 minutes that executed a
> Unidata program. The Unidata program did a PCPERFORM sbcsprogs to 
> capture everything that was running out of the global catalog. It 
> parses up the output of sbcsprogs and builds a Unidata file. This file 
> has the program name as the key and the following attributes:
> >
> > DR                      DoctoR (Display Record)     File:
> CBH.PROGRAM.TRACKING
> >
> > ATB ATB Name                  Conv       Value       Item: CLM101
> >
> >    1 Last Update               D2/        01/06/14
> >    2 First Recorded            D2/        11/16/00
> >    3 No of Times Captured                 4254
> > End of Defined Attributes
> >
> > If something consistently runs and finshes within 10 minutes, it 
> > will
> never be recorded. You could have the threshold set to whatever you want.
> But we thought 10 minutes was good enough for our usage.
> >
> >
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Wjhonson
> > Sent: Monday, January 06, 2014 7:07 PM
> > To: [email protected]
> > Subject: Re: [U2] Logging program execution in Unidata?
> >
> >
> > I believe there is something wrong with this suggestions.
> > IIRC you don't get the time and date it was last RUN, only the date 
> > it
> was last "Accessed".
> > I suspect this is the "touch" date, which could mean that just 
> > looking
> at it in a directory scan, "touches" it.
> > Along with a host of other things that don't actually *run* the code.
> >
> > So it wouldn't answer the Q as to whether it's "actively" executed.
> >
> > You also get the number of times is has run since being catalogued,
> which always seemed to be an odd choice for me.
> > It may have been run a thousand times, but not run at all in the 
> > past
> ten years.
> > But if I ruled the world, things would be different.
> > Not better just different.
> >
> > Anyway, let us know how it works for your purpose.
> >
> >
> >
> > -----Original Message-----
> > From: McGowan, Ian <[email protected]>
> > To: U2 Users List <[email protected]>
> > Sent: Mon, Jan 6, 2014 4:55 pm
> > Subject: Re: [U2] Logging program execution in Unidata?
> >
> >
> > Larry/Wol, thanks for this.  Trying it now on a dev server.  Not 
> > sure
> how I've missed this all these years, but glad to learn something new!
> >
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]
> > On Behalf Of [email protected]
> > Sent: Monday, January 06, 2014 4:44 PM
> > To: U2 Users List
> > Subject: Re: [U2] Logging program execution in Unidata?
> >
> > MAKE.MAP.FILE
> >
> >> We catalog all our programs - locally (so they end up in CTLG in 
> >> the current account) for programs specific to a particular account, 
> >> as well as globally (so there is a pointer in CTLGTB) for generic programs.
> >>
> >> Unfortunately, unidata seems to have  _MAP_ file in 
> >> $UDTHOME/sys/_MAP_ (as well as a MAP command) but at least for us 
> >> it's
> not populated.
> >>
> >> Thanks for the suggestion,
> >> Ian
> >>
> >> -----Original Message-----
> >> From: [email protected]
> >> [mailto:[email protected]] On Behalf Of dale 
> >> kelley
> >> Sent: Monday, January 06, 2014 4:13 PM
> >> To: U2 Users List
> >> Subject: Re: [U2] Logging program execution in Unidata?
> >>
> >> Ian,
> >>
> >> In universe the map file contains the most recent execution date 
> >> for cataloged programs.  Programs that are just "RUN" I don't know 
> >> of any
> way.
> >>
> >> Dale
> >>
> >>
> >> On 01/06/2014 06:08 PM, McGowan, Ian wrote:
> >>> We're looking into a major conversion late this year, which will 
> >>> involve checking out several thousand programs (mostly opens, 
> >>> reads or
> > writes).
> >>> Some programs are run many times a day, whereas some were 
> >>> throwaway and haven't been touched in years.  It would be great to 
> >>> get some sense of which ones are active.
> >>>
> >>> We unfortunately don't have a wrapper program, wondering if anyone 
> >>> has run into this before - is it possible to somehow log when a 
> >>> program is executed in Unidata?  Any magic triggers, directory 
> >>> flags or other audit flags that can get turned on?
> >>>
> >>> Any ideas gratefully received,
> >>> Ian
> >>>
> >>>
> >>> -----------------------------------------
> >>> IMPORTANT NOTICE:   This message is intended only for the addressee
> >>> and may contain confidential, privileged information.  If you are 
> >>> not the intended recipient, you may not use, copy or disclose any 
> >>> information contained in the message.  If you have received this 
> >>> message in error, please notify the sender by reply e-mail and 
> >>> delete the message.
> >>> _______________________________________________
> >>> U2-Users mailing list
> >>> [email protected]
> >>> http://listserver.u2ug.org/mailman/listinfo/u2-users
> >> _______________________________________________
> >> U2-Users mailing list
> >> [email protected]
> >> http://listserver.u2ug.org/mailman/listinfo/u2-users
> >> _______________________________________________
> >> U2-Users mailing list
> >> [email protected]
> >> http://listserver.u2ug.org/mailman/listinfo/u2-users
> >>
> > _______________________________________________
> > U2-Users mailing list
> > [email protected]
> > http://listserver.u2ug.org/mailman/listinfo/u2-users
> > _______________________________________________
> > U2-Users mailing list
> > [email protected]
> > http://listserver.u2ug.org/mailman/listinfo/u2-users
> >
> >
> > _______________________________________________
> > U2-Users mailing list
> > [email protected]
> > http://listserver.u2ug.org/mailman/listinfo/u2-users
> >
> > --------------------------------------------------------------------
> > --
> > -------- CONFIDENTIALITY NOTICE: If you have received this email in 
> > error, please immediately notify the sender by e-mail at the address 
> > shown.
> > This email transmission may contain confidential information.  This 
> > information is intended only for the use of the individual(s) or 
> > entity to whom it is intended even if addressed incorrectly.  Please 
> > delete it from your files if you are not the intended recipient.
> > Thank you for your compliance.  Copyright (c) 2013 Cigna 
> > ====================================================================
> > ==
> > ========
> >
> > _______________________________________________
> > U2-Users mailing list
> > [email protected]
> > http://listserver.u2ug.org/mailman/listinfo/u2-users
> >
>
> _______________________________________________
> U2-Users mailing list
> [email protected]
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> _______________________________________________
> U2-Users mailing list
> [email protected]
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

 
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users