|
|
| Wikipedia login page (Photo credit: Wikipedia) |
28-October-2014
Perhaps the most ignored and seemingly insignificant part of the PROMIS session is the
login part. And why not? Just invoking the session, then typing in your username and password gets you in, then what you do after that is no longer needing or relating to log-in processes.
Perhaps.
But if you do a lot of scripts, and I mean not just simple scripts, but if you have multiple log-in privilege, or that the script you wrote is run by many users who log in to different terminals at the same time, and they can run the script at the same time, then this is needing the variables you use in your scripts to be singletons, or they should be user-based, or ID-based.
ID-based would sometimes be a problem, because the same script can be run by a multi-session user, and the data cannot be crossing over. Same idea as
Microsoft's "sandbox" concept.
Thus, variables can be set in the login.com file. Some other files can be invoked. Messages, etc.
But most importantly, Host- or Instance-based variables can be detected and set, and this will determine what kind of session you will be having, running.
Machines are either transaction-serving or report-serving, so having that set in your login.com file will help you know right-away which session you are running, especially if you are like me, who opens 4 sessions, at the minimum. The flexibility and speed of PROMIS running in
VAX-
VMS is such that multi-session is no native, making you very productive.
It was just unfortunate that the time I started learning and using PROMIS, there was not much furor about
SAP, which was way behind
Oracle. Our company was using SAP back then, and I would have learnt it also, maybe. That was about 20 years ago.
A lot has changed since then - but not PROMIS and VMS. They remain. And while the company I now work in has decided to build their own MES by creating their own version of a
Manufacturing Execution System, the concept and base knowledge I gleaned from my almost 2 decades of working in PROMIS is in such a magnitude and scope - I learned other software and programming languages in the course of time, especially when parallel
dBase was introduced, and I was one of those who "qualified and stress-tested" the new system.
And even with native PROMIS datalink extraction method, my knowledge in Excel was enhanced, as there was a lot of data massaging afterwards - which all went away naturally when reports were generated using the parallel database, all running in Oracle. Which made me very comfortable navigating the tables because I know very well the structure of the
ISAM files in native PROMIS, so switching to Oracle tables was a breeze, and that gave me the advantage of simply focusing on
learning SQL.
I will stop here, before I digress too far away. I will present the login that make a native session come up with a unique idea that can be used as a variable for scripts that can be run at the same time by different users, or even the same user with multi-session privilege.
Till then!
Posts
