Aloha all, I'm working on some big things using MVSP and I have a need
to either execute a d3 program or call a d3 subroutine from a vb2008
application and have the d3 sub or pgm write to a file. This works
fine when writing to the d3 file system but I need it to write to a
unix file on the server set up as a q-pointer in the md.

When pointed at the q file it throws error B209 "File is update
protected." And, of course, when I run the program from tcl it does
not do that nor does the subroutine if i write a calling program and
call it. It only does that from mvsp called from vb.

Anyone know what's up with this? Do I need to diddle the unix file
permissions? If so how does it know I'm not running the program from
tcl? Is there a setting I've missed in mvsp somewhere?

Thanks,
Terry

Hi Terry,

On 2011-06-10 20:12:00 -0400, terrymaui <terrypen (AT) terrypen (DOT) com> said:

You might save yourself some headaches over the long therm if you did
this "indirectly". By that I mean, set up an application server that
you built/control to handle requests from client applications, such as
your vb2008 program. By creating an app server with a common,
well-defined protocol, such as XML or JSON over HTTP, you open it up to
being able to serve any client that can handle the protocol. Forcing
client applications to connect directly to D3 via MVSP limits possible
clients and is lock-in to MVSP and its associated libraries.

Of course, the above doesn't solve your problem, but, IMO, it's a step
in the right direction for application design.

So, to solve the issue at hand, and considering the suggested above
approach, how would the "app server" communicate with D3 without using
MSVP? You could write a simple message queue, having 1 or more phantom
processes on D3 pick-up and process requests dumped into the queue by
your app server. The queue would be maintained in a native OS
directory, most likely on the D3 server.

Your app server takes requests from client applications, (eg
GET.INVOICE 12345, WRITE.DATA XYZ to file ABC), and dumps that into the
Request queue. The D3 phantom picks up that request does the
processing and dumps the results into a Response queue that your app
server is monitoring. The app server picks up the response/result and
sends it back to the client.

The logic and the programming is actually quite simple. I've done this
myself, and the D3 request processor is less than 75 lines, including
spacing and comments.

Performance is very good. Implemented correctly, phantom poling of the
queue has virtually no impact on CPU or memory, even if you add
multiple phantom "workers" to scale the processing.

I've left out a lot details, but I'm not here to do the work. I just
wanted to give people an idea of what's possible. Using a message
queue approach is easy, reliable/stable, and only has dependancies on
what *you* write/control.

For me, message queuing was born out of years of frustration with
various libraries "breaking" with OS or D3 upgrades. I finally decided
to reduce, as much as possible, the dependencies on things which I do
not control.

--
Kevin Powick

On 06/10/2011 09:56 PM, Kevin Powick wrote:

[snip]

Very sensible. (nods)
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory project website: http://systemstheory.net
find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby
free MP3s of Systems Theory, Mike Dickson & Greg Amov music at
http://mikedickson.org.uk

terrymaui wrote:

I'll preface this with "Off the top of my pointy head..."

Terry, this is a typical permissions issue. The socket process
listening for the inbound MVSP connection is running as a Unix user
which does not have permissions to access the file in question.

To see what user it's running as, insert this into your program:

EXECUTE "!env" CAPTURING OUT

Comment out the code that writes to the OS and write the OUT var to a
D3 file, like MD, then check the item manually. The data contains
environment variables like USER, LOGNAME, HOME, PWD, etc.

Once you see the user under which MVSP is running, it should be
evident why it can't write to that file. You can either change the
user of that process (check with TL on that) or you can change access
permissions to the file from TCL:

!chmod 666 /path/to/myOSfile

After you do that, everyone has write access, and your MVSP operation
should work.

HTH

No joy - changed the file permissions to '666' after geting the 'env'
output which looks like this:
LC_MONETARY=en_US
SELINUX_INIT=YES
CONSOLE=/dev/console
TERM=linux
LC_NUMERIC=en_US
PICKUPASS=AMUVTSOP
LC_ALL=en_US
PICKVM=pick0
INIT_VERSION=sysvinit-2.86
REMOTE_HOST=192.168.48.95
PATH=/sbin:/usr/sbin:/bin:/usr/bin
LC_MESSAGES=en_US
_=/bin/env
RUNLEVEL=3
runlevel=3
LC_COLLATE=en_US
PWD=/home/pick
PICKUSER=MVSP
LANG=en_US
PREVLEVEL=N
previous=N
SHLVL=5
PICKMD=MVSP
LC_TIME=en_US

Same error but it sure would seem like permissions since I can write a
d3 item but not to the underlying file system so dunno
Mahalo for the help though.
Terry


On Jun 10, 9:13*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:

Hmmm, my bad. Try changing the permissions of the directory
containing the file to 666. I'm guessing that D3 is failing to open
the file=directory for write access.

Just to verify then:

You should have have a Linux directory with permissions 666 which can
be updated accessed through D3 via OSFI.

You should also be able to login to Linux as user MVSP (time to change
your password BTW) and update any file in that directory.

If that is not the case, fix that problem.

If writing is successful, you should be able to write via MVSP.

If that is not the case, time to contact TL.

HTH