INFO-VAX Tue, 07 Oct 2008 Volume 2008 : Issue 542 Contents: Decnet Over IP (Phase V question). Re: Decnet Over IP (Phase V question). Re: Decnet Over IP (Phase V question). Re: Decnet Over IP (Phase V question). Re: Decnet Over IP (Phase V question). Re: Decnet Over IP (Phase V question). EFi firmware revision infos from DCL Re: How to create a shareable image on IA64 using Pascal Re: How to create a shareable image on IA64 using Pascal Re: How to create a shareable image on IA64 using Pascal Re: How to create a shareable image on IA64 using Pascal Re: How to create a shareable image on IA64 using Pascal Re: How to create a shareable image on IA64 using Pascal Trying to contact the Hoff (and I dont mean Hasselhoff) VMS news reader Re: VMS news reader Re: VMS news reader Re: VMS news reader ---------------------------------------------------------------------- Date: Tue, 7 Oct 2008 05:34:36 -0700 (PDT) From: BaxterD@tessco.com Subject: Decnet Over IP (Phase V question). Message-ID: I am using TCPIP services with DECnet Phase V on 2 x Itanium Blades running OVMS 8.3-1H1. Here is the situation. Node 1 SCSNode = OESTST DNS Host name OESTST-TAB In DECNET I have it set up as NodeName = oestst-tab Synonym = oestst ------------------------------------- Node 2 SCSNODE = TABTST DNS Host Name = TABTST In DECNET it is set up as NodeName = tabtst Synonym = tabtst I have 2 DNS servers tab-dns1.myplace.com glc-dns2.myplace.com ----------------------------- I would primarily like the DNS servers to provide the name resolution. However the DNS host names are currently set up in the local tables on each node, (they are also defined in the DNS Servers coincidentally). how should I set up the naming information in DECNet Phase V.? i.e. "local,domain" or "domain", and how would I format the entries??? Dave. ------------------------------ Date: Tue, 7 Oct 2008 05:53:12 -0700 (PDT) From: etmsreec@yahoo.co.uk Subject: Re: Decnet Over IP (Phase V question). Message-ID: <7e547d96-9f4f-45c2-b8f6-30d9ce9c6429@e17g2000hsg.googlegroups.com> On 7 Oct, 13:34, Baxt...@tessco.com wrote: > I am using TCPIP services with DECnet Phase V on 2 x Itanium Blades > running OVMS 8.3-1H1. > > Here is the situation. > > Node 1 > > SCSNode = OESTST > DNS Host name OESTST-TAB > > In DECNET I have it set up as > NodeName = oestst-tab > Synonym = oestst > ------------------------------------- > Node 2 > > SCSNODE = TABTST > DNS Host Name = TABTST > > In DECNET it is set up as > NodeName = tabtst > Synonym = tabtst > > I have 2 DNS servers > tab-dns1.myplace.com > glc-dns2.myplace.com > > ----------------------------- > I would primarily like the DNS servers to provide the name resolution. > However the > DNS host names are currently set up in the local tables on each node, > (they are also defined in the DNS Servers coincidentally). > > how should I set up the naming information in DECNet Phase V.? > > i.e. "local,domain" or "domain", and how would I format the entries??? > > Dave. My understanding is that you need LOCAL, no matter what. I would suggest that you use LOCAL,DOMAIN as this will then dive off into the TCP/IP transport if you can't resolve the name through the LOCAL address towers. I'm not certain that the TCP/IP naming will actually go off through DNS or whether it will return remote node is unknown if the address is neither in the local DECnet database nor in the local host table. I suspect it'll return remote node is unknown because DECnet doesn't use DNS lookup for the IP stack. Steve ------------------------------ Date: Tue, 07 Oct 2008 14:03:54 GMT From: "Colin Butcher" Subject: Re: Decnet Over IP (Phase V question). Message-ID: @net$configure in advanced mode Answer "local,domain" to the naming service question. Answer "127.0.0.1" for the name / address of the name server - actually they really mean "BIND resolver". "127.0.0.1" equates to "localhost", so you always query your local HOSTS database first, then it will use whatever DNS nameserver list you have set up in your local IP stack. It's a useful trick that doesn't seem to be documented anywhere. All you then do is delete the 'old' DECnet style name from the local naming service (using DECNET_REGISTER) and insert the new name into the local HOSTS database, then move it out to your DNS if you ever need to. You might find the article I wrote some time ago for the VMS technical update useful, plus some of the slide sets available at www.xdelta.co.uk/seminars Don't forget that you can test the connectivity without relying on the naming by using things like set host ip$. You can check the naming at each end by looking at the SYS$*NODE* logical names. Beware that proxies work by node fullname, so expect to have to re-add your proxies. -- Cheers, Colin. Legacy = Stuff that works properly! ------------------------------ Date: Tue, 7 Oct 2008 07:34:54 -0700 (PDT) From: IanMiller Subject: Re: Decnet Over IP (Phase V question). Message-ID: <4d6380a5-0796-41f8-ae30-5f8ff4ce1635@j22g2000hsf.googlegroups.com> On 7 Oct, 13:34, Baxt...@tessco.com wrote: > I am using TCPIP services with DECnet Phase V on 2 x Itanium Blades > running OVMS 8.3-1H1. > > Here is the situation. > > Node 1 > > SCSNode = OESTST > DNS Host name OESTST-TAB > > In DECNET I have it set up as > NodeName = oestst-tab > Synonym = oestst > ------------------------------------- > Node 2 > > SCSNODE = TABTST > DNS Host Name = TABTST > > In DECNET it is set up as > NodeName = tabtst > Synonym = tabtst > > I have 2 DNS servers > tab-dns1.myplace.com > glc-dns2.myplace.com > > ----------------------------- > I would primarily like the DNS servers to provide the name resolution. > However the > DNS host names are currently set up in the local tables on each node, > (they are also defined in the DNS Servers coincidentally). > > how should I set up the naming information in DECNet Phase V.? > > i.e. "local,domain" or "domain", and how would I format the entries??? > > Dave. LOCAL, DOMAIN LOCAL means DECnet local host file DOMAIN means whatever the DNS Name resolver is setup to do. Currently that would be the local host file but could be the DNS servers if you configured it like that. ------------------------------ Date: Tue, 7 Oct 2008 07:59:24 -0700 (PDT) From: BaxterD@tessco.com Subject: Re: Decnet Over IP (Phase V question). Message-ID: <0c753193-dcfc-4f09-826c-3f8ab2503148@u28g2000hsc.googlegroups.com> On Oct 7, 10:03=A0am, "Colin Butcher" wrote: > @net$configure in advanced mode > > Answer "local,domain" to the naming service question. > > Answer "127.0.0.1" for the name / address of the name server - actually t= hey > really mean "BIND resolver". "127.0.0.1" equates to "localhost", so you > always query your local HOSTS database first, then it will use whatever D= NS > nameserver list you have set up in your local IP stack. It's a useful tri= ck > that doesn't seem to be documented anywhere. > > All you then do is delete the 'old' DECnet style name from the local nami= ng > service (using DECNET_REGISTER) and insert the new name into the local HO= STS > database, then move it out to your DNS if you ever need to. > > You might find the article I wrote some time ago for the VMS technical > update useful, plus some of the slide sets available atwww.xdelta.co.uk/s= eminars > > Don't forget that you can test the connectivity without relying on the > naming by using things like set host ip$. You can check the > naming at each end by looking at the SYS$*NODE* logical names. Beware tha= t > proxies work by node fullname, so expect to have to re-add your proxies. > > -- > Cheers, Colin. > Legacy =3D Stuff that works properly! Hi guys, thanks for your replies. I appreciate your "undocumented" solution, however as a newbe to this I think I have to stick to the "proper" stuff. Anyway, here is what I have concluded from your joint comments, SCSNODE =3D TABTST DNS Host Name =3D TABTST DNS Server Name =3D TAB-DNS1.myplace.com 1. @net$configure. 2. Select option 2 (Change naming information) 3. * Enter the directory services to use on the system [LOCAL] : local,domain 4. * Enter the full name for directory service LOCAL [LOCAL:.TABTST] : 5. * Enter the fully qualified host name for DNS/BIND : tab-dns1.myplace.com 6. * What is the synonym name for this node? [TABTST] : will this do the job?? And does this have to be set up on both originator and destination in order to work?? Also, once this is set up, should it work immediately, or do I have to wait, or flush cache, or anything? thanks Dave. ------------------------------ Date: Tue, 07 Oct 2008 17:17:42 GMT From: "Colin Butcher" Subject: Re: Decnet Over IP (Phase V question). Message-ID: Using "127.0.0.1" as the local IP name BIND resolver is not an "undocumented" solution in that you can enter whatever you like as the DNS nameserver. I'm just surprised that it's not the standard recommendation, because it's so easy and flexible in terms of setting up the name service lookup precedence order once you've jumped sideways into the IP stack. So, put "127.0.0.1" in as the name server, then set up the list of DNS name servers you wish to use in your IP stack in the usual manner. That way you get the HOSTS file first, followed by whatever name servers you choose to use. Means you don't have to go back to your DECnet configuration if you ever change your name servers. Easy. You should make consistent naming changes everywhere. In practice a destination node will accept inbound DECnet-over-IP connections without having all the naming in place, but you'll see "back translate" failures from the naming service until you have the naming consistent. You'll also need to flush the naming caches everywhere too. NCL> FLUSH SESSION CONTROL NAMING CACHE ENTRY "*" is what you need. Don't forget to enable the PWIP driver and allow ports 102 and 399 through the firewalls. You can also control which IP subnets you accept inbound connections from if you're on a recent version (can't remember which right now) - look at the NCL help for the rfc 1006 and rfc 1006-plus (aka rfc 1869) OSI transport templates. -- Cheers, Colin. Legacy = Stuff that works properly! ------------------------------ Date: Tue, 7 Oct 2008 12:37:10 +0200 From: "Walter Kuhn" Subject: EFi firmware revision infos from DCL Message-ID: <48eb3bd7$0$26587$91cee783@newsreader01.highway.telekom.at> Hello, do I have any chance to get some (or all) firmware revision infos on a rx6600 via DCL? regards Walter Kuhn ------------------------------ Date: Tue, 7 Oct 2008 01:44:16 -0700 (PDT) From: Bob Gezelter Subject: Re: How to create a shareable image on IA64 using Pascal Message-ID: On Oct 6, 6:42=A0am, "Ade" wrote: > 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 th= is > image, when installed with /open/header/share/write, =A0will be used simp= ly as > a data repository for other applications which are linked together with i= t. > All the examples I have seen in the documentation refer to shared memory > between linked object files rather than against a shareable image. Any he= lp > 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 > =A0 =A0 common_r =3D record > =A0 =A0 =A0 =A0 my_int : integer; > =A0 =A0 =A0 =A0 my_str : varying [10] of char; > =A0 =A0 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 =A0 =A0common:[common]common_r; > begin > =A0 =A0 common.my_int :=3D 1000; > =A0 =A0 common.my_str :=3D '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 =A0 =A0common:[common]common_r; > begin > =A0 =A0 writeln('int =3D ', common.my_int); > =A0 =A0 writeln('str =3D ', common.my_str); > end. > > $ pascal/debug/nooptim prog2 > $ link prog2, sys$input/opt > disk1:[dir]common.exe/share > $ run prog2 =A0 =A0 =A0 =A0!noting that prog1 is still running in your ot= her process > int =3D =A0 =A0 =A0 =A0 0 > str =3D Adrian, [SET SOAPBOX/SAVE] [SET SOAPBOX/MODERATE] I read things a little TOO quickly yesterday morning (here in New York City). I strongly recommend AGAINST using shareable storage between processes for data storage. The perceived performance benefits are not significant in the overwhelming majority of cases. The hazards of improper synchronization are far more disruptive and damaging. I have troubleshot many truly bizarre problems caused by nothing more egregious than the "performance" improvement cited by using shared memory. On the other hand, I have used intra-node DECnet logical links to query a server process for information in a far safer fashion. Admittedly, it is not as theoretically efficient, but in the scheme of things, it is not measurable in most cases. This is even more true today than it was 25 years ago. For most purposes, the substantially extra effort to design, implement, and qualify shared memory code is simply unjustified by the overall performance impact on the system. In short, if one is designing the OpenVMS file system, it is worth the effort. If one is maintaining applications data, it is far, far easier to debug a DECnet logical link-based reference monitor (which is straightforward to instrument) than to debug a collection of processes accessing a shared region. The increase in complexity is quite often exponential, for negligible increases in "efficiency". This is particularly true on today's multicore and multithread processors. For static data, consider the use of an applications specific logical name table, perhaps maintained by a control process and readable by designated other processes. DECnet logical links are also preferable to mailboxes, as they have the inherent ability to synchronize BOTH sides of the connection. The loss of either process is automatically reported to its correspondent, allowing appropriate action to be taken. This is far more subtle with mailboxes. [SET SOAPBOX/RESTORE] - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Tue, 7 Oct 2008 12:30:35 +0100 From: "Ade" Subject: Re: How to create a shareable image on IA64 using Pascal Message-ID: "Bob Gezelter" wrote in message news:b435d1ed-5fbb-4401-8d10-19fa66740aea@l42g2000hsc.googlegroups.com... On Oct 6, 6:42 am, "Ade" wrote: > 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 = Adrian, [SET SOAPBOX/SAVE] [SET SOAPBOX/MODERATE] I read things a little TOO quickly yesterday morning (here in New York City). I strongly recommend AGAINST using shareable storage between processes for data storage. The perceived performance benefits are not significant in the overwhelming majority of cases. The hazards of improper synchronization are far more disruptive and damaging. I have troubleshot many truly bizarre problems caused by nothing more egregious than the "performance" improvement cited by using shared memory. On the other hand, I have used intra-node DECnet logical links to query a server process for information in a far safer fashion. Admittedly, it is not as theoretically efficient, but in the scheme of things, it is not measurable in most cases. This is even more true today than it was 25 years ago. For most purposes, the substantially extra effort to design, implement, and qualify shared memory code is simply unjustified by the overall performance impact on the system. In short, if one is designing the OpenVMS file system, it is worth the effort. If one is maintaining applications data, it is far, far easier to debug a DECnet logical link-based reference monitor (which is straightforward to instrument) than to debug a collection of processes accessing a shared region. The increase in complexity is quite often exponential, for negligible increases in "efficiency". This is particularly true on today's multicore and multithread processors. For static data, consider the use of an applications specific logical name table, perhaps maintained by a control process and readable by designated other processes. DECnet logical links are also preferable to mailboxes, as they have the inherent ability to synchronize BOTH sides of the connection. The loss of either process is automatically reported to its correspondent, allowing appropriate action to be taken. This is far more subtle with mailboxes. [SET SOAPBOX/RESTORE] - Bob Gezelter, http://www.rlgsc.com Bob, I'm going to hold my hands up now and admit that what I'm doing is not just an out-of-interest project. I have been asked by a customer to assist in porting a huge application (million lines plus of pascal) from the current VAX to a new Blade they have purchased. Unfortunately, you guessed it, the system uses common shared memory for data storage and re-writing this for any other method is completely out of the question. The common memory of just one of the seven shareable images in this suite contains over a quarter mb of non-static real-time data. For my example, I have tested it on the old VAX and it works but I am still at a loss as to how to get it working on the IA64. I do, however, have to carry on with this and find the correct solution for the applications in question. If not, it starts to cost some serious money in lost revenue. Whatever happened to the use of files and disks and such - did I miss that particular boat? Anyway, upward and onward, there's a few windows left in the building that I haven't thrown something through yet. Thanks again, Ade ------------------------------ Date: Tue, 07 Oct 2008 07:56:54 -0400 From: "Richard B. Gilbert" Subject: Re: How to create a shareable image on IA64 using Pascal Message-ID: Ade wrote: > "Bob Gezelter" wrote in message > news:b435d1ed-5fbb-4401-8d10-19fa66740aea@l42g2000hsc.googlegroups.com... > On Oct 6, 6:42 am, "Ade" wrote: >> 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 = > > Adrian, > > [SET SOAPBOX/SAVE] > [SET SOAPBOX/MODERATE] > > I read things a little TOO quickly yesterday morning (here in New York > City). > > I strongly recommend AGAINST using shareable storage between processes > for data storage. The perceived performance benefits are not > significant in the overwhelming majority of cases. The hazards of > improper synchronization are far more disruptive and damaging. I have > troubleshot many truly bizarre problems caused by nothing more > egregious than the "performance" improvement cited by using shared > memory. > > On the other hand, I have used intra-node DECnet logical links to > query a server process for information in a far safer fashion. > Admittedly, it is not as theoretically efficient, but in the scheme of > things, it is not measurable in most cases. This is even more true > today than it was 25 years ago. For most purposes, the substantially > extra effort to design, implement, and qualify shared memory code is > simply unjustified by the overall performance impact on the system. > > In short, if one is designing the OpenVMS file system, it is worth the > effort. If one is maintaining applications data, it is far, far easier > to debug a DECnet logical link-based reference monitor (which is > straightforward to instrument) than to debug a collection of processes > accessing a shared region. The increase in complexity is quite often > exponential, for negligible increases in "efficiency". This is > particularly true on today's multicore and multithread processors. > > For static data, consider the use of an applications specific logical > name table, perhaps maintained by a control process and readable by > designated other processes. > > DECnet logical links are also preferable to mailboxes, as they have > the inherent ability to synchronize BOTH sides of the connection. The > loss of either process is automatically reported to its correspondent, > allowing appropriate action to be taken. This is far more subtle with > mailboxes. > > [SET SOAPBOX/RESTORE] > > - Bob Gezelter, http://www.rlgsc.com > > Bob, > > I'm going to hold my hands up now and admit that what I'm doing is not just > an out-of-interest project. I have been asked by a customer to assist in > porting a huge application (million lines plus of pascal) from the current > VAX to a new Blade they have purchased. Unfortunately, you guessed it, the > system uses common shared memory for data storage and re-writing this for > any other method is completely out of the question. The common memory of > just one of the seven shareable images in this suite contains over a quarter > mb of non-static real-time data. > > For my example, I have tested it on the old VAX and it works but I am still > at a loss as to how to get it working on the IA64. I do, however, have to > carry on with this and find the correct solution for the applications in > question. If not, it starts to cost some serious money in lost revenue. > > Whatever happened to the use of files and disks and such - did I miss that > particular boat? > > Anyway, upward and onward, there's a few windows left in the building that I > haven't thrown something through yet. > > Thanks again, > > Ade > > I hope you know that using "COMMON" storage (I'm assuming you mean something like Fortran COMMON) is an extremely poor idea. Yes, it gives you easy access to variables but the cost is that your code has access to variables that it does not need and should not be able to touch. It also means that the code is not portable unless you port the COMMON environment. Code like that can be a nightmare to work with. In my younger days I had to dekludge a fair amount of it. Imagine a dozen or more named common blocks, each with a dozen or more variables. Imagine that each subroutine or function uses ONE variable from each COMMON block. If a COMMON variable is being stepped on, you have as suspects every line of code in the program! ------------------------------ Date: Tue, 7 Oct 2008 05:13:29 -0700 (PDT) From: FrankS Subject: Re: How to create a shareable image on IA64 using Pascal Message-ID: <529e148e-272f-495d-a4ff-90691ca748b4@w7g2000hsa.googlegroups.com> On Oct 7, 7:30=A0am, "Ade" wrote: > Unfortunately, you guessed it, the > system uses common shared memory for data storage and re-writing this for > any other method is completely out of the question. My experience with Pascal has become extraordinarily rusty so I won't be of much help on syntax. However, I suspect the conversion from a shared image to a mapped memory section isn't as complex as you might think. Without much investigation, there would be three steps that I can think of, which have to be applied to all applications that are sharing the memory space: a) Define the record structure in a COMMON psect. I don't remember the Pascal equivalent, but I'm sure it's trivial. b) At the very beginning of each application insert a call to an external subroutine that invokes the SYS$CRMPSC system service. You have to calculate the number of pages being used by the data psect, and for that (on Alpha) you need to get the size of a page on the host system. c) Modify the linker options file to force the COMMON psect into its own address space. On Alpha the option was /SOLITARY. I haven't looked into the I64 equivalent, if it's not the exactly the same. From that point on the applications should behave the same. > The common memory of > just one of the seven shareable images in this suite contains over a quar= ter > mb of non-static real-time data. The wonderful thing about virtual memory is that it's virtual. I recently worked on an application which had a 4mb mapped global section which contains dynamic data updated by four cooperating processes. You might need to play with PGFLQUO but otherwise 1/4 mb of shared address space shouldn't be much of a concern. ------------------------------ Date: Tue, 7 Oct 2008 06:30:09 -0700 (PDT) From: Bob Gezelter Subject: Re: How to create a shareable image on IA64 using Pascal Message-ID: <9b0fc150-b839-4c9b-93d3-10e776e1d39f@k30g2000hse.googlegroups.com> On Oct 7, 7:30=A0am, "Ade" wrote: > "Bob Gezelter" wrote in message > > news:b435d1ed-5fbb-4401-8d10-19fa66740aea@l42g2000hsc.googlegroups.com... > On Oct 6, 6:42 am, "Ade" wrote: > > > > > Hi, > > > Does anyone have a quick example of how to create a shareable image usi= ng > > 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 simpl= y > > 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 memor= y > > 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 =3D 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 :=3D 1000; > > common.my_str :=3D '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 =3D ', common.my_int); > > writeln('str =3D ', 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 =3D 0 > > str =3D > > Adrian, > > [SET SOAPBOX/SAVE] > [SET SOAPBOX/MODERATE] > > I read things a little TOO quickly yesterday morning (here in New York > City). > > I strongly recommend AGAINST using shareable storage between processes > for data storage. The perceived performance benefits are not > significant in the overwhelming majority of cases. The hazards of > improper synchronization are far more disruptive and damaging. I have > troubleshot many truly bizarre problems caused by nothing more > egregious than the "performance" improvement cited by using shared > memory. > > On the other hand, I have used intra-node DECnet logical links to > query a server process for information in a far safer fashion. > Admittedly, it is not as theoretically efficient, but in the scheme of > things, it is not measurable in most cases. This is even more true > today than it was 25 years ago. For most purposes, the substantially > extra effort to design, implement, and qualify shared memory code is > simply unjustified by the overall performance impact on the system. > > In short, if one is designing the OpenVMS file system, it is worth the > effort. If one is maintaining applications data, it is far, far easier > to debug a DECnet logical link-based reference monitor (which is > straightforward to instrument) than to debug a collection of processes > accessing a shared region. The increase in complexity is quite often > exponential, for negligible increases in "efficiency". This is > particularly true on today's multicore and multithread processors. > > For static data, consider the use of an applications specific logical > name table, perhaps maintained by a control process and readable by > designated other processes. > > DECnet logical links are also preferable to mailboxes, as they have > the inherent ability to synchronize BOTH sides of the connection. The > loss of either process is automatically reported to its correspondent, > allowing appropriate action to be taken. This is far more subtle with > mailboxes. > > [SET SOAPBOX/RESTORE] > > - Bob Gezelter,http://www.rlgsc.com > > Bob, > > I'm going to hold my hands up now and admit that what I'm doing is not ju= st > an out-of-interest project. I have been asked by a customer to assist in > porting a huge application (million lines plus of pascal) from the curren= t > VAX to a new Blade they have purchased. Unfortunately, you guessed it, th= e > system uses common shared memory for data storage and re-writing this for > any other method is completely out of the question. The common memory of > just one of the seven shareable images in this suite contains over a quar= ter > mb of non-static real-time data. > > For my example, I have tested it on the old VAX and it works but I am sti= ll > at a loss as to how to get it working on the IA64. I do, however, have to > carry on with this and find the correct solution for the applications in > question. If not, it starts to cost some serious money in lost revenue. > > Whatever happened to the use of files and disks and such - did I miss tha= t > particular boat? > > Anyway, upward and onward, there's a few windows left in the building tha= t I > haven't thrown something through yet. > > Thanks again, > > Ade Ade, I understand the problem all too well. The challenge is, as you noted, complex. There is a good chance that there are undocumented (and quite possibly, not considered) timing presumptions in this code related to synchronization. There are many timing and atomicity presumptions that are commonly used on uniprocessors (most VAX systems) that do not hold on multiprocessors, Alpha or Itanium. I admit that I may sound excessively pessimistic, but I have the scars to prove it. Some of these atomicity problems can show up on even uniprocessor VAX systems, as I have pointed out in several of my AST sessions (and one attendee came up to me afterwards saying "I wondered how that could have happened"-- Guess the hazard was not so theoretical after all. I am not sure what to suggest. Prescribing "over the phone" without seeing the patient is problematical. My normal suggestion is a review of how the data is used, to see if there are some systemic hazards. The reason I am being so conservative is the difficulty of isolating and eliminating these problems, they can take man-months of time each. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Tue, 7 Oct 2008 16:47:53 +0100 From: "Ade" Subject: Re: How to create a shareable image on IA64 using Pascal Message-ID: Hi, My problem seems to be solved (for now). I simply removed the additional definitions of 'shared_memory' and referenced the area of 'shared_mem' as defined in the common programs' data area. After realising what I was doing, I gave myself a real good kicking. It should have been obvious. I've gone a bit overboard on the link options but it now works OK. For those wanting to see my solution, I have included the code below. Thanks to everyone for your help and suggestions. Ade {shared memory module} [environment ('shared')] module shared_memory; type shared_r = record my_int : integer; my_str : varying [10] of char; end; shared_mem : [global, common(shared_psect)] shared_r; end. $ instal remove disk1:[dir]common.exe $ pascal/align=vax common.pas $ link/map/full/share/gst common, sys$input/opt case_sensitive=no symbol_table=global gsmatch=lequal,1,10000 symbol_vector=(shared_mem=data, shared_psect=psect) psect_attributes=shared_psect,shr,gbl,noexe,wrt $ define/nolog common disk1:[dir]common.exe $ instal add /open/head/share/write/resident common {prog1 - writes to common memory} [inherit ('disk1:[dir]shared')] program prog1(input, output); begin shared_mem.my_int := 1000; shared_mem.my_str := 'Hello'; writeln ('int = ',shared_mem.my_int); writeln ('str = ',shared_mem.my_str); end. $ pascal/align=vax prog1 $ link /map/full prog1, sys$input/opt disk1:[dir]common.exe/share psect_attributes=shared_psect,shr,gbl,noexe,wrt {prog2 - reads common memory} [inherit ('disk1:[dir]shared')] program prog2(input, output); begin writeln ('int = ',shared_mem.my_int); writeln ('str = ',shared_mem.my_str); end. $ pascal/align=vax prog2 $ link /map/full prog2, sys$input/opt disk1:[dir]common.exe/share psect_attributes=shared_psect,shr,gbl,noexe,wrt $ run prog2 !<-- check contents before int = 0 str = $ run prog1 !<-- populate int = 1000 str = Hello $ run prog2 !<-- check contents after int = 1000 str = Hello Easy when you know how 8-) Ade ------------------------------ Date: Tue, 7 Oct 2008 10:25:41 -0700 (PDT) From: BaxterD@tessco.com Subject: Trying to contact the Hoff (and I dont mean Hasselhoff) Message-ID: Hoff, Went to your site (HoffmanLabs.org) and hit the "Contact Us" button. Unfortunately, there is no contact information there. Can you send me some contact info by e-mail? (see my profile) Dave ------------------------------ Date: Tue, 7 Oct 2008 09:45:51 -0700 (PDT) From: H Vlems Subject: VMS news reader Message-ID: <9aa8e7f9-dac2-4b17-b765-90f229f45f84@u46g2000hsc.googlegroups.com> What newsreader would you recommend for Alpha/VMS V8.3? Right now I use either Outlook Express or Google Groups. The first refuses to update comp.sys.dec and the latter tends to add funny strings, to the point that the message is unreadable. Last week I received the KZPCM-DX controllers and added more storage to my Digital Server 5305 (7 * 9 GB). I read comp.os.vms, comp.sys.dec, alt.sys.pdp10 and pdp11. A retain period of 3 months is sufficient I guess. So what amount of storage would you recommend and what tool? Hans ------------------------------ Date: Tue, 7 Oct 2008 09:53:50 -0700 (PDT) From: Ken.Fairfield@gmail.com Subject: Re: VMS news reader Message-ID: <2bc73e6f-ebbd-4236-b401-b11b07d8f1e4@c22g2000prc.googlegroups.com> On Oct 7, 9:45=A0am, H Vlems wrote: > What newsreader would you recommend for Alpha/VMS V8.3? > Right now I use either Outlook Express or Google Groups. The first > refuses to update comp.sys.dec and the latter tends to add funny > strings, to the point that the message is unreadable. > Last week I received the KZPCM-DX controllers and added more storage > to my Digital Server 5305 (7 * 9 GB). > I read comp.os.vms, comp.sys.dec, alt.sys.pdp10 and pdp11. A retain > period of 3 months is sufficient I guess. > So what amount of storage would you recommend and what tool? > Hans I have Mozilla installed on my PWS 600au and use it's built-in news reader (when at home!). There are a few other products you need to install for Mozilla, but I don't recall having any particular problem with that. I used to love ANU-News, but it's been a very long time since I've had access to a system where I could run it _and_ find an NNTP server to point it at. If I'm on my PC at home, I tend to use Thunderbird, but at work Google groups is my only option. Sigh. :-( -Ken ------------------------------ Date: 7 Oct 2008 12:27:23 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: VMS news reader Message-ID: In article <9aa8e7f9-dac2-4b17-b765-90f229f45f84@u46g2000hsc.googlegroups.com>, H Vlems writes: > What newsreader would you recommend for Alpha/VMS V8.3? > Right now I use either Outlook Express or Google Groups. The first > refuses to update comp.sys.dec and the latter tends to add funny > strings, to the point that the message is unreadable. > Last week I received the KZPCM-DX controllers and added more storage > to my Digital Server 5305 (7 * 9 GB). > I read comp.os.vms, comp.sys.dec, alt.sys.pdp10 and pdp11. A retain > period of 3 months is sufficient I guess. > So what amount of storage would you recommend and what tool? > Hans For just reading text, anu news as I'm using on Eisner right now is good. For non-text I use mozilla, since that's the latest news-capable browser for VMS where I prefer to do my browsing. (No stink'n virus to worry about.) ------------------------------ Date: Tue, 07 Oct 2008 10:40:03 -0700 From: "Tom Linden" Subject: Re: VMS news reader Message-ID: On Tue, 07 Oct 2008 09:45:51 -0700, H Vlems wrote: > What newsreader would you recommend for Alpha/VMS V8.3? > Right now I use either Outlook Express or Google Groups. The first > refuses to update comp.sys.dec and the latter tends to add funny > strings, to the point that the message is unreadable. > Last week I received the KZPCM-DX controllers and added more storage > to my Digital Server 5305 (7 * 9 GB). > I read comp.os.vms, comp.sys.dec, alt.sys.pdp10 and pdp11. A retain > period of 3 months is sufficient I guess. > So what amount of storage would you recommend and what tool? > Hans Opera has a very good threaded newsreader which I use with News.Individual.NET which costs ¤10/annum -- PL/I for OpenVMS www.kednos.com ------------------------------ End of INFO-VAX 2008.542 ************************