I am used to dumping objects from a queue manager without system objects.
But now I have to use dmpmqcfg and I cant find a flag to remove those system objects from output.
MQ version is 7.5.0.1
Command I use now : dmpmqcfg -m SMQ -t all -x object
Possible flags : c:\> dmpmqcfg -h
Usage: dmpmqcfg [-m QMgrName] [-n ObjName] [-t ObjType]
[-x ExportType] [-o Format] [-a] [-z]
[-s MsgSeqNo] [-q RplQName] [-r RmtQMgrName]
[-c default|-c DEFINE CHANNEL..]
-m Queue manager name.
-n Object name or a generic object name.
-t Object type:
all, authinfo, channel, clntconn, comminfo, listener,
namelist, process, queue, qmgr, service, topic.
-x Export type:
all, object, authrec, chlauth, sub.
-o Format: mqsc, 1line, setmqaut, grtmqmaut.
-a Dump all attributes.
-z Suppress warnings.
-s Reset channel message sequence number
-q Reply to queue name, default SYSTEM.DEFAULT.MODEL.QUEUE
-r Remote queue manager name (queued mode)
-c Client connection:
default, DEFINE CHANNEL(chlname) CHLTYPE(CLNTCONN) ...
The saveqmgr command was a SupportPac that was maintained outside of the MQ Development lab and with close interaction with the MQ User community through MQSeries.net and the Vienna MQ List Server. Though it was for many years the only way to get a full backup of the queue manger's configuration files, it was never a supported component of the product.
The dmpmqcfg command is a fully supported method of backing up the full configuration of the queue manager, maintained out of the MQ Dev lab. It's requirements were developed in close communication with the customers participating in the Early Access Program (effectively MQ's Beta program). Though there is some overlap with saveqmgr it was not intended to be a direct replacement for that program. Specifically, since it is primarily intended to create a complete backup it lacks the ability to omit the SYSTEM.* objects.
You can simulate the same thing by using the -o 1line option and filtering out the SYSTEM.* objects.
Windows:
dmpmqcfg -m [qmgr] -o 1line | findstr /V "('SYSTEM"
UNIX/Linux:
dmpmqcfg -m [qmgr] -o 1line | grep -v "('SYSTEM"
Note that this filters out any line containing ('SYSTEM, even if that string is in a description or other field. If you wanted to be completely sure you got only objects named SYSTEM.* you would need to be more explicit and use multiple filters like so:
dmpmqcfg -m [qmgr] -o 1line | grep -v " CHANNEL('SYSTEM" | grep -v " QLOCAL('SYSTEM" | grep -v " QALIAS('SYSTEM"...
I leave it as an exercise to the reader to add all the possible object types to filter onto the end of that command pipeline.
Note that you do not want to filter out AUTHREC definitions that contain PROFILE('SYSTEM because these are needed to control access to model queues, the command queue, etc.
It is unfortunate that the MQ Dev team does not work as closely with the MQ Community as the SupportPac authors, however there is good reason for this. Note that SupportPacs are not always kept up to date and their maintenance and bug-fix are performed on an as-available basis. While in general the SupportPac authors are very good at keeping up they have no enforced deadline.
Contrast this with the MQ Dev Lab's process for creating a new component like dmpmqcfg. Their use of the Early Access Program (EAP) formalizes the requirements and tracks them to ensure that the component is released on time with the rest of the product, translated into many languages, documented in the manual, etc. The issue isn't so much that the dev lab isn't listening to our requirements as much as it is getting companies to join the EAP, and then once there to dedicate time to testing and providing feedback in a timely manner.
However, as Jon stated, submitting a requirement on a released component is possible through the Request For Enhancement (RFE) process. What Jon's answer left out is that in order to be considered and prioritized, the RFE must either have a really compelling business case, or else receive some votes and/or comments. There are some strategies to help get the RFE passed:
Don't split votes between RFEs. Before submitting one, search (browse really because the RFE search functionality sucks) for similar ones. If you find one that is close, comment on it to clarify your requirement rather than submitting a new one, and vote it up.
Discuss your proposal with the communities at the Listserv and/or MQSeries.net. If someone has an RFE that you missed, you'll hear about it here. You will also get an idea of how much support you might get for an RFE, or if the thing you want is an anti-pattern (looks GREAT until you do it, at which point it becomes dangerous in unanticipated ways - for example using DNS names in CHLAUTH records).
If you do submit an RFE post a note to the Listserv and/or to MQSeries.net to let the community know that you have submitted it and ask them to comment and vote it up.
If you find an existing RFE or submit your own, update your question or add a comment to it to track progress. Stack Overflow is supposed to evolve over time and if the problem you face is solved, capturing that here will help others. And some of us here on SO will vote for it if we find the link in your follow-up.
Hope that helps. My requirement for dmpmqcfg was always that it duplicated the functionality of saveqmgr, plus a few more things. I'd vote for this.
Related
On the top right corner of the SSH-in-Browser terminal for a Compute Engine, there is a download button. What I'd like to do is trigger this functionality directly from the VM terminal.
Why?
Every once in a while, I'm requested to make a copy of a database for any reason. So far, this requires me to 1) Make the dumps, 2) Zip the dumps, 3) Download the zip and 4) Send it to whoever requested it. I decided to automate this since its becoming more frequent.
So far, 1 and 2 are done, and I would usually leave it at that, but I'm wondering if I can just trigger the "downloading function" from the script that handles the dumps and zipping, just to save me a few clicks and writing down the path. For example:
#!/bin/bash
here=$(pwd)
mkdir /home/me/back
mkdir /home/me/back/data
/home/me/saveTables $1
/home/me/saveRecords $1
cd /home/me/back
zip -r $here/$1.zip ./* > /dev/null
sudo rm -dr /home/me/back
# and then download it with something like
# 'gcpdk' is made up just for example purposes
gcpdk --download $here/$1.sql
Is this possible from the SSH-in-Browser at all? So far I'm guessing that the download function is not accessible from within the VM terminal, but I have not found documentation about the downloads themselves yet, so I can't tell. Or perhaps this is something I should do with a different tool?
By the way, I can't copy files to Cloud Storage (Lack the permissions) so at least for now, that is not an option.
Any help, link or confirmation of whether or not this is doable is welcome.
And just to be extra sure: This is not something critical. Its just me being lazy. Cheers!
The livestream doesn't end (for now, and if ended, I think will be erased of YouTube, that's my reason to download), actually, the video is still in transmission, you know, like the streams of the NASA or streams of channels news. The detail is that the transmission lasts about 10-11 hours, and the transmission has lasted about 3 days. So it was a matter of time before the first concerts were no longer available to watch on the broadcast.
This is the video: https://www.youtube.com/watch?v=rE6QI0ywr0c
I want to download some concerts, but the things that I wanted, are disappearing with the passing of time. Right now, I'm only interested in the Disclosure concert. His concert starts at approximately -3:38:12. I mention it in case someone wants to help me.
I was trying this command, but only appear a text that i don't understand (I'll post it in the comments, all the images with his info). The command is this → yt-dlp.exe -f (bestvideo+bestaudio/best) "link" --postprocessor-args "ffmpeg:-ss 00:00:00 -to 00:00:00" -o "%(title)s_method1.%(ext)s"
The idea of that command emerged on this ideas
https://www.reddit.com/r/youtubedl/wiki/howdoidownloadpartsofavideo/
https://github.com/yt-dlp/yt-dlp/issues/686
Also, I was trying to do this How do you use youtube-dl to download live streams (that are live)?, but I can't get the HLS m3u8 URL in Chrome and Chrome Dev (yes, I go to F12 (Chrome Developer Tools) - Network and I write m3u8, I didn't find anything.
I should mention that I don't have extensive knowledge on codes and yt-dlp. I only learned the necessary to download videos, you know, yt-dlp.exe -F (link) and then yt-dlp.exe -f (numbers of resolution and audio) (link).
So if you recommend any programs or commands, please let me know as precisely as possible.
Any new info I'm gonna update in the comments.
PS: sorry for my english
I have a Fabric fabfile.py with a long list of commands (and growing). When I go fab -l I can't see the top of the command list. Grouping the commands under headers wouldn't make the list any shorter but it would make skimming the list easier - rather like the output of Django's ./manage.py help command. Has anyone solved this problem?
Using Fabric's "new style" tasks, you can take advantage of namespaces. When you list your tasks, you can provide the -F (--list-format) argument, providing nested as the value, which will list the available tasks in a nested fashion, by namespace, the appearance of such is documented here.
Fabric's "nested" task listing isn't quite as neat looking as Django's management command separation that lists commands by app in a very neat fashion, but it's a start.
Trying to figure out how to have a .procmailrc rule that tosses all mail that is in reply to previously seen mail. Using maildir, and would like the rule to cover messages in either cur/ or new/...
Should I have the procmailrc parse all the files? Or should I have a rule that extracts message id headers, dump those into a file, and parse that?
I can't just check for and toss anything with the in-reply-to header, as if it's a reply to something that this address hasn't seen yet, it needs to be accepted.
You need to collect a cache of Message-Id:s from incoming messages:
:0c:
| formail -zxMessage-Id: >>msgid.txt
Then check the In-Reply-To: against this cache (probably earlier in your .procmailrc so you can filter spam before adding a Message-Id to the cache);
:0
* ? formail -zxIn-Reply-To: | fgrep -f msgid.txt -
./whitelisted
See also the examples of formail -D for comparison. Perhaps you could massage things into a form where you could actually use formail -D as the back end (replace Message-Id: with From: before adding to the cache; split the In-Reply-To: and perform a similar substitution on each message-id). formail can maintain a constant-size LRU cache, whereas the fgrep file will just keep on growing indefinitely (though in this case, perhaps that's precisely what you want).
When you initially set this up, you probably want to collect a cache from messages you have in cur and new already, but after that, you should not need to refer to those messages again from your recipe. (If your inbox is anything like mine, real-time grepping of the whole inbox would be quite infeasible.)
If you want a big cache, replacing a plain-text file with SQLite or something would probably be worth looking into. Actually, by the time a proper database is really worth the effort, you might want a real database rather than SQLite, but I only have vague ideas about the scalability of different database engines for this sort of thing, and no practical experience.
Note that -- unless you have an unusual set-up -- your outgoing Message-Id:s will not be added to the cache; for this to be actually useful, perhaps you should arrange for that to happen somehow, and/or establish a pattern which matches your outgoing Message-Id:s (ideally with no false positives, and certainly no false negatives. If you have switched MUAs in the past, you should perhaps look for patterns for old messages of yours separately, if you want full coverage).
Caution: untested, and I'm probably quite rusty.
There is a directory where a buddy adds new builds of a product.
The listing looks like this
$ ls path-to-dir/
01
02
03
04
$
where the numbers listed are not files but names of directories containing the builds.
I have to manually go and check every time whether there is a new build or not. I am looking for a way to automate this, so that the program can send an email to some people (including me) whenever path-to-dir/ is updated.
Do we have an already existing utility or a Perl library that does this?
inotify.h does something similar, but it is not supported on my kernel (2.6.9).
I think there can be an easy way in Perl.
Do you think this will work?
Keep running a loop in Perl that does a ls path-to-dir/ after, say, every 5 minutes and stores the results in an array. If it finds that the new results are different from the old results, it sends out an email using Mail or Email.
If you're going for perl, I'm sure the excellent File::ChangeNotify module will be extremely helpful to you. It can use inotify, if available, but also all sorts of other file-watching mechanisms provided by different platforms. Also, as a fallback, it has its own watching implementation, which works on every platform, but is less efficient than the specialized ones.
Checking for different ls output would send a message even when something is deleted or renamed in the directory. You could instead look for files with an mtime newer than the last message sent.
Here's an example in bash, you can run it every 5 minutes:
now=`date +%Y%m%d%H%M.%S`
if [ ! -f "/path/to/cache/file" ] || [ -n "`find /path/to/build/dir -type f -newer /path/to/cache/file`" ]
then
touch /path/to/cache/file -t "$now"
sendmail -t <<< "
To: aaa#bbb.ccc
To: xxx#yyy.zzz
Subject: New files found
Dear friend,
I have found a couple of new files.
"
fi
Can't it be a simple shell script?
while :;do
n = 'ls -al path-to-dir | wc -l'
if n -gt old_n
# your Mail code here; set old_n=n also
fi
sleep 5
done
Yes, a loop in Perl as described would do the trick.
You could keep a track of when the directory was last modified; if it hasn't changed, there isn't a new build. If it has changed, an old build might have been deleted or a new one added. You probably don't want to send alerts when old builds are removed; it is crucial that the email is sent when new builds are added.
However, I think that msw has the right idea; the build should notify when it has completed the copy out to the new directory. It should be a script that can be changed to notify the correct list of people - rather than a hard-wired list of names in the makefile or whatever other build control system you use.
you could use dnotify it is the predecessor of inotify and should be available on your kernel. It is still supported by newer kernels.