Is there a 64encode EXEC (not pipe stage) hanging around anywhere,
or do I need to write my own?
Thanks,
Shimon
Do you mean a base64 encode? Or 64 bit encode?
Les
Shimon Lebowitz wrote:
Is there a 64encode EXEC (not pipe stage) hanging around anywhere,
or do I need to write my own?
Thanks,
Shimon
Base64 Encode, like the 64encode pipe stage.
Thanks!
On Mon, Dec 27, 2010 at 12:44 PM, Les Koehler vmr...@tampabay.rr.comwrote:
Do you mean a base64 encode? Or 64 bit encode?
Les
Shimon Lebowitz wrote:
Is there a 64encode EXEC (not pipe stage) hanging around anywhere,
or do I need to
Why is a PIPE stage not good? You can wrap an exec around it, or
...anything possible with CALLPIPE/ADDPIPE
2010/12/27 Shimon Lebowitz shim...@iname.com
Base64 Encode, like the 64encode pipe stage.
Thanks!
On Mon, Dec 27, 2010 at 12:44 PM, Les Koehler vmr...@tampabay.rr.comwrote:
Do you
Ummm... gulp... because it needs to run on the OtherSystem.
(Please don't tell me that pipes are available there too. We spent months
trying to
verify that claim and it just wasn't possible, except as a special bid or
something like that,
at what was considered here a totally insane price).
So,
Depends on what Other System you mean, exactly. There is Pipelines for
MVS (TSO), but I am guessing that YOU of all people KNOW that. So are you
talking about Unix/Linux? or maybe Windows?
You could extract the logic from 64ENCODE REXX and make REXX from it.
-- R;
On Mon, Dec 27, 2010
z Other System... z/OS
Yes, I was going to mimic the pipe stage logic, but just wanted to see if I
could avoid reinventing a wheel.
Shimon
On Mon, Dec 27, 2010 at 4:25 PM, Richard Troth r...@casita.net wrote:
Depends on what Other System you mean, exactly. There is Pipelines for
MVS (TSO),
Just closing the loop on this thread... I did open a Sev 3 (should have
been Sev 4) PMR for this issue on November 20, 2010, pasting pretty much
the same text as posted earler to justify the W-level (Warning) message
type on this mesesage. The PMR response was received today, December 27,
Which begs the question, what are the criteria for determining the level of a
message?
I would think that something that could cause potentially serious system
problems, like getting an incorrect CP OWNED volume, would warrant an E. On the
other hand, if the duplicated volser is for a volume
I suspect the developer is being somewhat influenced by the z/OS
convention which simply warns you.
But, at the same time, it halts the IPL and also gives you the option to
select the appropriate duplicate.
z/VM does not have the select option so if IBM insists on retaining the
W class for
My thanks to Sir Rob, who kindly supplied the code for a rexx exec to do
this.
Thank you!
Shimon
On Mon, Dec 27, 2010 at 1:10 PM, Shimon Lebowitz shim...@iname.com wrote:
Base64 Encode, like the 64encode pipe stage.
Thanks!
On Mon, Dec 27, 2010 at 12:44 PM, Les Koehler
A dupkucate volser is not always an error, it can be, the system doesn't
know. So a W is right.
Better would indeed be an A, and have the operator decide what to do.
2010/12/27 George Henke/NYLIC george_he...@newyorklife.com
I suspect the developer is being somewhat influenced by the z/OS
On 12/27/10 11:18 AM, Mike Walter mike.wal...@hewitt.com wrote:
The response was:
The developer has decided not to change the message type for this messag
e.
That's a totally BS answer. Call them back and challenge it.
There should at least be a justification for why the developer refused to
On Mon, 27 Dec 2010 19:47:24 +0200, Shimon Lebowitz shim...@iname.com
wrote:
My thanks to Sir Rob, who kindly supplied the code for a rexx exec to do
this.
Thank you!
Shimon
On Mon, Dec 27, 2010 at 1:10 PM, Shimon Lebowitz shim...@iname.com
wrote:
Base64 Encode, like the 64encode pipe
14 matches
Mail list logo