Interesting follow-up. This week we didn't bring up the systems test queue
manager and there were no errors in Vegasoft. According to our IDMS person,
the Vegasoft product is implemented on the test LPAR without a specific
QMGR name specified in a table that is assembled and linked as part of the
install. On The production LPAR, the QMGR name is specified in that table
and there has not been any reported problem. Of course, it also has not
been upgraded yet either.
All that was to say that it appears that if only a single QMGR is run on an
LPAR, there should not be a problem. We are still testing.
Ernest Roberts
IT - Sr Sys Prog
MBUSA, LLC
Three Mercedes Drive
Montvale, NJ 07345
201-573-2619
201-573-4383 fax
866-308-3782 pager
----- Forwarded by Ernest Roberts/171/DCAG/DCX on 09/16/2003 04:28 PM -----
Ernest Roberts
To: [EMAIL PROTECTED]
09/12/2003 04:42 cc:
PM Subject: RE: Migrating MQSeries
libraries in IDMS
Understood Vince,
I just finished with our IDMS guy and He mentioned that part of the
Vegasoft install involved assemble/linkedit of MQ-related interface
modules. He's waiting for feedback (read confirmation) from the vendor that
he should re-run the asm/lnk jobs with the new MQ release libraries in the
JCL. I'll post the results on the list. As far as I can tell, the '2058' is
absolutely misleading, because the subsystem did not disappear when the JCL
was changed for the IDMS CV.
:<[) HavaGud Weekend
Ernest Roberts
IT - Sr Sys Prog
MBUSA, LLC
----- Forwarded by Ernest Roberts/171/DCAG/DCX on 09/12/2003 04:36 PM -----
[EMAIL PROTECTED]
al.com To: [EMAIL PROTECTED]
cc:
09/12/2003 03:06 Subject: RE: Migrating MQSeries
libraries in IDMS
PM
Ernest,
I generated this reason code myself in our test CV. The QM name in our
system is called "MQT1'.
I changed the QM name in our trigger monitor to "MQV1". MQV1 do not
exist on our system. In our software we pass the QM name at the time of
the MQCONN. The other option is to issue a MQCONNX, which connects the
program to the QM and provides connection handle. With this option you
do not pass the QM name. Maybe the mqseries guy need to turn this
option on in v531. Just a
thorough. Sometime going through releases it may require to reassemble
software. Good luck.
MQ000001 V85 T2130 ERROR CONNECTING TO QMANAGER MQV1 0002 2058
-----Original Message-----
From: ernest.roberts
Sent: Friday, September 12, 2003 12:08 PM
To: MQSERIES
Cc: ernest.roberts
Subject: Re: Migrating MQSeries libraries in IDMS
Hi Vince,
Our QMGRs are the same (we run two on our test LPAR). All associations
were
intact through the MQ migration/upgrade. When the libs were changed in
the
IDMS CV JCL, the errors showed up. Of course our IDMS guy is off today,
so
I cannot check with him about the Vegasoft configuration today. The 2058
did not arise from any disappearing MQ system information because we
haven't changed it. What I suspect is that some mismatch, possibly
release-related, is now occurring in the Vegasoft product between what
it
expects to see (from a systems standpoint) and what it actually is
seeing.
Thankfully, this is the test environment we're talking about. That's
where
mysteries should begin and end. I'll post the follow-up when I get some
results.
Thanx much,
Ernest Roberts
IT - Sr Sys Prog
MBUSA, LLC
----- Forwarded by Ernest Roberts/171/DCAG/DCX on 09/12/2003 12:58 PM
-----
Hi Ernest
We are under idms r15.0, os/390 v2.10. We just went from MQ v2.1 to
v5.31 without any problems. The MQSeries support staff had us changes
the loadlib's in the CV startup desk to point to MQ v5.31. After the
Jcl change we recycle the CV. We have not experience any problems.
The 2058 reason code means, Queue Manager Name error. Is there a
difference Queue Manager name between v2.1 and v5.31. If so, the
vegasoft software have to connect to this new queue manager name.
Vince Gibson
IDMS Systems Support
-----Original Message-----
From: ernest.roberts
Sent: Thursday, September 11, 2003 3:21 PM
To: MQSERIES
Cc: ernest.roberts
Subject: Migrating MQSeries libraries in IDMS
We are under IDMS R14.1 VegaSoft Release V11101 V2R.7 and just went
from
MVS MQ Release V2.10 to V5.3 in our Test Environment.
By that I mean we just updated the JCL to point to the new release
(v5r3).
I'm running on OS/390 V2.10 with MQS V5.3
I now see these errors:
VG007899 V12 PROGRAM MQSERPL1 TASKID 24 LTE LD000006
MQCALL MQOPEN
COMPLETION CODE 2 REASON CODE 2058
VG007853 V12 MQSERIES TRIGGER MONITOR ENCOUNTERED A FATAL MQSERIES ERROR
COMPLETION CODE 2 REASON CODE 2058
IN MQOPEN, INITIATION QUEUE: VEGA.INIT
VG007853 V12 MQSERIES TRIGGER MONITOR ENCOUNTERED A FATAL MQSERIES ERROR
COMPLETION CODE 2 REASON CODE 2058
IN MQDISCEX, INITIATION QUEUE: VEGA.INIT
VG007899 V12 PROGRAM MQSECHK1 TASKID 24 LTE LD000006
MQCALL MQBACK
COMPLETION CODE 2 REASON CODE 2058
VG007899 V12 PROGRAM MQSECHK1 TASKID 24 LTE LD000006
MQCALL MQDISCEX
COMPLETION CODE 2 REASON CODE 2058
Is there something that is not downward compatible with the new MQ
Release?
Has anyone else migrated the MQ from 2.1 to 5.3 in their IDMS
environment?
Is IDMS looking for a specific module that I should compile/assemble?
that
is the current direction I am looking.
Ernest Roberts
IT - Sr Sys Prog
MBUSA, LLC
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
