On Wed, 2 Dec 2020 16:43:11 -0800, Charles Mills wrote:
>This code has been changed since I last compiled it on Z but I don't think I
>changed that reference. It appears that PATH_MAX went away somewhere between
>V2R2 and V2R4. I see some comments in limits.h that are consistent with that.
>
This code has been changed since I last compiled it on Z but I don't think I
changed that reference. It appears that PATH_MAX went away somewhere between
V2R2 and V2R4. I see some comments in limits.h that are consistent with that.
I picked up _POSIX_PATH_MAX from limits.h. I am running
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.aopm000/av00120.htm
If a message indicates a RACF® or SAF error (such as, message EDC5164I):
- Make sure the user ID that starts Infoprint Server is a valid z/OS®
UNIX user ID. The user ID must have an OMVS segment,
You should be running QuickRef -
* Text Below Copyright (c) 2020, IBM
*
*AOP047Eexception-information *
Explanation: This message is displayed with message AOP004E and contains
diagnostic information that might be helpful in solving the
On Wed, 2 Dec 2020 15:16:10 -0800, Charles Mills wrote:
>I have some code that compiles both under Windows Visual Studio and z/OS
>XLC.
>
>In Windows the maximum length of a file path is defined by _MAX_PATH and
>__MAX_PATH (I guess MS thinks two macros are better than one).
>
>What is the
I have some code that compiles both under Windows Visual Studio and z/OS
XLC.
In Windows the maximum length of a file path is defined by _MAX_PATH and
__MAX_PATH (I guess MS thinks two macros are better than one).
What is the equivalent macro for XLC? Failing that, what *is* the maximum
path
I'm working on upgrading a client from 1.13 to 2.20 to start with. They use
INFOPRINT SERVER.
When trying to start AOPSTART I'm getting the following. Tried with IBM support
and they said you are out of support.
Does someone know where I can find the meaning of the errno2 for the RACF
error?
It's education!
I never knew what Paste Window did.
Thanks!
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Brennan
Sent: Wednesday, December 2, 2020 1:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Extraneous blanks
Like Gil said, I'm not sure that will work in this case. My theory is
that the two SDSF fields are simply concatenated together, including any
trailing blanks, when they arrive at the host. So splitting lines
without splitting words would introduce more blanks that would interfere
with the
On Wed, 2 Dec 2020 20:45:49 +, Bloomfield, Garth wrote:
>In PCOMM V14 in SETTINGS there is an EDIT PASTE option ‘don’t split words’
>checkbox that allows a long line to be successfully pasted into the SDSF
>command line.
>
What does ‘don’t split words’ do if the text to be pasted can be
In PCOMM V14 in SETTINGS there is an EDIT PASTE option ‘don’t split words’
checkbox that allows a long line to be successfully pasted into the SDSF
command line.
Cheers
Garth
>Date:Tue, 1 Dec 2020 20:06:47 -0800
>From:Tom Brennan
>Subject: Re: Extraneous blanks in SDSF
Thanks to everyone for the xlnt suggestions.
Much appreciated,
Mike
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mike Hochee
Sent: Wednesday, December 2, 2020 2:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Invoking IFASMFDP
Your post reminded me of a program I wrote that would first check and
set a flag as to whether it was running from TSO CP, JOB, or STC. The
input parms would be different for TSO of course, and I think the
JOB/STC difference was so I'd know to put the output in SYSPRINT or a
WTO. Kind of
> IBM's excuse
Is an excuse after the fact, not a considered design decision. That's why I
coined "Broken As Designed (BAD)".
> is that protects the user against unwittingly entering more than 1023
> characters
Except that it doesn't. Making the field shorter protects against excessive
On Wed, 2 Dec 2020 16:34:27 +, Seymour J Metz wrote:
>> In some cases, such as 3.17, ISPF puts a visible pillarbox around the 80
>> columns, marking it with "|".
>
>In those cases you're dealing with two input fields; you'd get the same insert
>behavior if the input fields and the
The IBM recommended way to run IFASMFDP is via the IEFU29 exit
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae400/ieae40040.htm
Joe
On Wed, Dec 2, 2020 at 1:25 AM Mike Hochee wrote:
> Wondering if anyone has attempted to invoke the SMF IFASMFDP utility
>
I've seen messages about programs that won't work properly if you LINK to them;
I consider that bad form, just as I consider reentrant but not refreshable to
be bad form. Fortunately, IFASMFDP is not such an offender.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
When you invoke it from JCL you are invoking it with LINK or something
similar. Any program that runs from PGM= should run from LINK, CALL or
ATTACH provided the usual "MVS" linkage convention is honored by the
invoker. (Yes, it would be technically possible, but relatively unlikely,
for a program
> In some cases, such as 3.17, ISPF puts a visible pillarbox around the 80
> columns, marking it with "|".
In those cases you're dealing with two input fields; you'd get the same insert
behavior if the input fields and the intervening output fields were in the same
line.
> Supporting the
Of course. Do it all the time. Look in the CBT tape for program SMFDUMP.
Matthew
On Wed, 2 Dec 2020 07:25:02 +, Mike Hochee wrote:
>Wondering if anyone has attempted to invoke the SMF IFASMFDP utility (handles
>dumping and clearing of SMF data set logs, digital signature validation,
In general, you can invoke any utility, but some require that you be APF
authorized. In the basic form, R1 points to a one-word PLIST with the VL (high
bet) set, and the single parameter contains a halfword length followed by a
parameter string. Most utilities document and support additional
What are the maximum block sizes of the two different device types?
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/r2259.htm
If the source tape has actual blocks bigger than the maximum blocksize
of the destination tape, it cannot be copied.
On Wed, Dec 2, 2020
Hello,
We are migrating data from 3592 to VTL.
The 3592 and VTL are both defined on the Mainframe as 3590 device.
The 3592 tape media has IDCAMS REPRO and DFDSS DUMP datasets.
The REPRO dataset could be copied and moved to VTL.
But, DFDSS DUMP datasets copy failed with copydump.
*IEF233A M
23 matches
Mail list logo
