You, sir, are a god.
I've been kicking IBM ever since SMAPI came out for something like this. Thanks.
Can you port if to CMS as well? Please?
-- db
On Feb 11, 2011, at 23:15, "Leland Lucius" wrote:
> Some of you folks might find this useful. It implements all but 1 of
> the SMAPI functi
Some of you folks might find this useful. It implements all but 1 of
the SMAPI functions in a single bash script. In addition, it supports
TCP/IP via bash's builtin /dev/tcp support and IUCV via the embedded
smiucv program that you can build using "smcli smiucv".
Documentation is slim, so yo
I do not think turning the virtualization engine (CP) into a scheduler (I'm
talking command/job scheduler here folks) is a good idea. CMS was designed
specifically to be able to 'automate' and issue CP commands as well as CMS
ones (which includes a filesystem, commands to read/write files, access
Actually, you are both right.
There is a need for both.
If I am a large mainframe shop, who cares, of course I'll buy the OM or
whatever, get the timer pop and all the other goodies as well, its all
chump change anyway.
But what if I am a small to medium size shop with a limited budget?
Must
On Friday, 02/11/2011 at 04:24 EST, Mike Walter
wrote:
> See? Alan's reply is precisely why I thought "it seemed prudent to run
it
> past others for wider consideration."
>
> I suspect that there will be many new LoZ (a new "Linux on System Z"
> acronym seen recently, and MUCH less to type) cu
See? Alan's reply is precisely why I thought "it seemed prudent to run it
past others for wider consideration."
I suspect that there will be many new LoZ (a new "Linux on System Z"
acronym seen recently, and MUCH less to type) customers who will not
purchase IBM OM, or CA VM:Operator, but whom
On Friday, 02/11/2011 at 03:10 EST, Martin Zimelis
wrote:
> David's comment is a perfect example of the reason Rich is exactly
right: The
> requirement should specify the effect you want, not the method of
> implementation.
>
> And don't forget to include the business case for the enhancemen
I will be out of the office starting 11/02/2011 and will not return until
15/02/2011.
On Paternity leave ! If urgent please contact TST MF front shop on 52580.
Maybe a good idea, but I doubt it will fly..
With the advent of the FOR command it is simple to put "CP FOR abc CMD CLOSE
CONS" in a WAKEUP file.
But if they did buy it how about an enhancement to XAUTOLOG with AT
hh:mm:ss?
Come to think of it a full date would be better yet.. AT mm/dd/yy hh:mm:s
David's comment is a perfect example of the reason Rich is exactly right:
The requirement should specify the effect you want, not the method of
implementation.
And don't forget to include the business case for the enhancement in the
requirement.
Marty
Those of us who already have ways to do it would need to convert :-(
Actually, having a built-in way to do it would relieve us of the kludges that
we have had to construct and would be one less item that new employees would
have to learn or relearn. It is something that has been missing since th
#2, but for clarity:
A) hh:mm:ss is based on CP time, or the virtual TOD in the virtual machine?
B) what happens in a SSI configuration if a virtual machine moves to a new CP
with a different clock?
If only #2 were implemented, the new SPOOL command could be entered in the
directory entry of s
It's probably best not to dictate how *you* want it implemented. Be very specific in
the wording of the requirement and they will figure it out.
On 02/11/2011 01:45 PM, Mike Walter wrote:
Almost every z/VM customer is forced to devise a method to close service virtual
machine consoles at mid
Almost every z/VM customer is forced to devise a method to close service
virtual machine consoles at midnight, or at some time of day. z/VM
old-timers have done this for ages, but new z/VM customers don't often
have the skills necessary to implement automated closures - or even
recognize the a
14 matches
Mail list logo
