Where is the licensing information kept for JET on UV.
Someone had their system reloaded - One big difference was their UV account went
From being c:\IBM\UV to c:\U2\UV and I'm not sure if the JET account was moved
to
A different location either.
When they run JET, it says it's not authorized
Have them contact their U2 support provider. Rocket has JET.
Cheers,
Dan McGrath
Managing Director, U2 Servers Lab
Rocket Software
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen
Sent: Monday,
Jet as a subset of Rocket instead or Rocket as a subset of Jet.
It's a different universe.
On 1/6/2014 8:00 PM, Daniel McGrath wrote:
Have them contact their U2 support provider. Rocket has JET.
Cheers,
Dan McGrath
Managing Director, U2 Servers Lab
Rocket Software
This is the *first* I've heard that Rocket is still shipping JET !
-Original Message-
From: Charles Stevenson stevenson.c...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Mon, Jan 6, 2014 2:39 pm
Subject: Re: [U2] JET
Jet as a subset of Rocket instead or Rocket as a
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
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
On 1/6/14, 7: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
That would be interesting. The only thing I've done in the past, is to stick a
subroutine call near the top, to write the name of the routine into a logging
file, and then recompile all the programs.
-Original Message-
From: McGowan, Ian james.mcgo...@bankofthewest.com
To: U2-Users
Maybe convert the VOC entries for the programs to R pointers. The r pointer
would point to a file with the original VOC entry for the program. Then in
attribute 4 of the R pointer put a security subroutine which logs the calling
details for each call etc. That way you can gain a picture of when
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
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
Will/Jeff, you're right that it's an option, but it's not a very appetizing
option. We certainly could add an include or subroutine at the top of every
program (does anyone care about the performance difference between the two
anymore? That used to be a big deal :-). Less concern with how to
On 07/01/14 00:40, McGowan, Ian wrote:
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
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: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of lar...@wcs-corp.com
Sent:
Phil, thanks for the suggestion. This isn't going to work for us as we catalog
our programs and don't generally catalog direct. I.e. we don't have VOC
pointers (except when someone forgets and does FIBR from within AE).
Thanks for the idea though; I learned two new things today - off to check
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
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
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
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
Wow! Didn't know about that command either. This has been very instructional.
I can easily filter out the vendor code from that command by path, and just
see our custom programs.
There seems to be some caching going on too, at least until the user logs off -
the reference count stays for
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
21 matches
Mail list logo
