Re: How to create a shareable image on IA64 using Pascal

On Oct 8, 5:52 am, "Richard Maher" <maher...@xxxxxxxxxxxxxxxxxx>
wrote:
Hi Adrian,

(Not so much for your benefit as for aothers that may be reading here)

Please do not listen to the incompetent filfth that have responded here!
Heaven forbid that VMS has to contend with the "Can't handle shared memory
slur" on top of everything else :-(

There is nothing wrong with "COMMON" areas and shared PSECTs! Tell the usual
suspects to "you know what"!

OOh! Global Sections are spooky; leave them to Unix! What about Cache
Fusion? What about an operating system that offers functionality? Global
Sections "a bridge too far"?

You all make me sick!

Regards Richard Maher

"Ade" <adrian.birk...@xxxxxxxxxxxxxxxx> wrote in message

news:rYlGk.35222$0D6.20078@xxxxxxxxxxxxxxxx

Hi,

Does anyone have a quick example of how to create a shareable image using
Pascal on IA64 (or please correct the code below). It is intended that
this
image, when installed with /open/header/share/write, will be used simply
as
a data repository for other applications which are linked together with
it.
All the examples I have seen in the documentation refer to shared memory
between linked object files rather than against a shareable image. Any
help
you can give me would be greatly appreciated.

Regards,

Adrian Birkett

My example:

$ edit common.pas
{ potential common storage module }
[environment ('common')]
module common;
type
common_r = record
my_int : integer;
my_str : varying [10] of char;
end;
end.

$ pascal common.pas
$ link common/share
$ install add/open/head/share/write disk1:[dir]common.exe
$ define common disk1:[dir]common.exe

$ edit prog1.pas
{simple data writer program}
[inherit ('disk1:[dir]common')]

program prog1(input output);
var common:[common]common_r;
begin
common.my_int := 1000;
common.my_str := 'Hello';
end.

$ pascal/debug/nooptim prog1
$ link prog1, sys$input/opt
disk1:[dir]common.exe/share
$ run prog1 !step through to end

[in a different process]

$ edit prog2.pas
{simple data reader}
[inherit ('disk1:[dir]common')]

program prog2(input output);
var common:[common]common_r;
begin
writeln('int = ', common.my_int);
writeln('str = ', common.my_str);
end.

$ pascal/debug/nooptim prog2
$ link prog2, sys$input/opt
disk1:[dir]common.exe/share
$ run prog2 !noting that prog1 is still running in your other
process
int = 0
str =

Richard,

I normally do not respond to comments of this sort, but a
clarification is in order. As I can read it, none of the posts in this
thread said "OpenVMS cannot do it". What was said was "In almost all
cases, this is a dangerous practice".

I have NEVER claimed that OpenVMS cannot handle shareable storage,
merely that in my extensive, 30+ year experience, I have seen far move
(actually, overwhelmingly more) incorrect implementations of shared
memory management than I have seen correctly done ones.
Synchronization errors (e.g., race conditions) are devilish difficult
to identify and eliminate, and virtually impossible to reproduce on
demand. Avoiding deadlocks and synchronization starvation in complex
systems is even more difficult.

Even something as simple as setting switch variable can be fraught
with hazard. Many programmers who first learned to program using COBOL
(and indeed, those working in COBOL) use strings to store switch
values. In one of my AST talks (admittedly multithread -- AST and
regular; not multiprocessor, which is worse) I reminded attendees that
the MOVC3 and MOVC5 instructions were interruptable, thus could be
interrupted by a number of events, including AST delivery. The
"simple" act of setting changing a switch string from "YES" to "NO "
could give rise to intermediate values of "YO ", "YE ", "NES", "NOS",
etc.). Nobody in the audience had considered that possibility
(admittedly several members of Engineering who heard about my example
found it amusing). The same thing can happen with inadvertantly mis-
aligned data. At one conference, someone overheard my discussion of
that hazard and realized that that was the likely reason why his large
scale simulation system sporadically produced invalid floating point
values.

These problems are exacerbated when the underlying architecture or
processor is changed, and the timing relationships alter.I have even
seen situations where a change in the IO configuration caused timing
issues.

My overall recommendation is to proceed with EXTREME care. A LINK, or
a simple test case is far different than multiple processes doing a
lot of work at high speed. It is all too easy to jump into shared
memory as a way to avoid complexity and become mired in a quagmire.
Since I have not seen Adrian's code base, I do not know if this is a
highly dynamic global area, or a set of read-only parameters. Even a
set of shared performance counters can become complex.

If the application is something along the lines of a large scale cache
(e.g., RMS global buffers, a DBMS, a very high performance system)
than I would consider the option of global storage, after:
- the fact of the global storage was hidden behind an API (or at
least a set of macros)
- a first implementation of the API was done using a resource monitor
model (a separate process that implemented the data store)
- the performance issue was severe enough to justify the extensive
developer time and review to make sure that the implementation was
valid and reliable.

As noted, I had a most entertaining converesation more than a decade
ago on the implementation of a stock trading message switch where the
client took exception to not using shared commons (I used DECnet
logical links, a client subroutine shareable library, and a central
datalink and server process; in effect a non-privileged device driver/
ACP model) to implement data link management. They even wanted me to
guarantee that if the performance was not adequate, I would
reimplement things at no charge.

I did the implementation on an Alphastation 3000, and the bottleneck
was somewhere around 10K transactions/minute. I was limited by the
trace code (using DECterm) and the link to the trading switch. I
probably could have gone quite a bit further with a little work. The
beta went into production without any problems.

I had a similar experience several years earlier with an application
that was supposed to support multiple terminals. It was quite a bit
more cost effective to install the single user image as a shareable
image than it was to spend man years to work multithreading the
application. It was also far more resilient.

Rule 1: Architect allowing the complex solution, but use a less
complex solution if at all possible. Context switches between
processes may be costly, but system crashes in the middle of the day,
are far costlier.

Thus, my comment that if one is in the applications business, one
should "Tread with care"

- Bob Gezelter, http://www.rlgsc.com

.

Relevant Pages

  • Re: Newsreader: Best of the bunch?
    ... I'm talking about COMMON functions such as ... which gives me that, I'll switch to it. ... When I use another editor, I constantly hit wrong keys, ...
    (Debian-User)
  • RE: Wired captive portal pen-test
    ... I've done similar voipsec audits at hotels. ... think) they are identifying my room by the switch port (I cannot figure ... Or are they deployed using common hardware ... Securing Web Applications ...
    (Pen-Test)
  • Re: Wired captive portal pen-test
    ... but the Nomadix is deployed as a Gateway with a ... switch you're plugged is configured to deny that. ... Or are they deployed using common hardware ... Top 5 Common Mistakes in Securing Web Applications ...
    (Pen-Test)
  • Re: Wired captive portal pen-test
    ... I've used a Nomadix system. ... but the Nomadix is deployed as a Gateway with a ... switch you're plugged is configured to deny that. ... Or are they deployed using common hardware ...
    (Pen-Test)