you
can have multiple address spaces with the same name, just not multiple
batch jobs.
gt
A little more ni-picking here. There is no one-to-one equivalency
between a unix process and an MVS task. In truth, a process (with
threads) is closer to a hybrid combination of an MVS address space and
subasks:
1. A unix process is
protected from other processes with paging, as is an MVS address space from
other address spaces (althought MVS also uses segmentation).
2. But, unlike processes, only a single instance of an
MVS address space with a given name is allowed to run, whereas there is no
such restriction with unix processes (which makes it very to similar to OS
subtasks in this respect).
3. OS
subtasks are not protected from other subtasks in the same address space.
(I assume) unix threads have the same exposure.
Roger Lacroix
<[EMAIL PROTECTED]>
Sent by: MQSeries List
<[email protected]>
04/25/2005 01:23 PM
|
|
Hi,
Well, since I spent many of my 'junior programming
years' doing
assembler (MVS)
for a bank, I will too nit-pick about a
comment:
>> 390 does have an equivalent concept - the TASK,
multiple of which
>> can run in the same address space.
I
would compare a z/OS (OS/390) TASK to a Unix process rather than a
Unix
thread.
And yes, USS POSIX threading model does make
cross-platform coding much
easier.
Again, except for
Windows!!
Regards,
Roger Lacroix
Capitalware
Inc.
http://www.capitalware.biz
Quoting "David C. Partridge"
<[EMAIL PROTECTED]>:
> Roger,
>
> You
said:
>
>> And some OSes don't have threading at all (i.e.
OS/390).
>
> Well just to be nit-picky, 390 does have an
equivalent concept - the TASK,
> multiple of which can run in the same
address space. What's more Unix
> Systems Services overlays
threads on top of that (either one/one or
> many/one).
>
>
The CHIN (as far as I understand) runs multiple TASKs and then runs
multiple
> channels under each TASK (whether it uses USS threads of the
many/one sort
> or uses its own cooperative dispatcher I don't
know).
>
> Other than that I agree entirely with your
remarks
>
> Dave
> -----Original Message-----
> From:
MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of
>
Roger Lacroix
> Sent: 25 April 2005 17:03
> To:
[email protected]
> Subject: Re: New version of
BlockIP2 released.. 2.20 Beta
>
> All,
>
> First off,
make sure you compile AND link with threading model turned on.
>
>
Second, parallel and thread programming are the two toughest concepts to
get
> right when programming. Make sure you do not use any global
variables.
> Allocate the memory you need and use semaphores when
accessing it.
> Programming
> an MQ exit involves both concepts,
so it is not for the faint of heart!!
>
> Third, all operating
systems are different even the Unixes (except Solaris
> &
Linux are very similar). Therefore, you cannot test it on one OS and
>
expect it to work on anothers. And don't get me started about how
bad
> Windows is (even Win2000). And some OSes don't have
threading at all (i.e.
> OS/390).
>
> Fourth, make sure you
use all appropriate threaded C functions and not the
> standard C
functions. i.e. use localtime_r and not localtime,
etc...
>
> Most people think that parallel programming is like
cars on a highway. The
> highway being the code and the cars are
threads. But it is not so simple.
> The highway part is correct
but the cars are transparent. What I mean is
> that
>
2,3,4,5 cars can overlap or exactly occupy the same spot on the
highway.
> The MQ exit may have 2,3,4,5 connections all invoked at the
same time, all
> occurrences updating the same variables at the same
time.
>
> Lastly, just to knit pick, you cannot say 'ready for WMQ
v6' when WMQ v6
> will not be available for a couple of months.
You can say 'successfully
> tested with WMQ v6 beta'. IBM
could change the code between the beta and
> the GA release.
>
Mostly likely IBM won't change the code but they could. Hence, you
should
> always be careful making global
statements.
>
>
> Regards,
> Roger Lacroix
>
Capitalware Inc.
> http://www.capitalware.biz
>
>
>
Quoting [EMAIL PROTECTED]:
>
>> Jorgen (et. al.),
,
>>
>> I'm having a problem when I have multiple
connections trying to be
>> established simultaneously (on Solaris).
What I am seeing appears to
>> be the inability of the exit
code to be driven concurrently by more
>> than 1 channel connection.
What compile options should I be using to
>> allow this exit to
be (using a mainframe term here) 'reentrant' ???
>>
>>
Thanks in advance,
>> Art
>>
>> Arthur C.
Schanz
>> Operating Systems Programmer I. - Specialist Federal
Reserve
>> Information Technology Messaging Middleware IBM Certified
System
>> Administrator - WebSphere MQ V5.3 IBM Certified Solution
Designer -
>> WebSphere MQ V5.3
>> (804)
697-3889
>>
[EMAIL PROTECTED]
>>
>>
>>
>>
>>
>>
J�rgen Pedersen <[EMAIL PROTECTED]>
>> Sent by: MQSeries List
<[email protected]>
>> 04/24/2005 04:54
PM
>> Please respond to MQSeries
List
>>
>>
>> To:
[email protected]
>>
cc:
>> Subject:
New version of BlockIP2 released.. 2.20
Beta
>>
>> Hi all,
>>
>> New version of
BlockIP2 version 2.20 Beta is ready for download. ;o)
>>
>>
Highlights: This version is ready for WebSphere MQ version 6.0 and
got
>> functions to control the number of connections on SVRCONN.
This
>> function was requested by many over time, so now it's ready.
Give it a
>> try. ;o) This version is currently not shipped for z/OS
Yet, there are
>> some testing I need to do
first.
>>
>> Here is the direct link:
>>
http://mrmq.dk/index.htm?BlockIP2.htm#Version_2.20_enhancement
>>
>>
I hope that you find it as usefull as before including the new
features.
>>
>> Just my $0.02 :o)
>>
>>
Kind regards
>>
>> J�rgen
>>
>>
www.mrmq.dk
>> the author of BlockIP
>>
>>
_________________________________________________________________
>>
F� alle de nye og sjove ikoner med MSN Messenger
>>
http://messenger.msn.dk/
>>
>> Instructions for managing
your mailing list subscription are provided
>> in the Listserv
General Users Guide available at http://www.lsoft.com
>> Archive:
http://listserv.meduniwien.ac.at/archives/mqser-l.html
>>
>>
>>
>>
Instructions for managing your mailing list subscription are
provided
>> in the Listserv General Users Guide available at
http://www.lsoft.com
>> Archive:
http://listserv.meduniwien.ac.at/archives/mqser-l.html
>>
>
>
Instructions for managing your mailing list subscription are provided in
the
> Listserv General Users Guide available at
http://www.lsoft.com
> Archive:
http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
>
Instructions for managing your mailing list subscription are provided
in
> the Listserv General Users Guide available at
http://www.lsoft.com
> Archive:
http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
Instructions
for managing your mailing list subscription are provided in
the Listserv
General Users Guide available at http://www.lsoft.com
Archive:
http://listserv.meduniwien.ac.at/archives/mqser-l.html
Instructions
for managing your mailing list subscription are provided in the Listserv
General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
