Re: Large Messages and # of Buffers - z/OS

[Richard Tsujimoto]

I've always been intrigued what sort of apps actually create such large
messages.  Personally, I always felt MQ was designed to promote
transactional processing and for distributing informational (non-persistent,
pub-sub) messages. But, as with any product, users always find new ways to
use it in ways the designer never invisioned.  That's usually a good thing.
But, at some point when you have to configure your resources for (what I
assume) is the exception, rather than the rule, then I think it's time to
consider other means for moving the data.  It's a trade-off of time, effort
and the impact to your resources.  If you allocate huge buffers, you may
impact other subsystems that have an on-going need for memory, e.g. CICS,
IMS, DB2 and so forth.
- Original Message -
From: "Criscione, Carol (DIS)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 25, 2004 12:02 PM
Subject: Large Messages and # of Buffers - z/OS


> We have large messages ranging from 1-100Meg.  I think my number of
buffers
> is too low.  What does anyone suggest for # of buffers, especially for a
> 100Meg message?
>
> Also, do you recommend increasing the region size if I substantially
> increase the number of buffers?  If so, best guess on how much?
>
> ThanX!
> Carol Criscione
> [EMAIL PROTECTED]
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: off-topic question - exclusive file control

[Richard Tsujimoto]

Roger,

It doesn't lock the file.  I tried it.

- Original Message -
From: "Roger Lacroix" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 16, 2004 6:38 PM
Subject: Re: off-topic question - exclusive file control


> Hi,
>
> I haven't tried this but you could open it for update.  i.e. "w" or "w+"
Hence
> the file should be locked (Again I haven't tried this.).
>
> Regards,
> Roger Lacroix
> Capitalware Inc.
> http://www.capitalware.biz
>
>
> Quoting Rick Tsujimoto <[EMAIL PROTECTED]>:
>
> > Is there a way to obtain a file lock using fopen (vs. open)?  I know
that
> > you can use lockf and fcntl, but I would like to use fopen.
> >
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQDISC error on VB application

[Richard Tsujimoto]

Hmmm.  The VB apps here run as server-side apps, not clients.  I wonder if
it problem is with VB clients?

- Original Message -
From: "Dennis Bryngelson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 5:16 PM
Subject: MQDISC error on VB application


> I have a VB app that does an MQCONN, MQOPEN, and MQCLOSE just fine.   But
> on the MQDISC it errors.  I am running MQ V5.3 and the app is getting to
MQ
> via  MQ client (also V5.3).   Is there a support pac out there for this
> problem 
>
>
> Thanks,
> Dennis Bryngelson
> Phone: (763) 765-4224
> Fax: (763)  765-3820
> mailto:[EMAIL PROTECTED]
>
>
>
>
> *
> PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary, confidential
and/or privileged information.  If you are not the intended recipient, any
use, copying, disclosure, dissemination or distribution is strictly
prohibited.  If you are not the intended recipient, please notify the sender
immediately by return e-mail, delete this communication and destroy all
copies.
> *
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: A little advice before I sign off for a while :-) - non-MQ related or not

[Richard Tsujimoto]

sound advice...good luck

- Original Message -
From: "Fryett.Chris" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 03, 2003 6:01 PM
Subject: A little advice before I sign off for a while :-) - non-MQ related
or not


There is a time in life when it is O.K. to move fast as long as you
have someone else looking at the signs going by
You never know if one of those signs give you the proper direction
to your destination or not
There is also a time in life when it is O.K. to move in the opposite
direction than everyone else; as long as you understand the risks
You never know if that direction will lead you to nowhere or right
back where you started.
There is also a time in life when it is O.K. to move slow as long as
you are willing to be behind everyone else
You never know if taking things slowly will make you obsolete, so
keep your eyes and ears open at all times.
Lastly, a team is constructed of two or more people of all skills,
personalities, and vision.
When an individual of that team fails, everyone fails.
When an individual of that team succeeds, everyone succeeds.

- Christopher Dean Fryett -





*
The information transmitted is intended solely for the individual or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of or
taking action in reliance upon this information by persons or entities other
than the intended recipient is prohibited. If you have received this email
in error please contact the sender and delete the material from any
computer.

*

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Carry over the network userid and password

[Richard Tsujimoto]

LU6.2 allows you to validate a userid and password using an ESM, e.g. RACF.
AFAIK, TCP does not support this.

- Original Message -
From: "Middleware Group Mailbox" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 30, 2003 5:21 PM
Subject: Carry over the network userid and password


> Hi,
>
> Can someone tell me if MQ5.3 is able to carry over the network (from AIX
to
> Z/OS) the userid as well as the password when TCP is used as the transport
> type? I do not want to use the CICS bridge. The application on z/os will
be
> written in COBL/MQ/CICS and on the AIX platform in the C language.
>
> Thanks,
> Mohamed.
>
> ===
> This email/fax message is for the sole use of the intended recipients(s)
and
> may contain confidential and privileged information.  Any unauthorized
> review, use, disclosure or distribution of this email/fax is prohibited.
If
> you are not the intended recipient, please contact the sender by email/fax
> and destroy all paper and electronic copies of the original message.
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries5.2 Performance on UNIX (persistent msgs) - facts and hints

[Richard Tsujimoto]

Volker,
 
There are two things you may want to take into 
account.  1.  Does your test include the overhead associated with a 
channel connection?  2. Does your test include the overhead for a process 
startup?  The former can be substantial and could skew your results, 
especially if your test load is small, e.g. 100 messages.
 

  - Original Message - 
  From: 
  Volker 
  Kaemmerer 
  To: [EMAIL PROTECTED] 
  Sent: Monday, January 13, 2003 5:59 
  AM
  Subject: MQSeries5.2 Performance on UNIX 
  (persistent msgs) - facts and hints
  Hi, came across some IBM documentation with 1200 
  msg/sec (persistent, 1KB, Fast-Binding) or e.g. "P6D: MQSeries for AIX V5.2 - Performance 
  highlights"  with up to 300 msgs/sec, (persistent, 1-2kB) processed by 
  MQSeries V5.2 on AIX UNIX 
  servers. We currently using a 
  single-process, single-threaded server application for MQPuts/Gets on one 
  queue manager with MQSeries V5.2 
  on one UNIX AIX 4.3.3 server. The 
  application can also be running in multiple processes and/or threads accessing 
  the same queue for MQGets and same queue for MQPuts. We 
  identified the performance optimum between 2-3 process or threads and 
  identified the Disk-IO being the performance limiting factor to approx. 45 msgs/sec (persistent, 
  <1KB) in our infrastructure. This Disk-IO is on the /var/mqm/qmgrs 
  filesystem, which is the only one 
  on this disk. This is far away from the IBM values for a single queue manager, 
  single server environment. What 
  can we do? We would be 
  interested to get some ideas of what kind of persistent throughputs are 
  achieved in your production live environment under UNIX (preferred AIX) and MQSeries V5.2 by 
  which type of hardware (disks) and MQSeries application 
  topology&architecture. What 
  kind of tuning on UNIX-Kernel, Disks, MQSeries and your application have 
  improved your performance considerably? What can you recommend or not recommend? Would be pleased to received some feedback 
  here. Thanks and best 
  regards,       
    Volker Kaemmerer --- Volker Kaemmerer           
                        
                        
            AMADEUS Data Processing GmbH  
                        
                        
                        
                        
               Communication Gateway   
                        
                 Phone:   
   +49-8122-43-4225                 
                        
             OSC - Open Systems Communication 
  Development                   
                        
                        
               FAX:       
    +49-8122-43-3260               
                        
               Berghamer Strasse 6 
    Email:      [EMAIL PROTECTED]   
                        
     D-85435 Erding, Germany

Re: Help - Pgm abended, msg stuck in the q OS390

[Richard Tsujimoto]

You can set the trigger attribute for the queue on manually.

- Original Message -
From: "JoE JK" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 24, 2002 4:29 AM
Subject: Help - Pgm abended, msg stuck in the q OS390


> Hi,
>
> I have one case where our application pgm is abended
> and somehow the message is stuck back to the queue.
> The problem is the queue is full with other messages
> coming and the triggering is somehow stop due to the
> earlier abend. Interim solution, we recylce the region
> and it solved the problem but if it going to happen
> again, how can I fix this problem? We can't recyle the
> region just like that...
>
> Thanks for any input.
>
> Joe
>
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Signalling

[Richard Tsujimoto]

Title: Signalling



I noticed that you set the MQGMO-WAIT option just 
prior to the second call MQGET, but didn't do so for the first call to 
MQBGET.  The following excerpt from the Programmer's Ref. manual may be 
helpful:
 
On OS/390, the following points apply:-If it is 
desirable for the application to proceed with other work while waiting for the 
message to arrive, consider using the signal option (MQGMO_SET_SIGNAL) instead. 
However the signal option is environment specific, and so should not be used by 
applications which are intended to be portable between different 
environments.-If there is more than one MQGET call waiting for the same 
message, with a mixture of wait and signal options, each waiting call is 
considered equally. It is an error to specify MQGMO_SET_SIGNAL with MQGMO_WAIT. 
It is also an error to specify this option with a queue handle for which a 
signal is outstanding.
 
I also noticed that you didn't wait on the ecb 
after the second call to MQBGET.

  - Original Message - 
  From: 
  Voges, P. 
  (Pieter) 
  To: [EMAIL PROTECTED] 
  Sent: Friday, November 29, 2002 6:10 
  AM
  Subject: Signalling
  
  Please help. 
  I have started getting intermittent 
  2069 errors for the first time after more than 5 years in production. We have 
  attempted to recompile and link with the 5.2 libraries but continue to get 
  this error.
  Currently I am in a LOOP (in a CICS 
  long running task (don't ask) ) processing a MQ,Q 
  
Copy the default values for the 
mqmd and mqgmo structures 
Move 
mqgmo-set-signal   to mqgmo-options 
add mqgmo-no-syncpoint to 
mqgmo-options 
move 
mqwi-unlimited   to mqgmo-waitinterval 

set the ECB to zero. 
setup mqgmo-signal1 with ECB 
address 
call 
MQGET  
    
    
    
    
     //First GET (with Signal) 
if  return-code = 0 
    Go 
Exit. 
//Ok lets process it. 
if  NOT WARNING OR not 
mqrc-signal-request-accepted   //Inform the Bridge and 
ABEND 
CICS WAIT EXTERNAL on the 
SINGLE ECB. 
evaluate 
ecb  

    when 
mqec-msg-arrived   
continue   
    when 
mqec-wait-interval-expired   go e-401m-no-msg   
    when 
other    
go e-401o-ecb-error 
end-evaluate 

Copy the default values for the 
mqmd and mqgmo structures 
move mqgmo-no-syncpoint to 
mqgmo-options 
add 
mqgmo-wait   
to mqgmo-options 
move 
mqwi-unlimited  to 
mqgmo-waitinterval 
call 
MQGET  
    
    
    
    
     //Second Get (after wait). 
if  return-code not = 
0    

    if  
reason = mqrc-no-msg-available 
    go 
e-401m-no-msg 

    
else 

    go 
e-401n-mq-failed  

    
end-if   

end-if   

go exit 
    
    
    
    
    
    // Ok Lets Process it. 

  MY QUESTION. How do I handle the 2069. DO I 
  
1) Only reset the ECB after the 
WAIT EXTERNAL 

  This will allow the WAIT 
  EXTERNAL to Return as soon as anything is posted to the ECB address even 
  if the First MQ get returned a 0(ok) reply?
2) Only set the mqgmo-set-signal 
when I get a  mqrc-signal-request-accepted again even if the previous get was 
successful.
3) Process the 2069 as I do the 
signal-request-accepted ie just drop into the wait external 4) Drop the wait option on the second 
get. 5) Combine 1 & 
3 6) Combine 1 & 3 
& 4 and expect the 2nd MQGET (after the wait external) to return NO 
MSG. 
  5 is my gut feel for this fix. 
  6 may be the solution 
  depending on how or why this MQRC-SIGNAL-OUTSTANDING  is being 
  returned. 
  If anyone as a solution of has a 
  flow chart of how these return codes get set, it would be most 
  appreciated 
  Thanks 
  André de 
  JagerIT OPS SA: S&M Retail and 
  Corporatecell 083 326 5243 
  ( 27(21) 488 8235 Speed 60888* 
  [EMAIL PROTECTED] 
  
 -Original 
Message- From:   
Voges, P. (Pieter)  Sent:   29 
November 2002 05:25 To: De 
Jager, A. (Andre); Ramjee, P. (Piyoosh); Strydom, G. (Gerard) 
Cc: CICS Subject:    RE: nxxpbtoz on prod. 
Please let me know how it is doing 
as soon as you have some info. 
Thank you Pieter 
VogesMQ SupportNedcor Bank LimitedTel: (011) 881 4410Sel: 083 6455 
300E-mail: [EMAIL PROTECTED]  


   

Re: How to know the channel stopped

[Richard Tsujimoto]

If the channel stops frequently, I think you should find out why this is
happening.  This is not normal.  It sounds like your network is not as sound
as it should be.

- Original Message -
From: < $B#t#a#g#u#t#i  (B <[EMAIL PROTECTED]>)>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 28, 2002 9:11 PM
Subject: How to know the channel stopped


> Hello,
>
> I've made several applications using MQ for a few years,
> not knowing much about MQ.
> I noitced that most frequently happening trouble is the
> unpredictable channel stopping.
> I made rather online applications requiring high-responce.
>
> I made a program checking channels every minutes by runmqsc "dis chs"
> in Perl. (Perl is my favourite)
> This program sends e-mail to administrators or try "start channel".
>
> But this has some inferiorities.
> 1) The applications doing "MQPUT" have no idea if the channel is stopped.
>"MQPUT" doesn't return the error.
> 2) I'm sometimes asked to introduce my checking program, but the
>new computor doesn't always have perl installed.
>
> I like to know if there is a good way for application programs
> to know if concerned chanels are stopped or running.
> The most favourite way may be reason code 2??? meaning the stop,
> maybe impossible as a usual MQ system.
> Another imaginable way is to force application programs to ask the
> watching program if OK, but this must be some re-programming of
> current applications.
>
> So what is the good solution? Any good idea?
>
> Regards,
> Hirosi Taguti
> [EMAIL PROTECTED]
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Trigger problem

[Richard Tsujimoto]

I think V5.2 under Windows sets up a trigger monitor for you when you create
your queue manager via the GUI.  If you remove one of the trigger monitors,
it should be ok.

- Original Message -
From: "Anderson, Lizette T. (RyTull)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 15, 2002 11:13 AM
Subject: Trigger problem


> I am having problems triggering a program on a Windows 2000 server.  The
> triggering works fine with the runmqtrm command from the command line, but
> when I set the trigger monitor up using MQservices, it does not trigger.
I
> already have one(successfully running trigger monitor) setup under
services,
> so the new monitor is showing up as TRIGGER MONITOR(2).  Any ideas?  We
only
> have two programs that need to be triggered on the server.  We are running
> MQ 5.2.
>
>
> --- Legal Disclaimer: The information contained in this communication may
be
> confidential, is intended only for the use of the recipient named above,
and
> may be legally privileged.  If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution, or copying of this communication, or any of its contents, is
> strictly prohibited.  If you have received this communication in error,
> please re-send this communication to the sender and delete the original
> message and any copy of it from your computer system. Thank you. ---
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Backing up a running Queue Manager

[Richard Tsujimoto]

I disagree.  Take a disaster, e.g. data center goes up in flames in the
middle of processing messages that represent money.  What do you tell
management, "oh these message should have been transient".  I happened to
work on the disaster recovery plan for MQ at JPM Chase for the mainframes.
The plan allows for a recovery from a point in time, and the logs that went
off-site are used to roll-forward the messages.  The exposure is the tapes
that didn't make it off-site.

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 31, 2002 6:08 PM
Subject: Backing up a running Queue Manager


> I don't see any real need to back up a running queue manager.  Messaging
> implies transience, by the time you back up the queues and its logs, the
> messages ought be consumed.  If, on the other hand, messages are not
> transient, then you may want to consider a database instead.
>
> Of course, backing up a queue managers configuration is a totally
different
> issue.  Using Saveqmgr to backup MQ object definitions and ms63/ms65/ms68
> to backup the OAM authorities should be considered.
>
>
>
>
> |-+--->
> | |   |
> | |   [EMAIL PROTECTED]|
> | |   om  |
> | |   Sent by:|
> | |   MQSERIES@akh-wie|
> | |   n.ac.at |
> | |   |
> | |   |
> | |   10/31/2002 05:13|
> | |   PM  |
> | |   Please respond  |
> | |   to jgoode   |
> | |   |
> |-+--->
>
>---
-|
>   |
 |
>   |To:  [EMAIL PROTECTED]
|
>   |cc:
|
>   |Subject: Re: Backing up a running Queue Manager
|
>
>---
-|
>
>
>
> I'm interested in this as well. Currently we shutdown our Qmgrs... then do
> our backup. We use Tivoli Storage Manager (TSM) for many of our backup
> processes. I understand there is a TSM agent for DB2 that allows you to
> back
> up Databases while they're running.  We hope to use that for our WMQI DB2
> databases . I'm in the process of trying to find out if there is / will be
> a
> TSM agent for WMQ.  That would be way cool. - jesse
>
> - Original Message -
> From: "John Scott" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, October 31, 2002 1:12 PM
> Subject: Backing up a running Queue Manager
>
>
> > All the manuals/redbooks etc seem to state that the queue manager needs
> to
> > be stopped before it can be backed up. This doesn't seem ideal if you
are
> > trying to run an application permanently.
> >
> > Can anybody suggest ways of backing up a running Queue Manager.
> >
> > Has anybody ever tried/succeeded in doing this kind of thing with
> MQSeries
> > (even using special "add-on" tools from another vendor...)
> >
> > Regards
> > John Scott
> > Senior Middleware Technical Specialist
> > Argos Ltd
> >
> >
> >
> > **
> >
> > Click here to visit the Argos home page http://argos.co.uk
> >
> > The information contained in this message or any of its attachments may
> be
> privileged and confidential, and is intended exclusively for the
addressee.
> > The views expressed may not be official policy, but the personal views
of
> the originator.
> > If you are not the intended addressee, any disclosure, reproduction,
> distribution, dissemination or use of this communication is not
authorised.
> > If you have received this message in error, please advise the sender by
> using your reply facility in youe e-mail software.
> > All messages sent and received by Argos Ltd are monitored for virus,
high
> risk file extensions, and inappropriate content. As a result users should
> be
> aware that mail maybe accessed.
> >
> > **
> >
> > Instructions for managing your mailing list subscription are provided in
> > the Listserv General Users Guide available at http://www.lsoft.com
> > Archive: http://vm.akh-wien.ac.at/MQSeries.archive
> >
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>
>
>
> This communication is for informational purposes only.  It is not intended
as
> an offer or solicitation for the purchase or sale of any financial
instrument
> or as an official confirmation of any transaction. All market prices, data
> and other information are not warranted as t

Re: ever growing FDC file

[Richard Tsujimoto]

Take a look at APAR IY28451

- Original Message -
From: "Donald Skidmore" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, October 19, 2002 2:35 PM
Subject: ever growing FDC file


> We have a production Win2000 server that constantly gets the same error.
> It doesn't seem to be affecting mq operation but it is filling up the
> Windows event log with thousands of entries every day and appending to
> an FDC file that grows to over a gig in less than a month. Here is the
> entry it keeps putting in:
>
+---
--+
> |
> |
> | MQSeries First Failure Symptom
> Report   |
> |
> =
> |
> |
> |
> | Date/Time :- Fri October 18 09:06:30 Central Daylight Time
> 2002 |
> | Host Name :- USBCHITRANS01 (NT Version 5.0 Build 2195: Service
> Pack |
> |
> 2)
|
> | PIDS  :-
> 5639B43|
> | LVLS  :-
> 521|
> | Product Long Name :- MQSeries for Windows NT and Windows
> 2000   |
> | Vendor:-
> IBM|
> | Probe Id  :-
> PC057000   |
> | Application Name  :-
> MQM|
> | Component :-
> pcmInquireChannelExits |
> | Build Date:- Jan 17
> 2002|
> | CMVC level:-
> p521-CSD03H|
> | Build Type:- IKAP -
> (Production)|
> | UserID:-
> MUSR_MQADMIN   |
> | Process Name  :-
> D:\MQSeries\bin\AMQPCSEA.EXE   |
> | Process   :-
> 0624   |
> | Thread:-
> 1872   |
> | QueueManager  :-
> BFSDMQ1P   |
> | Major Errorcode   :-
> OK |
> | Minor Errorcode   :-
> OK |
> | Probe Type:-
> INCORROUT  |
> | Probe Severity:-
> 4  |
> | Probe Description :- AMQ6125: An internal MQSeries error has
> occurred.  |
> |
> |
>
+---
--+
>  Further down I see this entry:
>
> Invalid Exit List
> 0057EA10 0101643A..d:
> 0057EA20   5C6D  \m
>
> Now it seems it is complaining about a channel exit but there is no
> channel exit defined. In fact there are no channel exits on this box.
> Does anyone know of a fix for this? Or is my only option to rebuild the
> queue manager?
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: multiple listeners

[Richard Tsujimoto]

Fred,

I'm not aware that you could actually run another listener on Z/OS.  But,
assuming you could, I would attribute the similar throughput results to your
test environment.  Using the same LPAR for 2 qmgrs in a throughput test
eliminates the biggest factor in a messaging test, namely the network
itself.  Your test is too close to being a loopback test.

- Original Message -
From: "Fred Oddo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 10, 2002 11:48 AM
Subject: multiple listeners


> Is anyone using multiple channel listeners ?
> In a Z/OS environment, using 2 queue managers on the same LPAR
> I sent 10,000 messages over each of 6 channels from one queue
> manager to another using one listener.  Then did the same have
> 10,000 over each of three channels using one listener and three
> other channels using a second listener. The throughput was the same.
> What is the purpose of being able to start more the one listener in the
> same queue manager?  I thought it would havesome impact on throughput.
>
> Thanks,
> Fred.
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Web Site

[Richard Tsujimoto]

Bruce,
 
Dude.  Sounds like you actually got an 
education and missed out partying.
 

  - Original Message - 
  From: 
  Bruce Olsen 
  
  To: [EMAIL PROTECTED] 
  Sent: Tuesday, October 08, 2002 1:16 
  PM
  Subject: Web Site
  
  During a consulting engagement several years ago, a colleague 
  and I spent a significant amount of time locating vendors of middleware 
  products. In the hopes that I could reduce the burden for others, I have 
  assembled the results of that product research and established a web site to 
  make the information available. I have augmented it from time to time and 
  hopefully it is reasonably up to date.I call it the Message Oriented 
  Middleware Resource Center. It can be accessed at http://www.middleware.org.Many of the products in 
  the vendor list pages work well with MQSeries. I'm sure many of you are 
  looking for such products, which fall into several categories, including 
  interface engines, system management tools, etc.Please feel free to 
  click over that way. If you have suggestions how the site could be made more 
  useful, including any resource I should know about, there are provisions to 
  provide feedback from within the site.I hope you find it 
  useful.===Bruce OlsenEmail: 
  [EMAIL PROTECTED]Web: http://www.middleware.orgPhone/FAX: (309) 
  213-1726 

Re: Question on Queue management - OS390

[Richard Tsujimoto]

you can compile one of the sample programs that will print the messages in
the queue.  then you can look at the reason code which indicates why the
message landed there.

don't recall the program name, but it's discussed in the MQ programming
guide.

- Original Message -
From: "Daniel McKinzie" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 27, 2002 6:17 PM
Subject: Question on Queue management - OS390


> I am new to the management of MQ so this may be one of the RTFM type
> questions.  Is there a command or process to view the messages in the
> dead letter queue?  To determine who or what is sending them.  Because
> the dead letter queue continues to fill up.
>
> Thanks
> Dan

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Codeset with no supporting CCSID

[Richard Tsujimoto]

Derek,

Don't know if this will help, but below is a snippet of an old posting:

To: [EMAIL PROTECTED]
cc:  (bcc: Richard Tsujimoto/CHASE)
From: Paul Clarke <[EMAIL PROTECTED]>
Date: 06/04/99 08:37:29 AM GMT
Subject: Re: V5/5.1 NT client to V5 CSD 5 AIX server problem



Scott,

The data conversion from clients is always done at the server. So, it would
seem that this AIX box
can not do  819 <-> 437 conversion. I seem to remember that AIX does not
(or did not) ship with the
437 codepage tables and you had to manually add them to the NLS directory.
I believe we even
shipped the 437 table with the MQSeries product.

You can check out whether the conversion is supported using the command :-

iconv -t IBM-819 -f IBM-437

If this complains that it can't find the conversion table then you'll have
to install it.
I'm saying all this from memory so I may be slightly out in some of the
details.

Paul G Clarke
MQSeries Development
IBM Hursley

- Original Message -
From: "Hornby, Derek" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 22, 2002 12:11 PM
Subject: Codeset with no supporting CCSID


> ... I hope this isn't too daft a question, but I am getting the following
message in /var/mqm/errors (accompanied by an FDC)on MQ5.2 over Solaris 2.8
>
> AMQ6173: No CCSID found for codeset ISO8859-1.
>
> Codeset ISO8859-1. has no supported CCSID. Check that the locale in use is
> supported. CCSIDs can be added by updating the file
> /var/mqm/conv/table/ccsid.tbl.
> None.
>
> ... but this error has only just started occurring, is intermittent, and I
don't think much has changed on this server in the last 6 months.
>
> ...and, of course, ISO8859-1 is the standard code page 819 , which is
definitely in the ccsid.tbl
>
> ... the env values look OK to me...
>
> LC_MONETARY=en_US.ISO8859-1
> LC_TIME=en_US.ISO8859-1
> LC_MESSAGES=C
> LC_CTYPE=en_US.ISO8859-1
> LC_COLLATE=en_US.ISO8859-1
> LC_NUMERIC=en_US.ISO8859-1
>
> ... and so does the locale
>
> LANG=
> LC_CTYPE=en_US.ISO8859-1
> LC_NUMERIC=en_US.ISO8859-1
> LC_TIME=en_US.ISO8859-1
> LC_COLLATE=en_US.ISO8859-1
> LC_MONETARY=en_US.ISO8859-1
> LC_MESSAGES=C
> LC_ALL=
>
> ... I am a little puzzled.
>
> Derek.
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: retrieve order

[Richard Tsujimoto]

Stefan,

The original poster made that claim, not me.  As far as what you're position
is, I concur.  The network is not a factor.  The messages will get there as
sent.  As for MQ, it depends on whether or not the stated conditions are met
or not.

- Original Message -
From: "Stefan Sievert" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 19, 2002 7:07 PM
Subject: Re: retrieve order


> Rick,
> I don't know if I have put together all the pieces of this thread
correctly,
> but my idea after that (and before that) is still that the physical
network
> is no constraint at all. I look at it from the MCA perspective: the
sending
> MCA doesn't even send message 2 if the receiver has received message 1. If
> the receiver sees message 3 before message 2, it will throw up and produce
> message AMQ9526 Message sequence number error for channel '&3'.
> So how would you be able to get out of sequence messages in your receiving
> application caused by the physical network layout?
> Stefan
>
>
> >From: Rick Tsujimoto <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: retrieve order
> >Date: Thu, 19 Sep 2002 12:58:12 -0400
> >
> >The issue is does IBM need to update their doc?  It makes no mention of
the
> >physical network as a constraint in order to retrieve messages
> >sequentially.
> >
> >
> >
> >
> >   RIBEIRO Paulo
> >   JorgeTo:
> >[EMAIL PROTECTED]
> >>   R.PT>Subject: Re: retrieve
order
> >   Sent by:
> >   MQSeries List
> >>   en.AC.AT>
> >
> >
> >   09/19/2002 12:31
> >   PM
> >   Please respond
> >   to MQSeries List
> >
> >
> >
> >
> >
> >Please don't forget that TCP/IP networks are based on dynamic paths. If
you
> >send msg-1,2,3, the message 1 and 3 can arrive in 10 seconds, and message
2
> >can take 10 hours to arrive. It is obvious that if MQ receives the
message
> >3
> >before message 2, it will make it available. For the specific problems
> >where
> >you must assure the receiving order, MQ offers the grouping feature.
> >Therefore, you have both options available.
> >
> >
> >Paulo
> >
> >
> >
> >-Original Message-
> >From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]]
> >Sent: 19 September 2002 17:24
> >To: [EMAIL PROTECTED]
> >Subject: Re: retrieve order
> >
> >
> >Not if they don't take the same path -- Rebecca
> >
> >-Original Message-
> >From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]]
> >Sent: Thursday, September 19, 2002 12:09 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: retrieve order
> >
> >
> >Brian,
> >
> >If the user sends msg-1, 2, 3 and gets 1, 3, 2 doesn't that conflict with
> >the IBM doc's claim for sequential retrieval?
> >
> >
> >
> >
> >   "Brian S.
> >   Crabtree"To:
> >[EMAIL PROTECTED]
> >>   NK.NET>  Subject: Re: retrieve
order
> >   Sent by:
> >   MQSeries List
> >>   en.AC.AT>
> >
> >
> >   09/19/2002 11:47
> >   AM
> >   Please respond
> >   to MQSeries List
> >
> >
> >
> >
> >
> >Rick
> >
> >What you quoted doesnt conflict with what Dave said
> >
> >
> >- Original Message -
> >From: "Rick Tsujimoto" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Thursday, September 19, 2002 9:59 AM
> >Subject: Re: retrieve order
> >
> >
> > > Dave,
> > >
> > > If what you say is true, then IBM has to update its claim about
> >sequential
> > > retrieval.  No where in that claims does it make exceptions due to the
> > > physical network.  I would have thought that TCP/IP would reassemble
the
> > > packets in their proper order regardless how they traversed the
network.
> > > But, may IBM can clarify that.
> > >
> > > Here's the IBM claim:
> > >
> > > 2.1.14.1  | Sequential retrieval of messages
> > >
> > >   | If an application puts a sequence of messages to the same
> >destination
> >|
> > > queue, those messages can be retrieved in sequence by a single
> >application
> > > | with a sequence of MQGET operations, if the following conditions are
> >met:
> > > All of the put requests were done from the same application.
> > > All of the put requests were either from the same unit of work, or all
> >the
> > > put requests were made outside of a unit of work.
> > > The messages all have the same priority.
> > > The messages all have the same persistence.
> > > For remote queuing, the configuration is such that there can only be
one
> > > path from the application making the put request, through its queue
> > > manager, thr

Re: Queue Manager Creation Error

[Richard Tsujimoto]

Did you apply any CSDs?

- Original Message -
From: "Prithwiraj Basu" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 16, 2002 4:58 PM
Subject: Queue Manager Creation Error


> Hi All,
>
> I am trying to verify the successful install of MQSeries Version 5.2 in a
> new environment.  The version of Unix is Solaris 8 and the C++ compiler is
> Sun Forte 6 Update 2.  I am attempting the "Verifying a local
installation"
> as per the MQSeries Quick Beginnings documentation.  However the creation
> of the queue manager fails and the following is the output at the command
> prompt:
>
> pb.oddev01.dev.r10.es1.src.../opt/mqm/samp/bin:crtmqm -q
> venus.queue.manager
> MQSeries queue manager created.
> Creating or replacing default objects for venus.queue.manager.
> Default objects statistics : 0 created. 0 replaced. 30 failed.
> For details of the failures that occurred, please check AMQERR01.LOG.
> Completing setup.
> Setup completed.
>
> Here are the first few messages from the log:
>
> 16//07//02  02:22:27 PM
> AMQ6174: The library /var/mqm/exits/amqzxmr0 was not found. The queue
> manager
> will continue without this module.
>
> EXPLANATION:
> The dynamically loadable file /var/mqm/exits/amqzxmr0 was not found.
> ACTION:
> Check that the file exists and is either fully qualified or is in the
> appropriate directory.
> --
-
> 16//07//02  02:22:28 PM
> AMQ8003: MQSeries queue manager 'venus.queue.manager' started.
>
> EXPLANATION:
> MQSeries queue manager 'venus.queue.manager' started.
> ACTION:
> None.
> --
-
> 16//07//02  02:22:28 PM
> AMQ6174: The library /var/mqm/exits/amqzif was not found. The queue
manager
> will continue without this module.
>
> EXPLANATION:
> The dynamically loadable file /var/mqm/exits/amqzif was not found.
> ACTION:
> Check that the file exists and is either fully qualified or is in the
> appropriate directory.
> --
-
> 16//07//02  02:22:29 PM
> AMQ5525: The MQSeries Object Authority Manager has failed.
>
> EXPLANATION:
> The MQSeries Object Authority Manager has failed to complete an MQSeries
> request.
> ACTION:
> Check the queue manager error logs for messages explaining the failure and
> try
> to correct the problem accordingly.
> --
-
> 16//07//02  02:22:29 PM
> AMQ5525: The MQSeries Object Authority Manager has failed.
>
> EXPLANATION:
> The MQSeries Object Authority Manager has failed to complete an MQSeries
> request.
> ACTION:
> Check the queue manager error logs for messages explaining the failure and
> try
> to correct the problem accordingly.
> --
-
>
> It seems to me like it can't find the programs it needs to create a queue
> manager.  The first log message states that /var/mqm/exits/amqzxmr0 is not
> found.  This is true as the contents of the /var/mqm/exits dir is empty.
> But that is also the case on our old server where mq is installed and
> things are running just fine.  What gives?  Did I forget exporting some
> variable or something?
>
> Please advice.
>
> Thanks.
>
> Prits
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Excessive elapsed times processing searches on mainframe via MQ from LAN

[Richard Tsujimoto]

Ken,
 
What you haven't explained in your architecture is 
how the message is processed on the m/f side.  Is it triggering an STC/job 
or what?  Or, are you polling the queue with a long running job?  
Non-persistent messages are not written to disk unless the buffers overflow, so 
the normal message retrieval should be via memory access.  So, the long 
response times seem out of place.
 

  - Original Message - 
  From: 
  Kenneth M Viney 
  To: [EMAIL PROTECTED] 
  Sent: Sunday, July 07, 2002 5:26 PM
  Subject: Excessive elapsed times 
  processing searches on mainframe via MQ from LAN
  Hi all, If anyone can offer any suggestions or answers to the 
  questions posed at the end of this mail it would be greatly appreciated. 
   Sorry for the length of this mail but it was felt it was best if we try 
  and give a complete picture of what our situation is like to better enhance 
  the chances of their being someone out there who could help us. 
  System Overview 
  Web based application, written in Java, that 
  utilises MQ Series and the Java MQ API to perform searches and retrieve 
  information from a database on the mainframe.  Loads vary from 3500 - 
  4000 searches per day. The application 
  on the MQ Client (web server) provides a limited multi-tasking search 
  capability using a pool of 'message processors'.  The 'message processor' 
  is our own custom built Java class that contains an MQ Queue Manager and 2 x 
  MQ queue's (1 request, 1 reply). Whenever a search needs to be performed, a 'round robin' algorithm is 
  used to select a message processor class to handle the search.  The pool 
  size is currently set to 5 message processor classes. Thus the application can have multiple threads reading 
  from the reply queue. OS/390 
  mainframe IDMS Rel 15.0 database on 
  mainframe MQSeries is v5.2 
  DB2 v7.2 fix pak 6 Java is JDK v1.3 LAN server is Windows NT4 fp6A  (dual 550Mhz processor - yeah I 
  know ... 19th century technology) MQ Architecture Overview The MQ infrastructure consists of the following : - Queue Manager running on a NT server - Queue Manager running on an OS/390 mainframe 
  Each Queue Manager has a sender and receiver 
  channel and use TCP/IP as the communication protocol. Processing a Search Each message processor performs a search in the 
  following manner: 1.     
     Create a request message with following options:    
          characterSet = MQC.MQCCSI_Q_MGR         format = 
  MQC.MQFMT_STRING       
    encoding = MQC.MQENC_NATIVE         messageType = MQC.MQMT_REQUEST 
          persistence = 
  MQC.MQPER_NOT_PERSISTENT     
      report = MQC.MQRO_EXCEPTION2.        Put the message on the request 
  queue 3.       
   Get the response off the queue with the following options: 
          MQC.MQGMO_CONVERT 
  + MQC.MQGMO_WAIT The 
  Problem What we have noticed 
  is that the average search time for a message is approximately 1 -2 seconds 
  (some less than 0.5 seconds).  However some of the searches appear to 
  take up to 60 - 70 seconds which is totally unacceptable. Given the above architecture, when a message takes 
  approximately 60 - 70 seconds, a message processor blocks all other GET's 
  until the slow message has been received. There is no indication that the slow elapsed times are due to slow 
  responses on the mainframe. Questions Is it 
  advisable to increase from 5 to 50 the number of active threads (by increasing 
  the pool size) to read from a queue? If we increase the pool size, will this require serious upgrading of 
  the server CPU processing power? Are 
  there any known threading issues in the Java API, when performing a 'Get and 
  Wait' operation? Hopefully 
  someone out there can offer help.  Thanks in advance. 
  Ken Viney MQSeries Administrator DMR Consulting + 61 3 9664 
  6626This message and any attachments are confidential and for the 
  addressee only.  If you have received it in error, please notify the 
  sender.  It may be subject to legal privilege or confidentiality 
  obligations imposed by legislation. The legal effect of this email is 
  subject to its compliance with the TAC's Electronic Communication Policy and 
  Guidelines (available at http://www.tac.vic.gov.au/ecom-policy).  If this 
  email does not include a digital signature, or comply with those Guidelines, 
  it should not be relied upon. TAC email addresses are for business use 
  only. All email sent to the TAC may be inspected and used by the TAC for any 
  lawful purpose. The TAC's policy prohibiting  transmission of 
  inappropriate material to its email address is strictly 
enforced.

Re: Access by revoked RACF userid

[Richard Tsujimoto]

I need to amend my response.  The userid assigned to CICS, or the one you
use via PLTPI would be used for connecting to MQSeries.  If you're doing
context security, inserting the userid of the signed on user, it would be
that userid that would be checked.  Otherwise, it's the former case.  Since
you tried a refresh for the MSTR and that didn't work, I would assume it's
similar to the case I mentioned using TSO.

- Original Message -
From: "Alfons Heirbaut" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 05, 2002 7:52 AM
Subject: Re: Access by revoked RACF userid


In our case, the user doesn't have an ACEE in CICS. It is the CICS PLTPI
user that executes the transactions triggered by the application queues. The
user should be prevented from putting a message into the application queue
after he has been revoked and security-tables in MQS have been refreshed.

Richard Tsujimoto <[EMAIL PROTECTED]>

05/07/2002 01:54
Please respond to MQSeries List <[EMAIL PROTECTED]>

To: [EMAIL PROTECTED]@SMTP@Exchange
cc:
Subject: Re: Access by revoked RACF userid


It's been a while, but I believe an ACEE is also created in the CICS address
space and is associated (chained) with the terminal session. I don't know
which one takes precedence, but one sure way to effect the security changes
is to force the user off CICS. I don't know if a refresh would give you
what you want. I seem to remember having have to logoff/logon TSO to effect
any RACF changes made to my userid. I suspect the same holds true for CICS.

- Original Message -
From: Alfons Heirbaut <mailto:[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Sent: Thursday, July 04, 2002 10:19 AM
Subject: Access by revoked RACF userid
Dear all,
Working in a client/server-environment using mqseries, the user-password is
validated once (using a queue with universal UPDATE and a corresponding
CICS-transaction that executes a RACROUTE REQUEST=VERIFY). Afterwards, the
userid needs the proper authorizations when accessing the application queues
on the mainframe. The MQ-master-address space will create an ACEE for the
user (RACROUTE REQUEST=VERIFY, ENVIRON=CREATE, USERID=userid, PASSSCHK=NO)
and for each (new) queue accesses, a resource validation takes place
(RACROUTE REQUEST=FASTAUTH, CLASS=MQQUEUE, ENTITY=queue=name,
ACEE=useracee).
For performance reaons, the MQ-master address space keeps track of the
resources already accessed.
Using the commands RVERIFY USERID(userid) or ALTER SECURITY TIMEOUT(0) the
corresponding or all ACEE's are deleted (RACROUTE REQUEST=VERIFY,
ENVIRON=DELETE, USERID=userid).
However, a user that has been manually revoked after the initial logon can
still access the queues that are found in the user's history. When he tries
to access a new queue, the MQ-master-address space tries to create a new
ACEE but fails with the message ICH408I LOGON/JOB INITIATION - REVOKED USER
ACCESS ATTEMPT.
Does anybody know how to clear the userid's history so that the userid will
be blocked from using the queues?
Or is there an alternate way to stop the revoked userid from acccessing the
queues?
Regards,
Fons Heirbaut
Seurity Officer
AXA BANK Belgium
__
AXA Bank n.v. Security Desk
Postcode: B2Z/650 - Site Berchem
Tel.: +32 (0)3 286 21 93
Fax: +32 (0)3 286 28 99
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
This message may contain confidential information destined to be read only
by the intended recipient. No other persons should read, use, publish or
reproduce the content of this message. If you receive this message by
mistake, please notify the sender immediately. The information contained
in this message represents the personal opinions of the individual that sent
it and should not be construed as representing the position of the AXA
Group.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Access by revoked RACF userid

[Richard Tsujimoto]

Unless your user do not do a CICS signon that's validated by RACF, he/she
certainly does have an ACEE.  If he/she doesn't do a signon, then the userid
that's checked could be the region's userid.

- Original Message -
From: "Alfons Heirbaut" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 05, 2002 7:52 AM
Subject: Re: Access by revoked RACF userid


In our case, the user doesn't have an ACEE in CICS. It is the CICS PLTPI
user that executes the transactions triggered by the application queues. The
user should be prevented from putting a message into the application queue
after he has been revoked and security-tables in MQS have been refreshed.

Richard Tsujimoto <[EMAIL PROTECTED]>

05/07/2002 01:54
Please respond to MQSeries List <[EMAIL PROTECTED]>

To: [EMAIL PROTECTED]@SMTP@Exchange
cc:
Subject: Re: Access by revoked RACF userid


It's been a while, but I believe an ACEE is also created in the CICS address
space and is associated (chained) with the terminal session. I don't know
which one takes precedence, but one sure way to effect the security changes
is to force the user off CICS. I don't know if a refresh would give you
what you want. I seem to remember having have to logoff/logon TSO to effect
any RACF changes made to my userid. I suspect the same holds true for CICS.

- Original Message -
From: Alfons Heirbaut <mailto:[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Sent: Thursday, July 04, 2002 10:19 AM
Subject: Access by revoked RACF userid
Dear all,
Working in a client/server-environment using mqseries, the user-password is
validated once (using a queue with universal UPDATE and a corresponding
CICS-transaction that executes a RACROUTE REQUEST=VERIFY). Afterwards, the
userid needs the proper authorizations when accessing the application queues
on the mainframe. The MQ-master-address space will create an ACEE for the
user (RACROUTE REQUEST=VERIFY, ENVIRON=CREATE, USERID=userid, PASSSCHK=NO)
and for each (new) queue accesses, a resource validation takes place
(RACROUTE REQUEST=FASTAUTH, CLASS=MQQUEUE, ENTITY=queue=name,
ACEE=useracee).
For performance reaons, the MQ-master address space keeps track of the
resources already accessed.
Using the commands RVERIFY USERID(userid) or ALTER SECURITY TIMEOUT(0) the
corresponding or all ACEE's are deleted (RACROUTE REQUEST=VERIFY,
ENVIRON=DELETE, USERID=userid).
However, a user that has been manually revoked after the initial logon can
still access the queues that are found in the user's history. When he tries
to access a new queue, the MQ-master-address space tries to create a new
ACEE but fails with the message ICH408I LOGON/JOB INITIATION - REVOKED USER
ACCESS ATTEMPT.
Does anybody know how to clear the userid's history so that the userid will
be blocked from using the queues?
Or is there an alternate way to stop the revoked userid from acccessing the
queues?
Regards,
Fons Heirbaut
Seurity Officer
AXA BANK Belgium
__
AXA Bank n.v. Security Desk
Postcode: B2Z/650 - Site Berchem
Tel.: +32 (0)3 286 21 93
Fax: +32 (0)3 286 28 99
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
This message may contain confidential information destined to be read only
by the intended recipient. No other persons should read, use, publish or
reproduce the content of this message. If you receive this message by
mistake, please notify the sender immediately. The information contained
in this message represents the personal opinions of the individual that sent
it and should not be construed as representing the position of the AXA
Group.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ vs Connect Direct

[Richard Tsujimoto]

You need to say email to make your management understand?  Nuff said.
- Original Message -
From: "Beinert, William" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 21, 2002 4:45 PM
Subject: Re: MQ vs Connect Direct


> Ronald is right. Basically MQ is reliable program to program e-mail.
> The rest is bells and whistles. Not stuff I am willing to live without,
but
> when I have to explain MQ to  management that has never heard of it,
> "reliable program to program e-mail" gets them to first base.
>
> Bill
>
> -Original Message-
> From: Richard Tsujimoto [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 21, 2002 4:16 PM
> To: [EMAIL PROTECTED]
> Subject: Re: MQ vs Connect Direct
>
>
> That's a stretch.  How does email support XA coordination with data bases?
> How does email support grouping/segmenting messages?  How does messaging
> support multi-levels of confirmation of delivery/arrival?  How about
> clustered queues?  Need I go on?
>
> - Original Message -
> From: "Ronald Weinger" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 21, 2002 7:15 AM
> Subject: Re: MQ vs Connect Direct
>
>
> In concept,  messaging is nothing more than e-mail between programs.
>
>
>
>
>
> "Roberto Sanchez" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on
> 06/20/2002 04:36:06 PM
>
> Please respond to "MQSeries List" <[EMAIL PROTECTED]>
>
> Sent by:"MQSeries List" <[EMAIL PROTECTED]>
>
>
> To:[EMAIL PROTECTED]
> cc:
> Subject:Re: MQ vs Connect Direct
>
>
> ... designed as an e-mail system...?,
>
> mqcommit, mqrollback, get(msgid), get(correlid), get(priority), mqalias,
> model queues, triggers, channel priority, cluster managers, etc. etc, etc,
> etc...
>
> all of this is so more than an e-mail system.
>
> Another option is consider Connect-Direct versus Tivoli Data Exchange (no
> Tivoli framework required)
>
> Regards.
>
>
> ---
> Roberto Oscar Sanchez - Arquitecto de Sistemas Centrales
> Banco Galicia - Gerencia de Sistemas - Arquitectura Corporativa
> Peron 537 - Piso 3 'A' - C1038AAK - 6329-5349/5346
> Buenos Aires - Argentina - [EMAIL PROTECTED]
> ---
>
>
>
>
> Ronald Weinger
>  FE.COM>   cc:
> Enviado por:  Asunto:  Re: MQ vs Connect
> Direct
> MQSeries List
>  ien.AC.AT>
>
>
> 20/06/2002
> 15.50
> Por favor,
> responda a
> MQSeries List
>
>
>
>
>
> Without some value-added functonality, MQSeries will lose.
> Connect Direct was designed as  a file transfer system. MQSeries was
> designed as an e-mail system. If you want head-to-head, look at
> CommerceQuest e-Adapter vs Connect Direct.
>
>
>
>
>
> "Steve Sacho" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 06/20/2002
> 02:14:44 PM
>
> Please respond to "MQSeries List" <[EMAIL PROTECTED]>
>
> Sent by:"MQSeries List" <[EMAIL PROTECTED]>
>
>
> To:[EMAIL PROTECTED]
> cc:
> Subject:Re: MQ vs Connect Direct
>
>
>
> I'm aware of the unfortunate misconception of MQ as a glorified and costly
> FTP, but this is precisely the area in which it's being challenged -
> Connect Direct is seen as a viable alternative when it's just a file
> transfer role that's being considered. My question was then as a
> head-to-head file transfer solution, what's the knock-out punch for MQ vs.
> CD, if any?
>
>
>
>
>
>
> philip.distefano@JPMCH
>
> ASE.COM  To:
>
> Sent by: "MQSeries
[EMAIL PROTECTED]
>
> List"T
>
> <[EMAIL PROTECTED]   cc:
>
> AT>  Subject:
>
>  Re: MQ vs Connect
>
> 06/20/2002 10:15 AM  Direct
>
> Please respond to
>
> "MQSeries List"
>
>
>
>
>
>
>
> Connect Direct is a file transfer system... Why do you want to compar

Re: Channel Question

[Richard Tsujimoto]

Sergio,

If the channel is, in fact, STOPPED, then either someone manually stopped
it, or the retry attempts after a channel error were exhausted.  The channel
should revert to an INACTIVE state once the disconnect interval expires.

- Original Message -
From: "Sergio Lima Costa Costa" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 21, 2002 10:29 AM
Subject: Channel Question


> Hello.
>
> Here We have MQSeries installed under Os/390 and SUN also.
>
> We have a problem, that sometimes, the channel of this machines are
Stopped.
> We want know if exist a automatic way that say to us if this problem
occurs
> in any machine, and also if is possible do a START automatic command.
>
> Any Help ?
>
> Sergio Lima Costa
> System Consultant
> Sao Paulo - Brasil
>
> _
> Converse com amigos on-line, conhega o MSN Messenger:
> http://messenger.msn.com
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Non threaded listener on Windows

[Richard Tsujimoto]

Paul,

How are other users who have queues that are not filled but effectively use
the same channel affected?  I would expect the listener to keep chugging
along as long as they don't use the same full queue.

- Original Message -
From: "Paul Clarke" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 21, 2002 11:18 AM
Subject: Re: Non threaded listener on Windows


> >Thanks Paul:
>
> >I 100% agree with the most of your e-Mail. NT threads are really good and
> worth to use instead of processes >(they could even provide a complete
> isolation of clients in security terms if MQSeries had some interface for
> >it).  But here is the scenario that bothers me from time to time:
>
> >1. The distributed application wants to use MQSeries natural message
> sequence. All conditions are satisfied, >including not having any dead
> letter queues.
>
> >2. Due to the slow subscriber the queue becomes full.
>
> >3. Channel stops in accordance with the documentation.
>
> >My question is, will this channel stop affect other applications
> communicating via the same listener process >with different queues? If the
> answer is yes, then I know why some users might want separate processes
for
> >their channels even on MQSeries NT :-).
>
> >Thank you,
> >Pavel
>
> Pavel,
>
> No a channel ending for whatever reason will not affect other channels
> running in the same process. Other applications using the same *channel*
> will obviously be affected which is why we strongly recommend that people
> *do* have Dead Letter Queues, but other channels will all operate
>
> Cheers,
> P.
>
> Paul G Clarke
> WebSphere MQ Development
> IBM Hursley
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ vs Connect Direct

[Richard Tsujimoto]

That's a stretch.  How does email support XA coordination with data bases?
How does email support grouping/segmenting messages?  How does messaging
support multi-levels of confirmation of delivery/arrival?  How about
clustered queues?  Need I go on?

- Original Message -
From: "Ronald Weinger" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 21, 2002 7:15 AM
Subject: Re: MQ vs Connect Direct


In concept,  messaging is nothing more than e-mail between programs.





"Roberto Sanchez" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on
06/20/2002 04:36:06 PM

Please respond to "MQSeries List" <[EMAIL PROTECTED]>

Sent by:"MQSeries List" <[EMAIL PROTECTED]>


To:[EMAIL PROTECTED]
cc:
Subject:Re: MQ vs Connect Direct


... designed as an e-mail system...?,

mqcommit, mqrollback, get(msgid), get(correlid), get(priority), mqalias,
model queues, triggers, channel priority, cluster managers, etc. etc, etc,
etc...

all of this is so more than an e-mail system.

Another option is consider Connect-Direct versus Tivoli Data Exchange (no
Tivoli framework required)

Regards.


---
Roberto Oscar Sanchez - Arquitecto de Sistemas Centrales
Banco Galicia - Gerencia de Sistemas - Arquitectura Corporativa
Peron 537 - Piso 3 'A' - C1038AAK - 6329-5349/5346
Buenos Aires - Argentina - [EMAIL PROTECTED]
---




Ronald Weinger
   cc:
Enviado por:  Asunto:  Re: MQ vs Connect
Direct
MQSeries List



20/06/2002
15.50
Por favor,
responda a
MQSeries List





Without some value-added functonality, MQSeries will lose.
Connect Direct was designed as  a file transfer system. MQSeries was
designed as an e-mail system. If you want head-to-head, look at
CommerceQuest e-Adapter vs Connect Direct.





"Steve Sacho" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 06/20/2002
02:14:44 PM

Please respond to "MQSeries List" <[EMAIL PROTECTED]>

Sent by:"MQSeries List" <[EMAIL PROTECTED]>


To:[EMAIL PROTECTED]
cc:
Subject:Re: MQ vs Connect Direct



I'm aware of the unfortunate misconception of MQ as a glorified and costly
FTP, but this is precisely the area in which it's being challenged -
Connect Direct is seen as a viable alternative when it's just a file
transfer role that's being considered. My question was then as a
head-to-head file transfer solution, what's the knock-out punch for MQ vs.
CD, if any?






philip.distefano@JPMCH

ASE.COM  To:

Sent by: "MQSeries   [EMAIL PROTECTED]

List"T

<[EMAIL PROTECTED]   cc:

AT>  Subject:

 Re: MQ vs Connect

06/20/2002 10:15 AM  Direct

Please respond to

"MQSeries List"







Connect Direct is a file transfer system... Why do you want to compare them
? CD uses TCP/IP, or SNA (LU6 or LU0) Its very fast using LU0.






Steve_Sacho@COUN To:
[EMAIL PROTECTED]
TRYWIDE.COM cc:
Sent by: Subject: MQ vs Connect Direct
MQSERIES@akh-wie
n.ac.at


06/20/2002 12:07
PM
Please respond
to MQSERIES





Anyone have a brief comparison of MQSeries vs. Connect Direct (from
Sterling)?

Thanks,

Steve
Anyone have a brief comparison of MQSeries vs. Connect Direct (from
Sterling)?

Thanks,

Steve




This communication is for informational purposes only. It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made
herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive






Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive



Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive




Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http:/

Re: COD delivery problem on AIX

[Richard Tsujimoto]

Title: COD delivery problem on AIX



How you doing Brant?
 
I think the problem is the COD is being put to the 
xmitq but under the userid that's in the MQMD.  You have to grant that 
userid put access to the xmitq.
 

  - Original Message - 
  From: 
  Gutekunst, Brant 
  To: [EMAIL PROTECTED] 
  Sent: Wednesday, June 05, 2002 12:09 
  PM
  Subject: COD delivery problem on 
AIX
  
  I am having a problem with report messages on AIX 
  4.3 MQ 5.2. 
  I receive messages from QM1 with MQMD.Feedback set 
  to MQFB_COA+MQFB_COD,  MQMD.ReplyToQueue = DESTQ and MQMD.ReplyToQMgr = 
  QM2
  Initially, the report messages were hitting my Dead 
  Letter Queue.  I created a QMgr Alias with QREMOTE(QM2) and 
  RQMNAME(QM1).  My intention was to force messages destined for QM2 to QM1 
  where they would be forwarded properly.
  COA messages are now being delivered, but the COD 
  messages are still ending up on my DLQ with MQRC = 2035 
  (MQRC_NOT_AUTHORIZED).  I also get an Event message at this time with 
  MQ_OPEN_NOT_AUTHORIZED.
  If I run runmqdlq with a retry rule, the messages 
  are transmitted successfully. 
  How can I figure out what I'm failing to open and 
  which process is failing to open it? Any 
  hints will be appreciated.  This one is starting to drive me 
  crazy. 

Re: Message ordering

[Richard Tsujimoto]

I tend to disagree with the *restictive* aspect of sequential message
delivery.  If the customer has a simple network topology and does not plan
to introduce complicated networking, the topology issue is a moot point.
Also, in a complicated network topology, if DLQs are used, using
msgid/correlids are of little value.  I think the biggest mistake people
make is trying to morph FTP into MQ's messaging paradigm.  If MQ is going to
be used to deliver files, treat it the same way FTP would, e.g. it's all or
nothing.  Trying to program for contingencies, e.g. network glitches,
reorder messages based on multiple channels, etc., is a recipe for trouble.
Just my two cents.

- Original Message -
From: "Miller, Dennis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 5:52 PM
Subject: Re: Message ordering


> MQ does deliver messages in sequence, given certain conditions. The
problem,
> of course, is that the conditions are so restrictive that sequential
> delivery is usually impractical. To make matters worse, some of the
> restrictions involve network topology. The last thing you want to do is
make
> your application unnecesarily dependent on how the channels are
configured,
> the path a message might take, or other things that are subject to change
> for operational or performance reasons.
>
> The best practice for satisifying a sequential delivery requirement is to
> provide for it in your application(s). You may be able to use logical
> message groups or message chaining. Message chaining has has been
discussed
> before: send every message with a unique msgid and a correlid containing
the
> msgid preceeding it. You can then guarantee sequential retrieval by
> qualifying the correlid on your mqget with the msgid of the prior message.
> That may get "interesting" when feeding JMS from a non-JMS application
> because of the way JMS manipulates the msgid, but I think it's still
> do-able.
>
> regards,
> Dennis
>
>
>
> > -Original Message-
> > From: Jodl, Joe R [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, May 29, 2002 6:25 AM
> > To:   [EMAIL PROTECTED]
> > Subject:  Message ordering
> >
> > We have a application running in MVS that puts messages to a MQ remote
> > queue name.  The application guarantees to put the messages in order.
> > This remote queue puts the message to a xmit queue on a Sun Solaris box
> > running MQ version 5.2
> > My question is will the messages be guaranteed to be in order when they
> > reach the UNIX box?
> >
> > Also once the messages are on the UNIX box they are read off by a JAVA
> > application using JMS.
> > Are there options with JMS to insure order?
> >
> > Thanks in advance 
> > Joe
> >
> > Instructions for managing your mailing list subscription are provided in
> > the Listserv General Users Guide available at http://www.lsoft.com
> > Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ vs CICS

[Richard Tsujimoto]

I think the answer has more to do with your application requirements rather
than just dollars and license costs.  MQ has few, well defined means for do
Request-Reply processing, albeit it's based strictly on an asychronous
messaging.

CICS, on the other hand (it's been a few years since I worked with it so,
there may be some dated things stated here), has more options.  It can
exploit MQ, you could use the CICS client, you could write a client using
sockets, HTTP, and so forth.  With CICS you can have true synchronous
processing as well.

- Original Message -
From: "N Vinodh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 30, 2002 8:08 AM
Subject: MQ vs CICS


> Hi all
> I have the following query.
>
> For a distributed environment with Request-Reply mode, which is preferred
> CICS or MQ?
>
> I need justifying reasons for anyone to be prefered.
>
> Plz help me in this
>
> Thanx in advance.
>
> Rgds
> vinodh
>
>

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Re-triggering a process

[Richard Tsujimoto]

Tom,

If a person has update access, then there's nothing to prevent them to alter
the queue attributes.  What I think you're asking for is something analogous
to field access control to a data base record.  In that case, you would want
to remove a person's update access and have a utility that performs the
update on his/her behalf.  The question is, how do you determine if a person
has legitimate rights to request trigger/notrigger requests, especially
against specific production queues?  This could result in maintaining
separate/redundant security rights for certain persons.  As for the
mechanics for doing the actual update (I'm not a RACF person), I *believe*
you should be able to switch the userid to one that has the rights you
require.  The queue manager effectively does that when it checks a user's
access to MQ resources.  Your utility would probably require APF access.
(For some reason, this subject rings a bell and you might find something
more specific in the archives).

- Original Message -
From: "Tom Kane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, May 18, 2002 3:28 AM
Subject: Re: Re-triggering a process


> Yes, we have altered the qlocal to notrigger and then back to trigger.
> To change the question slightly, in my production environment the
> application generally does NOT have access to alter their own queues.  But
> this is one attribute that I would think they should be able to change.
> However I don't see where the MQ RACF configuration supports permitting
them
> to change the one attrribute.
> A) am I correct about that.
> B) any thoughts on how I might implement a utility that would somehow
alter
> that attribute for people?  Check that they have update access to the
queue,
> and if they do, then do the alter for them?
> Thanks
> Tom
> - Original Message -
> From: "Paul Clarke" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 15, 2002 9:48 AM
> Subject: Re: Re-triggering a process
>
>
> > >Hi
> > >is there a way of re-triggering a process that has fired and failed,
> other
> > >than by changing the Q attributes (from depth 1 to depth x)  ?
> >
> > >TIA
> >
> > >Kevin Wolfenden
> >
> > Kevin,
> >
> > Change the local queue attribute to NOTRIGGER and then back to TRIGGER.
> > If the failure is quite common is might be worth looking at the TRIGINT
> > attribute of the Queue Manager.
> >
> > Cheers,
> > P.
> >
> > Paul G Clarke
> > WebSphere MQ Development
> > IBM Hursley
> >
> > Instructions for managing your mailing list subscription are provided in
> > the Listserv General Users Guide available at http://www.lsoft.com
> > Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Wanted: Super geek

[Richard Tsujimoto]

Jim,

I don't know about that.  Maybe it's different now with a tight market, but
I remember when it was pretty much accepted that a person moved every 2 yrs
or so.

- Original Message -
From: "Jim Keohane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, May 05, 2002 2:11 PM
Subject: Re: Wanted: Super geek


>I didn't take the "2 years" as applying to the list of skills at all. I
> just took it to mean they didn't want to hear from a frequent job jumper.
If
> your resume shows you are never at a job too long then they're not
> interested.  - Jim Keohane
>
> 
> 
>  Jim Keohane
>  Multi-Platforms, Inc.
>  Software Development & Consulting, expert witness,
> columnist
>  Chief Cook & Bottle Washer
>  (516) 579-2209
>  www.multi-platforms.com
>  [EMAIL PROTECTED]
>  640K ought to be enough for anybody. - Bill Gates
>  640K is enough. For FUN!
> 
> - Original Message -
> From: "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, May 05, 2002 12:38
> Subject: Re: Wanted: Super geek
>
>
> > Rick, you notice where it says "2 yrs experience in each job"? Well, if
> you
> > count up each of the things listed (and assume each counts as one job)
and
> > multiply by 2, it comes to about 24 years experience, depending on how
you
> > count stuff. Sounds about right for what they're looking for :-)
> >
> > -- Rebecca
> >
> >
> >
> > -Original Message-
> > From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, May 05, 2002 12:19 PM
> > To: [EMAIL PROTECTED]
> > Subject: Wanted: Super geek
> >
> >
> > I know this is a bit off topic, so I apologize ahead of time to those
who
> > object to this posting, but I couldn't resist.  I realize that some of
us
> > are out of work and others have been assigned additional
responsibilities
> > as a result of corporate mergers, down-sizing, etc.  When I saw this
want
> > ad in the New York Times today, I just had to post it.  At first I
thought
> > I was brewing the wrong sort of tea this morning, then I thought the ad
> > as a misprint, where the experience read 2+ yrs experience maybe they
> > dropped the zero.  Anyway, you judge:
> >
> > "Computer Database Administrator - NYC - administrate and maintain IMS,
> > DB2,CICS, MQSeries database subsystems in OS/390 mainframe environment,
> > install software using SMP/E, Customize subsystems & diagnose problems,
> > Perform DASD & RACF administration, Provide technical support & train
> > user. BS Computer Science, math or engineering + 2 yrs experience in
> > each job. Competitive salary, 40hr wk,..."
> >
> > For those of you who are not familiar with the m/f world, take my word,
> > this is pretty unreal.
> >
> > Instructions for managing your mailing list subscription are provided in
> > the Listserv General Users Guide available at http://www.lsoft.com
> > Archive: http://vm.akh-wien.ac.at/MQSeries.archive
> >
> >
> >
> >
**
> > This e-mail and any files transmitted with it may contain privileged or
> > confidential information. It is solely for use by the individual for
whom
> > it is intended, even if addressed incorrectly. If you received this
e-mail
> > in error, please notify the sender; do not disclose, copy, distribute,
or
> > take any action in reliance on the contents of this information; and
> delete
> > it from your system. Any other use of this e-mail is prohibited. Thank
you
> > for your compliance.
> >
> > Instructions for managing your mailing list subscription are provided in
> > the Listserv General Users Guide available at http://www.lsoft.com
> > Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Wanted: Super geek

[Richard Tsujimoto]

I did the math beforehand which is why I pointed out the 20+ yrs.  Given 2
yrs per skill, I would be skeptical of the person's overall knowledge.
Let's assume the person spent his/her first 2 yrs in CICS and the last 2 yrs
in RACF.  I'm not so sure I would trust the person's CICS skills at this
point.  I guess the point I'm trying to make is that the ad is, for the most
part, a bit far fetched.  I have 25+ yrs in the field (man, I hate saying
that) and, based on the folks I know who've been around as long, you won't
find many that meet those skill requirements.

- Original Message -
From: "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, May 05, 2002 12:38 PM
Subject: Re: Wanted: Super geek


> Rick, you notice where it says "2 yrs experience in each job"? Well, if
you
> count up each of the things listed (and assume each counts as one job) and
> multiply by 2, it comes to about 24 years experience, depending on how you
> count stuff. Sounds about right for what they're looking for :-)
>
> -- Rebecca
>
>
>
> -Original Message-
> From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 05, 2002 12:19 PM
> To: [EMAIL PROTECTED]
> Subject: Wanted: Super geek
>
>
> I know this is a bit off topic, so I apologize ahead of time to those who
> object to this posting, but I couldn't resist.  I realize that some of us
> are out of work and others have been assigned additional responsibilities
> as a result of corporate mergers, down-sizing, etc.  When I saw this want
> ad in the New York Times today, I just had to post it.  At first I thought
> I was brewing the wrong sort of tea this morning, then I thought the ad
> as a misprint, where the experience read 2+ yrs experience maybe they
> dropped the zero.  Anyway, you judge:
>
> "Computer Database Administrator - NYC - administrate and maintain IMS,
> DB2,CICS, MQSeries database subsystems in OS/390 mainframe environment,
> install software using SMP/E, Customize subsystems & diagnose problems,
> Perform DASD & RACF administration, Provide technical support & train
> user. BS Computer Science, math or engineering + 2 yrs experience in
> each job. Competitive salary, 40hr wk,..."
>
> For those of you who are not familiar with the m/f world, take my word,
> this is pretty unreal.
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>
> **
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and
delete
> it from your system. Any other use of this e-mail is prohibited. Thank you
> for your compliance.
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive