Hi Art,
Well, if you start the listener manually rather
than as a service, then it is do-able but I do
see where you are coming from. In the old days,
when I was an MQAdmin, I used MS03 nightly to
dump the MQ objects and copy the files to the DR
server. When I wanted to apply the updates, I
would start just the queue manager (pre-service
days) apply it and then either start the listener or stop the queue manager.
> PS I think you have a typo in your script.
Yah, the ".out" got dropped in the copy & paste.
i.e.
runmqsc $2 < startupCmds.mqsc > startupCmds.mqsc.out
Regards,
Roger Lacroix
Capitalware Inc.
At 04:15 PM 10/3/2013, you wrote:
>Roger
>
> Respectfully, I believe you may have missed the point.
>
>In configurations where DR QMGRs reside
>(potentially) at different physical locations
>and are only started during DR tests or
>(hopefully never) actual DR events, there is a
>real need to keep these dormant QMGRs
>up-to-date w/ object adds/deletes/changes. On
>z/OS, you have the ability to package those
>statements (the deltas) into a PDS member and
>have that member read and executed at QMGR
>start-up, prior to the CHINIT being started or
>applications being allow to connect. On
>distributed platforms, using the method you
>describe, applications could easily connect and
>obtain handles on the objects you need to
>modify, prior to the runmqsc cmd being executed.
>
>Im sure you are now thinking that the -ns
>flag of the strmqm command could be used (or
>possibly restricted mode), but this would
>require some manual intervention and/or
>additional QMGR recycle to complete the
>comparable changes to the QMGR. Having the
>option to read a file at start-up, prior to
>allowing connections, would provide exactly what
>is needed. In fact, unless I am mistaken, at
>one time (pre V5?) this was the method used to
>define/redefine the System objects as part of a
>migration/upgrade. (Perhaps our IBM colleagues can weigh in on that one).
>
>So while your solution has merit, it does not
>quite match the scenario I was presenting. We
>need a way to make those changes
>(synchronization) BEFORE the QMGR is open for business.
>
>Regards,
> Art
>
>PS I think you have a typo in your script.
>
>National IT Services
>Arthur Schanz
>Distributed Computing Spec
>Messaging and File Transfer
>701 East Byrd Street
>Richmond, VA 23219
>
>Email: <mailto:Arthur.Schanz-***@public.gmane.org>Arthur.Schanz-***@public.gmane.org
>
>National IT Green Logo
>
>CertWS_color
>
>
>From: MQSeries List
>[mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Roger Lacroix
>Sent: Thursday, October 03, 2013 3:11 PM
>To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
>Subject: Re: Request For Enhancement - Allow a
>file to be read at strmqm which could contain
>MQSC statements - similar to z/OS CSQINP1/CSQINP2 ddname d/s
>
>Hello Art,
>
>First off, what MQSC commands do you always need
>to do at queue manager startup?
>
>Second, I create scripts (batch files) to start
>my queue managers. If I ever felt the need to
>have MQSC commands run on startup, I would
>simply add a runmqsc line after strmqm.
>
>#!/sbin/sh
>#
># Startup script MQ queue managers
>
>case "$1" in
>'start')
> strmqm $2
> runmqsc $2 < startupCmds.mqsc > startupCmds.mqsc
> ;;
>
>'stop')
> endmqm $2
> ;;
>
>*)
> echo "Usage: $0 { start | stop } QMgrName"
> exit 1
> ;;
>esac
>exit 0
>
>If you look at the script as z/OS JCL, then you
>pretty much get the same thing.
>
>Regards,
>Roger Lacroix
>Capitalware Inc.
>
>At 02:15 PM 10/3/2013, you wrote:
>
>Description: Add a flag/switch to the strmqm
>command that allows the WMQ Admin to specify a
>file that can be read at QMGR start-up. The
>file could contain MQSC commands for object definition, alteration, etc.
>Use case: One use case is to allow a WMQ Admin
>to provide input to a cold contingency QMGR
>(define/alter/delete statements) so that it can
>be 'synched' to a PROD QMGR the next time the
>QMGR is started. This is very much like the
>capability that exists in z/OS via the CSQINP1/CSQINP2 ddcards
>Business justification: Provides WMQ Admins the
>capability to keep cold contingency QMGRs
>'in-synch' with current PROD QMGRs, from an
>object specification perspective. Providing
>the flag/switch and associated filename would
>allow the file of MQSC commands to be run at
>strmqm time, but before the QMGR was made
>available for application or channel connections.
>This could be implemented in much the same way
>that Default objects were once defined to the QMGR at strmqm time.
>Link to Vote:
><http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=39586>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=39586
>
>
>Cheers,
> Art
>
>National IT Services
>Arthur Schanz
>Distributed Computing Spec
>Messaging and File Transfer
>701 East Byrd Street
>Richmond, VA 23219
>
>Email: <mailto:Arthur.Schanz-***@public.gmane.org>Arthur.Schanz-***@public.gmane.org
>
>National IT Green Logo
>
>CertWS_color
>
>
>----------
><http://listserv.meduniwien.ac.at/archives/mqser-l.html>List
>Archive -
><http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>Manage
>Your List Settings -
><mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>Unsubscribe
>
>
>Instructions for managing your mailing list
>subscription are provided in the Listserv
>General Users Guide available at
><http://www.lsoft.com/resources/manuals.asp>http://www.lsoft.com
>
>
>
>----------
><http://listserv.meduniwien.ac.at/archives/mqser-l.html>List
>Archive -
><http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>Manage
>Your List Settings -
><mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>Unsubscribe
>
>
>Instructions for managing your mailing list
>subscription are provided in the Listserv
>General Users Guide available at
><http://www.lsoft.com/resources/manuals.asp>http://www.lsoft.com
>
>
>----------
><http://listserv.meduniwien.ac.at/archives/mqser-l.html>List
>Archive -
><http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>Manage
>Your List Settings -
><mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>Unsubscribe
>
>
>Instructions for managing your mailing list
>subscription are provided in the Listserv
>General Users Guide available at
><http://www.lsoft.com/resources/manuals.asp>http://www.lsoft.com
>
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
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