UNIX on the HP Nonstop
Gaby
At the risk of asking something too elementary, (I'm new to the
nonstop system) I wanted to ask if someone could tell me the purpose
of having the UNIX operating system on the nonstop. At the place I
work, I only have access to the TACL and I have never ever seen even
the main programmer get in the UNIX environment. However she has
mentioned several times that this is available. I have more experience
on UNIX than on TACL/ENTRUDER. This is why I am asking. Can I do the
same things I do on TACL if I switch to the UNIX partition. Again,
sorry if this is dumb...
dimandja
code stuff that you find on other Unix systems. Unix does have tools
similar to TACL.
Keith Dick
The purpose of providing the OSS environment is to offer a much more "standard" programming environment on a NonStop system than the Guardian environment is, so that programs available for Unix/Linux can be ported much more easily than they could if the only environment available were Guardian.
The OSS environment is decidedly *not* a standard Unix or Linux environment; just much closer to standard than Guardian is. There are manuals for the OSS environment in the online manual set whose names beging with "Open System Services", which most people abbreviate to OSS. The OSS Porting Guide and the OSS Programmer's Guide probably are the two best ones to look at to get an idea of what OSS is like -- how it is the same as a Unix or Linux system and how it differs.
The OSS environment sits on top of the NonStop Kernel and so OSS has no low-level OS stuff that a Unix or Linux system has. This allows fairly good integration between OSS and Guardian programs where that makes sense, but there are some points where cross-personality operation isn't possible.
When you are in the OSS environment, you run a standard shell (Korn shell, I believe) and have most of the normal Unix/Linux commands available (with specific documentation available online via man and in the OSS Shell and Utilities Reference manual.
You can run OSS commands from a TACL, and you can run TACL commands from the OSS shell. The TACL command osh does the former, and the shell command gtacl does the latter. There are some restrictions on what can straddle the OSS/Guardian divide, but quite a lot can be done that usefully combines commands from the two environments. From a TACL environment, you can enter the osh command with no arguments, and you are immediately at a shell prompt. I don't know whether there are any security-related things that have to be done to authorize that, so it might not work for you without some setup. I believe the gtacl command without arguments similarly switches from an OSS shell prompt to a TACL prompt. Since the 6530 terminal and the typical OSS terminal have different block mode interfaces, you cannot run block mode programs, such as vi or TEDIT when you cross from one environment to the other that way, but any purely command line commands work properly.
One interesting example of integration between OSS and Guardian is that Pathway servers can be OSS processes. The iTP Webserver is an OSS/Pathway hybrid whose high-level design is pretty clever, but I think the actual implementation has some issues.
I have no idea what ENTRUDER is or does, so I cannot comment specifically on it, so I don't know you would do the same thing on OSS, if it is even possible. I think the biggest failing of OSS is that it seems not to have been aimed to be a complete environment. You cannot run a NonStop system entirely from within the OSS environment -- some thing have to be done from Guardian. Still, OSS is rather successful at what it seems to have been aimed at -- more easily getting Unix/Linux software running on NonStop. It could be even better at that than it is, but it already is rather good at that.
If you have more specific questions, do ask. We probably can answer them.
Keith Dick
I probably should also have mentioned that OSS commands can access unstructured Guardian disk files via Unix-like names, but cannot access Guardian structured files. As far as I remember, TACL commands and most Guardian programs cannot access OSS files. It *is* possible to write Guardian programs that open and access OSS files, and it is possible to write a OSS programs that open and access Guardian structured files, but both tasks require that the program knows it is accessing the foreign kind of file so it can make the appropriate system calls to do so.
SQL/MX tables can be accessed from OSS programs. Since SQL/MP tables can have SQL/MX aliases, SQL/MP tables can also be accessed from OSS programs via those SQL/MX aliases.
Guardian unstructured files that can be accessed from OSS are named as /G/VOL/SUBVOL/FILE or /E/SYS/VOL/SUBVOL/FILE, where the "\" is omitted from the system name and the "$" is omitted from the volume name. I believe the names have to be given in all uppercase, but I'm not certain of that. There are some instances where you specify process names to OSS programs, and they are written /G/PNAME, where the "$" is omitted from the process name.
wbreidbach
The main question is: Has the Unix-personality been set up on the
system. You need to setup and start this environment. The simple way
to find out is typing OSH at the TACL-prompt, you should get an OSS-
prompt.
Within OSS you have a speecial directory named /G containing the
Guardian filesystem, /E containing Epand. Everything else is Unix look
and feel. Not everything can be done within the Unix shell, tools like
SCF and FUP are bound to Guardian.
Just to complete Keith's information about the filenames: Only /G and /
E have to be uppercase, another add: All OSS-files can be accessed
from Guardian programs, I wrote a Guardian program being able to read
every file on the system. SQL/MP is supported within OSS, too
A lot of Open-Source tools are available from ITUGLIB for the NonStop,
Samba is meanwhile supported by HP.
Keith Dick
Thanks for correcting some of what I said.
I thought that SQL/MP could not be used from OSS programs. Was that true at one time and has been changed, or am I just remembering it incorrectly?
About your program that reads every file on the system: I imagine it has to know whether the next file it is to read is Guardian or OSS so it can do the open differently (as I mentioned in the first paragraph of my addendum). Or is there a way to open a file that works regardless of whether the file is Guardian or OSS?
wbreidbach
Keith,
my program opens just one file and the open for an OSS-file is
different from the Guardian-open, you have to set the flag for OSS and
unstructured read.
dimandja
> different from the Guardian-open, you have to set the flag for OSS and
> unstructured read.
To be sure, the Guardian FILE_OPEN_ allows opening OSS files by
setting the Options param bit 10 to 1 thereby indicating you wish to
open an OSS file by its pathname.
Jeff Lanam
> A lot of Open-Source tools are available from ITUGLIB for the NonStop,
> Samba is meanwhile supported by HP.
Java is also available on OSS, and a lot of Java open-source will run
unchanged.
ghr
zahlungssysteme.de> wrote:
> On 10 Jun., 20:03, Keith Dick <kd...@acm.org> wrote:
The simple way
> to find out is typing OSH at the TACL-prompt, you should get an OSS-
> prompt.
I think typing OSH can fail even if OSS is running. I think, from
memory, having tried this on sites where OSS was definitely running,
that it can fail for Safeguard-related reasons. An error 4 (?) springs
to mind.
One of the requirements for landing properly inside OSS is for the
user's INITIAL-DIRECTORY to be set to an OSS path eg /home/<user> ,
and that directory must exist.
Joachim Schmitz
> On Jun 11, 5:24 am, wbreidbach <wolfgang.breidb...@bv-
> zahlungssysteme.de> wrote:
>> On 10 Jun., 20:03, Keith Dick <kd...@acm.org> wrote:
> The simple way
>> to find out is typing OSH at the TACL-prompt, you should get an OSS-
>> prompt.
>
> I think typing OSH can fail even if OSS is running. I think, from
> memory, having tried this on sites where OSS was definitely running,
> that it can fail for Safeguard-related reasons. An error 4 (?) springs
> to mind.
OSH can fail for several reasons:
The ROOT fileset has not been started
The ROOT fileset has not been populated with, at least, the OSS Utils
The initiatial-directory from Safeguard for the user trying to access does
not (yet) exist
The OSH command was used from a non-Telnet session (or not using OSSTTY)
A Safeguard ACL had been put on OSH that prevents execution
A system upgrade happened, including the rename phase, but the coldload
hasen't been done yet
(esp. an upgrode from a relaes prio to support for m64-bit file I/O APIs to
a realease with support for this)
> One of the requirements for landing properly inside OSS is for the
> user's INITIAL-DIRECTORY to be set to an OSS path eg /home/<user> ,
> and that directory must exist.
No, this is true only for accessing OSS via FTP. OSH places you in your
Guardian Default Subvol (in OSS notation, /G/vol/subvol) if no
initial-directory has been set in Safeguard, or Safguard is not running (and
maybe even is not installed at all)
Bye, Jojo
Randall
SQL/MP is available through the SQL/MX engine in OSS with the SQL/MX
module management, which I have liked since changes in 2.3.3 . You
need to set up an SQLMP ALIAS within an MX catalog/schema. At that
point, most SQL/MX constructs can be used to access the SQL/MP tables
- with some exceptions and limits that are only supported on native
tables. All the benefits of the MX engine, a little pain (the SQLMP
ALIAS management).
Keith Dick
Randall, what you wrote is what I remembered, but Wolfgang responded that SQL/MP is supported in OSS. I checked the manuals after reading that, and it does now seem to be true that one can compile an embedded SQL/MP program in the OSS environment and targeted for running in the OSS environment. I did not remember that that was possible, but, unless I am reading the manuals wrong, it is possible. I don't know whether my memory is incorrect and it has always been possible to use embedded SQL/MP in OSS programs, or the ability to do so was added later.
Joachim Schmitz
I believe this has been the case ever since, but I may well be wrong on
this...
Bye, Jojo
Anupam Das
OP: I am really excited to see that you have termed OSS and UNIX :-).
If many people feels like this in near future then surely we will get
a lot of ISVs developing applications like SAP right on this not-so-
similar version of UNIX :-).
Bad news is that - it is "almost" never possible to live only with OSS
or UNIX whatever you call it during your stay in NonStop. If I am not
wrong, here or there, this way or that way, you will have to touch
Guardian or your situation will make you do that.
Keith: If I am not wrong, SQL/MP, although installed only in Guardian
side, was accessible, is accessible and will remain accessible for any
OSS program always. We could use c89 option to compile, build and run
embedded SQL/MP programs in OSS since beginning.
During 1.8 era, using MP tables were mandatory from MX. During 2.0 and
after that, I could only see MX on MP where people still luved the row
performance of SQL/MP over SQL/MX. My personal belief is that, for
high speed OLTP, MP still moves faster than native MX. Any opinion on
this is most welcome.
Keith Dick
Thanks for the confirmation that one could use SQL/MP from OSS from the beginning. I don't know why I had the impression that SQL/MP was not usable from an OSS program. I must have been thinking of something else.
I think it is generally recognized that SQL/MP performs better than SQL/MX for some cases. Of course, SQL/MX performs better than SQL/MP for other cases. I don't have any personal experience with a head-to-head comparison of the same OLTP application using SQL/MP and SQL/MX, so I don't know how large the difference is for typical applications. And it might be that there were performance problems in early SQL/MX releases that have been corrected. If there still are performance problems in SQL/MX for OLTP, I imagine the SQL/MX developers would like to work on that, but I don't know whether there are any plans to do that. But we are straying from the "What is OSS?" topic of this thread.
Keith Dick
I just realized that there is a very important point about the reason for OSS that I did not explain. The point of doing OSS is to provide a much more "standard" programming environment PLUS the programs ported to run in that environment are able to take advantage of Tandem fundamentals such as fault tolerance, linear expandability, etc. Without the part of the statement following the "PLUS", there wouldn't be much point to the exercise.
It isn't magic, of course. If the application in question was designed to run in an SMP environment and is absolutely dependent on all processes of the application sharing access to some in-memory data, a port to OSS won't magically result in linear expandability (or any expandability, for that matter). However, most web-oriented applications already are structured in ways that make it pretty easy to integrate into a Pathway environment, and you get a lot of the Tandem benefits from that.
So that's why someone might want to use OSS rather than just get a real Unix or Linux system on which to run their Unix or Linux applications.
dimandja
advantage of the Tandem platform.
Even some 3rd party stuff installed on Guardian thumb their nose at
it. The thing would simply be written in C, and that's it. TACL
couldn't elicit any signs of life from those programs which usually
never heard of $Recieve or anything like that.
Keith Dick
Well, as I said, it isn't magic, so just getting something to execute without errors on the NonStop system doesn't give it Tandem Fundamentals. However, the disk files of even such just-get-it-running programs are protected by disk mirroring, and if the program uses SQL, it even gets transaction protection. It doesn't get fault-tolerance or linear expandability without some work, unless it is already suitable to use as a Pathway server, and I think some applications that were written to be service providers are in such a form already.
I don't understand what you mean about ported stuff on Guardian not knowing about $RECEIVE. Yes, such programs won't know about $RECEIVE, but they don't have to know about $RECEIVE to run in Guardian. The C runtime startup code takes care of the startup messages from TACL on $RECEIVE before the "main" function is called.
Maybe you are thinking of programs that provide a command line interface to a human user and how sometimes you have trouble using TACL's INLINE or INV to feed them commands. That is a little inconvenient, but I think once you recognize the problem, it usually is fairly easy to work around in the TACL code. But that is a problem with ports to the Guardian environment. What we are discussing in this thread is OSS, and I think there isn't a problem like that when porting to OSS. In OSS, stdin, stdout, and stderr work as a Unix programmer expects, so using such programs from shell scripts works the same on OSS as it does on Unix.
Randall
It's always been the case. My suggestion, though, is to use the SQL/MX
engine to access SQL/MP tables regardless. The engine is more stable
from a statistics standpoint and MX module management allows you to
access SQL/MP tables across catalogs.