Discussion:
f$getjpi("","LAST_LOGIN_I") Populated at login but not dynamic?
(too old to reply)
IanD
2017-02-15 02:02:50 UTC
Permalink
Raw Message
I was looking for a simple way of checking for the first interactive login for a day (to run some checks on first session opened, and to skip them on subsequent logins for the day)

I went to use: f$getjpi("","LAST_LOGIN_I") as a check but came unstuck...

It appears a call to f$getjpi("","LAST_LOGIN_I") gets you the last login value returned to your process but subsequent calls from the same process to f$getjpi("","LAST_LOGIN_I") does not update this symbol dynamically - it appears it's populated for your process once and only once at login :-(

I guess I will have to resort to getting the value via a UAF specific call and muck around with getting the value that way

Yes, f$getjpi implies it's a process related function call but doesn't allude to the fact that it does not return a dynamic value, just a static one derived at login time only for your given process

Maybe a lexical service f$getuai might be useful? (but I guess it depends on whether or not DCL is revamped or replaced with another scripting language)
Arne Vajhøj
2017-02-15 03:03:32 UTC
Permalink
Raw Message
Post by IanD
I was looking for a simple way of checking for the first interactive
login for a day (to run some checks on first session opened, and to
skip them on subsequent logins for the day)
I went to use: f$getjpi("","LAST_LOGIN_I") as a check but came
unstuck...
It appears a call to f$getjpi("","LAST_LOGIN_I") gets you the last
login value returned to your process but subsequent calls from the
same process to f$getjpi("","LAST_LOGIN_I") does not update this
symbol dynamically - it appears it's populated for your process once
and only once at login :-(
There is a lot of info stored in memory at process start.

Having $GETJPI hit SYSUAF would probably have been very
expensive in resource usage when the design was made.
Post by IanD
I guess I will have to resort to getting the value via a UAF specific
call and muck around with getting the value that way
I would think so.
Post by IanD
Yes, f$getjpi implies it's a process related function call but
doesn't allude to the fact that it does not return a dynamic value,
just a static one derived at login time only for your given process
I suspect that the same applies to all the other values from SYSUAF.
Post by IanD
Maybe a lexical service f$getuai might be useful? (but I guess it
depends on whether or not DCL is revamped or replaced with another
scripting language)
F$GETUAI would be great and match the rest of lexicals fine.

If you switch to another scripting language that supports
extensions, then something can easily be done.

Arne
IanD
2017-02-15 05:45:36 UTC
Permalink
Raw Message
Post by Arne Vajhøj
Post by IanD
I was looking for a simple way of checking for the first interactive
login for a day (to run some checks on first session opened, and to
skip them on subsequent logins for the day)
I went to use: f$getjpi("","LAST_LOGIN_I") as a check but came unstuck...
It appears a call to f$getjpi("","LAST_LOGIN_I") gets you the last
login value returned to your process but subsequent calls from the
same process to f$getjpi("","LAST_LOGIN_I") does not update this
symbol dynamically - it appears it's populated for your process once
and only once at login :-(
There is a lot of info stored in memory at process start.
Having $GETJPI hit SYSUAF would probably have been very
expensive in resource usage when the design was made.
Post by IanD
I guess I will have to resort to getting the value via a UAF specific
call and muck around with getting the value that way
I would think so.
Post by IanD
Yes, f$getjpi implies it's a process related function call but
doesn't allude to the fact that it does not return a dynamic value,
just a static one derived at login time only for your given process
I suspect that the same applies to all the other values from SYSUAF.
Post by IanD
Maybe a lexical service f$getuai might be useful? (but I guess it
depends on whether or not DCL is revamped or replaced with another
scripting language)
F$GETUAI would be great and match the rest of lexicals fine.
If you switch to another scripting language that supports
extensions, then something can easily be done.
Arne
Yeah, I can do it in Python ok but the instantiation costs of bringing up the Python interpreter is rather expensive. When it comes to seamless integration with DCL and scripting languages there is the constant need to find ways around transferring data across to symbol and back again :-(
Yeah, Python has methods available thanks to the great work done in the libraries that have been made but it's still somewhat convoluted to set the structures up

The other issue is when dealing with production systems it can be time consuming and painful getting extra tools / languages installed, if not nearly impossible depending on the environment (another plug for making these tools installed by default on future VMS systems)

Interesting that functions like f$getdvi have no such limitations when obtaining live data

You are probably right, way back yonder, when Vax's were state of the art, getting data out of the UAF was probably expensive. Perhaps it's because things like f$getdvi data is possibly stored in memory (although I don't think certain file attributes are)?
Arne Vajhøj
2017-02-20 03:48:44 UTC
Permalink
Raw Message
Post by IanD
Post by Arne Vajhøj
Post by IanD
Maybe a lexical service f$getuai might be useful? (but I guess it
depends on whether or not DCL is revamped or replaced with another
scripting language)
F$GETUAI would be great and match the rest of lexicals fine.
If you switch to another scripting language that supports
extensions, then something can easily be done.
Yeah, Python has methods available thanks to the great work done in
the libraries that have been made but it's still somewhat convoluted
to set the structures up
I have been playing around with some Java and JavaScript.

Demo:

$ type demo.js
load("vms.js");

printf("Processes:\n");
var fmt = "%-12s %-20s %-20s\n";
printf(fmt, "Username", "Process name", "Owner");
var p = syssrv.SYS$PROCESS_SCAN_and_SYS$GETJPIW_AsArray("USERNAME", "*",
["PID","USERNAME","PRCNAM"]);
for(i = 0; i < p.length; i++) {
printf(fmt, p[i].USERNAME, p[i].PRCNAM,
syssrv.SYS$GETUAI(p[i].USERNAME,["OWNER"]).getResult().OWNER);
}

$ jsshell demo.js
Processes:
Username Process name Owner
SYSTEM SWAPPER
SYSTEM LANACP
SYSTEM IPCACP
SYSTEM ERRFMT
SYSTEM OPCOM
AUDIT$SERVER AUDIT_SERVER
SYSTEM JOB_CONTROL
SYSTEM QUEUE_MANAGER
SYSTEM SECURITY_SERVER
SYSTEM ACME_SERVER
SYSTEM TP_SERVER
DECNET NETACP
DECNET EVL
SYSTEM REMACP
INTERnet TCPIP$INETACP
SYSTEM HGFTP Listener
APACHE$WWW APACHE$SWS
APACHE$WWW APACHE$TOMCAT
MYSQL051_SRV MYSQL051_SERVER
SYSTEM SMHANDLER
ARNE ARNE Arne Vajhoej
APACHE$WWW APACHE$SWS0000
APACHE$WWW APACHE$SWS0001
APACHE$WWW APACHE$SWS0002
APACHE$WWW APACHE$SWS0003
APACHE$WWW APACHE$SWS0004
Post by IanD
Yeah, I can do it in Python ok but the instantiation costs of
bringing
up the Python interpreter is rather expensive.
Does it matter?
Post by IanD
When it comes to seamless
integration with DCL and scripting languages there is the constant need
to find ways around transferring data across to symbol and back again :-(
If it supports setting symbols and logicals then it is possible.

But long term most of it should just stay in the new script
language.
Post by IanD
The other issue is when dealing with production systems it can be
time consuming and painful getting extra tools / languages installed,
if not nearly impossible depending on the environment (another plug
for making these tools installed by default on future VMS systems)
Exactly.
Post by IanD
Interesting that functions like f$getdvi have no such limitations when obtaining live data
That live info is probably in memory.
Post by IanD
You are probably right, way back yonder, when Vax's were state of the
art, getting data out of the UAF was probably expensive.
Yep.
Post by IanD
Perhaps it's
because things like f$getdvi data is possibly stored in memory
(although I don't think certain file attributes are)?
Does f$getdvi return file attribute??

Arne
Craig A. Berry
2017-02-20 13:02:34 UTC
Permalink
Raw Message
Post by Arne Vajhøj
I have been playing around with some Java and JavaScript.
Where did you get the Javascript interpreter; does it run on the JVM?
Post by Arne Vajhøj
$ type demo.js
load("vms.js");
printf("Processes:\n");
var fmt = "%-12s %-20s %-20s\n";
printf(fmt, "Username", "Process name", "Owner");
var p = syssrv.SYS$PROCESS_SCAN_and_SYS$GETJPIW_AsArray("USERNAME", "*",
["PID","USERNAME","PRCNAM"]);
for(i = 0; i < p.length; i++) {
printf(fmt, p[i].USERNAME, p[i].PRCNAM,
syssrv.SYS$GETUAI(p[i].USERNAME,["OWNER"]).getResult().OWNER);
}
Arne Vajhøj
2017-02-20 13:43:20 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by Arne Vajhøj
I have been playing around with some Java and JavaScript.
Where did you get the Javascript interpreter; does it run on the JVM?
Yes.

I just took Rhino (1.7 R5).

Arne
IanD
2017-02-21 08:16:35 UTC
Permalink
Raw Message
On Monday, February 20, 2017 at 2:48:45 PM UTC+11, Arne Vajhøj wrote:

<snip>
Post by Arne Vajhøj
Does f$getdvi return file attribute??
Arne
ha ha ha, yeah, after I posted it I realised I had typed the wrong thing but Google groups via the web has no edit ability so to fix it I would have had to delete and re-post, I could not be bothered and I needed to run out the door for something at the time

It does however return current space statistics so it sort of complies with my vain attempt to draw parallels to information being on-hand and at the ready

Another one I would like would be to do with directory information. How about a running total of files in a directory (since the index is being updated anyhow when files are being created / deleted). Maybe add a memory area that holds the last file edited too? (but I guess there would be gymnastics around listing rights etc)

Maybe we can have triggered events where you put a watch on a resource and when it changes a memory region / symbol structure you have defined gets populated? i.e. a move towards event driven occurrences versus polling stuff (I know you could set up an audit event but that's convoluted and ultimately privilege protected, hardly easily DCL accessible and friendly)

Maybe a future thing to add to VMS perhaps? Event services :-)

Stephen Hoffman
2017-02-15 19:16:29 UTC
Permalink
Raw Message
Post by IanD
I was looking for a simple way of checking for the first interactive
login for a day (to run some checks on first session opened, and to
skip them on subsequent logins for the day)
Either make the daily job re-entrant and safe to re-run — usually the
best approach, as clusters with less than completely synchronized times
can really mess up periodic jobs that aren't reentrant — or schedule
the task automatically from a nightly job scheduler and separate it
from the user login and yes you can submit batch or run detached
processes under other users, or (simplest) write or modify a turd file
during each run and that'll allow a subsequent run to detect and
process the contents or the turd file metadata via f$file with CDT
(don't see the file modified date listed in the help text for the
f$flle arguments), or write some code that calls sys$getuai or other
such and go after this from the system database. There are also
UAF-related tools on the Freeware, and I've ported and tweaked the
GETUAI tool originally written by Frank Nagy; that tool can fetch
settings to symbols. But I'd usually prefer to use the
reentrancy-based approach, and failing that use either the automatic
nightly run from your job scheduler, or the turd file. Yes, it'd be
nice to have f$getuai, too.
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Gezelter
2017-02-15 19:57:49 UTC
Permalink
Raw Message
Post by IanD
I was looking for a simple way of checking for the first interactive login for a day (to run some checks on first session opened, and to skip them on subsequent logins for the day)
I went to use: f$getjpi("","LAST_LOGIN_I") as a check but came unstuck...
It appears a call to f$getjpi("","LAST_LOGIN_I") gets you the last login value returned to your process but subsequent calls from the same process to f$getjpi("","LAST_LOGIN_I") does not update this symbol dynamically - it appears it's populated for your process once and only once at login :-(
I guess I will have to resort to getting the value via a UAF specific call and muck around with getting the value that way
Yes, f$getjpi implies it's a process related function call but doesn't allude to the fact that it does not return a dynamic value, just a static one derived at login time only for your given process
Maybe a lexical service f$getuai might be useful? (but I guess it depends on whether or not DCL is revamped or replaced with another scripting language)
Ian,

F$GETJPI is essentially a DCL-accessible SYS$GETJPI call. Certainly no more, sometimes somewhat less.

Sometimes the lexical documentation is not complete. The system service description is more extensive.

- Bob Gezelter, http://www.rlgsc.com
Bob Koehler
2017-02-16 20:20:42 UTC
Permalink
Raw Message
I was looking for a simple way of checking for the first interactive login =
for a day (to run some checks on first session opened, and to skip them on =
subsequent logins for the day)
I went to use: f$getjpi("","LAST_LOGIN_I") as a check but came unstuck...
It appears a call to f$getjpi("","LAST_LOGIN_I") gets you the last login va=
lue returned to your process but subsequent calls from the same process to =
f$getjpi("","LAST_LOGIN_I") does not update this symbol dynamically - it ap=
pears it's populated for your process once and only once at login :-(
How can one process have more than one login?
Arne Vajhøj
2017-02-16 20:32:46 UTC
Permalink
Raw Message
Post by Bob Koehler
I was looking for a simple way of checking for the first interactive login =
for a day (to run some checks on first session opened, and to skip them on =
subsequent logins for the day)
I went to use: f$getjpi("","LAST_LOGIN_I") as a check but came unstuck...
It appears a call to f$getjpi("","LAST_LOGIN_I") gets you the last login va=
lue returned to your process but subsequent calls from the same process to =
f$getjpi("","LAST_LOGIN_I") does not update this symbol dynamically - it ap=
pears it's populated for your process once and only once at login :-(
How can one process have more than one login?
The docs says:

JPI$_LAST_LOGIN_I
Returns, as a quadword absolute time value, the date of the last
successful interactive login prior to the current session. It returns a
quadword of 0 when processes have not executed the LOGINOUT image.

So it is not login of this process but previous login so definitely
another process.

It seems like:
- LOGINOUT calls $GETUAI and stuff into memory
- $GETJPI fetches it from memory

Arne
Chris Scheers
2017-02-17 17:30:06 UTC
Permalink
Raw Message
Post by Arne Vajhøj
Post by Bob Koehler
I was looking for a simple way of checking for the first interactive login =
for a day (to run some checks on first session opened, and to skip them on =
subsequent logins for the day)
I went to use: f$getjpi("","LAST_LOGIN_I") as a check but came unstuck...
It appears a call to f$getjpi("","LAST_LOGIN_I") gets you the last login va=
lue returned to your process but subsequent calls from the same process to =
f$getjpi("","LAST_LOGIN_I") does not update this symbol dynamically - it ap=
pears it's populated for your process once and only once at login :-(
How can one process have more than one login?
JPI$_LAST_LOGIN_I
Returns, as a quadword absolute time value, the date of the last
successful interactive login prior to the current session. It returns a
quadword of 0 when processes have not executed the LOGINOUT image.
So it is not login of this process but previous login so definitely
another process.
- LOGINOUT calls $GETUAI and stuff into memory
- $GETJPI fetches it from memory
Since it is defined as "the last successful interactive login prior to
the current session", by definition it is static and can not update.

Any subsequent logins will be after (not prior) to the login of the
current session.
--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ***@applied-synergy.com
Fax: 817-237-3074
Bob Koehler
2017-02-20 17:53:07 UTC
Permalink
Raw Message
Post by Arne Vajhøj
Post by Bob Koehler
It appears a call to f$getjpi("","LAST_LOGIN_I") gets you the last login va=
lue returned to your process but subsequent calls from the same process to =
f$getjpi("","LAST_LOGIN_I") does not update this symbol dynamically - it ap=
pears it's populated for your process once and only once at login :-(
How can one process have more than one login?
JPI$_LAST_LOGIN_I
Returns, as a quadword absolute time value, the date of the last
successful interactive login prior to the current session. It returns a
quadword of 0 when processes have not executed the LOGINOUT image.
OK, but "last successfull interactive login prior to the current
session" is a specific historical event, it doesn't change. So why
would this value change?
Arne Vajhøj
2017-02-20 18:44:04 UTC
Permalink
Raw Message
Post by Bob Koehler
Post by Arne Vajhøj
Post by Bob Koehler
It appears a call to f$getjpi("","LAST_LOGIN_I") gets you the last login va=
lue returned to your process but subsequent calls from the same process to =
f$getjpi("","LAST_LOGIN_I") does not update this symbol dynamically - it ap=
pears it's populated for your process once and only once at login :-(
How can one process have more than one login?
JPI$_LAST_LOGIN_I
Returns, as a quadword absolute time value, the date of the last
successful interactive login prior to the current session. It returns a
quadword of 0 when processes have not executed the LOGINOUT image.
OK, but "last successfull interactive login prior to the current
session" is a specific historical event, it doesn't change. So why
would this value change?
It don't.

But last successful interactive login do change. And that seems
to be what OP was expecting.

Arne
abrsvc
2017-02-20 19:16:40 UTC
Permalink
Raw Message
I've been following this discussion for a while and believe that the one way to provide what you want is to use logical name in either the group or system table (to survive the no-current-process environment) as follows:

Define trigger = Yesterday (for the first time only)

Check the value of trigger compared to the current day
If they are different, (current day more recent than trigger) perform the task and set trigger to the current day.
If they are the same, do nothing.

The above 2 steps will allow for the task to be performed at the first login of the new day and prevent execution on subsequent days.

While not perfect, this should do what you want.
With the proper compare, you shouldbe able to handle the case where the next login in not for a few days etc.

Hope this helps,
Dan
Loading...