INFO-VAX Sat, 08 Sep 2007 Volume 2007 : Issue 490
Contents:
Re: DECServer 700 help
Re: DECServer 700 help
Re: Here's one for Bob (hope it makes your head spin)
Re: I think I might understand N3 and the bullet
Re: Intel Launches Quad-Core "Tigerton"
Re: node and port alloclass, cannot add a node to the cluster
Re: SOAP, WSIT, I'm LOST, sort of...
Re: SOAP, WSIT, I'm LOST, sort of...
Re: SOAP, WSIT, I'm LOST, sort of...
Re: VMS License Plates
Re: VMS License Plates
----------------------------------------------------------------------
Date: Sat, 08 Sep 2007 06:05:55 GMT
From: "John E. Malmberg" <wb8tyw@qsl.network>
Subject: Re: DECServer 700 help
Message-ID: <7ZqEi.74064$Xa3.16332@attbi_s22>
bakermo wrote:
> OK - it's been a while since I worked with a DECServer 700 so I wonder
> if anyone can please give me some advice and/or help?
>
> I am trying to configure a reverse LAT port from an Alpha GS140 to a
> DECServer 700. I have a 4800 baud clock signal that will go into the
> DECServer on port 7 and have VMS get the signal on LTA7.
>
> The clock is ansi characters in the format:
>
> 203:00:00:02B
I presume you mean ASCII.
ANSI in this context usually applies to escape sequences used to control
terminal functions, usually display features.
> I have looked at this signal on a VT320 on a crash cart and it is OK.
> (4800 baud, XON, 1 stop bit, noparity). The cable is connected via a
> null modem into port 7 of the DS700.
>
> Here's how the server port is configured:
>
> Port 7: (Remote) Server: RAQ1TS
>
> Character Size: 8 Input Speed: 4800
> Flow Control: XON Output Speed: 4800
> Parity: None Signal Control: Disabled
> Stop Bits: Dynamic Signal Select: CTS-DSR-RTS-DTR
Should be 1 stop bit for anything other than 110 baud.
> Access: Remote Local Switch: None
> Backwards Switch: None Name: PORT_7
> Break: Local Session Limit: 4
> Forwards Switch: None Type: Ansi
> Default Protocol: LAT Default Menu: None
> Autolink Timer One:10 Two:10 Dialer Script: None
>
> Preferred Service: None
> Authorized Groups: 0-255
> (Current) Groups: 0-255
>
> Enabled Characteristics:
>
> ==========================================================
>
> Here's the VMS LAT port:
>
> Local Port Name: _LTA7: Local Port Type: Application
> (Queued)
> Local Port State: Active
> Connected Link: TSLINK
>
> Target Port Name: PORT_7 Actual Port Name: PORT_7
> Target Node Name: RAQ1TS Actual Node Name: RAQ1TS
> Target Service Name: Actual Service Name:
>
> =========================================================
>
> Here's the VMS LTA7 terminal:
>
> Terminal: _LTA7: Device_Type: Unknown Owner: NAME
> Username: USER
>
> Input: 4800 LFfill: 0 Width: 132 Parity: None
> Output: 4800 CRfill: 0 Page: 64
>
> Terminal Characteristics:
> Passall No Echo No Typeahead No Escape
> No Hostsync No TTsync Uppercase No Tab
> No Wrap Hardcopy No Remote Eightbit
> No Broadcast No Readsync No Form Fulldup
> No Modem No Local_echo No Autobaud No Hangup
> No Brdcstmbx No DMA Altypeahd Set_speed
> No Commsync No Line Editing Overstrike editing No
> Fallback
> No Dialup No Secure server No Disconnect Pasthru
> No Syspassword No SIXEL Graphics No Soft Characters No Printer
> Port
> Numeric Keypad No ANSI_CRT No Regis No
> Block_mode
> No Advanced_video No Edit_mode No DEC_CRT No
> DEC_CRT2
> No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No
> Ansi_Color
> VMS Style Input
>
> ========================================================
>
> A set host/dte LTA7 will show either nothing or sometime a buch of
> characters that seem to be a baud rate mismatch.
Are you doing:
$allocate lta7
$set term lta7:/type
$set host/dte lta7:
.....
$deallocate lta7:
> Here's what the program is getting for the input:
>
>
>
>
> Fmterr :OEOO¢
>
> Fmterr :OEOOª
>
> Fmterr :OEOO²
>
> Fmterr :OEOOº
>
> Fmterr :OEOOA
>
> Fmterr :OEOOE
>
> Fmterr :OEOO
>
> Fmterr :OEOO
>
> Fmterr :EOO
>
>
> Fmterr :EOO
>
>
> Fmterr :EOO¢
>
>
> ========================================================================
>
> Here's what it should look like:
>
> date= 7-SEP-2007 00:00:02.91 ,len= 23
> date= 7-SEP-2007 03:59:36.00 ,len= 23
> date= 7-SEP-2007 18:13:53.00 ,len= 23
>
> ========================================================================
>
> The example from a running program is from another server that is
> working except it is via a DS900. No - I don't have access to anything
> but the DS700 and the other server is across the country in another
> datacenter.
>
> I copied its port and terminal characteristics with three exceptions.
>
> 1. The working system has NOAltypeahd on its terminal and I have no
> idea how to set that on mine.
Altypeahd is a larger type ahead buffer. Having it on should improve
things in most cases like this. Usually though I have needed to make it
larger via AUTOGEN. But for a clock, it is probably not an issue.
> 2. The DS900 has no Signal Select: CTS-DSR-RTS-DTR setting
Watch how your cable is wired. If the DS900 does not support a signal
pair, it should be jumpered at the end of the cable.
CTS should be jumpered to RTS, and DTR should be jumpered to DSR if the
cable is not supporting them. Some devices will not send data if the
CTS signal is not asserted. If the hardware supports it, it is
preferable to use CTS/RTS for handshaking instead of XON/XOFF.
Normally though, your device should be asserting DTR when it is on, and
that signal will be wired to the DECserver DSR line, which the
application can monitor as a sanity check.
The DECServer should assert DTR when ever is allocated by an
application, the crossover cable should connect this to the device DSR
line. Devices may decide not to send data if they do not see a DSR
signal. The lack of a DSR signal indicates to them that there is
nothing on the other end of the wire.
Printers tend to use DTR/DSR for flow control instead of RTS/CTS for
some reason. This is preferred as some terminals servers forget the
state of the XON/XOFF when they are not allocated to a process on a host.
> 3. The DS900 has no Autolink Timer One:10 Two:10 setting
I am not remembering what this does, and not sure that it means anything
in this application.
> I have three systems that are all configured the same (all with
> DS700's) and none work. I would think that eliminates a hardware
> error.
It makes it unlikely that there is a malfunction in the DS700, but does
not eliminate other errors.
> Any thoughts?
The type of noise that you are seeing looks like either a baud rate
mis-match or of a wiring error.
Verify that you have the baud rate right. Some devices will autobaud,
which works when they are connected to a real terminal and someone hits
enter, but does not work when they are connected to a computer type device.
The application should be setting the port to /typeahead after it
assigns a channel to the ltann: device. Failure to do that may cause
problems.
If modtap or modular connectors are involved, be aware that there are
two signal commons on the cable. Both must be connected to the single
signal common(ground) on the typical D connector. If you only run one,
because of the twist in a NULL modem configuration, you actually end up
with no signal commons being connected. Surprisingly I have seen this
type of mis-configuration work most of the time, but it tends to fail
with the phase of the moon. In one case it was found that the safety
ground pin in the powerlines was handling the signal return because the
modular to D connectors were miswired by having only one signal common
connected at each end.
-John
wb8tyw@qsl.network
Personal Opinion Only
------------------------------
Date: Sat, 08 Sep 2007 07:53:44 GMT
From: John Santos <john@egh.com>
Subject: Re: DECServer 700 help
Message-ID: <cysEi.279$Af1.201@trnddc06>
Richard B. Gilbert wrote:
> bakermo wrote:
>
>> On Fri, 07 Sep 2007 18:26:00 -0400, "Richard B. Gilbert"
>> <rgilbert88@comcast.net> wrote:
>>
>>
>>> bakermo wrote:
>>>
>>>> OK - it's been a while since I worked with a DECServer 700 so I wonder
>>>> if anyone can please give me some advice and/or help?
>>>>
>>>> I am trying to configure a reverse LAT port from an Alpha GS140 to a
>>>> DECServer 700. I have a 4800 baud clock signal that will go into the
>>>> DECServer on port 7 and have VMS get the signal on LTA7.
>>>>
>>>> The clock is ansi characters in the format:
>>>>
>>>> 203:00:00:02B
>>>>
>>>> I have looked at this signal on a VT320 on a crash cart and it is OK.
>>>> (4800 baud, XON, 1 stop bit, noparity). The cable is connected via a
>>>> null modem into port 7 of the DS700.
>>>>
>>>> Here's how the server port is configured:
>>>
>>>
>>> <snip>
>>>
>>>> The example from a running program is from another server that is
>>>> working except it is via a DS900. No - I don't have access to anything
>>>> but the DS700 and the other server is across the country in another
>>>> datacenter.
>>>> I copied its port and terminal characteristics with three exceptions.
>>>> 1. The working system has NOAltypeahd on its terminal and I have no
>>>> idea how to set that on mine.
>>>>
>>>
>>> $ SET TERMINAL /NOALTYPEAHD LTAnnn:
>>
>>
>>
>> If you look in the DCL dictionary you will see there is no such
>> qualifier.
>
>
> My bad!
>
> It appears that once ALTYPEAHD has been set, there is no way to turn it
> off short of logging off and on again.
>
> If there WERE a way to turn it off, it would be /NOALTYPEAHD.
>
Yeah, but that's not your problem, unless the sysgen parameter TTY_ALTYPAHD
is set to something too small to allow a complete message from the clock
to be received. (Normally ALTYPEAHD is used to set a LARGER buffer for
some terminal ports, i.e. those used for "high-speed" comms, like for
Kermit or X modem, where you might be pumping in large quantities of data.)
Something must have done a set term LTA7:/altypeahd/permanent for this
to have happened (or there's a non-default value for TTY_DEFCHAR or (maybe)
someone set LTA0: to use /altypeahd; it's a template device so its
characteristics might propagate to cloned devices such as LTA7:.
It may well be that SET TERM/NOALTYPEAHD actually works, even though
it isn't documented. If not, it should reset to the permanent
characteristics when the device becomes free (log out if logged into
it or deallocate it from any owning process and close any I/O channels
to it.) If the *permanent* characteristics have been set to /ALTYPEAHD
(visible with show terminal/permanent), then the only way to clear it
is to write a program (requires LOG_IO privilege) to assign a channel
to it, read the current permanent characteristics (QIO with IO$_SENSECHAR
function code), clear the right bit, and set them back (IO$_SETCHAR
function.)
But this isn't your problem, I'm pretty sure.
You say the clock works with a terminal connected to it. Are you using
the null modem cable? If not, the clock is DCE and the the terminal is
DTE. Since the terminal server is also DCE, you need a null modem between
the clock and the DECServer. On the other hand, if you do have a
null modem between the terminal and the clock, then the clock is DTE and
so you want a straight-through connection to the DS700, not a null modem.
(This gets complicated to determine if they use different connector types,
such as DB25 and MMJ or RJ45. Some of the adapters might be crossing
the signals over. This kind of thing is much easier to diagnose with
a break-out box, if you can find one.)
DS700's came in two varieties, one with 8 modem control ports and DB25
connectors, and the other with 16 non-modem ports with RJ45 connectors.
IIRC, the VT320 was MMJ, so you must have some kind of adapter which
is clouding the picture. I've never used a DS900, but I think they
all had RJ45 ports.
I doubt the clock requires modem signals, but it might need hardware
flow control (RTS/CTS crossed over.)
I think both the DS700 and DS900 ran the same software, but the differences
you are seeing in the display might be due to different versions of the
software, or because one has modem control ports (DS700) and the other
does not. SHOW PORT STATUS on the DS700 should show the current state
of the modem signals, but I think you've got it set to ignore them anyway.
HTH.
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
------------------------------
Date: Sat, 8 Sep 2007 16:49:37 +0000 (UTC)
From: david20@alpha2.mdx.ac.uk
Subject: Re: Here's one for Bob (hope it makes your head spin)
Message-ID: <fbujr1$fg8$1@south.jnrs.ja.net>
In article <TvKm+IKGzuiz@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <40ea2$46e0317d$cef8887a$11281@TEKSAVVY.COM>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>>
>> Unless the various laws that govern the universe (physics etc) change,
>> then the future is already pre-determined.
>
> What century are you living in? The laws of physics specifically say
> that is not so and have said that for about 100 years now.
>
The newtonian classical universe is entirely deterministic ie a clockwork
Universe.
Relativity is even stronger. Two events separated in space which I regard as
happening simultaneously will be regarded as having happened at different times
by someone in an inertial frame which is moving with respect to me.
The only way to maintain a single consistent universe is to suppose that
space-time forms a fixed block and that the "now" which each inertial frame
observer sees is a slice through that fixed block - the angle between the
slices viewed by different inertial frame observers being determined by the
relative velocities of the different inertial frames.
The total fixed block is the complete space-time history of the Universe.
Hence the total history of the Universe is fixed ie predetermined.
In quantum theory (which I didn't really want to get into again) the
Schroedinger wave equation is perfectly deterministic however we don't have an
accepted mechanism for the collapse of the wave function (or even in some
interpretations an acceptance that it does collapse) hence we are unable to say
anything about the deterministic nature of that collapse.
David Webb
Security team leader
CCSS
Middlesex University
------------------------------
Date: Sat, 08 Sep 2007 10:06:03 -0700
From: Doug Phillips <dphill46@netscape.net>
Subject: Re: I think I might understand N3 and the bullet
Message-ID: <1189271163.614591.83890@19g2000hsx.googlegroups.com>
On Sep 7, 10:14 pm, Ron Johnson <ron.l.john...@cox.net> wrote:
> Hmmm. I think just had an insight!!!
>
> As a (fast moving) gas molecule strikes the bullet, there is an N3
> reaction. Bullet goes one way, gas molecule goes the other.
> Billions of such continuous tiny reactions:
>
> First overcome it's static inertia, then accelerate it down the
> barrel, imparting more and more kinetic inertia as it zooms down the
> barrel.
>
> As it zooms thru the fluid medium (air, usually), it strikes against
> other molecules. These opposing reactions are what is, in
> aggregate, known as friction.
>
> Am I still totally off-base?
>
Newton's laws are not just about "motion" even though they carry that
name, but are about the relationship between forces acting upon
objects. Other dead scientists expanded upon those ideas to describe
the interaction of force fields and such.
An N3 reaction happens when any two (or more) masses or forces
interact with each other. The explosion within the chamber (or the
cartridge contained by the chamber) reacts with its entire
surroundings. You describe what happens to the bullet, whose reaction
is most obvious.
The relationship between energy, mass and velocity along with other
factors, many you've already mentioned, will determine the outcome of
the interactions.
------------------------------
Date: Sat, 08 Sep 2007 06:56:29 -0700
From: "Tom Linden" <tom@kednos.company>
Subject: Re: Intel Launches Quad-Core "Tigerton"
Message-ID: <op.tyb80faahv4qyg@murphus.linden>
On Fri, 07 Sep 2007 10:14:31 -0700, Rick Jones <rick.jones2@hp.com> wrote:
> There are up to 64 sockets in a Superdome. At present, with dual-core
> Montecito that means 128 cores or 256 threads.
That should keep lmf busy.
--
PL/I for OpenVMS
www.kednos.com
------------------------------
Date: Sat, 08 Sep 2007 07:22:13 GMT
From: John Santos <john@egh.com>
Subject: Re: node and port alloclass, cannot add a node to the cluster
Message-ID: <F4sEi.1203$ed1.1055@trnddc05>
Bob Koehler wrote:
> In article <20070907155014.GA46122@mech-aslap33.men.bris.ac.uk>, Anton Shterenlikht <mexas@bristol.ac.uk> writes:
>
>>%CNXMAN, Lost connection to system DONKEY
>
>
> Running through all the messages it really looks like you've got
> a network problem.
>
>
>
>> CAUTION: If this cluster is running with multiple system disks and
>> common system files will be used, please, do not proceed
>> unless appropriate logical names are defined for cluster
>> common files in SYLOGICALS.COM. For instructions, refer to
>> the "OpenVMS Cluster Systems" manual.
>>
>>I understand that I need to adjust EXPECTED_VOTES only after the new
>>node is added successfully. Is that correct?
>
>
> I'd set the proper number of VOTES and EXPECTED_VOTES once you
> decide what they are. In your case 1 each and 3, or 1 per boot
> disk and 2.
>
>
>>I understand that "multiple system disks" means multiple system
>>disks for the same architecture, i.e. 2 alpha system disks, or 3 i64
>>system disks. As I only have a single alpha and a single I64 disk I
>>presume I don't have "multiple system disks". Is that correct?
>
>
> You do have multiple system disks as far as the logical names refered
> to in the above message are concerned. For example, there should
> only be one SYSUAF and all three nodes should have a logical name
> pointing to it, unless it just happens to be findable in sys$system:
> on that node. So if you put it in sys$common:[sysexe] on the disk
> the Alphas share then you only really need to define that on the
> IA64.
>
While what Bob says is correct, but I'm pretty sure it's not your
problem. You'll end up with multiple SYSUAF's, multiple queue databases,
etc., but that's actually legitimate in some cases (non-homogeneous
cluster.) And it won't keep the cluster from forming.
You mention a pagefile on the local disk on the new DS10L. Do you
have local disks on more than one node? If so, you want the allocation
classes to be *different* on each node, unless the "local" disks are
actually on a shared SCSI bus. If you have 2 $1$dka0:'s because
both alphas (or all 3 systems) have a local SCSI disk named DKA0:,
you will have problems, and quite possibly the cluster won't form
or one of the nodes will get booted out as soon as it tries to
access one of the colliding disks.
There are three reasons to have allocation classes: 1) shadowing
requires them, 2) to prevent colliding disk names so you can serve
them to the other systems and 3) to make sure and disks on a shared
SCSI bus have the same name when viewed from any of the systems.
If you have allocation class set to 0, then the local disks on
node HORSE will be called HORSE$DKcnnn:, and the local disks on
node ZEBRA will be ZEBRA$DKcnnn:, which will work fine unless you
want to shadow, or connect two of the local SCSI buses together.
If instead you assign allocation classes to each system, you
want them to be different. I.E. HORSE has 255, ZEBRA has 254,
etc. Then HORSE's local disk names are $255$DKcnnn: and
ZEBRA's disks are $254$DKcnnn:, no collisions in the name
space, and now you can shadow. However, shared SCSI buses
will not work.
To use shared SCSI buses, all the disks on a given bus must
have the same name when viewed from any host on that bus.
So you can either give all the systems the SAME allocation
class (but again break non-shared disks, unless they all
happen to have different controller letters and/or unit
numbers, maybe), or the best solution is to give each bus
a port allocation class that is the same on all systems.
In this case, the bus can be connected to different
controllers on each system, i.e. the "A" bus on one and
the "B" bus on another, since with port allocation classes,
VMS uses a fake device name that is always controller "A".
For example, if the DKBnnn: bus on one system is connected
to the DKCnnn: bus on the other, then if the PKB: controller
on the first system and the PKC: controller on the second
are both assigned port allocation class 3, the disks will
appear as $3$DKAnnn: on both systems. This makes configuring
much more flexible.
SAN disks, such as MSA1000's, always show up as $1$DGAnnnn:,
(always allocation class 1, always device name DG, always
controller "A".) They act kind of like a shared SCSI bus
with port allocation class 1 on all systems. So you don't
have to worry about name collisions there, but you do have
to make sure all the unit id's are different if you have
more than 1 SAN array.
(SAN tapes are always allocation class 2, i.e. $2$MGAnnnn:)
What this all boils down to is you need a set of rules for
preventing name collisions for different devices and ensuring
names are the same for shared devices.
Many people do this by assigning each host a different
allocation class, counting down from 255. Then they
assign each shared SCSI bus a port allocation class, counting
up from 3. (Skipping 1 and 2 used by the MSA1000 or other
SAN arrays.)
Or you could Google back to a fairly recent post where someone
else explained all this, probably much better and including some
edge cases I've forgotten about....
HTH
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
------------------------------
Date: Sat, 08 Sep 2007 05:42:16 -0700
From: ja <JohnDApps@gmail.com>
Subject: Re: SOAP, WSIT, I'm LOST, sort of...
Message-ID: <1189255336.869710.68940@y42g2000hsy.googlegroups.com>
Jan-Erik,
-- gSOAP, which Bob Gezelter mentioned, is probably the way for you to
go as 1) it is a full-blown Web Service implementation offering both
client and server functionality, i.e., VMS acts both as client and
server whereby WSIT only acts as a server; 2) it is written entirely
in 'C', thus fitting nicely into your current environment; 3) it runs
on Alpha and Integrity. It would not be hard at all to integrate it
into OSU or, use the mod_gsoap module for Apache which we have just
finished porting.
-- Windows Servers, or more correctly put, Microsoft, has plenty of
software to make the use of Web Services more or less transparent to
the user and even developer, be it from MS Office, a program, or
whatever.
-- the Java environment offers many ways of processing Web Service
requests
-- as do the 'P' (Perl, Python, PHP) languages
-- the reason there is not support for the OBJ2IDL.EXE utility on
Alpha is, as Bob already pointed out, due to the fact that the format
of an object file on Alpha is not standard and therefore very hard to
use to obtain the interfaces of the compiled program. On Integrity the
format is well documented and it is therefore easy to parse the file
and obtain the interfaces. It should be pointed out that the result of
OBJ2IDL.EXE on Integrity can be used equally well on Alpha
Cheers, John
PS: despite my Martinelli car parked in the HP car park, please feel
free to contact me directly as I do, occasionally, actually try and do
productive work:-)
On Sep 7, 4:43 pm, Jan-Erik S=F6derholm <jan-erik.soderh...@telia.com>
wrote:
> Jeffrey H. Coffield wrote:
> > Jan-Erik S=F6derholm wrote:
>
> >> To add the the picture, this "new" interface is ment
> >> to complement the current that is a simple mail based
> >> communication. The "other side" simply sends a mail
> >> to a specific user, using an agreed on subject with a
> >> datafile ZIP'ed and attachede using standrad MIME format.
> >> On the VMS system ("my" system) this mail is taken care
> >> of using DELIVER/MPACK/MUNPACK/UNZIP and the datafile
> >> is finely FTP'ed over to an IBM mainframe to be stored
> >> into a central DB2 database. The mainframe interface is
> >> not the target right now.
>
> >> Now, some users would like to have an alternative to
> >> this mail based communication. FTP has been discussed.
> >> WEB Services was also mentioned. And that's why I was
> >> asking.
>
> >> OK, I have to dig a little more into this.
> >> As you said, one of the problems with open source
> >> stuff is that it might be hard to find a consistant
> >> set of documentation...
>
> >> Jan-Erik.
>
> > If the "other side" is a person, why not put up a web page with a file
> > upload? If the "other side" is a program, then some change would have to
> > be made since it currently sends a e-mail. That can usually be switched
> > to cURL to do the post. The web page on your side is the same.
>
> > Jeff Coffield
>
> No, the other side are different client application. And they'd
> like to use the latest busniess buzz-words, of course. Whatever
> that looks good in the data sheets. :-) And it should be a fully
> automated setup. No manual intervention in any part.
>
> So, the *BEST* solution for *me*, is one where the client can use
> WEB services (or whatever "new" tools they like) and I can
> continue with the same hardware/VMS/OSU setup.
>
> I do not now what tools there are on Windows servers, but WEB Services
> was mentioned as one that they'd look at as interesting.
>
> Now, I guess I need some XML tool to receive and decode whetever
> the WEB Servicesa/SOAP tools at the client creates, right ?
>
> Jan-Erik.- Hide quoted text -
>
> - Show quoted text -
------------------------------
Date: Sat, 08 Sep 2007 06:49:26 -0700
From: "Tom Linden" <tom@kednos.company>
Subject: Re: SOAP, WSIT, I'm LOST, sort of...
Message-ID: <op.tyb8oowuhv4qyg@murphus.linden>
On Fri, 07 Sep 2007 07:43:39 -0700, Jan-Erik Söderholm
<jan-erik.soderholm@telia.com> wrote:
> Jeffrey H. Coffield wrote:
>> Jan-Erik Söderholm wrote:
>>
>>>
>>> To add the the picture, this "new" interface is ment
>>> to complement the current that is a simple mail based
>>> communication. The "other side" simply sends a mail
>>> to a specific user, using an agreed on subject with a
>>> datafile ZIP'ed and attachede using standrad MIME format.
>>> On the VMS system ("my" system) this mail is taken care
>>> of using DELIVER/MPACK/MUNPACK/UNZIP and the datafile
>>> is finely FTP'ed over to an IBM mainframe to be stored
>>> into a central DB2 database. The mainframe interface is
>>> not the target right now.
>>>
>>> Now, some users would like to have an alternative to
>>> this mail based communication. FTP has been discussed.
>>> WEB Services was also mentioned. And that's why I was
>>> asking.
>>>
>>> OK, I have to dig a little more into this.
>>> As you said, one of the problems with open source
>>> stuff is that it might be hard to find a consistant
>>> set of documentation...
>>>
>>> Jan-Erik.
>>>
>> If the "other side" is a person, why not put up a web page with a file
>> upload? If the "other side" is a program, then some change would have
>> to be made since it currently sends a e-mail. That can usually be
>> switched to cURL to do the post. The web page on your side is the same.
>> Jeff Coffield
>
> No, the other side are different client application. And they'd
> like to use the latest busniess buzz-words, of course. Whatever
> that looks good in the data sheets. :-) And it should be a fully
> automated setup. No manual intervention in any part.
>
> So, the *BEST* solution for *me*, is one where the client can use
> WEB services (or whatever "new" tools they like) and I can
> continue with the same hardware/VMS/OSU setup.
>
> I do not now what tools there are on Windows servers, but WEB Services
> was mentioned as one that they'd look at as interesting.
>
> Now, I guess I need some XML tool to receive and decode whetever
> the WEB Servicesa/SOAP tools at the client creates, right ?
IBM's PL/I compiler has an embedded XML parser both on windows and z
>
> Jan-Erik.
--
PL/I for OpenVMS
www.kednos.com
------------------------------
Date: Sat, 08 Sep 2007 16:35:03 GMT
From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?=
Subject: Re: SOAP, WSIT, I'm LOST, sort of...
Message-ID: <XaAEi.8213$ZA.4316@newsb.telia.net>
ja wrote:
> Jan-Erik,
>
> -- gSOAP, which Bob Gezelter mentioned, is probably the way for you to
> go as 1)...
OK.
Now, is it the sourceforge copy I should get, or is there
some VMS specific distribution ?
Jan-Erik.
------------------------------
Date: Sat, 08 Sep 2007 09:08:11 +0200
From: Dirk Munk <munk@home.nl>
Subject: Re: VMS License Plates
Message-ID: <fbthou$35a$1@news3.zwoll1.ov.home.nl>
Sue wrote:
> Dear Newsgroup,
>
> If you remember we have done VMS License plates over the years. The
> last one we did had "When downtime is NOT an option"
>
> I was thinking about doing them again for our 30th. Let me know what
> you think.
>
> Warm Regards,
> Sue
>
You will love this one:
OpenVMS - so reliable that the newsgroup is always OT
------------------------------
Date: Sat, 08 Sep 2007 13:38:37 +0200
From: "P. Sture" <paul.sture.nospam@hispeed.ch>
Subject: Re: VMS License Plates
Message-ID: <paul.sture.nospam-F8492F.13383708092007@mac.sture.ch>
In article <fbthou$35a$1@news3.zwoll1.ov.home.nl>,
Dirk Munk <munk@home.nl> wrote:
> You will love this one:
>
> OpenVMS - so reliable that the newsgroup is always OT
LOL!
--
Paul Sture
Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~sture/ovms-bookmarks.html
------------------------------
End of INFO-VAX 2007.490
************************