IS:: Feedback re VOS limitations
Green, Paul
running up against any sort of VOS limitation. I'm undertaking basic
research into which limits are important to our customers, and in what
sort of time frame they need to have them raised.
While I have my own pet theories about this, I'd rather hear from
people who have either hit specific system limits, or have had to
change their application to work around specific limits. I'm being
deliberately vague about what sort of limits I have in mind because
I don't want to color your thinking. If you think you have found a
limit, that's good enough for me.
I can't promise that this research will lead to any product changes,
but I can promise that the relevant Stratus executives will receive
the report and my recommendations.
Thanks
PG
--
Paul Green, Senior Technical Consultant
Stratus Technologies, Inc.
111 Powdermill Rd, Maynard, MA 01754
Tel +1-978-461-7557, Fax +1-978-461-3610
--
:: info-stratus
Green, Paul
don't wish to respond in public. I received a question about this.
To the gentleman at g f i g r o u p <dot> c o m, your anti-spam filter
blocked my original letter! I wonder which words triggered your filter...
owner-inf...@list.stratagy.com
Date: Mon, 12 Apr 2004 15:02:56 -0400
To: Info-Stratus <Info-S...@list.stratagy.com>
From: "Donita Wells" <Donita...@mbna.c0m>
Subject: Re: IS:: Feedback re VOS limitations
MIME-Version: 1.0
Content-Type: text/plain;charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-inf...@list.stratagy.com
Precedence: bulk
Reply-To: Info-S...@LIST.STRATAGY.COM
List-ID: <Info-Stratus>
+-----Original Message-----
| From: Paul Green
| Sent: Friday, April 09, 2004 2:20 PM
|
| I am interested in hearing from VOS customers who are concerned about
| running up against any sort of VOS limitation. I'm undertaking basic
| research into which limits are important to our customers, and in what
| sort of time frame they need to have them raised.
Hi Paul,
I've got a couple.
One I am paying for dearly right now is the fact that I can change
acls and dacls in a secure directory (everyone has null access except
for SysAdmin) and the system doesn't log it anywhere. I am currently
in the middle of an Internal Audit (and they must think I am a criminal)
because they are writing me up on this one. I have to come up with a
solution by EOD. I told them, no problem: I will just re-write VOS.
They didn't laugh.
The other one is file size limitation. This is a huge one for us.
We are in the beginning design phase of splitting up our cardholder
files to work around the 2GB limitation. This is a huge effort for us
and the mainframe that sends us the NDM transmissions.
Thanks for asking.
Donita Wells
Stratus Administration
MBNA Technology
donita.wells(at)mbna.com
voice 469 201-6424
fax 469 201-5239
ms 4314
--
:: info-stratus
Richard S. Shuford
For quite a while now, all of us who participate in the Info-Stratus
mailing list have been enduring various plagues of malicious, greedy,
or stupid email messages: our old friends viruses and spam.
However, please now beware a new and different email hazard: the
"spam detection false positive".
A "false positive" happens when some entirely legitimate message
innocently includes a text string (or other data) that, by chance,
happens to match some data pattern used by an email gateway's
spam-detection algorithm. The gateway decides that the message
*is* spam--when it is *not*--and tosses the message in the trash.
You never see it. As far as you can tell, the message was never sent.
(Sometimes the mailing-list administrator is notified, sometimes not.)
There is wide variation between commercially sold spam-filtering
software with respect to spam false positives; some currently popular
products take the carefree attitude "what you don't know can't hurt you"
and silently delete any message that looks even slightly suspicious.
As corporations desperately grasp at straws to deal with the viruses
and real spam, in deploying such deficient spam-filtering software they
are inadvertently blocking much legitimate and useful email. And you,
the user of the email system, never even know how many messages you have
missed. Fred Langa, a computing-industry pundit, believes that up to
40 percent of legitimate email messages are currently not getting through!
There is no magic bullet to solve the spam problem. However, some
email-filtering products handle spam with more sophistication and rarely
enerate a false positive. (If demand warrants, I could post references to
a few decent products.)
I have no idea if you will even receive this message. Your spam
filter might decide that it is a spam message, since it contains the
word "spam"!
...Richard S. Shuford
Info-Stratus List Administrator
shuford(at)list.stratagy.com
Sean O'Casaidhe
Not sure if this is on-topic, but it's a headache for me as a
SysAdmin, so here goes;
VOS does not, so far as I know, support mandatory secure User-account
logging. That is, logging the actions of a User into date-stamped
file which is not otherwise writeable, whilst ensuring that the User
is not able to disable said logging.
I currently use "start_logging" to log users activity, but I cannot
stop a competent user from using "stop_logging" to put a stop to this
(at least, not without contorting myself by putting acls on the
commands or other such techniques).
Nor can I prevent a competent user from finding out where the log is
and deleting/modifying it. After all, the User has to have write
access to the directory to write the log file!
At the end of the day, I would not be able to go to court and and say
"Yer honour, this log is evidence that this individual did something
wrong", because it is not (it's a given that all electronic evidence
is hearsay anyway, but still).
Given that the customer base for Stratus is generally concerned with
high-availability, and given that good User control is essential in
ensuring this, I see this lack as quite a big hole in the current
implmentations of VOS.
just my 2 cent!
sean.
Green, Paul
>
> VOS does not, so far as I know, support mandatory secure
> User-account logging. That is, logging the actions of a
> User into date-stamped file which is not otherwise writeable,
> whilst ensuring that the User is not able to disable said
> logging.
Well, first of all, thanks for sharing this idea with me.
But I have to say that we never intended VOS to be accessed
by untrustworthy users. Sure, we have privileged vs. unprivileged
as a fairly coarse split, but that's really to keep the system
administration functions out of the hands of ordinary users.
The idea that you would let someone access your system that you
don't trust to behave himself is, to say the least, a surprise.
What is to prevent them from deleting every file they can access?
Even if we logged it, all you'd be able to do is point fingers,
you still might not be able to repair whatever damage or
denial-of-service that their mischief caused.
In thinking about how to implement such a thing, I think I'd route
the communication/ethernet traffic thru a box that simply logged
everything. I would not even have the host (VOS in this case)
aware of the logging. That way, they would have zero chance of
bypassing it or of tampering with the logs. I would think that a
good TCP/IP proxy server would have such a capability.
I did a web search using keywords like "TCP/IP proxy server log
communication traffic" and found some products that would seem
to have this capability.
Hope this helps.
Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
--
:: info-stratus
Sean O'Casaidhe
thanks for the feedback; unfortunately my examples weren't the best.
It's not a simple matter of trust - there are no untrusted (or more
importantly, untrustworthy) users on the Stratii we run (e.g. we have
given them all individual training ourselves!). But going by the NSA
definations, a "trusted" user is one that can break your system. As
such, I am required to record their activities, and this is difficult
to do. This problem is not of course unique to Stratus!
I could only use proxies if I was happy to have unencrypted comms
between the host & user - in this case, I have a whole new world of
worry waiting for me. If I could get around that (e.g. VLAN or
something), I'd still have to secure the proxy, with all the problems
that entails.
Anyway, I've made my contribution (I hope) and I don't want to bang on
about it endlessly - thanks for listening!
john c.
Paul....@stratus.com (Green, Paul) wrote in message news:<A2A34F15EE916148BC4C...@exna4.stratus.com>...
Erik Devriendt
1. full path name length limitation (256 chars?)
2. filename lengh limitation (32 chars)
3. total length limitation of arguments of command macro
4. limit of about 32000 source lines in C module
(included files are counted, too).
5. absence of shared libraries.
Erik Devriendt
Project Engineer
--
Siemens n.v./s.a.
EIT-ES5
Tel. ++32 2-536.48.56
Fax. ++32 2-536.28.80
Erik.De...@siemens.com
http://www.siemens.be/
--
:: info-stratus
Green, Paul
| From: Eric Devriendt
| Sent: Monday, April 19, 2004 4:30 AM
| To: Info-Stratus
| Subject: VOS limitations
|
| -From a developers point of view:
|
| 1. full path name length limitation (256 chars?)
| 2. filename lengh limitation (32 chars)
| 3. total length limitation of arguments of command macro
| 4. limit of about 32000 source lines in C module
| 5. absence of shared libraries.
Hi Erik,
Thanks for your suggestions. A couple of comments...
1 & 2. These are fundamental limitations that are present all
over VOS. I certainly agree that they are issues, because
I've also tried to port code that assumes higher limits.
I'll put them on the list, but they are going to be hard
to raise.
3. This is something we might be able to do something about.
I recently raised the maximum number of command arguments,
for example.
4. We raised this limit in VOS 14.1, as I recall. We now have
32-bit internal line numbers. If you are hitting this limit
on a recent release of VOS, please open a call as you have
found a bug in the compilers.
5. No argument, I agree!
Thanks
PG
--
Paul Green, Senior Technical Consultant
Stratus Technologies, Inc.
111 Powdermill Rd, Maynard, MA 01754 USA
Eran Mertens
| From: Sean O'Casaidhe
| To: Info-Stratus
| Sent: Thursday, April 15, 2004 1:33 PM
| Subject: Re: IS:: Feedback re VOS limitations
|
| logging. That is, logging the actions of a User into date-stamped
| file which is not otherwise writeable, whilst ensuring that the User
| is not able to disable said logging.
Hi Sean,
This is a known and old issue. SoftMark's VOS Security Shell
(SPS-VSS) provides the perfect solution:
The process (SPS-VSS) is started by a sysadmin and, like
"start_logging", it logs the user's activity to a log file in a
directory to which only the sysadmin has access. The program
has many other security functions that I will not mention here.
For more info, take a look at:
http://www.softmark.com/vss.htm
There are also several users; testimonials that might interest you.
Best regards,
Eran Mertens
--
Application Resources, Inc.
http://www.StratuSoft.com/
+1 516.536.6200
--
:: info-stratus
Oliver Gaerlan
R089-03 (VOS Commands User's Guide) states that:
Explanation
The operating system interprets all lines in a command macro file
between a &begin_parameters statement and an &end_parameters
statement as parameter declarations. You can include only one
&begin_parameters statement in a command macro, and it must be
the first line of the macro that is not a comment (before any
executable command).
Can this be not limited to the first line? Also, so we can have
multiple &begin_parameters/&end_parameters within the command macro?
Example:
&label GetParameters
&begin_parameters
Arg1 Arg1:string...
&end_parameters
&ValidateArg1
&if invalid Arg1&then &goto GetParameters
...&if valid Arg1&then &goto GetNextParameter
&
&label GetNextParameter
&begin_parameters
Arg2 Arg2:string...
&end_parameters
...
--
Oliver.Gaerlan(at)bxs.com
--
:: info-stratus
Colin Forster
Sean,
We agree entirely that this is a significant limitation of VOS
security/auditability.
Our product RoSE_COMB contains a replacement for the VOS logging
facility which can write to files which the normal user cannot modify
and can be configured not to be stoppable. It will also audit the
starting and stopping of logging to the syserr_log.(date).
Of course, RoSE_COMB contains many other security and operational
facilities and is widely used in the VOS community.
Contact us directly if you need more information.
Colin Forster
sup...@rose.co.uk
Bob Sweeney
Hi Richard,
Well, it looks like this message never made it to the Stratus news
server. I'll look into that and see if my anti-spam filters blocked
it.
Bob Sweeney
Stratus Postmaster
> shuford(at)list.stratagy.com
Green, Paul
I hope that each of the vendors that offers add-on security
software for VOS will chime in with a short description of
their products and a link to their web site. I know that
several competing packages are available that offer features
that should help to satisfy current auditing or logging
standards. How to the folks who are currently using these
add-on packages feel about them? Do they do the job for you?
Thanks
PG
--
Paul Green, Senior Technical Consultant
Stratus Technologies, Inc.
111 Powdermill Rd, Maynard, MA 01754
Erik Devriendt
VOS has no relative symbolic links.
That is, a link always uses a full path name to point
to its target.
This becomes annoying when creating POSIX tar archives of
directories that are supposed to contain relative symbolic links.
When untarring such a tar archive on another system or in
another directory, this can give very annoying problems.
Erik Devriendt
Project Engineer
Siemens n.v./s.a.
EIT-ES5
Tel. ++32 2-536.48.56
Fax ++32 2-536.28.80
Green, Paul
|Date: Mon, 19 Apr 2004 17:06:25 -0400
|To: Info-S...@list.stratagy.com
|From: "Hogan, Phil" <Ho...@descc.com>
|Subject: RE: IS:: Feedback re VOS limitations
|
| Paul,
|
| Just wanted to let you know that the VOS limitations that I'd
| like to list are #1, 2, and 3 from Eric's list.
|
| I appreciate your feedback and can understand the difficulties
| in changing filename and pathname maximum lengths.
|
| Thanks,
| Phil
Thanks, Phil. Got 'em. The filename length limit and the pathname
length limit will be hard to raise. But there is some hope for the
command line length limit (and the related limits, like the command
function return value limit).
PG
--
:: info-stratus
Ledoux, Clifford J.
| From: Sean O'Casaidhe
| To: Info-Stratus
| Sent: Thursday, April 15, 2004 1:33 PM
|
| VOS does not, so far as I know, support mandatory secure User-account
| logging. That is, logging the actions of a User into date-stamped
| file which is not otherwise writeable, whilst ensuring that the User
| is not able to disable said logging.
| I currently use "start_logging" to log users activity, but I cannot
Sean,
A bit extreme perhaps--but if your users don't use the
start_logging command, you can assign null access to the
stop_logging command to all but members of the SysAdmin
and System groups. See Internal Command Access in R283.
Cliff Ledoux
--
Stratus System Administrator
CVS/pharmacy
1 CVS Drive
Woonsocket, RI 02895
cjle...@cvs.com
--
:: info-stratus
Hogan, Phil
| From: Eric Devriendt
| Sent: Monday, April 19, 2004 4:30 AM
| To: Info-Stratus
| Subject: VOS limitations
|
|
| 1. full path name length limitation (256 chars?)
| 2. filename lengh limitation (32 chars)
| 3. total length limitation of arguments of command macro
| 4. limit of about 32000 source lines in C module
| 5. absence of shared libraries.
Paul,
Just wanted to let you know that the VOS limitations that I'd
like to list are #1, 2, and 3 from Eric's list.
I appreciate your feedback and can understand the difficulties
in changing filename and pathname maximum lengths.
Thanks,
Phil
--
Ho...@descc.com
--
:: info-stratus
Green, Paul
have reported to me. I've left out a few obscure issues,
but otherwise, this is the full list. If you see something
on this list that applies to you, and you haven't voted for
it by sending me mail, please do so right away, every vote
counts. If reading this list makes you recall some other
issue, let me know. As before, I'll take either public or
private responses.
This list is unordered. As before, I can't promise we can
fix any of these. But I can promise that knowing about them
is the first step towards action. If any of our 3rd-party
providers sees an issue listed below that they have a solution
for, please post or contact me privately.
1. Enhance the save command to create save files larger
than 2 gigabytes.
2. Enhance sequential files so that they can grow
beyond 2 gigabytes.
3. Provide a disk defragmentation tool.
4. Securely log security-sensitive activities.+
5. Increase 32-byte object name length.
6. Increase 256-byte path name length.
7. Speed up access to remote files.
8. Speed up OSL error recovery times.
9. Eliminate cases where remote file I/O operations can
declare a module offline.*
10. Speed up access to files by segmenting the file based
on primary key value.
11. Support the vi editor and implement support for long lines.
12. Provide a relational database such as PostgreSQL or MySQL.
13. Provide a patch mechanism so a customer can take a single
bug fix.
14. Enhance list_users to be able to sort the rows by various
columns.$
15. Increase the maximum command line length, the maximum command
argument length, and the maximum length of command function
return values.
16. Support user-written command functions.
17. Provide a modern multiple-window interface to the debugger.
18. Support shared libraries.
19. Support 10 groups per user (up from 5 currently).
20. Increase the maximum number of lines in a C program above 32K.*
21. Allow multiple uses of &begin_parameters / &end_parameters in
the same command macro. Implement check procedures for them.
22. Support multiple terminal sessions under a single login.+
* I believe we have fixes for these issues in releases that are
newer than the one the customer is running.
+ I believe that a 3rd-party can provide this capability today.
$ I believe that the procbrowser performance tool on the VOS
anonymous-FTP site can do this today.
Thanks
PG
--
Paul Green
Senior Technical Consultant
Stratus Technologies
111 Powdermill Road
Maynard, MA 01754-3409 U.S.A.
TEL +1 (978) 461-7557
FAX +1 (978) 461-3610
--
:: info-stratus
Green, Paul
>
> The Explanations section of &being_parameters in Appendix D of
> R089-03 (VOS Commands User's Guide) states that:
>
> Explanation
>
> The operating system interprets all lines in a command macro file
> between a &begin_parameters statement and an &end_parameters
> statement as parameter declarations. You can include only one
> &begin_parameters statement in a command macro, and it must be
> the first line of the macro that is not a comment (before any
> executable command).
>
> Can this be not limited to the first line? Also, so we can have
> multiple &begin_parameters/&end_parameters within the command macro?
Based on your examples (which I didn't copy into this reply),
it looks like what you really want is a check procedure.
The &begin_parameters / &end_parameters statements process all of
the arguments as a bundle. It would not be possible to have them
process one argument at a time. But we might be able to come up
with a way to let you specify a validation procedure that would
return 1 or 0 to indicate that the arguments were ok or not. If
the arguments were not ok, it would automatically stay in the form
(or display an error in lineal mode). I'll add it to the list of
suggestions.
However, I would also caution that the VOS command macro language
is not designed to replace PL/I or C as a programming language. We
have deliberately tried to keep it pretty simple. This is obviously
a judgment call, but I've worked on systems where the command macro
language was so powerful that people wrote applications in it.
However, these applications invariable had extremely poor error
handling and were much more difficult to maintain than regular
programs. It was a desire to avoid just such an outcome that led me,
as the designer of the macro language, to limit its functionality.
Tom Guilderson
>
> If you see something on this list that applies to you, and
> you haven't voted for it by sending me mail, please do so
> right away, every vote counts.
> 5. Increase 32-byte object name length.
Yes
> 6. Increase 256-byte path name length.
Yes
> 8. Speed up OSL error recovery times.
Yes
> 12. Provide a relational database such as PostgreSQL or MySQL.
Yes - we spoke about this already
> 13. Provide a patch mechanism so a customer can take a single
> bug fix.
Yes - definitely
> 14. Enhance list_users to be able to sort the rows by various
> columns.$
Yes - would be nice
> 15. Increase the maximum command line length, the maximum command
> argument length, and the maximum length of command function
> return values.
> 18. Support shared libraries.
Yes
> 19. Support 10 groups per user (up from 5 currently).
Yes
Also, I believe this is something already in the works; but just
in case: SSH (server and client) - the ability to stop using telnet
and ftp, and securely log in and transfer files to/from VOS.
Thanks Paul!
--
Tom Guilderson
Applied Technology Team
CVS Pharmacy
401-770-3913
mailto:TWGuil...@cvs.com
http://www.cvs.com/
--
:: info-stratus
Ceuster, Hendrik de
| From: Ledoux, Clifford J.
| Sent: Dienstag, 20. April 2004 16:01
| To: Info-Stratus
| Subject: RE: IS:: Feedback re VOS limitations
|
| A bit extreme perhaps--but if your users don't use the
| start_logging command, you can assign null access to the
| stop_logging command to all but members of the SysAdmin
| and System groups. See Internal Command Access in R283.
I don't know what the situation is in other companies, but
here audit is in particular interested in the users that
belong to *.SysAdmin groups and anyone with sufficient
access to mess with customer data.
For non-SysAdmin it is possible to limit their access so
that they cannot fiddle with their logs.
The problem still remains with the *.SysAdmin user.
Another lack in audit is a history trail on the user
registration database. At the moment I can only monitor
changes by using log_registered_users and comparing with the
previous one. Obviously this log should also be read-only.
The next problem is then how to clean up these logs.
Harry De Ceuster
--
:: info-stratus
Lambie Peter
>
> I hope that each of the vendors that offers add-on security
> software for VOS will chime in with a short description of
> their products and a link to their web site. I know that
> several competing packages are available that offer features
> that should help to satisfy current auditing or logging
> standards. How to the folks who are currently using these
> add-on packages feel about them? Do they do the job for you?
We are using the Rose_Comb product for reporting and logging security,
we have been using this for several years and have passed numerous
audits using the software.
Pete Lambie
Systems Management
* 020 7090 6096
* mobile 07786936965
--
This message and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this message in error please delete it and any files
transmitted with it, after notifying postm...@uk.mizuho-sc.com Any opinions
expressed in this message may be those of the author and not necessarily those
of the company. The company accepts no responsibility for the accuracy or
completeness of any information contained herein. This message is not intended
to create legal relations between the company and the recipient.
[Permission assumed to re-distribute to Info-Stratus.]
Recipients should please note that messages sent via the Internet may be
intercepted and that caution should therefore be exercised before dispatching
to the company any confidential or
Mizuho International plc
Bracken House, One Friday Street, London EC4M 9JA. TEL. 020 7236 1090
Registered in England No. 1203696. Registered office as above. Authorised
and regulated by the Financial Services Authority. A member of the London
Stock Exchange. A member of Mizuho Financial Group headed by Mizuho Financial
Group, Inc.
--
:: info-stratus
Eran Mertens
>
> Re: security packages for VOS, better logging, etc.
>
> I hope that each of the vendors that offers add-on security
> software for VOS will chime in with a short description of
> their products and a link to their web site. I know that
> several competing packages are available that offer features
> that should help to satisfy current auditing or logging
> standards. How to the folks who are currently using these
> add-on packages feel about them? Do they do the job for you?
Hi All,
How can I refuse such an invitation especially when it's
requested by Paul Green :)
So here are my 2 cents with a lot of links for more descriptive
info.
ARI distributes & supports SoftMark's VOS products.
We provide several solutions for securing VOS Systems.
The SPS/VOS Security Shell eliminates unrestricted access to VOS
and greatly enhances operators' and developers' productivity. Any
operator, even with no Stratus experience, can become proficient
and operate the system safely. The SPS/Security Shell is an
indispensable environment for any mainframe trained personnel.
http://www.softmark.com/vss.htm
The SPS/Menu system organizes applications into concise,
professional and user friendly interfaces. Creating menus is a
simple procedure; it takes minutes to complete thereby saving
time and money and helping meet development deadlines. SPS/Menu
requires no programming and therefore does not require any
Stratus expertise.
The system greatly enhances system security by adjusting and
generating menus on a per-user basis according to the
individual's security profile. Furthermore, any item or submenu
may be password-protected.
The SPS/Menu provides complete audit trail logs of all system and
operator activities including security violation attempts
detailing commands executed, user names and the time of execution.
http://www.softmark.com/menu.htm
Here are some links from our web site with a couple of articles
that were written by Coby Schanz, President of SoftMark, a well
known expert in this field, as well as some testimonial letters
from our customers regarding secure Stratus operations. For more
info, contact our office.
http://www.softmark.com/secure_ops.htm
http://www.softmark.com/management_style.htm
Customer Testimonials:
AOL: http://www.softmark.com/aol_ltr.htm
SIAC: http://www.softmark.com/siac_ltr.htm
Eran Mertens
Carlos Molina
>
> Here is a brief summary of some of the VOS limits that you
> that applies to you, and you haven't voted for it by sending
> me mail, please do so right away, every vote counts.
> If reading this list makes you recall some other issue,
Paul,
- If could be possible, a way to limit CPU use (and Disk use)
to specific processes.
- TCP/IP secure telnet (or substitute like SSH) and Secure FTP
Regards,
Carlos Molina
--
:: info-stratus
Green, Paul
| From: Tom Guilderson
| Sent: Wednesday, April 21, 2004 9:31 AM
| To: Info-Stratus
| Subject: Re: IS:: Summary of VOS limits reported by customers (was: Feedback re VOS limitations)
|
| Also, I believe this is something already in the works; but just
| in case: SSH (server and client) - the ability to stop using telnet
| and ftp, and securely log in and transfer files to/from VOS.
Thanks, Tom. I've added your votes to the tracking list.
I am working on a port of SSH to VOS. I have it all building.
It is now just a matter of debugging it.
PG
--
:: info-stratus
Allen, Doug
There has been much discussion regarding security concerns, not
only within Stratus systems but also within the datacenter as a
whole. I just wanted to point out that Stratus offers assessment
and implementation services specifically designed to address your
Availability and Security needs. Let the Availability Experts
help your company achieve your uptime goals!
For a complete list of the offerings of Stratus Professional Services,
please visit:
http://www.stratus.com/services/ps/index.htm
or contact your local Account team.
Regards,
-Doug Allen
Consulting TAM
Stratus Technologies
+1 978-461-7675
Doug....@Stratus.com
--
:: info-stratus
Steiner, David G
>
> I hope that each of the vendors that offers add-on security
> software for VOS will chime in with a short description of
> their products and a link to their web site.
We have been using SoftMark's SPS Security Suite for several years.
We passed a firm audit using these programs.
The programs were very easy to install and simple to manage.
Application Resources (SoftMark's rep) have been supporting these
programs and we are extremely pleased with the support and
software performance.
David Steiner
System Administration
Citibank
--
:: info-stratus
Menuz2
> counts. If reading this list makes you recall some other
> issue, let me know. As before, I'll take either public or
> private responses.
It has been a while that I have been deep into VOS programming but here some
of the things I have wished for in the past: Excuse me if some of these
have been covered in recent releases.
10. How about a decent help facility, even something as crude as man.
Stratadoc is cool but I want something I can use on the Stratus!
It would be nice to do "help s$sparkler" from the VOS command line.
9. Someone mentioned shared libraries, but shared libraries with dlopen
would be cool.
8. syslogd or some other more refined logging facility; and has anyone
other than me
used userland error codes? Maybe a better error code facility
7. On index reads, how about a KEY_REGULAR_EXPRESSION or a KEY_WHERE
6. The ability to rename indices and also to repack/reorg them in an open
file.
Also to create/delete an index in an open file.
5. In TP, how about the ability to run several tp_overseers and assign
particular files to particular tp_overseers.
4. The ability to map a file (svm) to an heap allocated block of memory
that might be at different addresses
in different processes. It also might be different sizes and even
different locations in the file.
3. The ability to map an index of a file to memory, or maybe just some
btree routines.
2. pl/1 and/or cobol etc native access to tcp/ip routines
and my number 1 request is . . .
1. Command completion; Command recall
Nuz
Steiner, David G
| From: Paul Green
| Sent: Wednesday, April 21, 2004 3:04 PM
| To: Info-Stratus
| Subject: Re: IS:: Summary of VOS limits reported by customers (was: Feedback re VOS limitations)
|
| It is now just a matter of debugging it.
Paul,
Citibank is very interested in SSH.
It seems that "audit" is trying to insist on SSH in place of telnet/ftp.
You have got my vote.
David Steiner
System Administration
Citibank N.A.
--
:: info-stratus
Doug Steinberg
|
| Here is a brief summary of some of the VOS limits that you
| have reported to me. I've left out a few obscure issues,
| but otherwise, this is the full list. If you see something
| on this list that applies to you, and you haven't voted for
| it by sending me mail, please do so right away, every vote
| counts. If reading this list makes you recall some other
| issue, let me know. As before, I'll take either public or
| private responses.
Paul,
Your list seems to include feature requests in addition to limitations.
I'd like to suggest a feature request.
For those of us still running Continuum 1245s, enhance analyze_system
command "summary -pp_pages" to display the memory pool that the process
is running in. This would make it much easier to balance memory usage
between the different memory pools.
Thanks.
Doug
____________________________________________
Doug Steinberg, Sr. Director, Network & DataCenter Ops
America Online, Reston, 2K02
703-265-4222 (office), 703-328-7643 (cell)
--
:: info-stratus
Mitchell Pilot
>
>Here is a brief summary of some of the VOS limits that you
>have reported to me. I've left out a few obscure issues,
>but otherwise, this is the full list. If you see something
>on this list that applies to you, and you haven't voted for
>it by sending me mail, please do so right away, every vote
>counts. If reading this list makes you recall some other
>issue, let me know. As before, I'll take either public or
Paul:
I have not seen this mentioned yet. This may fall into the
"obscure" category, but it has affected me several times, so
I will mention it (hopefully).
VOS command macros do not support the "starname" qualifier,
nor the name(*) syntax that is supported by s$parse_command.
Macros treat "starname" as if it were "pathname," returning
the actual starname. name(*) returns a "not supported in
command macros" error message. Other args that can also be
multiple, such as date_time(*) return a similar error message.
In s$parse_command, starnames and (*) return a pointer to a
list-structure, something that certainly cannot be handled by
command macros. But what could easily be done is for the macro
processor to expand the list, returning all the names in the
supplied argument as a space-separated list. Then the macro can
use (before... and (after... to parse each name from the list as
needed. Of course, this might push the envelope on the length
of command macro arguments, but I think that is being addressed
anyway.
just my .02
--
Mitchell Pilot
Cerner Corporation
"We make healthcare smarter(sm)"
5 E Greenway Plaza STE 2000
Houston, TX 77046-0510 USA
(832) 325-1567
--
:: info-stratus
Arthur Haddad
| From: Steiner, David G
| Sent: Thursday, 22 April 2004 22:35
| To: Info-Stratus
| Subject: Re: IS:: Summary of VOS limits reported by customers
| (was: Feedback re VOS limitations)
|
| trying to insist on SSH in place of telnet/ftp.
Hi,
Turbosoft has recently added SSH support to its TTWin and TTWeb
products. The feature is currently in pre-release form across all
terminal emulations, including the Stratus V102, V103, and V105.
If you would like to have a look, please feel free to download a
demo from
Cheers
Arthur Haddad
Turbosoft
--
:: info-stratus
Jon Schmidt
| From: "Steiner, David G"
| To: Info-Stratus
| Sent: Wednesday, April 21, 2004 10:51 AM
| Subject: RE: IS:: Feedback re VOS limitations
|
| We passed a firm audit using these programs.
| The programs were very easy to install and simple to manage.
| Application Resources (SoftMark's rep) have been supporting these
| programs and we are extremely pleased with the support and
| software performance.
A couple of interesting issues have been raised regarding security.
I'd like to answer specifically how they might be addressed by
LTS/OnGuard.
Registration tracking: LTS/OnGuard has a complete subsystem for
registration maintenance. This subsystem provides full auditing,
as well as the opportunity (if you want) to do a two-phase
registration process: One person enters the changes, while another
person has to approve/submit the changes.
Sensitive commands: LTS/OnGuard allows a site to substitute
sensitive commands by calls to the LTS/Onguard proxy servers.
These servers execute the command for the user, with full auditing
and access control. The substitution can be mostly invisible to
the user. So SysAdmin users, for example, can use common commands,
have them logged and audited, providing an audit trail in case
someone does something in error. This facility also allows
non-privileged users (such as operators) to do priv things if you
want to allow them. Backups or analyze_system requests, for example.
The LTS/OnGuard has a huge amount of audit reports, including things
like "who can access," "have the acls changed", "who has owner access,"
"whose passwords are in what state," etc. The reports are designed
to be comprehensible to a non-VOS security person.
One of the other frequent issues is inactive session logout. VOS
provides a rudimentory facility. LTS/OnGuard provides rules for
inactive logout based on connection, user, and/or group.
For more details, please contact me or check out:
http://www.transactiondesign.com/onguard/ltsconfac.pdf
Best regards,
Jon E. Schmidt
--
Transaction Design, Inc.
http://www.banbottlenecks.com/
1-415-927-5860
1-415-342-1097 mobile
"Making Capacity Management EASY!"
--
:: info-stratus
Newman, Randy
>
> Here is a brief summary of some of the VOS limits that you
> have reported to me.
Hi;
How about a Disk Defragmenter in VOS?
How about a full blown version of Perl?
Randy Newman
--
:: info-stratus
Hogan, Phil
>
> ...but here some of the things I have wished for in the past...
>
> 8. syslogd or some other more refined logging facility; and has
> a better error code facility?
I have used them--a lot. But it's kind of weird to setup and
use...I agree, could be better.
> 1. Command completion; Command recall.
Yah, would be nice.
-Phil Hogan
--
:: info-stratus
Laurence B. Jacobs
>
> For those of us still running Continuum 1245s, enhance analyze_system
> command "summary -pp_pages" to display the memory pool that the process
> is running in. This would make it much easier to balance memory usage
> between the different memory pools.
Doug:
I know it seems as if RoSE_BUD monitors everything--it doesn't,
but it's close.
We did build in Memory Pool Monitoring many years ago to assist
our users with balancing of the 1245's, so we can provide:
per-memory pool where the memory pool (0 or 1) is specified
number pages, pages used, pages free, evictions
Let me know if you'd like more details.
Best regards
--
Laurence
http://www.rose.co.uk/
--
:: info-stratus
Steiner, David G
| From: Jon Schmidt
| Sent: Thursday, April 22, 2004 1:17 PM
| To: Info-Stratus
| Subject: Re: IS:: Feedback re VOS limitations
|
| A couple of interesting issues have been raised regarding security.
| I'd like to answer specifically how they might be addressed by
| LTS/OnGuard.
We have sites that use LTS/Onguard product and we are
very satisfied with the product. It does a fabulous job.
Best Regards,
David Steiner
System Administration
Citibank
--
:: info-stratus
Giorgio Pirota
>
> I am interested in hearing from VOS customers who are concerned about
> running up against any sort of VOS limitation.
I completely agree about all suggestions, but VOS suffers not only
for lacking of open software tools but also for the absence of a
D.B. engine onboard and new communication hardware and software.
About D.B. I know that somebody already made proposals. Nothing,
instead, about communication.
I remember that the strength of VOS in the past was the communication.
In many of our experiences VOS covers the role of a FRONT-END system.
Now all VOS communication without HOST presence (with the ballast of
SNA or LUs) is reduced to LAN and TCP/IP.
Now I don't heard requests about PPP that doesn't require hardware
development. In my opinion, together with VOS machine down-sizing
(prices should follow), this is the only chance to revitalize VOS.
Otherwise we must surrender to handle the sold until our application
remain actual.
When X.25 is discontinued in Italy, we will not have other reasons
to promote VOS instead of open systems. In a few little companies,
and not only, a system able to handle communication and running the
application is still a good playing card. I am always in love of
VOS IPC...
Then:
When a chipset PSTN modem integration on a VOS board ?
- PPP protocol, CHAP on async . This should be the simplest step.
The next is to extend PPP over other transports...
For example ... what about:
- ISDN PRI/BRI interface and software ? (for this a native-mode
handler should be for us very interesting) For us this is the
new frontier for POS gathering.
- Asynchronous Transfer Mode (ATM) ?
Thanks Paul to you and all the others.
Regards.
Giorgio e Massimo Pirota
Networks & transactional Systems S.p.A.
STRADA 4 PALAZZO A5
Milano Fiori - 20090 ASSAGO (MI)
ITALY
tel. 0039-(0)2-82276563 / 8227651
fax. 0039-(0)2-57514170
--
:: info-stratus
Green, Paul
features or raising various system limits. As Doug Steinberg
noted, some of the requests are more feature-related than
limit-related, but that's ok. It serves the wider purpose of
giving you a chance to say how we can better serve you.
Here are a couple of quick comments on some of the new items.
If I don't comment on your item, it just means I have nothing to
add right now. I'm putting all of the suggestions into my list,
and tracking which customers requested each item. As I said
before, right now this is just an idea-generation exercise, which
may or may not end up influencing Engineering projects. If there
is some feature or issue that is particularly near and dear to
you, I urge you to send a formal request to your Stratus Account
Executive as well.
1. Issue: Fix the analyze_system "summary -pp_pages" request to
show memory pools.
Response: We have already added this feature to VOS 14.6.1aj and higher.
2. Issue: VOS-based help facility.
Response: We have made a decision that StrataDoc (online or CD-ROM)
is so superior that we won't invest any effort in the online help.
I don't expect this decision to change.
3. Issue: PL/I native access to STCP routines.
Response: Do you know about "options(c)" in PL/I? It will do what
you want here. You can write PL/I source code that directly calls a
C function, without having to stand on your head.
4. Issue: shared libraries and dlopen, etc.
Response: In my mind these are two different ways of discussing the
same concept.
Thanks
PG
--
Green, Paul
>
> How about a Disk Defragmenter in VOS?
On the list; I'll add your site to the list of requesters.
> How about a full blown version of Perl?
Already have it. Order a copy of "GNU C/C++ and GNU Tools". We have
a full port of Perl 5.6.1 to VOS, with all the bells and whistles, and
we support it.
Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
--
:: info-stratus
Green, Paul
where we may already have a solution. I've been corresponding with
some of the people who posted to see if they can take advantage of
these ideas. I'm posting this information for everyone because I
think many people can benefit from it, and because we're more likely
to invest in areas where there are no current solutions at all.
The following item numbers correspond to the previously-posted master list.
2. Enhance sequential files so they can grow beyond 2 gigabytes.
It turns out that some customers are actually using fixed or
relative files, not sequential files. The limit for fixed or
relative files is 128GB, but you must create the file as a
dynamically-allocated extent (DAE) file. The limit for normal
(so-called block-at-a-time) fixed or relative files is still 2GB.
Please double-check; you may have a solution that you can use
right now. The support for DAE files was released with VOS 14.3.0.
3. Provide a disk defragmentation tool.
VOS goes to some trouble to avoid fragmenting a disk that contains
both block-at-a-time and SAE or DAE files. It does not split up
large, free areas of space until smaller chunks have been used.
But if you let the disk fill up, there isn't much VOS can do to
avoid fragmentation, because we will hand out the available space
first-come, first-served.
Until we can create an online defragmenter (a big task), the
work-around is to
(a) Use bigger disks and don't let them fill up.
and/or
(b) Segregate SAE/DAE files onto their own logical disk.
Don't attempt to share the same disk for block-at-a-time
and extent files.
and
(c) Use a single extent size for all DAE files on the same disk.
Now, I haven't tested these ideas out myself, but it seems evident
that they would help a lot.
4. Securely log security-sensitive activities.
I think it is evident from recent postings that our long-time
software partners have this area well-covered; multiple,
competing packages are available.
9. Eliminate cases where remote file I/O operations can declare a
module offline.
We think we've fixed this problem as of the fix for fio-661
(in 14.4.1ba, 14.5.0ap, 14.6.0aj). If you are still seeing it,
and are on a release newer than these, please open an issue with
the CAC. If you are on a release without the fix, please upgrade
and re-run your test case.
20. Increase the maximum number of lines in a C program above 32K.
We think we've fixed this problem as of VOS 14.1. Again, please
open an issue if necessary.
22. Support multiple terminal sessions under a single login.
Laurence Jacobs of Real-Time Software tells me that MDTerm can
do this. If any of the other software suppliers have a terminal
emulator that can do this, please post.
Thanks for using VOS.
Tomas
Użytkownik <owner-inf...@list.stratagy.com> napisał w wiadomości
news:C3E16A30C33FD511B147...@xexdal06.mbnainternational.com
...
> Organization; MBNA Technology
> Date: Mon, 12 Apr 2004 15:02:56 -0400
> To: Info-Stratus <Info-S...@list.stratagy.com>
> From: "Donita Wells" <Donita...@mbna.c0m>
> Subject: Re: IS:: Feedback re VOS limitations
> Content-Type: text/plain;charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> Sender: owner-inf...@list.stratagy.com
> Precedence: bulk
> Reply-To: Info-S...@LIST.STRATAGY.COM
> List-ID: <Info-Stratus>
>
> +-----Original Message-----
> | From: Paul Green
> |
> | I am interested in hearing from VOS customers who are concerned about
> | research into which limits are important to our customers, and in what
> | sort of time frame they need to have them raised.
>
> Hi Paul,
>
> I've got a couple.
>
> One I am paying for dearly right now is the fact that I can change
> acls and dacls in a secure directory (everyone has null access except
> for SysAdmin) and the system doesn't log it anywhere. I am currently
> in the middle of an Internal Audit (and they must think I am a criminal)
> because they are writing me up on this one. I have to come up with a
> solution by EOD. I told them, no problem: I will just re-write VOS.
> They didn't laugh.
>
> The other one is file size limitation. This is a huge one for us.
> We are in the beginning design phase of splitting up our cardholder
> files to work around the 2GB limitation. This is a huge effort for us
> and the mainframe that sends us the NDM transmissions.
>
> Thanks for asking.
>
> Donita Wells
> Stratus Administration
> MBNA Technology
> donita.wells(at)mbna.com
> voice 469 201-6424
> fax 469 201-5239
> ms 4314
>
>
>
> --
> :: info-stratus
Tomas
Uzytkownik "Green, Paul" <Paul....@stratus.com> napisal w wiadomosci
news:A2A34F15EE916148BC4C...@exna4.stratus.com...
tratus
Laurence B Jacobs
|
| Citibank is very interested in SSH.
| It seems that "audit" is trying to insist on SSH in place of telnet/ftp.
Folks:
We have a variant of the MDTerm Server and Client in final testing right
now that support encryption.
This includes comprehensive two way encryption/decryption. This will be
available for both OS TCP and STCP.
This provides secure access to Stratus VOS modules, for all local, remote
and dial-up connections that use CRYPT_MDTerm
Contact me or Jim Cowie in the US for further details.
Best regards - Laurence
--
l...@rose.co.uk
--
:: info-stratus